AI Agent Audit Trails for Regulators Guide

When a regulator, auditor or court asks what an AI agent did and on whose authority, most organisations can produce application logs but not evidence. An agent plans, calls tools, chains credentials and acts across several systems in seconds, and the record of that activity is usually split between a model provider's console, an orchestration framework, cloud audit logs and the target applications. This guide explains what regulators actually require of AI system logs, what an agent audit record needs to contain, how to make the trail tamper-evident and attributable, and how to retain and produce it. It is written for security, compliance and platform teams who run agents in production and expect to be asked to prove what happened.

Key takeaways

Logs are not yet evidence. A trail stands up when it is complete, attributable to a named agent identity and a human principal, time-synchronised, tamper-evident and retained for a defined period.
The EU AI Act sets a floor for high-risk systems. Article 12 requires automatic event logging over the system's lifetime, and Articles 19 and 26(6) require providers and deployers to keep logs under their control for at least six months, unless other law sets a different period.
Record the delegation chain, not just the API call. Every action should link back to the agent identity, the user or job that started it, the policy decision that allowed it and any human approval.
Do not trust the agent's own account. Agents can misreport what they did, so the authoritative record must be written by the platform and target systems, outside the agent's control.
Retention has two sides. Prompts and tool outputs often contain personal data, so log design must satisfy data minimisation as well as record-keeping duties.

What regulators actually require

No single rule defines an "agent audit trail". The duties come from AI-specific law, sector record-keeping rules and data protection law, and they overlap. The table summarises the obligations most organisations meet first. Dates and status are as published on the official sources at the time of writing and may change.

Source	Who it applies to	Logging or record duty	Retention
EU AI Act Article 12	High-risk AI systems (design duty on the provider)	Systems must technically allow automatic recording of events (logs) over their lifetime, with traceability appropriate to the intended purpose	Set by Articles 19 and 26
EU AI Act Article 19	Providers of high-risk systems	Keep the Article 12(1) logs to the extent they are under the provider's control	Appropriate to intended purpose, at least six months, unless Union or national law (especially data protection) provides otherwise
EU AI Act Article 26(5) and (6)	Deployers of high-risk systems	Monitor operation against the instructions for use; keep automatically generated logs under their control	At least six months, same carve-out for other law
EU AI Act Article 19(2) and 26(6)	Financial institutions under EU financial services governance rules	Keep the logs as part of the documentation already required by financial services law	As that law requires
US SEC Rule 17a-4(f)	Broker-dealers keeping electronic records	Records kept either with a complete time-stamped audit trail of changes and deletions, or in non-rewriteable, non-erasable format	Per the record type in the rule
GDPR Article 30 (and UK GDPR)	Controllers and processors of personal data	Records of processing, including purposes, categories of data and recipients, retention schedules and security measures	For as long as the processing continues

EU AI Act detail that shapes log design

Article 12(2) purposes: logs must record events relevant to identifying situations that may cause the system to present a risk under Article 79(1) or to undergo a substantial modification, to post-market monitoring under Article 72, and to the deployer's monitoring of operation under Article 26(5). Design your event schema against those three purposes.
Article 12(3) minimums: for remote biometric identification systems (Annex III point 1(a)) the logs must at least record the period of each use, the reference database checked, the input data that led to a match and the natural persons who verified the results. Even outside biometrics, this list is a useful model: when, against what, on which input, and who confirmed.
Article 26(5) escalation: a deployer that has reason to consider a system presents a risk must inform the provider or distributor and the market surveillance authority without undue delay and suspend use. For a serious incident, the deployer informs the provider first, immediately. The log is what lets you show when you knew.
Timing: the Digital Omnibus on AI, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. According to the European Commission's AI Act Service Desk timeline, high-risk obligations for Annex III systems now apply from 2 December 2027 and for AI embedded in Annex I regulated products from 2 August 2028. The sources reviewed for this guide do not indicate changes to the text of Articles 12, 19 or 26; check the consolidated text before relying on that.

Most enterprise agents are not high-risk systems under the Act. The Article 12 model is still the clearest public statement of what a regulator expects an AI log to do, and sector supervisors, data protection authorities and courts will ask the same questions. See the Agentic AI Compliance Guide for classification and wider obligations.

What an agent audit record must contain

An agent run produces several kinds of event. Each needs a minimum set of fields so that an investigator can reconstruct the chain without relying on the agent's narrative.

Field	Why it matters	Example source
Agent identity (stable ID and version)	Attributes the action to a specific registered agent, not a shared service account	Agent registry, OpenTelemetry `gen_ai.agent.id` and `gen_ai.agent.name`
Human principal or triggering job	Shows on whose authority the agent acted	Session token subject, ticket or scheduler ID
Delegation chain	Shows each hop where authority was passed between users, agents and services	OAuth token exchange `act` claim (RFC 8693)
Run and conversation correlation ID	Ties model calls, tool calls and downstream API calls into one story	`gen_ai.conversation.id`, trace and span IDs
Model, prompt template and configuration version	Shows what system was in use at the time, which matters for "substantial modification" questions	Deployment manifest, model gateway logs
Tool call: name, parameters, target resource	Shows exactly what the agent attempted	`execute_tool` spans, MCP gateway logs
Policy decision and reason	Shows the action was allowed by a rule, or blocked	Policy engine decision log
Human approval: approver, time, what was shown	Proves oversight was real and not a rubber stamp	Approval workflow record
Outcome and side effects	Records what changed in the target system	Target application audit log, cloud audit log
Timestamp from a synchronised clock	Allows ordering across systems	NTP-synchronised hosts, UTC with offset

