Architecture reference · CRG

Cryptographic Runtime Governance.

Our proposed architecture for binding runtime decisions to a policy and exporting records a reviewer can check. The published AGA packages implement only part of it.

Proposed by Attested Intelligence. Revised September 28, 2026. This is a company-defined architecture, not an independently adopted standard or a certification.

What ships today Read the definition

Canonical definition

The architecture and its boundary.

Cryptographic Runtime Governance (CRG) is the discipline of sealing software and AI agent behavior into cryptographic policy artifacts and producing tamper-evident, offline-verifiable records of the governance decisions made at runtime. Where the governed system is deployed behind the governance boundary, those same artifacts constrain which state transitions are permitted.

That definition describes the intended architecture. A valid signature does not prove that a deployment meets it. A separate process alone does not protect a key, force traffic through the boundary or establish that an action happened.

For the published format and verifier behavior, use the specification. For the distinction between this technical component and broader organizational practice, see agentic AI governance.

Three phases

Seal, capture, verify.

01 · Seal
Fix the reference
Bind the expected state and governance parameters before execution. In aga-proxy, the policy is an unsigned JSON file whose canonical hash is signed into recorded tool-call receipts.
02 · Capture
Record a decision
Evaluate at the configured boundary. The architecture also includes scheduled state measurement; the public MCP server measures only on request.
03 · Verify
Check the export
Export receipts, inclusion proofs and a signed checkpoint. A reviewer checks them offline against an expected key established separately.

Six architectural criteria

A definition, not a product scorecard.

Within this proposed definition, all six criteria are required for a full implementation. A component that satisfies only some of them is not the full architecture. The published AGA packages are such a component; no independent conformance assessment is claimed.

C1Policy fixed before execution: A signed policy artifact exists before the subject runs. Its signed boundary includes the governance parameters: measurement cadence, triggers and disclosure rules.
C2Measurement bound to that policy: The runtime compares current state with the reference hashes in the artifact, on the schedule the artifact specifies. The published aga-mcp-server measures caller-supplied content on request; scheduled measurement belongs to the private reference runtime.
C3An authorized response to drift: The architecture renders and signs a decision automatically when a measurement detects drift, using action types authorized in the artifact. Making a response affect an external system requires deployment-specific handlers.
C4A record of the measurement: The proposed measurement receipt documents the current hash, reference hash, comparison result, governance decision and chain sequence. The published MCP server's bundle records the allowed measurement call, not its internal drift or QUARANTINE verdict.
C5A tamper-evident receipt chain: Each canonical receipt, including its signature, is hashed into the next. Changing a signed value is detectable against a pinned key established separately. The key holder can still sign a different history; argument hashes do not make low-entropy inputs secret.
C6Verification without the producer: A reviewer can check the receipt signatures, signed checkpoint and Merkle inclusion proofs offline, using an expected key obtained separately. This checks the retained record, not capture completeness, independent time or the truth of its inputs.

Published implementation scope

Separate the gateway from the wider design.

Published gateway: aga-proxy evaluates routed MCP tool calls and signs the decisions it records. It does not forward a call it denies. Its default permissive profile denies nothing on policy grounds; policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode. Receipt coverage has exceptions. The bundle does not include the policy itself.
Published MCP server: aga-mcp-server measures caller-supplied content on request. Drift and TTL outcomes remain in process. A revoke_artifact call and later blocked calls appear in its bundle, but the governed client can lift quarantine, revocation or termination through attest_subject without that reset appearing in the export. Its artifact issuer key is generated per process, not a persistent independently established identity.
Private reference runtime: Scheduled measurement and the artifact check against a pinned issuer key belong to the private reference runtime, available by request. They are not capabilities of the public packages. A private implementation is not evidence of isolated deployment readiness or external validation.
Deployment responsibilities: Key isolation, traffic containment, export retention and external checkpoint custody are separate controls. In runtime 3.6.0 through 3.6.2, an environment-supplied gateway key is inherited by a stdio upstream. No published component consumes a TEE quote, measures a server binary or supplies an independently witnessed checkpoint log.

