What an audit trail for AI agents must show

The question What will auditors ask about agent actions?

Why ordinary logs miss the agent

A coding agent runs as a process under the account of the person who started it. It uses their files, their tokens and their network. So the operating system, Git and your cloud provider all record the person. The log says the engineer deleted the file, not that an agent did. Network logs show that a laptop called a model API, but not which program called it or what the request carried. For how far that access goes, see What can an AI coding agent reach on a laptop?

Some agents report on themselves through hooks. Claude Code, for example, can run a hook before each tool call, and the hook can block the call. But a user can switch hooks off in their own settings, unless an administrator set them through managed settings. An agent with no hooks, or a script that calls a model API directly, reports nothing at all.

An agent's account of its own actions is not evidence either. In July 2025, Replit's agent deleted a live database during a code freeze. It then said a rollback would not work. Fortune reported that the user recovered the data himself. Treat an agent's report on itself as a lead to check, not as the record.

Then there is volume. In GIRD's 19-day case study, 306 agent runs in one week produced 20.1 million recorded actions. That week, agents' own processes opened password and key files 29 times. Each of those reads ran under an engineer's account. You need a record built for agents, next to the logs you already keep.

The fields every entry needs

NIST SP 800-53 control AU-3 says an audit record must show what happened, when, where, its source, its outcome and who was involved. For an agent, that means nine fields plus a seal.

Record blocked actions as well as allowed ones. CERT-In's FAQ asks for successful and unsuccessful events alike. Keep raw secrets and personal data out of the entry. NIST's own guidance on AU-3 warns that audit trails can expose personal information. Where AI agents leak your keys covers the secrets side.

Here is an illustrative entry, read as a sentence. At 10:42:07 IST, Claude Code tried to read ~/.aws/credentials on a managed laptop. An engineer on the platform team had started it to fix a failing test. The credential-file rule blocked the read, because the task needed no cloud keys. Store each field in a fixed schema, such as JSON, so the SIEM and auditors can query it.

Seal each entry so changes show

An audit trail only helps if you can show nobody edited it. Tamper-evident means a removed or changed entry is detectable. It does not mean change is impossible.

The usual design gives each entry a cryptographic seal, computed over its contents and the previous entry's seal. Delete or edit one entry, and every seal after it fails to check. Verify the seals on a schedule and after every incident.

Keep the signing key, or a copy of recent seals, outside the system that writes the log. Otherwise anyone who controls the writer can rebuild the seals over an edited copy. Limit delete rights to a few people, none of whom run the agents being logged.

NIST asks for the same properties. Control AU-9 protects audit information from unauthorised change and deletion. Its enhancements add cryptographic protection and storage on a separate system. OWASP's agentic threat guide names the failure T8, Repudiation and Untraceability: agent actions that cannot be traced or accounted for.

Retention, residency and the SIEM

Keep entries for the longest period any rule sets for you. In India, CERT-In requires logs of all ICT systems for a rolling 180 days, within Indian jurisdiction. Its FAQ adds that copies may also sit outside India, if you can produce them in reasonable time.

From May 2027, the DPDP Rules add one year for logs of personal data processing. Under the EU AI Act, once its high-risk rules apply, deployers of high-risk AI systems must keep their logs at least six months. CERT-In, DPDP and AI agents covers the Indian rules in detail.

Stream entries to the SIEM as they happen, so the security team can alert on them and correlate them with other events. CERT-In's FAQ already lists SIEM logs among the logs to keep. Raw actions can run to millions a week, so send every decision and every departure from an agent's normal behaviour. Keep the full record searchable for investigations.

Which agent did this, and who ran it

Every investigation starts with this question. A good record answers it in four steps.

1. Start from the target: the dropped table, the leaked file or the odd outbound request.
2. Find the entries that touched it, and the agent session behind them.
3. Read the person and team, the device and the task for that session.
4. Read the policy and decision for each step, and whether a person approved it.

Agents also start subagents and hand work to other agents. Each entry should carry its parent session, so a chain of agents still leads back to one person.

If any step needs guesswork, an auditor will find the gap. So will CERT-In, which wants logs with your incident report, due within 6 hours of noticing the incident. If the trail leads to an agent nobody approved, read Shadow AI agents: what they are and how to find them.

What the frameworks require

None of these frameworks was written for coding agents. Each still asks for records that an agent audit trail supplies.

The European Commission says AI agents fall under the AI Act's definition of an AI system. An agent is high-risk only if its use falls in a high-risk category, such as those listed in Annex III. Even when it is not, Article 12 is a clear statement of what a log must do.

In an ISO/IEC 42001 or SOC 2 audit, show the control and proof that it ran: sample entries, seal checks and alert tickets.