What Is an Agent Audit Trail?

Quick answer
An audit trail records actions, not intentions: tool calls, arguments, identities, destinations, and outcomes.
It must live outside the agent’s reach, because an agent with shell access can edit or delete local logs.
The minimum fields are run identifier, agent identity, action, target, timestamp, and result.
Retention should match the data the agent can touch, not the convenience of the logging pipeline.
A trail that cannot answer “which run changed this?” is a transcript, not an audit trail.

What does an agent audit trail need to record?

Every action that changes state or moves data: tool calls, file writes, API requests, deployments, and permission changes. Each entry needs the run and agent identity, the action, the target, the arguments with secrets redacted, the result, and the timestamp.

It also needs the human context: which ticket or prompt authorised the run, and who approved any privileged action. Without that, the trail shows what happened but not whether it was allowed.

Why does it have to be outside the agent’s reach?

Because the threat model includes the agent being manipulated. An agent that can write to its own log can hide an action, and an agent that can delete the log removes the evidence of everything in the run. Local files are for debugging, not for accountability.

Ship entries to a separate system as they happen. Append-only storage, or a hash chain that makes tampering detectable, is the difference between a log and evidence.

How long should it be kept?

Long enough to investigate an incident discovered late, and no longer than necessary for the data involved. A run that touched personal data needs a retention period that matches the privacy policy, not the default on the logging platform.

Redact secrets at write time rather than at read time. A log that contains a token and is retained for a year is a long-lived credential leak, regardless of who can query it.

How is it used in practice?

Three ways: investigating an incident, answering an audit question, and debugging unexpected behaviour. The first two need completeness and integrity; the third needs readability. Design for the first two and the third follows.

The most common use is attribution: a change appeared in a repository and nobody knows which run made it. With a run identifier on every action, that question takes seconds instead of an afternoon of git archaeology.

Where this bites vibecoders
Most setups have no trail: the agent’s chat transcript is the only record, and it is written by the agent, stored in a vendor system, and gone when the session is deleted. Add a tool-call log before the first write-capable credential.

Where AI coding assistants get this wrong

Keeping the only record in the agent’s transcript.
Logging a summary instead of the action and its target.
Writing secrets into the log unredacted.
Sharing one identity across runs, destroying attribution.
Setting retention by pipeline default rather than data sensitivity.
Storing logs on the same host the agent can modify.

Checklist

Log every state-changing action.
Include run, identity, target, arguments, result, and time.
Redact secrets at write time.
Ship to append-only storage the agent cannot write.
Set retention from the data classification.
Test that one change can be traced to one run.

FAQ

Is this the same as LLM observability?

Observability covers prompts, latency, token use, and model calls for debugging and cost. An audit trail covers actions and accountability. They can share a pipeline, but they answer different questions and have different retention needs.

Do I need it if the agent only reads?

Reads can be sensitive too: reading a customer record is an access event, and reading a private key is a potential exfiltration. Log reads of sensitive data at least, even when nothing is modified.

How do I keep the log from becoming a liability?

Redact at write time, restrict who can query it, set retention by classification, and avoid storing full prompts unless you need them. A trail is valuable evidence and a data store with its own obligations.

What is the smallest useful version?

One line per tool call with run identifier, agent identity, tool, redacted arguments, and result, shipped to a separate append-only store. That is enough for attribution and enough to begin an investigation.