• Deny by default. The policy gate refuses an action unless a policy permits it. A request with no matching permit is denied, not allowed.
• Fail closed. When a check cannot be completed safely, the safe outcome is denial or a loud error, never a silent allow. See docs/NEGATIVE-TESTING.md for the verified failure modes.
• Post-quantum from day one. Every signature, in the audit chain and in every capability token, is ML-DSA-65 hybrid with Ed25519. A hybrid verifier rejects a PQ-only payload and a PQ-only verifier rejects a hybrid one.
• The center is authoritative. A node's self-report is never trusted on its own. The control plane re-verifies every pushed audit chain against the node's pinned public key, and that verification is the one shown.
• Self-hosted only. There is no SaaS and no hosted service. Data and audit never leave the enterprise.

• The enrollment token is a bootstrap secret. Presenting it returns a node token scoped to the node endpoints only. It cannot reach any admin endpoint.
• The admin token gates the CLI, the console, and the admin API. It is the strongest credential. Rotate it by setting a new [control].admin_token.
• A client-auth key authorizes model traffic through a gateway. It is shown once at mint time and never stored in the clear; only a short prefix is ever displayed.
• A capability token is a post-quantum bearer credential for an agent. It is signed by the issuer, scoped, time-bounded, and revocable. The grant is the ceiling; a holder can attenuate it, only narrowing, and the central policy still gates each action.

Every governance decision lands in a hash-linked, signed audit chain. Each entry is signed under the producing node's key, and the entries are linked so that removing or reordering one breaks verification. The control plane re-verifies each pushed chain independently. Tampering is detected: a single changed byte, a removed entry, or a reordered entry all fail verification, and the node is marked not verified rather than silently accepted.

Signed evidence bundles and signed compliance bundles carry the same property. A forged status or a corrupted embedded chain breaks the top-level signature.

A token verification checks, in order: the grant signature against the issuer bundle, each attenuation-layer signature against the subject, that layers only narrow, and the validity window. Then the guard checks revocation and scope, and finally runs the central policy. Any failure denies the action and records it. An expired token, a revoked token, a token signed by the wrong issuer, an out-of-scope action, and a token whose bytes do not match its signature are all denied.

Report privately through this repository's GitHub Security Advisories (the Security tab, Report a vulnerability). Please do not open a public issue for a security report. Include the version from niyam bom, the affected component, and a reproduction.

• Change every CHANGE_ME_* token before any real use.
• Inject the admin, enrollment, and provider secrets by environment or a secret store, not in config files.
• Run nodes non-root. The provided container image already does.
• Back up the control-plane store, the issuer keypair, and each node's audit key.
• Keep the trust root coherent on every dependency bump with scripts/check-coherence.sh.
• Terminate TLS in front of the listeners, or put them behind a mesh. The binaries speak plain HTTP by design, to be fronted.