AI agent audit trails: what to log and how to prove it's intact
When an agent does something it shouldn't, the first questions are who, what, when and who allowed it. An audit trail should answer all four, and still be believable when the answer is embarrassing.
Why you need one
Incident review. An agent emailed the wrong customer, or refunded the same order twice. You need the exact call, the arguments, and the decision path to work out whether it was the prompt, the tool, the policy or a person.
Compliance. SOC 2 asks you to monitor system activity and control logical access; an agent with production credentials is a user whose activity needs monitoring. ISO/IEC 27001:2022 has a control for logging (Annex A 8.15) that expects logs to be protected from tampering. For high-risk AI systems, Article 12 of the EU AI Act requires automatic record-keeping of events. Whether these apply to you depends on your situation, but they all ask for roughly the same thing.
Trust inside the company. The fastest way to get an agent approved for real work is to show exactly what it did last week.
What to record for every tool call
| Question | Field |
|---|---|
| Which agent? | Agent name, and the config or policy version it ran with |
| Acting for whom? | The person or team accountable for it (the principal) |
| What did it try? | Server, tool and arguments, with secrets redacted |
| What was decided? | Allowed, held, denied; the rule that matched and its reason |
| Who said yes? | The approver or rejecter, their note, and when |
| What happened? | Completed or failed, with a summary of the result |
| When? | A UTC timestamp for every step, and an ID tying the steps together |
Log the denied and timed-out calls too. "The agent tried to delete the customers table four times on Tuesday" is often the most useful line in the file.
What not to record
The audit trail is a long-lived copy of everything the agent touched, so it can easily become the most sensitive file you own. Redact API keys, passwords and tokens, card numbers and government IDs before the line is written, not afterwards. Keep personal data to what you need to identify the action. If you need the full payload for debugging, keep it somewhere else with shorter retention.
Making it tamper-evident
Most teams start with an application log or a database table. Both share a problem: anyone with write access, including an attacker or an admin having a bad day, can change a row and nothing shows it. An audit trail that can be silently edited is weak evidence.
A hash chain fixes the silent part. Each entry includes the cryptographic hash of the entry before it, and its own hash covers that link:
{"seq":41,"event":"call.pending", "tool":"send_email",…,"prev_hash":"07c1…","hash":"9f2c…"}
{"seq":42,"event":"call.approved","tool":"send_email",…,"prev_hash":"9f2c…","hash":"41ab…"}
{"seq":43,"event":"call.completed","tool":"send_email",…,"prev_hash":"41ab…","hash":"d3e0…"}Change anything in entry 42 and its hash no longer matches its content. Delete it and entry 43 points at a hash that doesn't exist. A verifier walks the file in seconds and names the first bad entry.
To defend against someone rewriting the whole file from the edit onward, record the latest hash somewhere they can't reach: versioned object storage, a ticket, a scheduled message, or a timestamping service. Anyone holding that hash can later prove the log up to that point is unchanged. We walk through the mechanics, with code, in Tamper-evident audit logs in 40 lines.
Retention and export
Decide retention up front. A year is a common floor for SOC 2 evidence; your legal team may want longer. Plan for the auditor's question too: they will want a CSV for a date range, and ideally a way to re-check integrity themselves. A log that includes both hashes on every row lets them do that without trusting you.
Checklist
- Every tool call is logged, including denied and timed-out ones.
- Each entry records agent, principal, tool, redacted arguments, decision, rule, approver and outcome.
- Secrets and card numbers are redacted before writing.
- Entries are hash-chained and the file is append-only.
- The chain is verified on a schedule, and the latest hash is stored elsewhere.
- You can export a date range as CSV in one command.
- Someone reads it weekly.
SpotAgentIQ writes this log for every MCP tool call that passes through it. spotagentiq verify checks the chain and spotagentiq export produces the CSV. See the audit log docs for the format.