The AI Agent Audit Trail

An agent audit trail is evidence a party who was not there, and does not trust you, can check. A log is what a system says happened.

An AI agent audit trail is the evidence that lets someone who was not there, and who does not trust you, establish what an agent did. That is a higher bar than logging. A log is a record of what a system says happened, written by the system, stored by its operator, and editable by whoever administers the store. An audit trail has to survive a reader who assumes you might be wrong or might be lying. The difference is not volume or retention. It is whether the record can be checked independently of the party that produced it.

What separates a trail from a log?

Three properties, and each one can be missing on its own.

Completeness. Every action is recorded, including the ones that were refused and the ones that failed. A trail of successes describes a different system from the one you are running.
Integrity. A record cannot be altered or removed after the fact without that being detectable. NIST's log management guidance treats protection of log integrity as a primary requirement rather than a nice property (NIST SP 800-92).
Attribution that the actor cannot deny. The record binds the action to the identity that authorised it, with evidence the identity itself produced. This is the control NIST files as AU-10, non-repudiation (NIST SP 800-53 Rev. 5).

What does tamper-evident actually buy?

Hash chaining is the mechanism. Each record commits to the one before it, so removing or editing any record breaks every record after it. Haber and Stornetta described the construction and its purpose in 1991: a document's time-stamp is made verifiable without trusting the time-stamper, by linking records together and publishing the links (Haber and Stornetta, 1991).

Chaining alone is not enough, because the party holding the chain can rebuild it. What closes that gap is publication to someone else. Certificate Transparency is the large scale example: logs are append-only, they issue signed commitments, and independent monitors and auditors check them, so a log that presents two different views can be caught (RFC 9162). Trusted timestamping does the same job for time, by having a third party sign a hash at a moment (RFC 3161). The general rule holds for agent records too: a record only you hold is a record only you can edit.

What do the rules require to be recorded?

The EU AI Act requires high-risk systems to "technically allow for the automatic recording of events (logs) over the lifetime of the system", at a level of traceability appropriate to the intended purpose (Regulation (EU) 2024/1689, Article 12(1) and 12(2)). Article 26(6) then puts retention on the deployer, for a period appropriate to the purpose and of at least six months. The detailed minimum fields in Article 12(3) apply to Annex III point 1(a) systems, not to every high-risk system.
The DORA technical standard requires logging of events on "logical and physical access control ... and identity management", and that logs be protected "against tampering, deletion, and unauthorised access" (Commission Delegated Regulation (EU) 2024/1774, Article 12(2)(c)(i) and 12(2)(d)).
ISO/IEC 27001:2022 Annex A carries A.8.15, Logging, and A.8.16, Monitoring activities. There is no ISO control named non-repudiation; AU-10 is a NIST identifier and does not transpose.

What has to be in the record of one agent action?

An agent record is only useful if it lets a reader reconstruct the decision, not just the outcome. That takes seven fields.

The action as proposed: operation, target, arguments.
The version of the policy the decision was made against.
The decision, including refusals and holds that expired.
The inputs the decision turned on, as the deciding side computed them.
Who approved, as identities that signed, with the time.
Which identity performed the action, and against which system.
The outcome, including failures.

Field two is the one usually missing, and without it the rest cannot be audited. "Allowed" is not a finding. "Allowed under this rule, in this version, which these two people signed" is.

Where does the audit trail fail?

Outcome only. The action is logged, the decision is not, so nobody can tell whether it should have run.
The administrator can rewrite it. Root on the log store is root on the evidence. Adversaries treat log removal as a routine step (MITRE ATT&CK T1070).
Retention shorter than discovery. Incidents are typically found long after the first action. A window that closes first makes the question unanswerable.
Prompts and tool output stored wholesale. The trail becomes a secondary copy of your secrets and personal data, with a wider readership.
Sampling. A sampled trail cannot answer whether a specific action happened.
Nobody verifies. A signed record that is never checked is a claim. A receipt transmitted but not verified is exactly what an attacker sends.
Unlinked records. Three systems each holding part of the story, with no shared identifier, is an investigation rather than a trail.

Refusals belong in the trail as first class records. An injected instruction that tried to delete backups and was refused is evidence, and it is the only way to measure how often the boundary is being tested. What the boundary can still permit is the subject of containing a successful injection.

What does a ZIFFER receipt contain, and what does it prove?

A ZIFFER receipt is the signed record of one decision: the proposal it answers, the grade, the quorum that met, the identities that signed, and when. It is signed under two independent signature algorithms and verification requires both, your executor verifies it before acting, and every receipt joins an append-only ledger anchored where a second party can read it. The format and the verification rules are published, so a party who does not trust the vendor can check a receipt with the receipt, the proposal bytes and a public key, and nothing else: see the specification for what that proves and what it does not, and every refusal for the names a verifier raises. Two limits stated plainly: the SDK does not store, forward or log receipts, so keeping them is your job, and the clause by clause standards position is in agent controls mapped to DORA, the AI Act, NIS2 and ISO 27001. The decision that produced the record is covered in agent authorization.