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 the signer possessed the private key corresponding to the embedded public key.
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 without access to 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 for verification.
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. Roughtime IETF corroboration is available but optional. Without Roughtime enabled, 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, not 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.
Enforcement Boundary
The public components described on this site (MCP gateway, Python SDK, evidence bundles) provide observation and proof. A separate, private runtime component provides enforcement by ensuring the agent cannot bypass the governance gateway. The enforcement runtime is not open-source and is available under separate licensing. Contact us for details.
Verify It Yourself
Every claim on this page can be tested against public artifacts.
Deployment Assurance Levels
AGA supports three tiers of deployment assurance. Each tier adds cryptographic and infrastructure guarantees that reduce the trust surface.
| Tier | Components | Trust Assumption | Use Case |
|---|---|---|---|
| Bronze | Sealed artifact + signed receipts | Portal operator is honest | Development, testing |
| Silver | + Continuity chain + external timestamps | k-of-n operators not all colluding | Production, enterprise |
| Gold | + HSM key isolation + TEE attestation + external anchor | Hardware enclaves are uncompromised | Defense, critical infrastructure |
What Cannot Be Eliminated
After every engineering mitigation is applied, three risks remain. Every system terminates in assumptions. Ours are smaller than any competing approach, and we name them explicitly.
Total Collusion
If all k-of-n TEE-hosted Portal operators collude simultaneously, receipts can be forged. This is the terminal trust assumption of any distributed cryptographic system.
Policy Quality
AGA proves a policy was authored, approved, enforced, and measured. It cannot prove the policy was correct for the situation. Policy quality is a human judgment, intentionally out of scope.
Legal Precedent
Cryptographic governance evidence has no case law yet. The first legal proceeding that accepts it establishes precedent. Everything before that is engineering preparation.
Quantum-Resistant Signing
AGA supports ML-DSA-65 + Ed25519 hybrid composite signatures (NIST FIPS 204). Both signatures are produced over the same message and both must verify for acceptance. No downgrade attacks are possible.
This provides quantum resistance today while maintaining compatibility with existing Ed25519 infrastructure. If Shor-class quantum computers break Ed25519 (per Babbush et al., Google Quantum AI, March 2026), ML-DSA-65 remains valid. If ML-DSA-65 has an undiscovered classical weakness, Ed25519 remains valid. An attacker must break both simultaneously.