Agentic AI Audit Logs: The Four Claims Your Record Has to Substantiate

Pick one row out of your agent's history and try to answer the question an assessor opens with: which identity performed this write, standing in for whom, and what permitted it? Most teams can return a timestamp and a tool name. That is telemetry. Evidence is a different artifact, and nothing produces it by accident.

This guide sets out the claims an agentic record has to substantiate, which events carry each claim, and the places where a pipeline that looks healthy on a dashboard turns out to carry none of them. It is written for the platform and security engineers who will be handed the request: by an incident commander, by an external assessor, or eventually by a regulator. Treat it as engineering guidance. It is not a security audit, and it is not legal review of your own obligations.

Understanding the Four Claims a Record Has to Substantiate

Strip away the format arguments and every serious review of an agent's history tests the same four claims. Fail one of them and what you hold is diagnostic output, not evidence.

1. Attribution. A named, non-shared principal performed the action, running a known build, on behalf of a known person or scheduled job.
2. Fidelity. The action in the record is the action that reached the downstream system, with its arguments and its outcome.
3. Authorization. Something granted it: a named policy rule, a scope, or a person who pressed approve.
4. Integrity. The sequence is complete, the ordering is defensible, and the subject of the record had no way to edit it.

Regulators are starting to write this expectation down. Article 12 of the EU AI Act requires high-risk systems to technically allow automatic recording of events across the lifetime of the system, and binds that capability to three named purposes: identifying situations that may present a risk under Article 79(1), supporting post-market monitoring under Article 72, and monitoring operation under Article 26(5). For one Annex III category the article sets a floor on content: the start and end date and time of each use, the reference database consulted, the input data that produced a match, and the natural persons who verified the result under Article 14(5). Whether your system sits inside that scope is a question for counsel, and the summary on that page puts the obligation's start at 2 December 2027 for Annex III systems. The engineering conclusion holds either way. Recording is a property you design in, because retrofitting it during an investigation is miserable.

Why Conventional Application Logging Leaves a Hole Here

A service log narrates a deterministic path: a request arrived, code branched, a row changed. An agent inserts a chooser between the request and the call, and three structural gaps open underneath it.

• The trigger goes missing. A call with no pointer to the context that produced it cannot be explained afterwards. If a retrieved document carried the instruction that caused it, the investigation has to be able to name that document rather than theorise about it.
• The principal dissolves. Shared credentials collapse many actors into one. The MCP security best practices are blunt about what that costs an investigation: a downstream resource server's logs "may show requests that appear to come from a different source with a different identity," and a server handed an opaque upstream token cannot distinguish its own clients at all. The same document states that servers must not accept tokens that were not issued for them, which is an audit requirement as much as an access-control one.
• The record sits inside the blast radius. If the agent's credential can append to, rewrite or expire its own history, that history proves only what the agent was content to leave behind.

Bind Every Action to a Resolvable Actor

Emit one structured event per tool invocation and make the actor fields mandatory rather than best-effort: the agent identity, the build or prompt revision it is running, the principal it acts for, the tool, a bounded summary of the arguments, the result status and the elapsed time. Oversized or sensitive arguments get hashed so the record can prove sameness without storing the payload.

Resolvability is the part teams skip. An identity that resolves to a human owner, a team and a lifecycle is worth more than a verbose event with a service account in the actor field. Audience validation is what keeps that identity intact across a hop, so verify tokens at each boundary instead of forwarding them, and keep the mapping from agent identity to owner somewhere an investigator can query without filing a ticket.

Record the Verdict, Not Only the Call

Store what decided the action: which rule matched, which scope was presented, whether a person intervened, and what they chose. Refusals matter more than approvals in a review, because a stream with no denials in it is indistinguishable from a control that was never wired up. Shipping agents already demonstrate the shape worth copying. The Claude Code telemetry reference documents a tool decision event that carries the accept or reject outcome together with the source of that decision, separating a configured rule from a one-off human click.

Scope granularity feeds the same claim. The MCP guidance warns that an omnibus scope masks user intent per operation and advises logging elevation events with the scope requested, the subset granted and a correlation identifier. Coarse permissions do not only widen the blast radius. They erase the reason an action was allowed.

Keep a Pointer From Each Action Back to What Triggered It

For each action, retain references to the inputs the model saw immediately before it: retrieved document identifiers, message identifiers, the memory keys read, the upstream run that queued the work. You rarely need the full text. You need enough to retrieve the text later and enough to prove nothing was swapped underneath you in the meantime.

Content capture is a policy decision, not a default to drift into. Prompts and tool arguments carry personal data and secrets, so write down the capture scope, the named readers and the retention period, then run that past privacy review before the first event lands. A record that nobody is allowed to open during an incident is not much of a record either, so settle the access path at the same time.

Put the Stream Out of the Agent's Reach

Ship events to a destination whose write credential the agent does not hold, then make the destination append-only with a retention lock. Synchronise clocks across every emitter so ordering survives a challenge, and keep the collector's own receipt times alongside the source timestamps rather than letting one overwrite the other.

