Security model and limits
Outcome: Operate a development appliance without mistaking a passed test, signed USB image or authenticated Panel for a fully qualified production deployment.
What each layer is designed to enforce
| Layer | Trust boundary and observable behavior | Limits / operator action |
|---|---|---|
| UEFI boot | The image is signed with a development certificate. Unknown keys, altered kernel material and rollback tampering were rejected in VM qualification. | Certificate must be appended to firmware
db; development signing is not production
certification. Physical Secure Boot qualification remains open. |
| LexiKernel | Requires active IOMMU for DMA isolation; verifies hardening state (SMEP, SMAP, write protection, NX), checks supported boot policy and refuses unknown hardware revisions. | Kernel and native GPU features have not all run on physical hardware; missing IOMMU is a refusal, not a warning. |
| LexiOS | Boot-time firewall and verified-image executable admission; signed update/rollback decisions and self-test reporting. | Read the self-test and unavailable state; don't infer every service is implemented on both kernels. |
| LexiPanel | Authenticated sessions, scrypt passwords, role permissions and scoped API keys; origin/CSRF controls on writes, rate limiting, audit records and content-security restrictions. | First-boot setup code is optional and absent by default, leaving a first-visitor enrollment risk until an administrator is created. |
| Files and tool access | Home-rooted file manager, protected system folders, sealed password vault and a restricted terminal. Agent execution passes through a policy gate with human approval for selected tools. | Privileged actions require administrator/operator authorization; never assume a model response is itself an authorization. |
| Model service | Bounded HTTP/model parsing, verified admission options and refusal of unsafe remote cleartext listeners. | Verify model hashes and any exposed API transport; model content and output are not guaranteed trustworthy. |
| Updates and recovery | Signed Ed25519 manifests, bounded inputs, rollback protection, backups and controlled restart/restore paths. | Store backups separately; release media still needs its own validation and qualification. |
| Diagnostics | Failed Panel requests and crash evidence are recorded for support diagnosis. | Debug kits exclude credentials by design; review logs before sharing any diagnostic bundle. |
Local, authenticated operation: safe sequence
- Verify the archive SHA-256 and choose the right USB target; see Install from USB.
- If using Secure Boot, append only the development certificate and verify the existing firmware trust entries remain; see Secure Boot. A disk-encryption recovery key may be needed.
- Connect the machine only to a trusted, controlled network during enrollment. The current UI has no required setup code by default: the first visitor can create the administrator account. Secure this page immediately; do not publish it to a shared or untrusted network.
- Choose separate strong root and Panel administrator credentials. Sign in, review Access roles, token scopes and expiry; revoke unused tokens and avoid using the admin terminal for routine model tasks.
- Review network and firewall exposure. The USB appliance serves the Panel at port 8090 on the available network; a developer build has different listener defaults. Do not copy development listen settings onto an internet-facing machine.
- Prefer verified model sources and hash checks; turn on verified-only admission and consider load-time rehashing when tamper assurance outweighs startup cost.
- Before an update, test backup/recovery and inspect signing and rollback evidence. Do not bypass a signature or kernel-refusal message to get a device running.
Why fail-closed matters
- A model with a bad or missing required verification hash should not be admitted under verified-only policy. An unsafe hardware revision should be refused, not treated as compatible.
- A non-administrator must not be given administrator-only setup, terminal or system controls by changing the URL; authorization is enforced by the server, not simply by hiding buttons.
- An untrusted agent request is not a substitute for the human confirmation required by policy-gated tools.
- A revoked or expired scoped token must not be treated as a reusable administrator credential.
The supplied November 2026 source summary reports 308 of
375 crate roots forbidding unsafe and another
9 denying it; 161 of 3,906 Rust files contain
unsafe in bounded hardware/FFI areas. These are
source-audit indicators, not proofs of vulnerability
absence.
Known gaps and qualified claims
- The release key is a development key. VM Secure Boot and tamper refusals passed; booting this exact secure image on a physical Secure Boot PC has not yet been demonstrated in the supplied status.
- Default first-boot enrollment does not require a code. Treat the first-visitor window as a real exposure risk and finish setup on a trusted LAN before further operation.
- Native LexiKernel RDNA3 hardware operation is unproven, and an IOMMU-enabled VM is not physical AMD-hardware qualification.
- LexiKernel CPU/storage telemetry has known gaps and one reported intermittent browser freeze; do not treat absence of errors or absent metrics as full operational security validation.
- TLS support in the native runtime intentionally refuses older-than-1.2 TLS, TLS 1.2 without extended master secret, client certificates and encrypted private keys. These refusals are limits, not interchangeable authentication modes.
- Proprietary project README pricing and repository licence wording differ materially; Licence explains the need for a written permission grant.
Security-related controls
| Control | What it enforces / consequence |
|---|---|
Secure Boot db → Append |
Trusts this development image's owner certificate while retaining existing authorized certificates. |
| First boot → Complete first-boot setup | Creates initial privileged accounts; unconfigured access is time-sensitive. |
| First boot → setup code (opt-in) | Requires a locally supplied code only when configured; absence by default is an acknowledged gap. |
| Access → users / roles / API tokens | Limits who may operate routes and how long scoped credentials stay valid. |
| Models → verified-only / hash at load | Rejects unverified model admission when enabled, with extra load-time hashing cost if requested. |
| Network → firewall preview/apply/confirm/revert | Reviews network changes and can roll back unconfirmed operations; avoid locking out remote access. |
| Diagnostic bundle | Captures logs and failed requests; review it before transfer. |
See First Boot, Troubleshooting, Kernels and FAQ.