Use a common vocabulary

OpenTelemetry GenAI conventions: the OpenTelemetry semantic conventions define agent spans with gen_ai.operation.name values create_agent, invoke_agent and execute_tool, and attributes such as gen_ai.agent.id and gen_ai.conversation.id. They are marked Development status, so pin the version you emit and record it in your logging standard.
Token exchange for delegation: RFC 8693 represents delegation with nested act claims. The outermost act names the current actor and nested claims name earlier actors, so a logged token can show the whole user to agent to service chain. Log the decoded claims, never the token itself.
Target system logs: keep the cloud and SaaS audit logs (for example Microsoft Entra audit and sign-in logs, AWS CloudTrail) because they are written by the system that was changed. See the Cloud Logging and Audit Trail Guide.

Where identity fits

An audit trail can only attribute what the identity model makes distinct. If five agents share one API key or one service principal, no log will tell a regulator which agent acted.

One identity per agent: register each agent with its own workload identity, owner and purpose, so that sign-in and audit logs name it directly. See the Identity Governance for AI Agents Guide.
On-behalf-of, not impersonation: when an agent acts for a user, prefer flows that keep both identities in the token (delegation) over flows where the agent simply becomes the user. Impersonation makes the agent's actions indistinguishable from the human's.
Short-lived credentials: issue credentials per task where possible, and log issuance. A credential issuance event with a task ID is often the best link between a run and its downstream effects.
Privileged functions: log every use of privileged functions by agents (NIST SP 800-53 AC-6(9)), including role assignment, policy changes and secret reads.

Making the trail tamper-evident

A regulator will ask whether the log could have been changed after the event. The answer must be "no, and here is how we know", not "we trust our administrators".

Control	What it proves	Example implementation
Separate write path	The agent and its operators cannot edit the record	Logs shipped to a separate account or tenant the agent's identity has no rights in
Hash chaining and signed digests	Any modification or deletion is detectable	AWS CloudTrail log file integrity validation: SHA-256 hashes, hourly digest files signed with SHA-256 with RSA, each referencing the previous digest
WORM storage	Records cannot be overwritten or deleted during retention	Amazon S3 Object Lock in compliance mode, where no user, including root, can delete a protected version before its retain-until date
Legal hold	Records under investigation survive normal expiry	S3 Object Lock legal hold, which has no expiry until removed by a user with `s3:PutObjectLegalHold`
Trusted time	Event order and timing are reliable	Synchronised clocks on all hosts; trusted timestamping (RFC 3161) for high-value exports
Access logging on the log store	Shows who read or exported evidence	Data-access logging enabled on the archive

Governance vs compliance mode: S3 Object Lock governance mode can be bypassed by users holding s3:BypassGovernanceRetention. Use it while you test retention settings, then move regulated evidence to compliance mode, which cannot be shortened.
Defence impairment: attackers disable or modify logging (MITRE ATT&CK T1685 Disable or Modify Tools) and remove indicators (T1070 Indicator Removal). Alert on changes to logging configuration, trail deletion and retention policy edits, and treat those changes as privileged.

Retention, minimisation and production

Set retention per event class

Security and action events: who did what, tool calls, policy decisions, approvals. Keep at least as long as the longest applicable duty: six months is the AI Act floor for high-risk systems; sector rules are often longer.
Prompt and response content: often contains personal or confidential data. Keep a hash and a reference by default, store full content only where needed for the stated purpose, and set a shorter retention with access controls. Record the purpose and retention in your Article 30 records.
Model and configuration history: keep for the life of the system plus the retention period, because a question about an old action needs the configuration that was live then.

Prepare for production to a regulator

Define an evidence pack format: run ID, timeline of events, identities involved, policy decisions, approvals, outcomes and integrity proof (digest validation result).
Write a retrieval runbook with owners, so a pack for a given run or period can be produced within an agreed time.
Include the chain of custody: who exported the data, when, from which store, and the hash of the export.
Redact personal data that is not needed for the question, and record what was redacted and why.
Test the runbook at least twice a year with a mock request.

See the Log Management and Retention Guide for retention tiers and storage design.

How to implement

