Five steps, no surprises.
A proposal goes in. A sealed allow or deny comes out, with the exact rules that produced it and a record you can verify years later.
Canonicalize the proposal
The structured proposal is rewritten into one stable form (sorted keys, normalized values) and hashed with SHA-256, so the same logical request always has the same identity.
Load the pinned policy
Policies are versioned and immutable once activated. The active policy is pinned by hash; if the file no longer matches its pin, every decision is denied until it is reviewed and re-pinned.
Evaluate, deterministically
Rules are applied in a fixed order. Deny takes precedence; anything not explicitly allowed is denied. The evaluator performs no network, clock, filesystem or environment access.
Seal and chain
The proposal hash, policy hash, decision and reasons are written to an append-only ledger. Each entry carries the hash of the one before it. An allow that cannot be recorded does not happen.
Anchor and replay
The ledger head is signed and committed to version control. Later, any decision can be replayed against its original policy version; signatures and the chain prove nothing was removed or rewritten.
Binary outcomes, explicit reasons.
The sealed outcome is always allow or deny. Escalation, approval and quarantine are dispositions on a deny, never a third answer.
| Situation | Outcome | Reason code (example) |
|---|---|---|
| Nothing in the policy allows the action | deny | DEFAULT_DENY |
| An explicit deny rule matches | deny | DENY_RULE_MATCH |
| An overlay tries to widen the base policy | deny | DENY_OVERLAY_WIDEN_FORBIDDEN |
| Policy file differs from its pin | deny | DENY_POLICY_HASH_MISMATCH |
| An allow rule matches and nothing denies | allow | ALLOW_RULE_MATCH |
See where it is enforced.
The same evaluator guards commits, CI, AI assistants and the file system.
Explore enforcement