AI Agent Audit Trail: What to Log

An AI agent audit trail is a record that lets you replay what an agent did, why it did it, and who approved it. Not a pile of text logs. A record.

If an auditor asks “what happened on ticket 4471,” you should answer in minutes, not days.

This post gives you a minimum schema, the retention and access rules I would set, and a checklist. It also covers the part people skip: the log itself can leak the data you are trying to protect.

Why a normal app log is not enough

A normal application log tells you a server handled a request: status code, latency, maybe an error. That works when software does the same thing every time.

An agent is different. It reads context, picks tools, calls them, and changes its plan based on what comes back. The same request can take a different path tomorrow. If you only log the request and the final answer, you cannot explain the middle. And the middle is where the risk is.

Two things make agents harder to audit. The model, not your code, chooses the next step. And actions have side effects: an agent can send an email, update a record, or approve a refund. Those need the same trail you would want for a human employee.

OWASP lists excessive agency as a top risk for LLM applications. Its guidance includes requiring a human to approve high-impact actions and to “log and monitor the activity of LLM extensions and downstream systems.” That is the job of the audit trail.

Regulators are heading the same way. Article 12 of the EU AI Act says high-risk AI systems must technically allow for the automatic recording of events over the lifetime of the system. The goal is traceability. If your agents touch the EU, read our EU AI Act guide to see if you are in scope.

The minimum log schema

Here is the schema I would start with. Every agent run gets one run ID. Every step inside it gets a step ID and a timestamp. All records link back to the run.

Field group	What to record	Why an auditor cares
Request	Run ID, timestamp, who or what triggered it, channel, task type	Shows who started it
Identity	Agent name, agent version, the end user or service account it acted for	Shows on whose authority it acted
Model	Model name and version, provider, key settings (temperature, max tokens)	Shows what produced the decision
Instructions	System prompt version ID, tool list version, policy version	Lets you rebuild the exact setup
Context sources	IDs and versions of documents, records, or search results that were read	Shows what the agent saw
Tool calls	Tool name, parameters (redacted), result status, duration, error	Shows what the agent did
Policy checks	Rule that fired, allow or deny, reason	Shows controls worked
Approvals	Who approved, when, what they saw, what they decided	Shows human oversight
Outcome	Final result, who received it, side effects, error state	Shows what changed
Cost	Tokens in and out, tool cost, total time	Supports budget and anomaly review

A few notes on this table.

Version everything you can. A classic audit gap is “we cannot tell which prompt was live that day.” Give prompts, tools, and policies version IDs.

Log context by reference. Store the document ID and version, not the document. You can fetch the document later if you need it. This keeps your logs small and your risk lower.

Log denials. A blocked tool call is evidence your controls work.

Write the log before you act. For any action with side effects, record the intent first, then the result. If the process crashes between the two, you still know what was attempted.

For general practice, NIST SP 800-92 is the long-standing reference on log management. It predates agents, but the basics hold.

Approvals and who did them

Human approval is where audits get sharp. “A human approved it” is not an answer. You need to show which human, when, and based on what.

For each approval, log:

The approver’s identity (a real user ID, not a shared account)
The time they saw the request and the time they decided
What was shown to them: the proposed action, the key inputs, any risk flags
Their decision: approve, reject, edit
If they edited, the before and after values
The policy that required the approval

The “what they saw” field matters most. If an approver clicked yes on a screen that hid the amount, the approval means little. Store a reference to the exact view or payload they were shown.

Also log auto-approvals. If a rule lets low-risk actions go through without a human, record the rule and its version. Our guide on least-privilege permissions pairs well with this: the fewer actions an agent can take, the fewer approvals you need to explain.

Article 12 names this idea for one class of high-risk systems: the logs must identify the natural persons involved in verifying results. Even outside that class, it is a good rule.

Sensitive data inside logs

Here is the trap. An audit trail full of raw prompts and outputs becomes a second copy of your most sensitive data. And logs usually get weaker protection than the source system.

OWASP’s guidance on sensitive information disclosure lists personal data, financial details, health records, and credentials as things LLM apps can expose through outputs. Logs are one more place that exposure can happen.

My defaults:

Redact before you write. Strip or tokenize names, account numbers, health details, and secrets in tool parameters and outputs. Never log credentials or API keys.
Store hashes for proof. A hash of the full output lets you prove later that a stored copy matches what the agent produced, without keeping the text in the log.
Keep raw content in a separate, locked store. If you need full text for debugging or disputes, put it in a restricted store with a short retention window and tight access. Link to it by ID.
Tag sensitivity. Mark each record with a data class so retention and access rules can follow the tag.

For personal data in the EU, GDPR Article 5 sets two principles that apply directly: data minimisation (keep only what is necessary) and storage limitation (keep identifiable data no longer than necessary). That creates a real tension with audit needs. The answer is to keep the structured record long and the raw content short.

