AI agent audit trail: what it is and what it must prove
An AI agent audit trail is a record of what an agent intended, what it did, what happened, and on whose authority— captured at the moment of action, not reconstructed after.
The definition carries two tests that most logging fails. The record has to exist before anyone needs it— written automatically as the work happens. And it has to remain credible when someone challenges it— which is the entire reason audit trails exist, and the property this page is mostly about.
Last updated: 2026-06-05
Why application logs are not an audit trail
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. Intent and authority are only honest when they are signed 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.
The mechanism the field is converging on
Independent designs for agent audit trails keep arriving at the same mechanism class: append-only records, hash-chained, cryptographically signed, verifiable by a third party.
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.
What to require of any implementation
Vendor-neutral. Whether you build or buy, these are the properties that separate an audit trail from structured logging.
1.Captured at write time, not reconstructed
Intent and authority are recorded before the action runs. An agent asked afterward has lost context and reconstructs a plausible story; a record signed at the moment it was real cannot be retrofitted.
2.Append-only
Records can be added, never edited or removed. Enforced structurally — at the storage layer — not by policy documents.
3.Hash-chained
Each record carries the hash of its predecessor. Remove or alter any entry and every subsequent link breaks; gaps are detectable, not deniable.
4.Signed
Each record is cryptographically signed when written, binding it to the key that produced it. This is what makes the trail attributable — who acted, on whose authority — rather than merely ordered.
5.Attributable across delegation
When one agent hands work to another, the trail preserves the chain of authority across the handoff. Most incidents in agent systems happen at exactly these boundaries.
6.Verifiable without the operator
A third party holding the public keys can confirm the chain is intact and the signatures genuine — offline, without an account, without trusting whoever runs the system. If verification requires the vendor, the trail proves nothing about the vendor.
7.Exportable as evidence
The trail can leave the system in machine-readable, signed form for auditors, regulators, and counterparties — without the operator curating what they see.
How AGLedger implements it
AGLedger is a self-hosted cryptographic notary for automated work. Agents record intent, action, outcome, and authority as Ed25519-signed, hash-chained records — tagged COSE_Sign1 envelopes over in-toto v1 Statements, the same envelope SCITT standardizes — in a PostgreSQL database you operate.
Notarize
The trail itself — every record signed and hash-chained as the work happens, including delegation chains that preserve authority across handoffs.
Gate
When work crosses a delegation boundary, the principal renders accept or reject and the signed verdict joins the trail. AGLedger holds the record; it is not the judge.
Verify
Anyone holding the public keys can confirm the chain offline — no account, no API access, no need to trust the operator. The proof outlives the vendor.
Where the obligation comes from
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.
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.
Sources & further reading
draft-ietf-scitt-architecture — SCITT architecture (IETF, RFC Editor queue)
draft-sharif-agent-audit-trail — Agent Audit Trail logging format (individual Internet-Draft)
RFC 9052 — COSE: structures and signing (COSE_Sign1)
RFC 9162 — Certificate Transparency v2 (Merkle inclusion proofs)
Regulation (EU) 2024/1689, Article 12 — record-keeping obligation for high-risk AI systems