AI Agent Audit Trails: What to Record Before the Auditor Asks

Once an AI agent starts taking actions — updating records, sending messages, moving money, calling APIs — the question changes from "is the output good?" to "can you prove what happened?". Most teams can answer the first question. Very few can answer the second, and that gap tends to surface at the worst possible moment: an ISO 27001 audit, a cyber insurance renewal, or a customer's security team working through a supplier questionnaire.

We have written before about why audit trails matter for agentic AI. This piece is about the practical side: what your log actually needs to contain, where it needs to live, and who reviews it.

Why an agent changes the logging picture

Traditional application logs record what your software did. An AI agent is a different animal, because three things are running at once: a model making probabilistic decisions, a workflow engine executing steps, and tools acting on live business systems. A log that captures only the final action cannot answer the questions an auditor will ask.

Specifically, an audit trail for an AI agent run needs to answer:

What did the agent see? (the input, including any retrieved context or documents)
What did it decide, and with which model and agent version?
What did it actually execute, step by step?
Who approved it, if a human approval was in the loop?
What changed in the underlying systems, before and after?

What to record for every run

At minimum, each execution should capture:

Identity: which agent ran, which version, which model underneath it. "The AI did it" is not an audit answer; version 2.4 of your triage agent acting through a named model is.
Input: what the agent received — the message, document, or trigger, including any context retrieved from your knowledge base. Retrieval-augmented agents are only as auditable as their sources.
Tool calls and parameters: every external action the agent took, with the parameters passed. This is usually the line of evidence that reconstructs an incident.
Before and after state: what a record looked like before the agent edited it and after. Most disputes reduce to this.
Approvals: any human sign-off in the chain, tied to a named person or role, with a timestamp.
Outcome and errors: what completed, what failed, and what the agent did in response to the failure.

Append-only storage matters here. If the log can be edited after the fact, an auditor will treat it as a claim rather than evidence, and they will be right to.

The UK compliance angle

Two obligations make this more than good hygiene.

The UK GDPR accountability principle means you must be able to demonstrate how personal data is processed — and an agent updating customer records is processing, whether or not a human clicked the button. Your records of processing activities should reflect automated agents as processing operations, not sit silently beside them.

If ISO 27001 is in scope — increasingly a condition of enterprise contracts — logging and monitoring are explicit controls in the standard's Annex A. Auditors do not accept "we use a platform that probably logs things". They ask to see the log, the retention policy, and the review routine.

Insurers are moving the same direction. When a cyber renewal asks how you detect and investigate unauthorised changes, an AI agent audit trail is fast becoming part of the answer.

Who checks the log, and how often

A log nobody reads is an expense, not a control. Two routines cover most SME needs:

Monthly sample review: pull a handful of agent runs at random, read them end to end, and confirm the actions match the intent. This catches drift — a prompt that has slowly degraded, a tool permission nobody meant to grant.
Exception alerting: define the actions that should never happen without a named approver — refunds above a threshold, deletes, anything touching privileged systems — and alert when they occur.

Someone has to own both routines. Not "the team", not the agent platform. A named person.

Red flags worth fixing now

Your logs record prompts but not the actions the agent executed.
Agent runs are not versioned, so you cannot tell which behaviour produced an old result.
The audit trail lives in a system the agent itself can modify.
Human approvals are recorded as a generic "approved" with no identity attached.
Nobody can name the retention period for agent logs, because nobody chose one.

None of these require a big programme to fix. Structured logging, append-only storage and a named owner get you most of the way there, and the tooling is ordinary — the discipline is the hard part.

If your team is rolling out agent workflows and you want an independent view on what an auditor, insurer or enterprise customer will expect to see, get in touch via the contact page.