Control Before, Prove After: An Accountability Model for AI Agents
A new accountability primitive restricts AI agents before acting and cryptographically proves actions after, closing gaps left by policy engines and logs.
When AI agents are given real-world capabilities—moving money, shipping changes, touching customer accounts—teams often revert to manual approval the moment an agent takes an action nobody can later explain. The root cause isn't the model; it's that authorization (a policy engine) and audit logging are two separate systems that drift apart over time, making it hard to prove months later exactly what policy was in force when a decision was made.
The proposed primitive fuses authorization and proof into a single object. 'Control before' mints a scoped capability for an agent—spend caps, counterparty allowlists, expirations—and checks every consequential action against committed policy state, denying out-of-bounds actions before they execute. 'Prove after' hashes the full decision context (salted per tenant), signs it, and anchors it in an append-only record tied to the exact policy version used, so the same object that authorized the action is the object that proves it.
Architecturally, the allow/deny verdict is returned synchronously off committed state, while the tamper-evident record is persisted through a transactional outbox and settles asynchronously—avoiding both blocking latency and the risk of an authorized-but-unrecorded action. Exactly-once recording and single-writer-per-capability guarantees make this split safe. Verification doesn't require trusting the vendor's server: anyone holding the context can recompute the hash and check it against the anchor. Signatures use post-quantum ML-DSA (FIPS 204), and a per-record 'crypto-shred' salt allows provable erasure without breaking ledger immutability. Client SDKs for TypeScript, Python, and Go are open source.
The system currently runs on a custom post-quantum L1 blockchain, though developers never touch tokens, wallets, or gas. It's in managed beta: signing keys are custodied via KMS and validators are run by the company itself, with non-custodial issuance and third-party validation described as future goals rather than current reality. The author is candid that simpler append-only logs suffice when server-independent verification or per-record erasure aren't required.