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. Without an external time anchor, 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. There is no certificate chain or identity binding. 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.