Inventory agents and classify them: list every agent, its owner, identity, tools and data, and decide whether any could be high-risk under the AI Act or fall under sector rules. That decides minimum retention.
Write a logging standard: define the required fields from the record table above, the event vocabulary and version (for example a pinned OpenTelemetry GenAI version) and the clock source.
Instrument in audit mode first: enable tracing in the agent framework, model gateway and tool gateway for one pilot agent, and compare a reconstructed timeline against the target system's own audit log. Gaps show where correlation IDs are lost.
Separate and protect the store: ship logs to a separate account, enable integrity validation, and start with WORM governance mode while retention is tuned.
Add identity and approval events: log credential issuance, delegation claims and every human approval with the content shown to the approver.
Move to enforcement: switch to compliance mode for regulated classes, and block deployment of agents that do not emit the required fields.
Rollback: if logging causes performance or privacy problems, reduce content capture (hashes only) rather than switching off action logging. Never shorten a compliance-mode retention; plan the period carefully before you set it.

Decision guidance

Full content vs metadata: capture full prompts and outputs where you must explain a decision about a person or where post-market monitoring needs it; otherwise log metadata plus hashes. Full content increases breach impact and subject access workload.
Provider console vs your own store: a model or agent platform's activity view is convenient but may be deleted when the agent is removed or the contract ends. Treat it as a working view and keep the authoritative copy in a store you control.
Small organisations: a single cloud audit trail with integrity validation, a WORM bucket and one correlation ID per run covers most needs. Avoid building a bespoke platform.
Large or regulated organisations: add a central agent registry, a policy decision log, a tool gateway that logs every call, and a formal evidence production process owned by compliance.

Detection and measurement

Monitor: agent actions with no correlation ID, actions by identities missing from the registry, logging configuration changes, retention policy edits, spikes in privileged tool calls, and approvals given faster than a person could read the request.
Correlate: join agent traces with target system logs (NIST CSF 2.0 DE.AE-03) so an action seen in one place is explained in the other.

Metric	Target direction
Percentage of agent actions traceable to a registered agent identity and a human principal or job	Towards 100%
Percentage of production agents emitting all mandatory fields	Towards 100%
Integrity validation failures or gaps in digest chains per month	Zero, each investigated
Time to produce an evidence pack for a given run	Within the agreed internal target
Retention policy exceptions open	Falling

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	AU-2 Event Logging, AU-3 Content of Audit Records, AU-12 Audit Record Generation	Which events to log and what each record contains
NIST SP 800-53 Rev. 5	AU-9 Protection of Audit Information, AU-9(3) Cryptographic Protection, AU-10 Non-repudiation	Tamper evidence and attribution
NIST SP 800-53 Rev. 5	AU-6 Audit Record Review, AU-11 Audit Record Retention, AC-6(9) Log Use of Privileged Functions	Review, retention and privileged agent actions
NIST CSF 2.0	PR.PS-04, DE.AE-03	Log generation for monitoring; correlation across sources
ISO/IEC 27001:2022 Annex A	8.15 Logging, 8.17 Clock synchronisation, 5.28 Collection of evidence, 5.33 Protection of records	Logging, time and evidence handling
CIS Controls v8.1	Control 8 Audit Log Management	Collection, storage, time synchronisation and retention of logs
OWASP Top 10 for LLM Applications 2025	LLM06:2025 Excessive Agency	Recommends logging and monitoring the activity of LLM extensions and downstream systems
MITRE ATT&CK v20	T1685, T1070	Attacks on the logging itself

ISO/IEC 42001:2023, the AI management system standard, provides the management system around these controls: scope, roles, risk assessment and continual improvement for AI.

Common failure patterns

Relying on the agent's own report. In the Replit AI agent database deletion, the agent deleted production data during a code freeze and then said rollback was impossible, which turned out to be wrong. Only records written outside the agent can settle what happened.
Shared credentials. Several agents use one API key or service account, so the log names the key, not the agent. Investigators cannot separate agent activity from ordinary user or service traffic. The AEPD's description of the first AI agent data breach notified in Spain shows why recording agent involvement and the credential used matters.
Broken correlation. The trace ID is lost at the tool or MCP boundary, so model calls and downstream API calls cannot be joined.
Evidence held only by the vendor. Agent activity history lives in a platform console that is deleted when the agent is removed or the subscription ends.
Approval without context. The log shows "approved" but not what the approver was shown, so the oversight cannot be demonstrated.
Logging everything forever. Full prompts with personal data kept without a purpose or retention limit create a data protection problem of their own.

Practitioner checklist

Register every production agent with its own identity, owner and purpose.
Publish a logging standard with mandatory fields, a pinned event vocabulary and a clock source.
Carry one correlation ID from the user request through model, tool and target system calls.
Log delegation claims and credential issuance, never raw tokens or secrets.
Record every human approval with approver, time and the content shown.
Ship logs to a separate account with integrity validation and WORM retention.
Set retention per event class, at least six months for high-risk AI Act systems, and document it in your records of processing.
Alert on logging configuration changes and gaps in digest chains.
Write and test an evidence pack runbook with chain of custody.

Standards and references

Related NHI Mgmt Group resources: Identity Governance for AI Agents Guide · Agentic AI Compliance Guide · Log Management and Retention Guide · AI Agent Observability and Incident Response Guide. This guide summarises logging and record-keeping duties relevant to AI agents and is not legal advice.

AI Agent Audit Trails for Regulators Guide: Logging Evidence That Stands Up