Trust and scope.
This page describes exactly what Cryptographic Runtime Governance evidence bundles prove, what they do not prove, and the trust assumptions underlying the system. Read this like a threat model, not marketing.
What Evidence Bundles prove.
A specific tool call decision was recorded
Each receipt contains the tool name, decision (PERMITTED or DENIED), request ID, and timestamp. The receipt is signed with Ed25519 over the canonical JSON representation.
The signer held a specific private key at signing time
Ed25519 signatures are deterministic. A valid signature proves possession of the private key corresponding to the embedded public key. Attribution to a specific party additionally requires exclusive custody of that key and a trusted out-of-band binding of the key to the party.
The receipt chain is tamper-evident
Each receipt includes the SHA-256 hash of the previous receipt (including its signature). Any modification to a receipt breaks the chain from that point forward.
The Merkle tree binds all receipts to a single root
Inclusion proofs allow any single receipt to be verified against the bundle's Merkle root in isolation, without access to or trust in the other receipts.
Verification works offline and air-gapped
All cryptographic operations use Ed25519 and SHA-256. No network access, certificate authorities, or external services are required, so verification runs entirely on the verifier's machine.
What Evidence Bundles do NOT prove.
That the tool call actually executed
A receipt records a governance decision, not an execution trace. A PERMITTED receipt means the gateway approved the call. It does not prove the tool ran, returned a specific result, or completed successfully.
That the AI agent was actually constrained
The receipt chain proves decisions were recorded and signed. It does not prove the agent could not bypass the gateway. Enforcement is a separate concern addressed by a private runtime component.
That the policy was correct or complete
The bundle references a policy hash, not the policy itself. A bundle with all PERMITTED decisions may reflect a permissive policy, not a secure one.
That the timestamps are accurate
Timestamps are self-reported by the signing gateway. You can corroborate them with Roughtime IETF, but until that is configured a compromised gateway could backdate or future-date receipts.
That the public key belongs to a specific entity
Evidence bundles embed a raw Ed25519 public key. Self-signed X.509 identity binding via SPIFFE is available but optional. Without identity binding enabled, the key proves cryptographic consistency; it does not yet attest to organizational identity.
Trust assumptions.
The signing key is not compromised
If an attacker obtains the Ed25519 private key, they can forge receipts indistinguishable from legitimate ones. Key management is the deployer's responsibility.
The gateway is positioned to observe tool calls
The MCP gateway must be in the request path between the AI agent and tool providers. Calls that bypass the gateway are not recorded.
The verifier has the correct public key
Verification requires the verifier to trust that the public key in the bundle corresponds to the expected signer. Out-of-band key distribution is assumed.
Cryptographic primitives remain secure
The system relies on SHA-256 collision resistance and Ed25519 unforgeability. If these primitives are broken, all guarantees are void.
Governance boundary.
The public components described on this site (MCP gateway, Python SDK, evidence bundles) provide observation and proof, and the gateway evaluates each call and seals a permit-or-deny decision at the edge. Whether a denied call also blocks is a deployment property, and here is the strongest result we can state for it: in a July 2026 live trial of the standalone aga-proxy deployment, calls denied under the sealed allowlist profile at the tool-call boundary never reached the upstream tool server, confirmed against the upstream’s own request log rather than the proxy’s, while permitted calls did. That result is in-path and deployment-bounded: it holds where the proxy is the route to the tool, and it says nothing about routes that bypass the proxy. Beyond the edge, a separate closed-source governance runtime exists under separate licensing; we do not claim results for it here beyond what that public evidence shows. Contact us for details.
Verify it yourself.
Deployment assurance levels.
Bronze
- Components
- Sealed artifact + signed receipts
- Trust assumption
- gateway operator is honest
- Use case
- Development, testing
Silver
- Components
- + Continuity chain + external timestamps (timestamps deployer-provided)
- Trust assumption
- k-of-n operators not all colluding
- Use case
- Production, enterprise
Gold
- Components
- + HSM key isolation + TEE attestation + external anchor (deployer-provided)
- Trust assumption
- Hardware enclaves are uncompromised
- Use case
- Defense, critical infrastructure
| Tier | Components | Trust Assumption | Use Case |
|---|---|---|---|
| Bronze | Sealed artifact + signed receipts | gateway operator is honest | Development, testing |
| Silver | + Continuity chain + external timestamps (timestamps deployer-provided) | k-of-n operators not all colluding | Production, enterprise |
| Gold | + HSM key isolation + TEE attestation + external anchor (deployer-provided) | Hardware enclaves are uncompromised | Defense, critical infrastructure |
What cannot be eliminated.
Total Collusion (terminal trust assumption)
If all k-of-n gateway operators collude simultaneously, receipts can be forged. This is the terminal trust assumption of any distributed cryptographic system; the threat model tracks it as gateway trust.
Policy Quality (irreducible)
AGA proves a policy was authored, approved, applied, and measured. It cannot prove the policy was correct for the situation. Policy quality is a human judgment, intentionally out of scope.
Legal Precedent (irreducible)
Cryptographic governance evidence has no case law yet. The first legal proceeding that accepts it establishes precedent. Everything before that is engineering preparation.
What happens to our evidence if Attested Intelligence disappears?
Nothing. The format is published, the verifiers are open source and pinned, and bundles verify offline with standard cryptography (Ed25519, SHA-256) on tooling you can fork today. Your records do not depend on our existence. We designed for that question, because "trust the vendor" is the failure mode this system exists to remove.
Standard cryptography, proven by two implementations.
The cryptography is standard and conformance-engineered: the post-quantum scheme is pinned to NIST known-answer vectors, and two independent implementations agree byte-for-byte. Classical Ed25519 is the live profile today. The ML-DSA-65 + Ed25519 hybrid composite (NIST FIPS 204) is implemented and cross-verified: both signatures cover the same message and both must verify, so an attacker must break both.
Migration is additive: classical records stay verifiable, and a hybrid-aware verifier still accepts them. If Shor-class quantum computers break 256-bit elliptic-curve cryptography like Ed25519 (resource estimates: Babbush et al., Google Quantum AI, 2026), ML-DSA-65 holds; if ML-DSA-65 has an undiscovered classical weakness, Ed25519 holds.