Policy Engine
Policy Engine
A deterministic admission machine that decides, for every operation against a custody key, whether it proceeds, which approvals it requires, and what evidence the decision leaves behind.
The policy engine sits between orchestration and the MPC crypto core. Signing, refresh, reshare, destroy, and key-export operations reach the core through a one-shot authorization token issued by the engine after it evaluates the active policy against the normalized operation context.
Policies execute as compiled, verified bytecode. Authors write rules in the policy language; compilation produces a PolicyPackage that binds the bytecode, the schema it was type-checked against, the human-readable explainability artifacts, and the analyzer report. The engine loads packages through the verifier under a governance-approved, epoch-gated activation; decision time consumes the verified package and snapshot.
Default action is explicit and conservative: an empty policy, evaluation error, or unreachable dependency produces DENY. Every DENY carries a machine-readable reason and a decision trace.
Placement and authority
Three rings with strictly bounded responsibilities. Authority increases through the token-bearing admission path.
- Orchestration. Builds operation intents, moves protocol messages, renders UIs, and passes opaque tokens between components.
- Policy engine (trust boundary). Normalizes intents, evaluates bytecode, collects approvals, reserves meters, issues one-shot tokens, and appends evidence.
- Crypto core (key material). Verifies token signature, audience, expiry, and purpose before every secret use; its contract is token validity.
Unit of deployment: PolicyPackage inside a signed PolicyBundle
The compiled package is content-addressed; the bundle is the signed envelope that governance activates. The rules_root of the bundle is the package root — activating a bundle pins exact bytecode, exact schema, and exact explainability artifacts.
pub struct PolicyBundle {
pub version: u16,
pub policy_bundle_id: PolicyBundleId,
pub policy_version: PolicyVersion,
pub domain_id: DomainId,
pub epoch_id: EpochId,
pub scope: PolicyScopeId, // tenant / key / cluster
pub default_action: PolicyAction, // MUST be Deny; verified at load
pub rules_root: Cid, // PolicyPackage root
pub obligations_root: Cid, // obligation catalog root
pub business_schema_root: Cid, // PolicySchema root
pub activation: PolicyBundleActivation,
pub signatures: Vec<SignatureRef>, // m-of-n policy authority
}Default deny is a verifier rule
The package verifier requires default_action: Deny, a terminal verdict instruction, and at least one permit rule for standard bundles. A Forbid overlay uses an explicit overlay marker. The accepted package shape makes the allow surface explicit.
Evaluator scope
The engine evaluates a total, terminating function of the normalized context, the active package, and a recorded state snapshot. Identical inputs produce identical decisions on every conforming evaluator, native or browser.