AI Agent Audit Trail: What to Log, How Long to Keep It and How to Prove Control to an Auditor

An AI agent audit trail is a tamper-evident, append-only record of each agent run: who or what triggered it and on whose behalf, which sources it retrieved, which model and version responded, every tool call with its arguments and result, each policy decision and approval, and the final output or action. Keep it inside your own perimeter on synchronised clocks, and retain it for at least six months where the EU AI Act's high-risk rules apply, or longer where sector law or your own risk assessment requires.

The test of an audit trail is easy to state and hard to pass: can someone outside the engineering team reconstruct one run months later and show that every action in it was permitted? The sections below cover the record itself, its integrity, its privacy limits and the retention rules, and end with the questions auditors ask. The security guide for agentic AI explains why the same record also matters for detecting attacks.

Audit trail, observability and telemetry are different jobs

Teams often assume their tracing tool doubles as an audit trail. It rarely does, because the three serve different readers.

OpenTelemetry’s semantic conventions for generative AI show why a trace is not automatically evidence. The conventions, which moved to their own repository in 2026 and are still marked Development, define spans such as invoke_agent and execute_tool, but make tool-call arguments and results, prompts and model outputs opt-in attributes because they may contain sensitive information. A default trace can show that a tool ran without showing what it was asked to do. Observability is covered in the guide to logs, traces and audits for agents, the agent observability explainer and the comparison of LLM observability tools.

What an AI agent audit trail should record for each run

Record one entry per step, linked by a run identifier, so that a run involving several agents and tools can be rebuilt as a tree.

Store references rather than copies where content already lives under its own access control, but keep enough to reconstruct the decision: a document ID without a version or hash cannot prove what the agent read once the document changes. The governance and security handbook gives a field-level trace schema, and decision receipts for regulated agent workflows package the same fields into one reviewable record per consequential decision.

Making the audit trail tamper-evident

Sooner or later an auditor asks how you know the record has not been changed. Four measures answer the question.

Append-only, write-once storage. Write entries to storage that cannot be overwritten or deleted before the retention date, such as object storage with a retention lock or a WORM archive, administered by a team other than the one running the agents. US broker-dealers know the pattern: SEC Rule 17a-4(f)(2)(i) requires electronic records to be preserved either with a complete time-stamped audit trail of every modification and deletion or in a non-rewriteable, non-erasable format.

Hash chains and signed checkpoints. Put a hash of the previous entry into each new one, so that removing or editing any entry breaks the chain, and sign the latest hash at intervals. Merkle-tree logs of the kind Certificate Transparency uses (RFC 9162) add inclusion and consistency proofs, and a time-stamping authority under RFC 3161 can show that a checkpoint existed at a given moment.

Synchronised clocks. Timestamps from drifting hosts make a multi-agent run impossible to put in order. DORA’s risk-management standards require financial entities to synchronise the clocks of their ICT systems to a documented reliable reference time source, ISO/IEC 27001:2022 lists clock synchronisation as Annex A control 8.17, and NIST SP 800-92 asks administrators to keep every logging host on a common time source.

Protection and failure detection. Restrict who can read the trail, since it concentrates sensitive data, and alert when logging stops. The DORA standards name both duties: protect logging systems and log information against tampering, deletion and unauthorised access, and detect a failure of logging systems.

Privacy: minimisation, pseudonymisation and erasure

A log of agent runs holds personal data whenever prompts, documents or tool arguments mention people, so the GDPR applies to the log itself.

• Minimise. Article 5(1)(c) limits personal data to what is necessary for the purpose. Log the fields an auditor needs rather than whole conversations by habit, and redact sensitive values before they are written.
• Pseudonymise. Replace direct identifiers with tokens and keep the mapping separately under its own access control, as the definition in Article 4(5) requires; Article 32(1)(a) names pseudonymisation and encryption among the measures for securing processing.
• Limit storage. Article 5(1)(e) allows identifiable data to be kept no longer than necessary. Set retention per field group, because the skeleton of who, what and when may need to outlive the payload.
• Handle erasure requests. The right to erasure in Article 17 does not apply where processing is necessary to comply with a legal obligation or to establish, exercise or defend legal claims, under Article 17(3)(b) and (e). Records a law requires can usually stay; convenience copies cannot.

