Trust the check.
Know its limits.

A passing result

The receipts present are the scope.

Signed content

The verifier checks signatures on the receipt fields defined by the format. A receipt records a decision, tool name, request ID and timestamp. A signature supports possession of the corresponding private key; naming an organization additionally requires trusted key attribution and custody.

Ordering and commitment

Hash links and the signed checkpoint bind the recorded sequence, count, head and Merkle root. A changed signed value, removed receipt or reordered sequence fails against the original commitment. A key holder can still sign a different history.

Expected issuer

Pin the expected public key from a separate trusted channel. A key copied from the bundle establishes internal consistency, not who issued it. The published verifiers do not establish organizational identity for you.

Local verification

Once you have the file, expected key and verifier with its dependencies, verification needs no producer service, certificate authority or network. Package installation or fetching a sample is a separate network operation.

Read the parsed result. Duplicate JSON field names are accepted with the last value retained. The envelope's bundle_id, schema_version, policy_reference copy and offline_capable, undefined fields and whitespace are unchecked metadata. See known issue 5.

Outside the file

What the check cannot settle.

Full capture

The bundle does not prove the operator recorded every action. Calls outside the interception point leave no receipt, and some refusal paths within it also produce none. Known issues 6 and 7 describe coverage gaps.

Execution and results

A PERMITTED tools/call receipt records approval, not that the tool ran or returned a result. A passthrough receipt records an unevaluated method sent toward the upstream, not delivery. A measure_behavior receipt can record a drift finding marked PERMITTED when not enforced.

Policy quality

aga-proxy signs the SHA-256 of the policy's canonical JSON into its receipts. The separate aga-mcp-server recording path in 3.6.0 through 3.6.2 uses an empty policy_reference. Neither establishes who approved the policy or whether it was appropriate.

Freshness and time

An older genuine export can pass. Compare a checkpoint obtained independently if you need the latest record. Timestamps use the signing gateway's clock and are not corroborated by an external time authority.

Containment

In-path, aga-proxy does not forward tools/call it denies. The default permissive profile denies nothing on policy grounds. Another route to the tool bypasses that control. A signed denial alone is not evidence that every route was blocked.

Legal or regulatory acceptance

Cryptographic verification is not a certification of compliance, admissibility or policy adequacy. Acceptance depends on the reviewer, facts and applicable requirements. We do not claim established legal precedent for AGA.

All thirteen known issues and the threat model are part of the evaluation, not exceptions to ignore after a green result.

Deployer duties

Review the boundary before running it.

The published gateway is a reference implementation before the first pilot. Network isolation, key custody, control endpoint access and evidence retention belong to the deployment. AGA does not establish those properties merely by producing a bundle.

Network and process isolation

Restrict the agent to the intended tool path and place the signing key under an OS identity the agent cannot read. Runtime 3.6.6 defaults to a loopback agent listener, with no client authentication. Host and Origin checks on the control channel do not authorize local processes. Gateway-key environment filtering does not isolate files or processes under the same OS account. Do not expose it on an unisolated workstation or assume a container alone provides the required separation.

Policy and method coverage

Use an explicit policy appropriate to the actual tool names. Only tools/call is policy-evaluated. Other methods may pass through unevaluated or unrecorded; the published CLI cannot refuse them. Exact policy modes and method coverage.

Key custody

The signer holds its key in process memory. Persist a gateway key in your own secret handling if you need a stable identity across restarts. The published proxy supports a seed file through AGA_GATEWAY_KEY_FILE. Rotation and distribution of a new trusted public key require a deliberate procedure. HSM, TPM and threshold signing are not integrated into the published gateway.

Export and retention

The live receipt chain is in memory; a restart starts a new chain. Export before stopping, retain the bundle and expected key, and test restoration. In 3.6.0 through 3.6.2 export can hold governed calls while it runs. Choose retention for the actual data, contracts and applicable rules; this page is not a retention schedule.

Cryptographic assumptions

Standard methods. Explicit scope.

The live signer uses Ed25519 and SHA-256. Integrity depends on signature unforgeability, hash collision resistance and correct implementations. Key compromise defeats issuer assurance; the key holder can produce another signed history.

ML-DSA-65 + Ed25519 composite signing is implemented as a library export, not the live default. Both signatures cover the same message and must verify. The published hybrid verifier is aga-proxy verify; aga-verify and Python aga-governance support Ed25519 bundles only.

The 28 composite conformance cases measure agreement between implementations, not independent validation of the complete construction. External timestamps, HSM isolation, TEE attestation and external checkpoint retention are architectural directions, not integrated assurance tiers available to deploy today.