AI agent audit trail: tamper-evident, attributable, verifiable offline

Logs miss the two facts that matter. A log captures what the code emitted - requests, responses, errors. It does not capture what the agent meant to do or whose authority it claimed, because nothing forced the agent to declare either before acting. Ask the agent afterward and it has lost the context; it will reconstruct a plausible story that may never have been true. We measured this failure mode directly. Intent and authority are only honest when they are recorded at the moment they are real: before the action.

Logs cannot defend themselves. Anyone with write access to the log store can alter or delete entries, and nothing in the log proves it is complete. That is acceptable for debugging. It is worthless under challenge - an auditor, a regulator, or a counterparty asking “prove this record is what was written” can only be answered with “trust us.” A log is vouched for. An audit trail is verified.

A real audit trail is not a stream of disconnected events. It is a single signed record that spans the full lifecycle of a piece of work - the intent and authority at the start, the delegation handoffs in the middle, the result at the end, and a verdict on success when the work is gated. Each stage is captured the moment it becomes real and hash-chained to the one before it.

The agent reports with its key; the notary signs what it reported. Every stage names the accountable principal inside the signed payload - usually the agent itself, a human when you need a real person in the loop - along with the authorizing chain that delegated to it. The authority belongs to the principal; the signature is the notary’s. The agent is not required to hold keys or assemble proof, which is what makes the trail honest without making the agent do compliance work. What you get is notary-attested, tamper-evident attribution.

That an agent recovers its own signed intent from this record is the developer’s reason to adopt; the same records become your audit-grade evidence with no migration. See the enforcement pattern and durable intent for that angle.

The hardest reader of an audit trail is the one who will not take your word for anything. An auditor does not want assurances about your process; they want to confirm the evidence themselves. A trail that can only be vouched for by its operator fails that reader no matter how complete it looks.

The whole point of a signed, hash-chained record is that it survives this. The auditor holds the system’s published verification keys, takes a signed export, and confirms offline, without an account, without trusting whoever ran the system, that every signature is genuine and every hash link unbroken. The proof outlives the vendor. This is verification in the strict sense - offline cryptographic confirmation - not a judgment about whether the recorded work was good. How offline verification works.

Independent designs for agent audit trails keep arriving at the same shape: append-only records, hash-chained, cryptographically signed, verifiable by a third party. AGLedger is built on the standards that form is made of.

The IETF's SCITT architecture (draft-ietf-scitt-architecture, in the RFC Editor queue) standardizes the general form: Signed Statements - COSE_Sign1 envelopes per RFC 9052 - registered on an append-only transparency log, with Merkle inclusion Receipts per RFC 9162. An individual Internet-Draft, draft-sharif-agent-audit-trail, applies the same shape directly to agents: hash-chained records with signatures for non-repudiation, mapped to EU AI Act and ISO/IEC 42001 obligations. Security vendors writing about agent logging converge on the same vocabulary - tamper-evident, append-only, signed.

The convergence is not fashion. It is the minimum mechanism that makes a record credible to someone who does not trust you - and an audit trail that is only credible to its own operator is a diary.

Organizations running consequential agent work need tamper-evident, attributable records regardless of regulation. As a downstream effect, those records map cleanly to obligations under several frameworks - the compliance pages carry the article-by-article crosswalk for procurement and GRC.

EU AI Act Article 12 requires high-risk AI systems to automatically record events over their lifetime; Articles 19 and 26(6) set six-month minimum retention for providers and deployers. See the EU AI Act mapping for the full crosswalk.

ISO/IEC 42001 Clauses 8–10 require operational evidence of AI system behavior; NIST AI RMF MAP, MEASURE, and MANAGE assume traceable records of system actions.

None of these mandates a mechanism. They specify what must be recorded and kept - the tamper-evident implementation is what keeps the kept records credible under challenge.