Picture a contract between an AI provider and a government customer that collapses over a few words. The provider wants explicit prohibitions on certain uses; the customer wants the right to use the technology for any lawful purpose. Both sides argue over the text. Neither can say how the other would know, at runtime, what the model was actually used for.
Contracts define obligations, while technical controls apply rules and produce records during operation. A dispute may require both. This article examines one narrower engineering question: what can a reviewer check from an exported record of gateway decisions?
Contract language was never designed to constrain behavior inside a compute environment, and no amount of negotiation will change that. What such a dispute exposes is the absence of Cryptographic Runtime Governance: deciding at execution time against a hash-bound policy, and keeping a signed record of each decision. That is an engineering problem, not a legal one.
Where governance ends and execution begins
Legal obligations, contractual terms and voluntary policies are distinct sources of requirements. Translating an applicable requirement into an enforceable technical rule takes additional work; a signature on a decision does not establish that the translation was correct.
Operational logs are useful evidence. Unprotected files can be changed, while access controls, write-once storage, external custody and cryptographic protections can strengthen a logging system. The relevant question is which protections the actual deployment provides.
When a reviewer cannot access the producing system, a portable record may make a specific check easier to reproduce. That does not eliminate reliance on collection controls, the expected signing key or supporting evidence from the deployment.
The debate usually focuses on what the contract should say. The harder question is how either party would check what an AI system was asked to do and what was decided. Contractual governance can't answer that. The demand isn't “trust me.” It's “verify me,” and that kind of verification has to be built into the system architecture.
Constraints built into the system
Governance a reviewer cannot check is indistinguishable from a promise. Closing that gap requires constraints built into the system itself, requirements it either satisfies or fails to satisfy.
Keep the signing key out of the agent's reach.
Governance constraints are encoded into a policy that a separate runtime boundary applies. The boundary signs; the governed agent holds no signing key when the boundary runs under an identity it cannot read. In the published gateway, aga-proxy, the policy is a JSON file; every receipt carries the signed SHA-256 of the policy's canonical JSON, and the agent has no tool that changes it. (In aga-mcp-server 3.6.0 through 3.6.2, the governed MCP client can re-attest its own baseline, and the exported bundle does not record that.) An out-of-policy call gets a signed DENIED receipt; in-path, aga-proxy does not forward it, and whether the agent has another route is a property of the deployment.
Each recorded decision is signed.
Each tool-call decision the boundary records is a signed record appended to an append-only structure (known issue 7 on /security describes the calls aga-proxy refuses without a receipt). Against a pinned gateway key, altering signed fields breaks verification; a key holder could re-sign a changed history. NIST's Measure function is broader than this receipt mechanism. AGA produces signed, chained, offline-verifiable records, but that alone does not satisfy every measurement or assurance need. In the architecture, measurement also runs on a cadence set in the sealed policy; the published aga-mcp-server measures only on request. In NIST SP 800-207 terms, for tool calls that pass through it, the boundary sits where SP 800-207 places a policy enforcement point.
Verification works without a network.
AGA exports signed receipts, Merkle inclusion proofs and a signed checkpoint for offline verification. This lets a reviewer check the exported record without a callback to its producer. Online audit services can also provide useful evidence, with different availability and trust assumptions.
How the format relates to broader standards
The NIST AI RMF is a voluntary, broader risk-management framework; NIST states that version 1.0 is being revised as of September 28, 2026. SP 800-207 describes zero-trust architecture. AGA is a particular evidence-format and gateway implementation, not a replacement for those frameworks or proof of conformity with them.
The gap runs down to the protocols. The Model Context Protocol, now under the Agentic AI Foundation at the Linux Foundation with over 10,000 active servers, standardizes how AI agents connect to tools and data. It doesn't standardize governance on those connections. There's no built-in record of which tool calls an agent made and what was decided about them.
NIST has begun to address this gap directly. The NCCoE published a concept paper on Software and AI Agent Identity and Authorization, and CAISI published an RFI on AI agent security (Docket NIST-2025-0035, 91 FR 698). Both focus mainly on technical controls and practices. We submitted technical responses to both, describing runtime governance for MCP deployments; both submissions are public record, and they are kept as filed on our diligence page.
Attested Governance Artifacts
We built AGA because the same problem kept surfacing: autonomous systems that needed a verifiable record of how they were governed, rather than an assertion. AGA is our implementation of Cryptographic Runtime Governance. Attested Governance Artifacts (AGA) bind a governed agent to a policy whose hash each receipt carries, and sign each decision into a receipt as it is made; effecting a decision beyond the gateway's own forwarding is wired per deployment. The architecture is the subject of USPTO Application No. 19/433,835 (pending), filed December 28, 2025. A working reference implementation is published to npm. The historical 3.6.0 release CI reviewed on September 21, 2026 reported 428 tests. The retained conformance snapshot reports agreement across JavaScript, Go and Python on 61 classical cases as the harness feeds them, and between two language oracles on 28 composite cases. These are bounded historical results, not certification of the current packages. The harness re-serializes parsed cases, so leaf_index spelled 0.0 runs as an integer; see the specification and exact scope. The company-authored offline verifier uses zero AGA imports.
Sealed policy, signed decisions.
In aga-mcp-server, the Policy Artifact is a signed JSON object encoding a Subject Identifier (computed from hashes of the subject's bytes and canonicalized metadata), governance parameters (time-to-live, governance triggers) and a sealed hash of the attested state; a change to the signed values fails verification against the original issuer key. That per-process key is not an independently established issuer identity. The published server signs it under an issuer key generated per process, so no issuer key survives a restart to pin; the check against a pinned issuer key is in the private reference runtime (evaluation access), not in the published packages. The gateway is a separate process that holds the signing key; the agent holds none only when the gateway runs under an identity the agent cannot read. In the published aga-proxy, the policy is a JSON file, and each receipt carries the signed SHA-256 of the policy's canonical JSON. A call out of policy gets a DENIED receipt, and aga-proxy does not forward it. Its default profile, permissive, denies nothing on policy grounds; policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode. In aga-mcp-server 3.6.0 through 3.6.2, a measurement that doesn't match the sealed reference makes the server refuse its own governed tools, each refusal a DENIED receipt; the QUARANTINE verdict itself stays in process and is not in the exported bundle.
Measurement and decisions, with receipts.
In aga-mcp-server 3.6.0 through 3.6.2, measurement runs when the client asks, over content the client supplies, and compares its hash with the sealed reference. A mismatch puts the server in QUARANTINE, and a revocation, or a TTL expiry found at the next measurement, puts it in TERMINATE; both verdicts stay in process, and the exported bundle shows the governed calls refused afterward and, for a revocation, the revoke_artifact call itself. The governed client can lift a quarantine, revocation or termination by calling attest_subject, and the exported bundle does not record that call. SAFE_STATE and ALERT_ONLY are decision types in the library that the server does not reach. In the architecture, measurement runs on the cadence the sealed Policy Artifact sets, and the decision is sealed into the receipt chain; in 3.6.0 through 3.6.2 it stays in process, as above. Effecting it is wired per deployment.
Quarantine, as designed, inverts the typical incident response model. The conventional approach is to kill the process, triage the damage, and reconstruct what happened from whatever logs survived. That throws away the most valuable thing you have during a compromise: the attacker's ongoing behavior. In the design, quarantine moves the agent into a phantom execution environment where its connections to protected resources are severed at the deployment boundary while it keeps running, and every step is signed and appended to the receipt chain. That design exists only in a demo orchestrator, not in a published package. What ships in aga-mcp-server 3.6.0 through 3.6.2 is narrower: during quarantine each governed call is refused with a DENIED receipt that carries the reason.
Each recorded tool-call decision is a signed Decision Receipt appended to the receipt chain; known issue 7 on /security describes the calls aga-proxy refuses without a receipt. Arguments are committed by SHA-256 hash, so third parties can verify the chain end to end without the argument contents; in 3.6.0 through 3.6.2 a path-constraint denial names the offending path in its signed reason, and a denied-pattern denial names the matched pattern. Against the gateway's pinned key, an added, altered, reordered, or truncated entry fails verification, though a field name repeated in the file still verifies, because the verifiers read the last copy (known issue 5 on /security). An earlier genuine export presented as the current one still verifies, because the verifier has no freshness input. Completeness of capture is bounded by the interception point: the chain proves the record, not that every action was recorded.
Offline-verifiable evidence.
Evidence Bundles are portable verification packages containing signed Decision Receipts, Merkle inclusion proofs, and a signed checkpoint. The bundle does not contain the policy; on aga-proxy each tools/call receipt carries policy_reference, the SHA-256 of the canonical JSON of the policy it applied (a passthrough receipt, for an MCP method passed toward the upstream without evaluation, carries the active policy's hash too), and aga-mcp-server 3.6.0 through 3.6.2 signs it as an empty string. All verification works offline. The reference implementation includes a standalone verifier (company-authored, zero AGA imports, audit it yourself), separated from the AGA codebase so the verification path stands on its own. The verifier needs only the bundle and a public key.
What AGA does not require:
No trusted execution environment, no specialized hardware, and no zero-knowledge proof circuits. That is a deliberate design choice. TEE-dependent architectures inherit the supply chain and side-channel risks of their hardware, and any architecture that requires specific silicon creates a procurement dependency that disconnected environments can't always satisfy. The published packages use Ed25519, SHA-256, a JCS-lineage JSON canonicalization and Merkle trees. These run on anything with a CPU.
AGA is complementary to model-level safety measures such as alignment training. It operates at the system level, recording what the agent was permitted to do with the access it has been granted, regardless of what its reasoning engine attempts. It does not prevent prompt injection; prevention is a model-level problem. What it adds at the system level is a signed decision for each governed call it records and a record a reviewer can check.
Governance for MCP
The gateway maps directly onto MCP as a governance boundary: aga-proxy intercepts each tools/call routed through it, evaluates it against the policy, and signs a Decision Receipt (known issue 7 on /security describes the exceptions). We described this integration in public federal submissions, and it ships on npm.
That is what a dispute like the one above is missing: a record of the decisions an AI agent's tool calls received, which any party can check offline against a key pinned in advance. It removes the need to trust either side's logs, though not the need to trust whoever holds the signing key.
The shift from policy to proof
When autonomous systems operate at machine speed in consequential environments, contracts can't constrain them in real time. Disputes over what a model was used for will recur, and any governance model built on contract language alone will produce the same standoff.
Which side has the better contract language is the wrong question. The right one is why either side accepts contract language as the only governance mechanism when a signed decision record can sit beside it. Regardless of who sets the boundaries, model provider or deployer, both parties need the same thing: a record of what was decided at runtime that both can check.
AI has crossed a threshold. It generates answers, and now it takes actions, in environments where those actions have real consequences. If your AI governance still lives in a PDF, what you have is documentation of intent, disconnected from the system it claims to constrain. The shift from generative to agentic AI calls for a shift from policy to a verifiable record, and Cryptographic Runtime Governance is built from standard primitives, with its format published and a reference implementation you can run.
See the working implementation on npm.
AGA is a reference implementation of a published format for verifiable decision records: hash-bound policies, signed Decision Receipts, and Evidence Bundles that verify offline. The implementation is on npm. The evaluation path walks through it in working code.