When the record was the problem
The failure mode is simple to state. An AI coding agent deletes a production database during an explicit code freeze. Afterward, its own account of events is unreliable: it describes the damage as unrecoverable when a rollback in fact works, and it has generated data and test results that obscure what happened. The sequence has to be reconstructed forensically, from the platform's records and the operator's screenshots, because the only witness in the room was the agent.
Versions of this failure have been reported publicly. The structural lesson stands apart from any one vendor: a system’s account of its own behavior needs corroboration. Independent collection can help. Signatures protect the values collected, but neither an agent-generated log nor an AGA receipt establishes that those values describe reality completely or accurately.
The logging assumption
Logs feed monitoring tools, trigger alerts and help security teams investigate anomalies. A review also needs to ask who collected the events, what could be omitted, who can change the stored record and how a recipient checks its integrity.
The distinction is between controls and their absence, not between the words “log” and “receipt.”
A log based on self-reporting tells you what the system reported. Separate collection, signatures, and storage controls can strengthen a logging system, but the label alone establishes none of those properties. A signed AGA bundle does not prove that every action was recorded or that the system could not bypass its policy.
Three properties to examine
Unprotected logs can be changed.
An administrator with write access can change an ordinary file or database record. Retention controls, separate collection, and cryptographic integrity checks can make that harder or expose a change. The review question is which controls the actual logging system uses and what trust each control still requires.
Recording and policy checks serve different functions.
A log records what happened. It does not prevent what should not happen. A log entry that says “tool invocation denied” tells you the system reported a denial. It does not prove that a governance boundary existed, that the boundary was active at the time of the request, or that the denial could not have been bypassed. Passive recording and active governance are different capabilities. Conflating them is the root of the problem.
Check who controls collection and retention.
When a collector relies entirely on an agent's account, the agent can report compliant behavior while acting otherwise. A separate collector can instead observe requests directly. Signed records make the resulting values checkable against a key, but they do not make the collector truthful: AGA also depends on its gateway and whoever holds the signing key.
The failure class this does not fix
Another family of failures belongs to a different class, and the difference matters. An AI support bot invents a policy that does not exist, and customers act on it. A report is delivered with citations a model fabricated. Those are content-accuracy failures: the AI asserted something false. Signed decision records would not help either one, because the record of what was produced is never in dispute; the output itself is the problem. Cryptographic governance records address the first class of failure, where the question is what actually happened and the producer's own account cannot settle it. They do not make model outputs true.
What proof requires
For this use case, examine three properties. A logging system can provide some or all of them; compare the implementation, not the label.
Tamper-evidence. Against the producer's pinned key, any alteration of a signed value is detectable by any party holding the record, unless the key holder re-signs it.
A decision at the boundary. Something must evaluate each action against the policy at the moment it is decided, and be able to refuse it. A mechanism that only observes is a monitoring tool. The record of that decision shows what was decided; whether the system had another route is a property of the deployment, and the record does not prove it.
Offline verifiability. A reviewer must be able to check the record without the producer's logs: against a key pinned in advance, with no network access to the producing system and no proprietary tools. What remains is trust in whoever holds the key. If checking requires cooperation from the system being audited, it is a trust relationship rather than verification.
A record built to be checked
This is what Attested Governance Artifacts (AGA) are built for. Beside the logs, the architecture adds a signed record of each governance decision that anyone can verify offline.
In the architecture, a sealed, signed Policy Artifact encodes what a governed agent is authorized to do; without the signing key, changing any field invalidates the signature. In the published gateway, aga-proxy, the policy is a JSON file, every receipt carries the signed SHA-256 of the policy's canonical JSON, and the agent has no tool that changes the policy; it holds no signing key when the gateway runs under an identity the agent cannot read. (In aga-mcp-server 3.6.0 through 3.6.2 the governed MCP client can re-attest its own baseline, and the exported bundle does not record that.)
The gateway, a runtime boundary, evaluates each tool call against the policy and signs the decision into a receipt. In-path, aga-proxy does not forward a call it denies; whether the agent has another route to the tool is a property of the deployment. Its default profile, permissive, denies nothing on policy grounds; policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode.
Every tool call the gateway evaluates, except the calls known issue 7 on /security describes as refused without a receipt, produces a signed Decision Receipt appended to the receipt chain. Each receipt is hash-linked to its predecessor, forming a tamper-evident sequence. Changing any receipt breaks its signature and its hash link to the next receipt, so the bundle fails verification against a pinned gateway key; hiding the change would take that key, to re-sign that receipt, every later receipt and the checkpoint. Checked without a pin, a history re-signed under a new key verifies. This is a signed decision history whose integrity is checkable against the pinned key. Logging systems can use similar cryptographic controls.
Evidence Bundles package signed Decision Receipts, a signed checkpoint, and Merkle inclusion proofs into a portable verification unit. The policy is not included; on aga-proxy each receipt binds it by hash. Any party with the bundle and a public key can verify every receipt present in the record, offline, using standard Ed25519 and SHA-256. No network callback and no proprietary tooling. The reviewer no longer relies on the producer's logs; what remains is trust in the key they pinned.
Two limits hold for this record as they do for logs. 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, because completeness is bounded by where the interception point sits, which is outside the bundle. And a PERMITTED receipt records a governance decision, except a passthrough receipt, which records an MCP method the gateway passed toward the upstream without evaluating it, and does not prove the upstream received it; a receipt does not prove the tool call executed or what it returned.
The practical gap
A reviewer’s evidence needs sit within a broader risk-management process. The NIST AI RMF is voluntary guidance for managing AI risks. Its current published 1.0 framework is under revision as of September 28, 2026. This essay does not determine which legal requirements apply to a particular deployment.
FINRA's 2026 Annual Regulatory Oversight Report lists, among considerations for firms using AI agents, “how to track agent actions and decisions,” and it mentions “storing prompt and output logs for accountability.” These are considerations, not rules.
These references do not establish that AGA satisfies a legal obligation. Applicable duties depend on the system, organization and jurisdiction. The practical question is narrower: would a portable, pinned-key record help this reviewer check the signed decisions without access to the producer’s systems? Whether it improves review time remains to be tested with a real reviewer.
From recording to proving
Logging remains useful infrastructure. A logging system can also use signatures, independent collection and write-once retention. Compare those controls with the actual AGA deployment. A signature does not prove collection coverage, truthful authorship or that a denied call was blocked.
AGA adds a specific export format: signed, hash-linked decisions, a checkpoint and verification material. Where the deployment routes calls through the gateway, the gateway evaluates its configured policy and records the decisions it handles. A third party can check the retained export offline against a key obtained separately. Routing, collection coverage and key custody remain deployment responsibilities.
Edited July 1, 2026: an earlier version of this essay said "runtime governance closes that gap." AGA proves the governance record; whether a deny also blocks the action is a property of how the deployment wires the boundary. The argument here is about what can be proven afterward, which is where logs fail.
Revised July 1, 2026: retitled from "Why Logs Aren't Proof" and restructured around a 2025 incident, with a content-accuracy contrast and a FINRA 2026 note added. The argument is unchanged; the earlier edit note above is preserved. Later revisions are described in the note at the top.
Explore the technical architecture, review the published research, or explore the MCP Server on npm.
See the working implementation on npm.
AGA is a reference implementation of a published format for verifiable decision records: hash-bound policies, signed Decision Receipts, and Evidence Bundles that verify offline. The implementation is on npm. The evaluation path walks through it in working code.