AI agent audit trails: what to record, and what your records can prove

An AI agent does not just answer questions. It calls tools, edits files, opens pull requests, moves money, sends messages. Sooner or later one of those actions gets questioned — by a customer, an auditor, a regulator, or your own incident review — and what you can say at that point depends entirely on what you recorded at the time.

Building a useful audit trail for an agent is really two problems, and teams usually only notice the first one. Completeness: did you capture the right events? Credibility: can anyone other than you believe the record? This post covers both, including the record-keeping duties the EU AI Act now attaches to high-risk systems.

What an AI agent audit trail should record

Chat transcripts are not an audit trail. The transcript records what the model said; the questions that matter later are about what the system did. A trail worth keeping records, for every run:

• Which code and model ran. Agent and skill versions, the model identifier, and content hashes of the code that executed, not just a version string someone can retag.
• The inputs. The task or prompt, the configuration, and the policy in force. Store sensitive payloads as SHA-256 digests rather than plaintext: a hash proves the input was what you say it was without retaining the data itself.
• Every tool call. Name, arguments, result and exit status. Tool calls are where an agent touches the world; a trail that omits them records the commentary and drops the actions.
• What changed. Files written, diffs applied, messages sent, records created, again as digests, so the artefact can be checked against the record later.
• Timing. Start and end of the run and of each step. This is not gold-plating: for biometric systems, Article 12(3) of the EU AI Act requires logging "the period of each use of the system (start date and time and end date and time)" explicitly.
• Human involvement. Which steps ran under an approval, and who gave it. When something goes wrong, the first question after "what happened" is "who signed it off".

The regulatory floor: EU AI Act record-keeping

If your agent falls in the Act's high-risk category, record-keeping stops being a best practice and becomes a duty with numbers attached. Three articles of Regulation (EU) 2024/1689 do the work:

• Article 12 requires high-risk AI systems to "technically allow for the automatic recording of events (logs) over the lifetime of the system", covering events relevant to identifying risk, post-market monitoring, and monitoring of operation by deployers.
• Article 19 obliges providers to keep those automatically generated logs, to the extent they are under their control, for a period appropriate to the system's purpose and at least six months.
• Article 26(6) places the mirror-image duty on deployers: keep the logs your high-risk system generates, again for at least six months, longer where other EU or national law (data protection in particular) requires it.

On timing: under Article 113 the Act applies generally from 2 August 2026, which brings the obligations for high-risk systems listed in Annex III with it; systems that are high-risk because they are safety components of regulated products (Article 6(1)) follow from 2 August 2027.

Most coding and operations agents are not high-risk systems under the Act. But the transparency duties in Article 50 already apply to systems that interact with people or generate content, and if you are going to keep records at all, the Act's six-month retention floor is the obvious number to copy rather than invent your own.

A complete log can still prove nothing

Suppose you record all of the above faithfully. You now have a trail that is excellent for debugging and incident response — and still worthless the moment someone outside your organisation needs convincing.

The problem is authorship. Application logs are written by the same system they describe, stored on infrastructure the operator controls, and editable by anyone with write access to the store. When the record's author is the party whose conduct is in question, the record cannot clear them. Security practice has long treated missing or unprotected logs as a top-tier weakness (it is A09 in the OWASP Top 10), but integrity is a separate property from existence. A log that exists, is complete, and could have been rewritten yesterday answers "what happened?" only for people who already trust you.

We have written up the full argument in why logs are not evidence; the short version is that WORM storage, centralised log collectors and hash chains each move the trust boundary without removing it.

Making the trail verifiable

The fix is mechanical, and none of it is exotic cryptography:

1. Hash every artefact the run touched, so the record commits to specific bytes rather than descriptions.
2. Serialise the record as canonical JSON, so there is exactly one byte sequence a signature can cover.
3. Sign it at execution time with an ed25519 key held outside the agent's reach, so neither the agent nor a later intruder can rewrite history without breaking the seal.
4. Anchor it in a transparency log, so the record provably existed before the dispute did.

That turns your audit trail into a receipt anyone can check offline, with no access to your systems:

$ pip install traceseal-verify
$ traceseal-verify receipt.json
[OK] receipt.json — operator signature verified

We walk through what that verification actually proves in an earlier post, and the honest limits matter here too. A signed receipt proves the record has not changed since it was sealed and who sealed it. It does not prove the record is complete: an action taken outside the instrumented path leaves no receipt at all. That is why receipts pair naturally with sandboxing the agent — the sandbox narrows what can happen off the record, and the receipt seals what happened on it.

A checklist you can apply this week

• Record tool calls and artefacts, not just conversation.
• Hash sensitive inputs and outputs instead of hoarding them.
• Retain records for at least six months, the floor set by Article 19 and Article 26(6).
• Sign records when they are made. A trail you start keeping after the dispute begins says nothing about what came before.
• Rehearse retrieval: if you have never pulled a specific run's record under time pressure, you do not know whether you can.

The receipt format, verifier and transparency log are open — the spec, the verifier on PyPI, and the public log. You can adopt the format without adopting us.