Then monitor the pipeline as a control in its own right. Silence from a busy agent is a finding, not an absence of findings, and it is the cheapest early signal that either the exporter broke or something is suppressing it. The detection half of this problem is covered in our guide to watching agents at runtime, and the question of which signals deserve an alert in what to measure and page on.

Prove Coverage Across the Fleet, Not the One Agent You Designed

A pipeline that covers the flagship agent and nothing else will fail the first request that names a different system. Keep an inventory with an owner and an identity per agent, and assert emission the way you assert anything else: a test that drives one trivial tool call and fails the build when no event arrives. Unregistered agents are the usual hole, so treat discovery as part of the control rather than as a quarterly clean-up.

Versioning belongs in the same inventory. If an agent's prompt, tool set or model changed mid-quarter, the record has to show which revision acted on which day. Without that, two differing behaviours look like an inconsistency instead of an upgrade, and you cannot explain either one.

How Long You Have to Keep It, and the Date That Moved

Teams argue about coverage. Retention decides whether the record still exists when somebody asks. The EU text is specific here. Article 19 of the AI Act puts the duty to keep the automatically generated logs on the provider, where those logs are under the provider's control, for a period appropriate to the intended purpose of the system and in any case not less than six months, unless other Union or national law sets a different period. The same article routes financial institutions differently: they keep the logs inside the documentation their financial services governance rules already require. So the floor is a floor, not a ceiling, and data protection law can push it the other way.

The applicability date has moved, which matters if you planned around the original one. Under the Digital Omnibus agreement, summarised by Gibson Dunn, the obligations for stand-alone high-risk systems listed in Annex III shift from 2 August 2026 to 2 December 2027, and high-risk AI embedded in products regulated under Annex I moves from 2 August 2027 to 2 August 2028. The provisional political agreement landed on 6 May 2026 and Member State representatives confirmed it on 13 May 2026, but the new dates bind only once the text appears in the Official Journal. Two consequences follow. The extra runway is real and easy to misspend: a record designed now is cheap, one reconstructed under a request is not. And since the binding dates depend on publication, the date in your compliance tracker should carry the link it came from.

Do Not Bet the Schema on a Vocabulary With No Release

The obvious move is to adopt a vendor-neutral event vocabulary and let the tooling follow. That is still premature. The OpenTelemetry generative AI conventions, which cover model calls, tool execution and whole agent runs, left the main semantic conventions repository for a dedicated one. In that repository the releases list is empty and the schema URL in the README is marked as a placeholder. Worth tracking, not yet something to pin an evidence contract to. Define your own mandatory field set, version it in every event, and keep any mapping to an external vocabulary as a collector transformation rather than your source of truth.

Two Retention Classes, Not One

Here is where most programmes actually fail, and it is not field coverage. A team argues for weeks about which attributes to capture, settles on a generous set, then applies a single retention policy to all of it. That resolves one of two bad ways. Either everything expires on the short clock the platform team chose for application logs, which quietly deletes the attribution trail at the moment it becomes useful and sits below the floor Article 19 assumes for in-scope providers. Or everything is kept for years, including prompt text and tool arguments, and the evidence store becomes the largest unmanaged collection of customer data and leaked secrets in the company.

Split it. One class holds the thin spine: actor, build revision, principal, tool, argument digest, verdict, outcome, correlation identifiers. That class is small, carries little personal data, and is the one you keep long. The second class holds the content-bearing fields: prompt text, full arguments, retrieved document bodies. Keep that class for as long as an investigation realistically needs and no longer, with named readers and encryption, and let the digests in the spine prove that a given payload was the one that ran. The spine survives; the payloads age out.

The exception is worth stating. If your legal basis for content capture is settled, your store meets the control standard your assessor accepts, and the volume is small enough that nobody notices the cost, then one long retention class is simpler, and simpler systems get operated correctly. The same applies to an agent that never touches personal data at all. Outside those cases a single policy is a choice to be wrong in one direction, and teams that defer the split usually make it under a deletion request instead.

When to Involve Counsel, Compliance and Your Auditor

Bring them in before the design freezes, not when the request lands. Retention periods, lawful basis for content capture, cross-border storage and what counts as sufficient for a given framework are not engineering calls, and they change. Agree the split too: the platform team builds the stream, security defines the mandatory event set and reads it, and the compliance owner signs off on what is kept.

A record also proves rather than prevents, so pair it with the control layers described in our layered controls walkthrough and rehearse retrieving from it as part of agentic incident response. For a worked example of how thin the default trail is on a specific product, see what a coding agent's session history leaves out.

The honest test takes an afternoon. Choose one action an agent took last month, hand a colleague nothing but query access to your event store, and ask them to establish all four claims. Time it, and write down what they could not reach. A short, candid gap list earns more credibility in a review than a confident assertion of full coverage, and it tells you precisely which event to add next.