Security and TrustIndex

Security and trust on this platform rests on one idea: every component holds a verified, scoped credential it must present to act — not an inherited grant of trust. That discipline shows up across five areas: who's known to the system and what they're allowed to do, how a reader independently verifies a record hasn't been altered, what contains a compromise once one occurs, how data is handled and kept private, and the controls that keep code honest from a contributor's machine to production.

A diligence reader's real question is can this be trusted? An engineer's is usually narrower — how does capability-based access control actually work? Both start below.

Start here: Capability-based security — the access-control model the whole category is named for: components hold verified cryptographic tokens instead of ambient privilege. One software layer implements it today; kernel-level enforcement is planned.

Where to start

Fourteen articles cover how the platform is protected and how its records are verified. These five are the load-bearing ones: the posture map, the identity model everything else assumes, the primitive underneath it, the one-way flow rule, and the path code takes to reach a customer.

• Security overview — The whole posture in one page: hardware isolation, the Diode command-flow rule, the AI boundary, and the WORM audit ledger.
• Machine-based authorization — Access is granted to a device's key, not a person's password. The most-referenced article in this knowledge base.
• Capability-based security — The primitive under that model: an unforgeable, scoped token in place of ambient privilege, with an honest account of what one software layer enforces today versus what the kernel is planned to enforce.
• Diode standard — Command and data flow one way only, from authority to subject — and a clear statement that several mechanisms follow it while no component yet enforces it as a named standard.
• Five-stage supply chain — How a contributor's commit reaches a customer deployment across three repository tiers, and what review does and does not exist along the way.

Posture overview

One article that crosses all five areas below, written for a reader evaluating the platform as a whole rather than looking up a single mechanism.

• Security overview — The platform's security posture: capability-based hardware isolation, the Diode command-flow standard, the Doorman AI boundary, and the WORM audit ledger.

Identity and permissions

Who is known to the system, how a device proves it, and what it's allowed to do.

• Capability-based security — Capability-based security grants each component an unforgeable, scoped token it must present to act, replacing ambient privilege. One software layer implements it today; kernel-level enforcement is planned.
• Machine-based authorization — Access is granted to a device's key rather than to a person's password. A short-code pairing ceremony binds an SSH key fingerprint to a user record after operator approval, with no password stored anywhere.
• Personnel and permissions — Four permission tiers, P1 through P4, are implemented as a typed enumeration and served over an HTTP endpoint that reads a workspace configuration file. That file currently declares no contributors, so the endpoint resolves nothing for any real user.
• Identity ledger schema design — Three record types — Person, Anchor, Claim — separate who is known from how they were observed and what was asserted. Identity is a UUIDv5 of a lowercased email, so the same input always yields the same identifier.
• Verification surveyor — A command-line tool that requires a person to confirm each extracted identity against external evidence before it is promoted from a queue to a verified record, throttled to ten confirmations per day.

Cryptographic verification

How a reader independently checks that a record hasn't been altered.

• Cryptographic payload attestation — Cryptographic payload attestation lets a reader recompute a hash of published content and compare it against a published value. Unwired, cosmetic prototypes exist in a few release templates; the knowledge wiki does not offer it.
• Cryptographic ledgers — An append-only log where each entry's hash covers the one before it, closed by Ed25519-signed checkpoints and anchored monthly in a public transparency log. Implemented as a linear chain, one flat file per tenant.

Isolation boundaries

What contains a compromise once one occurs. Thin relative to the category's own scope — see the tenant isolation and VM tenant articles in Infrastructure for the commercially load-bearing case, which isn't yet cross-referenced from here.

• seL4 capability topology — In an seL4 system the security policy is the shape of the capability graph established at boot, not a runtime policy layer. First-party work is nine bare-metal test binaries; no platform service runs on seL4.
• Diode standard — The Diode Standard is the design rule that command and data flow in one direction only, from authority to subject. Several real mechanisms follow it; no component enforces it as a named standard.
• Genesis protocol — The Genesis Protocol is the designed fleet-bootstrapping sequence for os-infrastructure nodes: ship with no prior configuration, boot on any network, and reach a secure, claimable state with no control-plane contact required.

Data handling and privacy

• Data sovereignty and zero-state telemetry — Zero-state telemetry is the intended posture of measuring site usage without retaining identifying data. The pipeline running today writes full unmasked IP addresses to a plaintext file for up to a year; masking is not implemented.

Supply-chain controls

Keeping code honest from a contributor's machine to production.

• Five-stage supply chain — The path from a contributor's commit to a customer deployment crosses three repository tiers and two organisations, gated by a heavily guarded promotion script. There is no pull request and no second-party review.
• Pre-commit defense in depth — Four independent git hooks run before a commit is recorded: a helper-only gate, a data-path block, a staged-content secret and size scan, and an author-identity check. Every bypass is logged.

Several articles linked here describe planned, not-yet-built mechanisms and are hedged in their own text. This page is an orientation, not a compliance attestation.

See also

• Architecture — how the platform is put together
• Governance and Standards — what was decided and why it is compliant
• Infrastructure — the deployed storage and ledger infrastructure these mechanisms protect