Position Paper · Published March 28, 2026
From Declaration to Proof
Cryptographic Governance Evidence for Autonomous AI Agents
Every major AI governance framework declares what autonomous agents should do. None prove what they actually did. This paper identifies the structural gap between policy declaration and runtime enforcement evidence, explains why conventional logging and monitoring cannot close it, and describes a concrete architecture (Seal, Enforce, Prove) that produces cryptographic proof of governance enforcement verifiable by any third party on an air-gapped machine.
Core Argument
Declaration without enforcement is aspiration. Enforcement without evidence is a trust relationship. The standards that govern autonomous AI agents need all three.
Paper Structure
Eight sections tracking the argument from problem identification through architecture, standards alignment, and implementation.
The Declaration-Enforcement Gap
Every framework declares intent. None prove enforcement.
Why Logging Is Not Proof
Logs are mutable, passive, and producer-controlled.
Three Properties of Governance Evidence
Sealed. Signed. Portable.
Architecture: Seal, Enforce, Prove
Standard cryptographic primitives on commodity hardware.
Standards Alignment
Five standards bodies, one common gap.
The MCP Governance Gap
MCP's delegation model creates an accountability gap.
When Configuration Replaces Enforcement
A CMS leak demonstrates why configuration is not enforcement.
Implementation Path
Four steps from declaration to proof.
1. The Declaration-Enforcement Gap
Governance frameworks for autonomous AI agents share a common structure. They define roles, specify authorized behaviors, establish access boundaries, and prescribe monitoring requirements. NIST AI RMF prescribes Govern, Map, Measure, and Manage functions. The EU AI Act mandates quality management systems (Article 17), risk assessments (Article 9), and automatic recording of events (Article 12). OWASP's Top 10 for Agentic Applications catalogs risks and recommends mitigations. The MCP Server Security Standard defines four compliance levels with 24 controls.
Each of these frameworks answers the question: what should an AI agent be allowed to do?
None of them answer the question that follows: can anyone prove, after the fact, that the agent did only what it was allowed to do?
The consequences are documented. When Palo Alto Networks mapped a leading autonomous agent framework to every OWASP Agentic category, it concluded the framework exhibited “near-absent governance protocols.” When SecurityScorecard identified over 135,000 exposed agent instances, the common finding was not absent policies but absent enforcement boundaries. When an autonomous trading agent destroyed $441,000 in a single transaction, the failure was not a missing policy but a missing enforcement boundary.
2. Why Logging Is Not Proof
Logs are mutable. Anyone with sufficient system access can alter, delete, or selectively omit entries. When the system under investigation controls its own audit trail, trust is conditional at best.
Logs are passive. A log records what happened. It does not prove an enforcement boundary existed, was active at the time of the request, or could not be bypassed. Recording and enforcement are fundamentally different capabilities.
Logs are producer-controlled. The system generating the log determines its completeness. A compromised agent can report compliant behavior while acting otherwise. Producer-controlled evidence is a self-assessment, not proof.
These are inherent characteristics of the logging model. No amount of log aggregation, SIEM integration, or retention policy changes the fundamental structure: a log is a claim made by the system about itself.
3. Three Properties of Governance Evidence
Sealed. Authorized scope cryptographically committed into an immutable artifact before operation. Ed25519 signature over SHA-256 hash of JCS-canonicalized (RFC 8785) policy. Modification of any field invalidates the signature. The governed agent cannot alter the artifact because it does not hold the signing key.
Signed. Every enforcement decision produces a cryptographic receipt containing the action, policy reference, decision, timestamp, and a SHA-256 hash linking it to the previous receipt. The chain is append-only. Modification of any receipt invalidates every subsequent link. The governed subject operates in a separate execution context with no access to the signing key.
Portable. Evidence bundle with sealed artifact, signed receipts, and Merkle inclusion proofs verifiable by any third party offline. Standard Ed25519 + SHA-256 on an air-gapped machine. No network access, no proprietary tooling, no trust in the producing system.
4. Architecture: Seal, Enforce, Prove
Standard cryptographic primitives: Ed25519 (RFC 8032), SHA-256 (FIPS 180-4), BLAKE2b-256 (RFC 7693), RFC 8785 JSON canonicalization, Merkle trees (RFC 6962). No TEE required. Commodity hardware.
Phase 1: Seal
The Policy Artifact (Claim 1(a)) encodes agent identity via Subject Identifier (Claim 1(b)), cryptographic hashes of normalized bytes and canonicalized metadata, authorized behavior, enforcement parameters including measurement cadence and TTL (Claim 6), and an Ed25519 signature binding all fields.
Phase 2: Enforce
The Portal (Claim 1(e)) operates as a Policy Enforcement Point (NIST SP 800-207). The agent holds no keys. On every request: compute the agent's binary hash, compare to sealed reference (Claim 1(f)), evaluate against behavioral constraints, make the enforcement decision, generate a signed receipt.
When behavioral drift is detected, the Portal can transition the agent to phantom execution (Claim 11): all connections to protected resources are severed, but the agent continues executing in a sandboxed environment, receiving no signal of the transition. Every unauthorized action is captured as signed forensic receipts.
Phase 3: Prove
Every decision produces a signed receipt appended to a Continuity Chain (Claim 3). Chain linking uses structural metadata only (Claims 3(d-f)); payload is excluded for privacy-preserving verification. Merkle checkpoints (Claim 12) anchor batches. Evidence Bundles (Claim 9) package everything into a portable verification unit.
| Stage | Attestation | Proves |
|---|---|---|
| Build | SLSA Provenance | Built from expected source by expected builder |
| Package | OMS Model Signing | Model integrity from build to distribution |
| Deploy | Container Signing | Deployed artifact matches signed reference |
| Operate | Governance Predicate | Agent actions evaluated against sealed policy; enforcement decisions signed and chain-linked |
5. Standards Alignment
MCP Server Security Standard (MSSS). 24 controls across 8 domains, four compliance levels. At L3/L4, no continuous evidence that controls remained enforced between assessments. Sealed artifacts provide L3 pre-commitment. Signed receipts provide L4 continuous proof. Evidence bundles provide the offline audit mechanism.
CoSAI Workstream 4. 12 threat categories, ~40 threats. The white paper explicitly scopes out implementation. Across all categories, the common gap is identical: mitigations recommended, no mechanism to prove they were applied. A detailed mapping is published at attestedintelligence.com/diligence/cosai-ws4-mcp-threat-analysis.
OWASP MCP Top 10. Cryptographic enforcement evidence addresses MCP02 (scope enforcement), MCP03 (tool poisoning attribution), MCP07 (continuous authentication), MCP08 (tamper-evident audit), and MCP09 (shadow server detection).
CSA / CSAI Foundation. Mission: “Securing the Agentic Control Plane.” Evidence bundles feed the AI Risk Observatory. Sealed policies implement Agentic Best Practices. Offline bundles support STAR-style assessment.
Sigstore / OpenSSF. OMS covers build-to-deploy provenance. This architecture covers deploy-to-operate governance. Together they complete the attestation lifecycle using compatible primitives (Ed25519, SHA-256, DSSE envelope).
6. The MCP Governance Gap
MCP mediates the interaction between AI agents and external tools via JSON-RPC 2.0. When an agent calls a tool, it exercises delegated authority. No component in the standard MCP architecture produces cryptographic proof that the decision was authorized, that the policy was immutable, or that the decision history is tamper-evident.
Seal a policy governing an MCP agent's tool access. Start an enforcement proxy. Route tool calls through it. Observe permitted calls passing through and denied calls blocked with {"code":-32600,"message":"tool call denied by policy"}. Export an evidence bundle. Verify offline. Seven tool calls. Seven signed receipts. Three PERMIT, three DENY, one DRIFT. One evidence bundle. Independent verification on a disconnected machine using zero framework imports.
7. When Configuration Replaces Enforcement
On March 26, 2026, a major AI lab's most capable model was discovered through a misconfigured CMS that exposed ~3,000 unpublished assets. The policy existed. The intent was clear. Enforcement depended on mutable configuration that failed silently.
Cryptographic enforcement changes the failure mode. A sealed artifact cannot be misconfigured without breaking its signature. An enforcement boundary that intercepts every action cannot be silently bypassed. A signed receipt chain cannot be altered without invalidating subsequent links. The system either enforces and proves, or fails closed and proves the failure. There is no silent middle ground.
8. Implementation Path
Step 1: Define the policy. Specify permitted tools, denied tools, rate limits, required parameters, and enforcement actions. Most organizations already have this in some form.
Step 2: Seal the policy. Generate an Ed25519 key pair. Sign the JCS-canonicalized policy into an immutable artifact. Any modification invalidates the signature.
Step 3: Route through enforcement. Configure the agent to reach MCP servers through the governance proxy. Every tool call is evaluated, receipted, and chain-linked.
Step 4: Export and verify. Export an evidence bundle. Verify on any machine with the public key. No network required.
Reference implementation: npm @attested-intelligence/aga-mcp-server. Python SDK: PyPI aga-governance. Independent verifier: attestedintelligence.com/verify.