Receipts not yet exported are held in gateway memory. Earlier genuine exports can still verify; the verifier has no freshness input. Runtime 3.6.6 refuses repeated JSON members in proxy traffic; other verifier parsers retain their separately documented behavior. Tool names are plaintext, and path or pattern denials can disclose those values in the signed reason. Read the current limits and historical findings before choosing an evaluation environment.

Controls that can work together

Keep the rest of the security system.

Access controls, protected logs, policy engines, software provenance, monitoring and hardware attestation serve distinct purposes. They can also produce strong or signed evidence. CRG is not a claim that these approaches are merely advisory, always mutable or unable to prevent an action.

Choose based on the reviewer’s required record, capture coverage, trust assumptions and integration cost. Other gateways already offer signed receipts and offline checks. See the evidence comparison, threat model and limited standards mappings.

What verification proves, and does not

A verified bundle proves the integrity of every receipt present, as the verifier parses it: a field name repeated in the file still verifies, because the verifiers read the last copy (known issue 5 on /security). It does not prove the operator recorded every action.
A PERMITTED receipt records a governance decision, with two exceptions. A receipt whose tool_name is "(passthrough)" records an MCP method the gateway passed toward the upstream without evaluating it, and does not prove the upstream received it. An aga-mcp-server measure_behavior receipt records a drift finding, marked PERMITTED when the finding is not enforced. A receipt does not prove the tool call executed, or what it returned.
Receipts prove decisions were recorded and signed. They do not prove the agent could not bypass the gateway; interception placement is a deployment property.

Architecture questions.

Does CRG require TEE silicon or zero-knowledge proofs?

No. CRG uses standard cryptographic primitives: Ed25519, SHA-256, Merkle trees, and a JCS-lineage JSON canonicalization. No TEE silicon and no ZKP circuits are required. TEEs are complementary: in the architecture a TEE attestation quote could be one measurement input, and no published component consumes one. ZKPs are orthogonal. Neither is a prerequisite.

What is the difference between Agentic AI Governance and CRG?

Agentic AI governance is the organizational practice of managing autonomous AI agents. CRG is a technical discipline that makes part of it checkable: sealed policy artifacts, a separate gateway process, signed receipts, and offline-verifiable evidence bundles. The architecture is broader than the capabilities in the published AGA packages.

How does CRG apply to AI agents?

CRG proposes checkable evidence at an agent's execution boundary. Its architecture includes sealed policy artifacts and deployment-specific handlers. The published aga-proxy instead binds the hash of an unsigned JSON policy into each decision it records; aga-mcp-server measures on request. Known issues 6 and 7 on /security describe gaps in receipt coverage. The default permissive profile denies nothing on policy grounds; policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode. The signed receipt chain shows recorded decisions. It does not prove that every action was captured or that an action executed.

Can CRG operate offline, with no network?

Verification runs offline: receipt signatures, the signed checkpoint, and Merkle inclusion proofs can be checked without calling the producer. The expected signing key must already be available to check provenance. A deployed gateway may need network access to its tools; that depends on the deployment. Publishing checkpoints to an external log is a separate deployer integration and is not shipped.

What standards does CRG align with?

The control mappings on /standards identify where a published AGA mechanism contributes evidence, where it contributes only in part, and what it does not address. They distinguish those shipped mechanisms from the broader CRG architecture. A signed record alone does not establish compliance or certification.

Is CRG the same as zero-knowledge attestation?

No. Zero-knowledge proofs allow a prover to convince a verifier that a statement is true without revealing the underlying witness. CRG's privacy-preserving properties come from a different mechanism: receipts commit to arguments by hash, so integrity verifies without disclosing argument contents. In AGA 3.6.0 through 3.6.2 a path-constraint denial names the offending path in its signed reason, a denied-pattern denial names the matched pattern, and tool names are plaintext. ZKP circuits are not required and not used.

Who proposed Cryptographic Runtime Governance?

Cryptographic Runtime Governance was proposed by Attested Intelligence Holdings LLC. The company's patent filing details are on /patent: USPTO Application No. 19/433,835 (pending). This page does not characterize the application's claim scope.

Start with a static record.

Check the sample and its negative controls before considering a runtime evaluation. For citation, link to this page’s canonical definition. The original definition is retained; this revision separates it from current implementation claims.

Static evaluation Read the walkthrough