Retention and access

How long? There is no single number. It depends on your industry and your lawyers. Some anchors:

Under the HIPAA Security Rule, 45 CFR 164.316 requires you to retain required security documentation for 6 years from creation or the date it was last in effect. Whether a specific log counts as that documentation is a question for counsel. I would not guess.
The text of Article 12 requires logs to be recorded but does not state a retention number in the paragraphs I read. Check the rest of the Act and your own legal advice.
Your contracts may set a number too.

My recommendation: use two tiers.

Tier	Contents	Suggested approach
Structured audit record	IDs, versions, decisions, approvals, outcomes, hashes	Keep long, set by your strictest rule
Raw content	Full prompts, outputs, documents	Keep short, delete on schedule

The numbers are yours to set with legal. The split is the part I would insist on.

Who can read them? Fewer people than you think.

Engineers get debug access to redacted records.
Compliance and security get read access to the full structured record.
Raw content needs a ticket, a reason, and a log of who looked.
Nobody gets edit or delete rights on audit records. Not admins, not the agent itself.

An agent’s service account should never be able to alter the trail that describes its own behavior.

Make tampering visible. “Tamper-proof” is a big promise. I prefer “tamper-evident.” Write to append-only storage, restrict write paths, and chain or sign records so changes show up. As an example of the pattern, AWS CloudTrail’s log file validation uses SHA-256 hashing and signed digest files delivered every hour, so you can check whether a log changed after delivery. You can apply the same idea to agent logs.

Observability tools do not replace the audit trail. Debug traces are for engineers and often get sampled or expire fast. An audit trail is complete and kept. See our observability tools comparison for the debugging side.

Answering an auditor

An auditor does not want your dashboard. They want a sample, an explanation, and proof the controls ran. Prepare for these questions:

Auditor question	What answers it
Show me what the agent did on this case.	Run ID lookup, full step list
Who approved this action?	Approval record with identity and timestamp
What version of the system was live?	Model, prompt, tool, and policy versions on the record
What data did it read?	Context source IDs and versions
Did any control block something?	Policy check and denial records
Could someone have changed this record?	Access rules plus integrity checks
How long do you keep this?	Written retention policy per tier
How do you handle personal data in logs?	Redaction rules and data class tags

The test I would run quarterly: pick five random runs. Give someone who did not build the system 15 minutes to reconstruct each from logs alone. Where they fail, you have gaps.

The AI governance gap post explains why many companies have policies but no evidence. The audit trail is the evidence.

A starter checklist

Use this before you take an agent to production.

Schema

Every run has a unique run ID, and every step links to it
Agent, model, prompt, tool, and policy versions are recorded
Context sources are logged by ID and version
Every tool call logs name, redacted parameters, status, and duration
Denied and failed actions are logged, not just successes
Intent is written before any action with side effects

Approvals

Approver identity is a real user, not a shared account
The view or payload the approver saw is referenced
Edits store before and after values
Auto-approval rules are logged with version

Data protection

Redaction runs before write
Secrets never enter logs
Raw content lives in a separate store with short retention
Records carry a sensitivity tag

Retention and access

Written retention policy for each tier, reviewed by legal
Read access is role-based; nobody can edit or delete records
Access to raw content is itself logged
Integrity checks run on a schedule

Readiness

Quarterly five-run reconstruction test, with a named owner

Bottom Line

Log the decision path, not just the answer. Version everything, record every approval with the approver’s identity and what they saw, and keep raw content out of the long-term trail.

Split storage into two tiers: a long-lived structured record and a short-lived raw store. Make records tamper-evident and unwritable by the agent.

Next step: run the five-run reconstruction test on your current agent. The gaps you find are your build list.

FAQ

What should an AI agent log? At minimum: a run ID, the identity it acted for, model and prompt versions, the context it read, every tool call with redacted parameters, policy decisions, approvals, and the final outcome. Log denied actions and failures too.

How long should logs be kept? It depends on your industry, contracts, and counsel. For example, the HIPAA Security Rule requires 6 years for required security documentation, but whether an agent log counts is a legal call. I suggest keeping the structured record long and the raw content short.

Who can read them? Give engineers redacted debug access, give compliance and security read access to the structured record, and require a ticket and a reason for raw content. Nobody, including the agent’s own account, should be able to edit or delete audit records.

Do logs themselves hold sensitive data? Yes, if you log raw prompts and outputs. Redact before writing, store hashes instead of full text where you can, and keep raw content in a separate store with tight access and a short retention window. Privacy rules like GDPR’s data minimisation and storage limitation apply to logs too.

What will an auditor ask? They will ask you to reconstruct a specific case, show who approved it, show which versions were live, show what data the agent read, and prove the record was not changed. If your logs answer those five questions fast, you are in good shape.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect

AI Agent Audit Trail: What to Log and Why