What signed records add to a deployment review

Start with the handoff.

Suppose a team sends a reviewer an export of tool-call decisions. The reviewer has the expected signing key through a separately agreed channel. They need to establish which recorded requests were permitted or denied, which policy reference the receipts commit to, and whether the supplied record verifies under that key.

That is the task an AGA evidence bundle can support. The signed fields, receipt chain, Merkle proofs and signed checkpoint give the reviewer a defined construction to check outside the producer's dashboard. The usefulness of that handoff depends on the recipient needing it and accepting its limits.

Keep the questions separate.

What was recorded?

The verifier checks signed fields and the consistency of the supplied bundle. Establishing the issuer also requires a trusted association between the expected key and that issuer.

What actually happened?

A permitted decision does not prove that a tool ran or returned a particular result. Whether a denied action reached a tool is a deployment question. Use independent observation and integration tests for those claims.

What is absent?

The supplied chain cannot establish that all activity was captured, that the export is the latest one, or that the key holder never signed another history. Coverage, freshness and independent witnessing need separate evidence.

A record does not evaluate a model.

Model evaluations, traces, policy controls and retained records answer different questions. A signed tool-decision receipt does not detect hidden intentions, explain the model's reasoning or establish how it behaves outside the observed workflow. It also cannot make an incomplete policy sufficient.

A deployment can combine those controls. The important engineering work is to establish the actual call path, protect signing keys and credentials, define the recorded events, and observe whether the control behaves as intended. A separate process alone does not prove that the agent cannot read its key or bypass it.

Inspect the shipped boundary.

The published aga-proxy evaluates covered MCP tools/call requests and does not forward a call it denies. Its default permissive profile denies nothing on policy grounds. The operator must choose a policy that fits the workflow and qualify how the agent reaches its tools.

Receipts bind the policy's canonical JSON hash, but the bundle does not establish that the policy was appropriate or that every refusal produced a receipt. Some refusal paths produce no receipt; see the documented capture limitation. Continuous runtime measurement and the proposed synthetic-response mode are separate from the published decision-record path.

Make the integration earn its place.

The existing stack may already provide an acceptable signed export, protected logs and a verifier the recipient can use. Compare the artifact format, key distribution, coverage and maintenance burden before adding another component. Offline verification and signatures are available in other systems too.

The current AGA reviewer case is synthetic. It demonstrates an inspectable record and its failure controls; it is not a customer deployment or an independent usefulness result. A useful next evaluation starts with one real recipient's question and measures whether this handoff helps answer it.