The AI Act points the same way: its six-month minimum for logs applies unless Union or national law, in particular data protection law, provides otherwise. Deletion across indexes, caches and derived data is covered in retention and erasure for private RAG, and the pii-redact tool can strip personal data before an entry is stored.

How long to keep AI agent logs: EU AI Act logging requirements and other rules

Two sets of dates frame the EU rules. DORA has applied to financial entities since 17 January 2025. The AI Act’s high-risk obligations apply from 2 December 2027 for Annex III systems and from 2 August 2028 for products under Annex I, after the Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the dates. Most agents will not be high-risk, yet six months is a sensible floor for any agent that touches customers or regulated decisions, because complaints and disputes can surface long after the event.

Which agents fall under the high-risk rules is covered in the EU AI Act for AI agents, and how DORA’s ICT rules reach AI in DORA and AI. For a high-risk system, the AI record-keeping agent drafts an Article 12 logging specification.

What auditors ask, and the fields that answer

Questions about oversight deserve particular care, because an approval record without the evidence shown to the approver proves only that a button was pressed. The EU AI Act’s expectations are explained in human oversight for high-risk AI systems, and the evidence pack checklist for on-premises AI shows how logs turn into audit artefacts. Logging permission decisions is the other half of proving access control; the guide to AI agent permissions covers how those decisions are made.

How to test an AI agent audit trail before an auditor does

A reconstruction drill, run each quarter and after any change to the logging pipeline, finds the gaps while they are still cheap to fix:

1. Pick a consequential run at random and rebuild it from the trail alone: initiator, sources, model version, each tool call and the approval. Every missing field is a finding.
2. Compare the trail with the downstream system’s own records of the same changes. Timestamps that disagree point to clock drift; changes with no matching entry point to lost events.
3. Verify the hash chain against the latest signed checkpoint, then try to edit or delete an entry with an administrator account and confirm the storage refuses.
4. Stop one log source on purpose and check that the alert fires.
5. Plant a test secret and a test personal identifier in a run, then search the stored trail to confirm both were redacted.

Keep the drill record. It is evidence in its own right that the control operates, which is what an auditor tests.

Common gaps in AI agent audit logging

Prompts logged, tool arguments missing. Prompt and response logging is common, while tool arguments and results are often left out because default tracing treats them as optional. Without them you can see that an agent called a payments tool, but not with which amount or payee.

Approvals with no context. A record that says a named user approved at a given minute does not show whether that person saw the right payload or had time to read it. Store what was presented and how long the decision took.

Logs held in a vendor cloud. When the trail sits in a provider’s console, its retention, export and access follow the provider’s terms. Article 26(6) obliges deployers to keep logs only “to the extent such logs are under their control”, which is a reason to keep them under yours, not a loophole.

Unpinned model versions. Logging an alias such as “latest” makes reproduction impossible once the provider updates the model behind it.

Broken correlation across agents. When work passes between agents and tools, each component must carry the same run ID or the trail falls apart into fragments. The 2026-07-28 MCP revision documents how to carry OpenTelemetry trace context in request metadata, which helps keep tool calls on the same trace.

Secrets and personal data in the log. Traces capture what agents see, including tokens pasted into tickets and customer details in documents. Scan and redact before storage.

Silent logging failures. If a log pipeline stops, nobody may notice until an investigation finds the gap. Alert when any source stops sending.

How VDF AI fits

Each agent in VDF AI Agents writes its own audit log and execution trace: the input and who sent it, the retrieval hits it used, every tool call with its arguments, what the model returned and the output it produced. Reviewers can search that record with audit-trail-query, which filters an append-only, tenant-scoped audit trail by time, actor or resource.

Approval evidence lives with the run. If a consequential step pauses at an approval gate, or at the Human Approval node of VDF AI Networks, the review, the reviewer and the time it took are stored together with that run, and human-approval-request records the approver’s identity. Networks keep an execution history with provenance, and VDF AI Router attaches a reason and the candidate list to every routing decision.

Across agents and Networks, the AI governance platform adds a Vault that holds a cryptographically durable record of every execution, decision receipts that hash the prompt, sources, model, tools and outcome together, and evidence packs for the EU AI Act or a sector audit built from those records. Its controls are mapped to the EU AI Act, DORA, NIS2, GDPR and ISO 42001; the mapping supports your evidence but does not make a system compliant on its own. Run in your own data centre, a private cloud or an air-gapped network, the whole trail stays in your custody, and the Trust Center lists the deployment options.