A signed, hash-linked record of every decision.
Sealed so a third party can re-derive it offline, with no callback and no proprietary tools. What follows is how that record gets built, and why you can check it without trusting us.
Three-phase architecture.
Each phase in detail, and the artifact it hands to the next: the sealed policy, the runtime decisions, and the receipt chain that records them.
Policy Artifact
Approve
Subject + Policy
permitted operations
policy.json (excerpt)
{ "subject": "agent-3.2.0", "tools": ["mcp.fetch", "mcp.write"], "cadence_ms": 100 }Sign
Ed25519 (live default)
hybrid ML-DSA-65 profile selectable
signature (first 32 bytes hex)
8e2af1d9 73c4b605 a91e2f7c 18d5ebb3 f60c7a44 9d1eaa72 4f8b0c63 c1e2d098Sealed Artifact
Tamper-evident policy with its validity window bound into the signature
post-seal modification breaks the signature and the policy with it
Gateway runtime boundary
Validate
Launch Gate confirms the artifact before execution
fail-closed when wired
launch-gate check
verify(artifact.signature) → OK · subject_hash == sealed_baseline → OKMeasure
Continuous sampling at the cadence the artifact specifies
100 ms to 5 s, ten classes
measurement frame
sha256(exe_image) · sha256(config_manifest) · memory_region_samples[8]Decide
Hash matches the sealed baseline?
autonomous, no human in the loop
Match
Continue and record an ALLOW receipt.
Mismatch
Seal the decision and record a DRIFT receipt.
Evidence Bundle
Record
Signed receipt per decision
Ed25519 · hybrid profile available
receipt skeleton
{ "ts": "2026-05-24T18:42:11Z", "subject": "agent-3.2.0", "op": "mcp.fetch", "decision": "PERMITTED", "prev_hash": "4f9c..", "sig": "8e2a.." }Chain
Hash-linked, append-only
tamper-evident
chain link
next.prev_hash = sha256(canon(receipt))Evidence Bundle
Sealed policy + receipt chain + Merkle proofs in a single portable file
offline-verifiable by any third party
Three phases on one continuity chain. Every decision is signed and chained into one continuity-bearing sequence.
One decision, end to end.
An agent asks to fetch a URL. Follow that one decision from the sealed policy through to the signed receipt that anyone can re-derive offline. A representative fixture, not live data.
{ "subject": "agent-3.2.0", "tools": ["mcp.fetch", "mcp.write"], "cadence_ms": 100 }Artifact hash a17c.. is covered by the signature; any edit breaks it.
sha256(exe_image) · sha256(config_manifest) · memory_region_samples[8]Each hash equals the sealed baseline, so the decision is PERMITTED.
{ "ts": "2026-05-24T18:42:11Z", "subject": "agent-3.2.0", "op": "mcp.fetch", "decision": "PERMITTED", "prev_hash": "4f9c..", "sig": "8e2a.." }Signed with the deployment's signature profile.
next.prev_hash = sha256(canon(receipt)) = 7b3e..Append-only. Reordering or deletion breaks the chain forward.
$ aga-verify evidence-bundle.json → PASSRecompute each receipt hash, walk the chain, re-check every signature. No callback to us.
One decision, three artifacts, one continuity chain, re-derivable offline from the bundle alone.
Cryptographic primitives policy
Industry-standard primitives. No proprietary algorithms.
Both the hash and the signature algorithm are named in a single suite identifier carried in the artifact, covered by the signature (for example Ed25519-SHA256-JCS, or ML-DSA-65+Ed25519-SHA256-JCS). A verifier checks that identifier first and rejects any record with an unrecognized suite, before checking a signature byte.
The suite cannot be silently downgraded: a changed identifier breaks the signature, and an unknown identifier fails closed. That keeps the architecture algorithm-agile without softening verification.
Ed25519
Policy-artifact and receipt signatures for classical deployments, and the reference baseline outside the post-quantum threat model.
ML-DSA-65
Post-quantum artifact and receipt signatures at NIST Level 3, used inside the hybrid composite that is the target signing profile.
SHA-256
Addresses every artifact and chains every receipt into the continuity record; also the leaf hash beneath the Merkle checkpoint.
JSON canonicalization
A JCS-lineage canonicalization with sorted keys, defined by the conformance vectors, so signature inputs reproduce identically across implementations.
Merkle Trees
Checkpoint anchoring with inclusion proofs, so an auditor can verify any single receipt against a sealed root without the full chain.
BLAKE2b-256
Alternative hash for high-frequency measurement workloads where lower latency per frame outweighs the default FIPS preference.
Cryptographic Foundation
Standard cryptography, proven by two implementations that agree.
AGA introduces no new cryptography. It composes standardized primitives, Ed25519 and the NIST post-quantum standard ML-DSA-65, and then proves they are implemented correctly: the post-quantum scheme is pinned to NIST known-answer vectors, and two independent implementations are shown to agree byte-for-byte. There is no novel cryptanalysis to take on trust.
Two profiles, one construction. A signed record carries a versioned signature profile. The classical profile, live today, signs with Ed25519 (RFC 8032), with SHA-256 chaining the receipts and anchoring the signed checkpoint. The hybrid profile, implemented and cross-verified across two independent-language oracles (@noble in JavaScript and CIRCL in Go), signs with a composite of ML-DSA-65 (NIST FIPS 204) and Ed25519: both components cover the same bytes, and both must verify for the record to be accepted. An attacker would have to break ML-DSA-65 and Ed25519 to forge a record, so it holds as long as either scheme stands. Canonicalization, hashing, the Merkle tree, and the checkpoint are identical across profiles. Only the signature primitive changes.
Built to migrate, not to break. A verifier reads the profile from the bundle and checks the signatures accordingly. Records signed under the classical profile stay verifiable indefinitely, and a verifier that understands the hybrid profile still accepts them. Post-quantum migration is additive: the profile is defined and proven before any record needs to depend on it.
Supported Signature Modes
| Mode | Algorithm | Security | Status |
|---|---|---|---|
| Classical | Ed25519-SHA256-JCS | Ed25519, ~128-bit classical | Default · live |
| Hybrid (post-quantum) | ML-DSA-65+Ed25519-SHA256-JCS | Ed25519 (~128-bit classical) and ML-DSA-65 (NIST Level 3); both must verify | Implemented · cross-verified |
Hybrid mode produces both signatures. Verification requires both to pass. No downgrade fallback. Ed25519-only artifacts from existing deployments remain verifiable.
Proven by two implementations
The post-quantum scheme is pinned to the NIST ACVP known-answer vectors for key generation, signing, and verification, so each implementation is checked against a fixed external oracle. Beyond those vectors, the implementations are exercised against the shared cross-language conformance corpus, 57 classical and 28 post-quantum cases, and the equality check is concrete: for the same input they must produce byte-identical canonical JSON, identical signature bytes, and the same Merkle root, and each must verify what the others produced. That agreement against a fixed oracle, not an assurance from us, is the evidence the construction is correct.
Measured performance
At every supported cadence the cryptography is a rounding error against the measurement window, so it is never the bottleneck. The classical Ed25519 path signs in tens of microseconds with no heap allocation; the hybrid figure is dominated by the ML-DSA-65 component and is reported as the full per-decision sign-and-verify cost, not a best case. The full benchmark tables, key and signature sizes, and the standard each primitive implements are on the specification page.
View specification and benchmarksWhat a verified record proves, exactly
A passing verification proves the signed record has not changed since it was sealed, and that any third party can re-derive it offline with no callback to us. It does not prove an agent was prevented from acting; governance is a separate property of how the system is deployed. It does not prove a recorded value is true, and says nothing about identity or legal standing. The proof is about the record, because an instrument that overstates what it measures is not an instrument.
MCP integration
Cryptographic governance for agentic tool use over the Model Context Protocol.
Tool-call request path
every routed call is recordedAI Agent
model + reasoning
MCP Client
tool discovery
gateway
MCP gateway, signing boundary
MCP Tool
external resource
AI Agent
model + reasoning
MCP Client
tool discovery
gateway
MCP gateway, signing boundary
MCP Tool
external resource
Every tool call is routed through the gateway, which exposes the MCP interface. The gateway holds the signing keys; the subject holds none and cannot mint a call that passes as approved or a valid receipt. Routing is arranged by the deployment: the subject reaches external tools only through the gateway, and the receipt chain records every call that transited it. What AGA proves is the record of calls that went through the boundary, not that no call ever evaded a misconfigured or root-compromised host.
The Model Context Protocol defines how agents discover and invoke external tools.
AGA integrates at the MCP layer and seals a signed governance decision on every routed tool call. Approved tool configurations are sealed into the Policy Artifact, runtime invocations are inspected against that seal, and each operation produces a signed receipt that chains into the continuity record. That makes AGA the cryptographic decision-and-evidence record for securing autonomous agents at the protocol boundary, where an application that routes through the gateway cannot reach the tool without producing a signed receipt.
Two-process mandatory separation.
Core security property: the governed subject holds no signing keys and cannot self-authorize.
gateway (Governance Engine)
- Holds all signing keys
- Parses and validates policy artifacts
- Renders and seals governance decisions (TERMINATE, QUARANTINE, SAFE_STATE, ALERT_ONLY)
- Generates and signs all receipts
- Manages the continuity chain
Subject (Governed Agent)
- Holds no signing keys
- Cannot produce a valid policy or a valid receipt
- Cannot make an action it takes outside the gate appear governed
- Cannot suppress, forge, or reorder receipts without breaking the chain
- Measured against the sealed reference hash every cycle
These hold because the subject has no key. Process isolation between the gateway and the subject is supplied by the deployment, and is stated as an assumption in the security model below.
Deployment architecture
Where the gateway exists in your stack.
The gateway runs as its own process and holds every cryptographic signing key in the system. The governed agent runs as a separate process with no key access. That two-process separation is the core security primitive, and when the launch gate is wired to require it, the agent does not start until the gateway has parsed and validated the sealed Policy Artifact.
In containerized environments the gateway deploys as a sidecar alongside the agent container. On bare-metal and edge hardware it runs as a co-process on the same host. For agents routed to the outside world through MCP, every tool invocation that transits the gateway is measured and recorded at the protocol layer before it leaves the boundary.
AGA operates at the process level, so its trusted computing base is the gateway process plus the host kernel and the deployment's process isolation. An operator with root on the host sits inside that boundary and can interfere with governance. What survives a compromised host is the signed record, because forging it still requires the gateway's key. Where the host operator must sit outside the boundary, the gateway can run inside a Trusted Execution Environment (Intel SGX, ARM TrustZone, AMD SEV), which shrinks the trusted base to the enclave and lets its attestation quote be recorded alongside the gateway's other measurement inputs.
Container Sidecar
Deploys alongside agent containers in Kubernetes or Docker. When the pod is wired to route egress through it, the gateway records every outbound call before it leaves to the network.
Edge Co-Process
Paired process on bare metal, embedded controllers, or forward-deployed compute. No container runtime is required, and the same standard cryptographic primitives carry into disconnected operation.
TEE-Hardened (Optional)
gateway runs inside a hardware enclave, moving the host operator outside the trusted base while it holds. AGA records the enclave’s attestation quote as one measurement input, so a verifier sees which enclave produced the record.
Measurement inputs.
Runtime state evaluated through policy-defined measurement classes. Each class runs at its own cadence. The artifact specifies which apply.
Binary integrity
exe + weights hash
Configuration
runtime params
Module checksums
loaded modules
Container image
image digest
SBOM digest
supply chain
Environment
host metadata
File system
filesystem state
Network config
routes + interfaces
Memory samples
region snapshots
Control flow
execution graph
Classes apply at different cadences: binary verification once on startup, configuration every minute, memory sampling every second. The sealed Policy Artifact sets which classes apply and how often. Memory and control-flow are sampled, not observed continuously, so the sampling interval is the security model’s detection window.
Integrity drift detection
Hash comparison against the sealed baseline, sample by sample.
Hash sample stream
representative sequenceA representative measurement sequence, not live telemetry. Each tick is one cycle. Every measurement hash is compared for exact equality against the sealed value; the first hash that does not match fires a DRIFT_DETECTED receipt. There is no tolerance band. Equality is binary.
AGA compares every runtime measurement to the hash values sealed into the Policy Artifact, and any deviation produces a signed drift receipt. Governance decisions rest on deterministic hash equality: the comparison checks whether values match, with no interpretation of model outputs.
No hardware root of trust required.
AGA requires no connectivity, so it can be deployed on air-gapped networks, in classified-style environments, on legacy infrastructure, and on commodity hardware. When hardware attestation is available, the gateway records it as measurement input.
AGA architecture
Software cryptography on every platform.
The gateway renders and seals governance decisions using standard primitives (Ed25519, ML-DSA-65, SHA-256, JSON canonicalization) and is designed to run on commodity edge hardware, air-gapped networks, and classified-style environments. When TPM, TEE, HSM, or secure-boot mechanisms are present, the gateway can record their attestation quotes alongside its other measurement inputs.
Standard cryptographic primitives
Runs where TPM, TEE, or HSM are unavailable
TPM 2.0 quotes ingested when present
Intel SGX, ARM TrustZone, AMD SEV as inputs
HSM-backed key custody on the roadmap, never required
Secure-boot chain optional as one measurement
Phantom execution (Quarantine)
Phantom execution is the quarantine mode of the governance design: the gateway keeps accepting the agent's outputs while the wired quarantine handler severs them from any downstream system that would normally consume them. By design we do not claim the quarantined agent cannot detect containment.
The result is a controlled observation window for a subject that has already drifted. In the shipped gateway, each quarantined call is recorded with the tool name and quarantine reason as a phantom-tagged receipt any verifier can tell apart from normal entries; the rich eight-field forensic capture is implemented and tested in the demo orchestrator and is integration-staged for the live proxy. The architecture lets an investigator observe a drifted agent under containment, with no path into production.
Quarantine sits alongside three other decision outcomes: TERMINATE, SAFE_STATE (a pre-approved fallback profile), and ALERT_ONLY (a signal without intervention). The artifact policy maps each drift class to a signed decision; the decision path is shipped and tested, and the handlers that effect each action are wired per deployment.
Privacy-preserving verification
The bundle carries only hashes of your data, never the data itself. Every receipt records an arguments_hash, a SHA-256 of the tool call's arguments, so anyone can verify the signatures, the hash-chain, the Merkle inclusion, and the signed checkpoint without the arguments ever leaving the producing system.
receipt.arguments_hash = SHA-256(canon(arguments)) // the bundle stores the hash, not the argumentsAn auditor confirms the chain is intact, that every link hashes to the next, and that every signature verifies, all without seeing the payload. When a specific payload must be disclosed, the recipient re-hashes it and confirms it matches the arguments_hash the producer signed, so a withheld or swapped payload cannot pass as valid. The auditor verifies the record and its ordering, not the truth of the data inside it.
What AGA assumes, and what it proves.
Assumes
- 1.The gateway process is not compromised at signing time. A compromised gateway could sign an artifact or receipt of an attacker’s choosing.
- 2.The measurement cadence is fast enough to catch drift before it causes harm. The right interval is a per-deployment risk decision.
- 3.The deployment environment applies process isolation between the gateway and the governed subject, so the subject cannot reach the signing keys.
- 4.The configured signature algorithm (Ed25519 or ML-DSA-65) and SHA-256 stay computationally secure for the artifact’s validity period.
- 5.The host clock is roughly accurate. AGA records a self-reported time, so receipts establish ordering and integrity, not an independently attested wall-clock time.
Guarantees
- Any modification to a sealed policy artifact invalidates its signature, so a verifier rejects the altered artifact. Whether that rejection stops the subject from launching depends on the launch gate being wired to fail closed: the signature check is the guarantee, the gate behavior is a deployment property.
- Receipt ordering and contents are tamper-evident: any deletion or reordering of an existing entry breaks the hash chain forward and a verifier detects it. A verified chain proves the entries it contains are intact and correctly ordered, not that none is missing.
- Evidence bundles are independently verifiable by any party using standard cryptographic primitives, with no callback to the producing system.
- Privacy-preserving disclosure proves chain integrity without exposing payload content, so auditors verify the record without seeing the data inside it.
- Every governance action is signed. A receipt in the chain is bound to the key that produced it, so a holder of that key cannot credibly claim a chain entry was not produced under it. This binds the key, not a legal identity, and holds while that key is uncompromised.
Indexed by adversary
If an attacker can do this, here is what AGA catches, what it does not, and what closes the gap.
| Adversary can | AGA detects | AGA does not | Residual mitigation |
|---|---|---|---|
| Tamper with the sealed policy artifact | The signature breaks; a verifier rejects the altered artifact | Nothing beyond detection | Detection is the property |
| Delete or reorder existing receipts | The hash chain breaks forward from the changed entry, and verifiers detect it | Recover deleted content | Anchor the chain at a signed checkpoint |
| Withhold or truncate the receipt tail (compromised gateway) | A single receipt can be proven to belong to a checkpoint | Prove no entry is missing from the chain alone | Compare against a checkpoint anchor held outside the gateway |
| Swap the binary or config at runtime | Drift is caught at the next measurement cycle | Prevent action between two cycles | Faster cadence, at higher resource cost |
| Exfiltrate the gateway signing key | Not detected by AGA itself; later artifacts and receipts are suspect | Stop forged artifacts and receipts until rotation | Scheduled rotation, HSM storage, out-of-band key verification |
| Run an ungoverned subject beside a governed one | Out of scope | Prove anything about the ungoverned subject | Operator deployment policy |
Failure modes and limits
These are the scenarios where AGA offers reduced or no protection.
gateway Compromise
An attacker who exfiltrates the gateway signing key can forge artifacts and receipts until the next rotation. Mitigations are scheduled rotation, HSM storage, and out-of-band key verification.
Measurement Cadence
AGA detects drift at measurement intervals. Between intervals, a compromised subject could act outside policy. Faster cadence reduces the window but increases resource cost.
Key Management
AGA specifies the cryptographic protocol but not the key management infrastructure. Deployments must implement secure key storage, rotation, and revocation appropriate to their threat model.
Deployment Governance
AGA proves the record of the governance decisions it made. It does not prevent an operator from deploying an ungoverned subject alongside a governed one; that subject simply produces no receipts. Deployment policy governance is the operator's responsibility.
Record Integrity, and Its Boundary
A verified chain proves the entries it contains are intact and correctly ordered. It does not by itself prove none is missing. The subject cannot suppress a receipt, but a compromised gateway could withhold one or truncate the tail. The signed Merkle checkpoint anchors a sealed root, so a single receipt can be proven to belong to a checkpoint; detecting a truncated tail requires comparing against an anchor held outside the gateway.
The verifier is published. Check us with it.
The same Ed25519-SHA256-JCS construction the gateway signs with is published as an independent command-line verifier on npm. Install it and re-check any evidence bundle on your own machine, or run the VerifyBundle offline verifier in your browser. The package ships with SLSA build provenance.
What you get depends on the key. Without a pinned key the verifier confirms integrity only: that the bundle is internally consistent under its own key. Pin the gateway key to also prove who issued it and to rule out whole-bundle re-signing.
The demo gateway key is a published fixture, and a live deployment uses a persisted key (the server’s default key is ephemeral).
Every decision, signed and chained. Verifiable offline.