Article

What audit evidence do you need for AI agents?

Rajesh Seshadri Appikulam

Senior Director, Identity Security Services, Simeio

We tend to build systems in fear of audits, trying to get into the mind of an auditor and making sure we have the right answers. And while sometimes it skews our priorities or adds biases towards over-logging, there’s no doubt that asking yourself the questions an auditor will result in higher resiliency.

For agent actions, here’s what an auditor might ask you about an action from weeks ago, such as a deleted record or an export:

Which agent did this?
Under what entitlement?
With whose approval?
On whose authority?

As this project demonstrates time after time, the first question is relatively easy and the last question is extremely hard.

Why is the authority question so complex? Because it’s the only one that can’t be reconstructed unless it was written down at the moment of the action. The decision chain isn’t a native part of our logging. So if an application log names a service account, which belongs to an OAuth client shared by every agent in the platform, there won’t be a human anywhere in the record.

Even with OAuth 2.0 Token Exchange, the most you’re getting is an act claim: a nested chain of delegation. It doesn’t tell you what user request led to the action, whether they consented, and why the specific tool was picked for it. An auditor would need those to establish authority.

If you expect newer technology to be better prepared to answer the authority question, you’re mistaken. Take the MCP standard: it has no field to establish which human triggered a specific task, even after the 2026-07-28 revision. So you still need to inject it, together with a correlation ID, at the point of invocation.

Audit Classes

Class	The question	What passes	What fails
Identity and registration	Does this agent exist in your inventory, with a named human owner?	Registry entry with agent ID, owner, purpose, approval record, model and version	An agent discovered during the audit; an offboarded owner
Authorization	Who granted this scope, and when was it last reviewed?	Entitlement grant with approver and date, scope change history, access review that treats the agent as a reviewable identity	Agent excluded from the quarterly review because it is not in the IdP
Action	What did it do, to what data, on whose behalf?	Per-action record carrying the human, the delegation chain, and the data classification	Application log with a service account name
Human oversight	Where a human was required? Prove they were there	Per-decision record: reviewer identity, timestamp, the output they saw, what they changed	A policy document describing an approval workflow
Lifecycle and change	Prove the control operated for the whole period	Credential rotation events, prompt and tool and model version history, decommission record	Sample snapshot

The EU AI Act requires the people involved in verifying results to be identifiable in the log for certain high-risk systems (Article 12(3)(d). That would include the name, the timestamp, and the output the reviewer actually saw.

The evidence record

These fields cannot be reconstructed later, so they have to be written at the moment of the action.

Field	Why it has to be captured live
`event_id`, `correlation_id`	The correlation ID will let you stitch the task back together across MCP servers
`human_principal`	This is the one place in which the accountable person can be recorded for everything that happens downstream
`agent_id`, `agent_version`	Agents can change between versions, so the version will tell you what the instruction set was
`model_id`, `model_version`	Another thing that changes the behaviour is a model change
`tool_name`, `mcp_server`, `server_version`	Yet another place where version change can influence behavior
`delegation_chain`	Ordered `act` claims, so multi-hop calls stay attributable
`trigger_source`	User prompt, schedule, webhook, or another agent. This is how we separate autonomous and delegated actions
`consent_ref`	Pointer to the consent or request that authorized this action
`parameters`	Needed, but can be redacted or hashed.
`data_classification`	Drives which framework’s retention rule applies to this record
`policy_decision`, `rule_id`	Allow, block, or redact, and the specific rule that decided it
`approval_ref`	Links to the human oversight record where one was required
`outcome`, `error`	Attempted-and-blocked is evidence that the control works
`timestamp`, `clock_source`	Mixed clock sources across servers make ordering unprovable
`integrity_hash`, `sequence`	Lets you demonstrate the record has not changed since it was written

What each framework actually requires

Framework	Clause	What it demands	Retention
EU AI Act	Art. 12 record-keeping, Art. 19 provider logs, Art. 26(6) deployer logs	The system must technically allow automatic recording of events over its lifetime. Manual records do not satisfy it. For Annex III point 1(a) systems: period of each use, reference database checked, input data producing the match, and the natural persons verifying results	At least six months (Art. 19(1)), to the extent the logs are under your control
ISO/IEC 42001:2023	A.6.2.8, one of 38 Annex A controls	You must determine and document at which phases of the AI system life cycle event log recording is enabled. Design and development and testing count, not only production	Set by your own AIMS; you are audited against what you wrote
SOC 2	CC6.1–6.3 logical access, CC7.2–7.3 monitoring and event evaluation	Agent treated as a non-human identity: authorization evidence, actions attributable to an accountable person, logs the agent cannot alter	Full observation period, typically 12 months for Type II
PCI DSS 4.0.1	Req. 10.2 log content, 10.5.1 retention	Non-human accounts logged and reviewed on the same footing as human ones, with user ID, event type, date and time, success or failure, origin, and affected resource	12 months, with the most recent 3 immediately available
NIST AI RMF 1.0	Govern, Map, Measure, Manage	Voluntary. Useful as the structure your evidence hangs on when an auditor asks how you decided what to log	Not prescribed

Three notes on status

The relevant EU AI Act clauses will be enforced on 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I.
No harmonised logging standard exists. prEN 18229-1, the European logging standard intended to carry the presumption of conformity with Article 12, reached the Enquiry stage in mid-2026. Its international counterpart, ISO/IEC 24970, is at FDIS.
US work is at the concept stage. The NCCoE published Accelerating the Adoption of Software and AI Agent Identity and Authorization in February 2026; NIST's Center for AI Standards and Innovation launched its AI Agent Standards Initiative the same month.

How Long to Log? Depends on Compliance

There’s no good rule of thumb for retention. If you want, for example, PCI DSS compliance, six months will not be enough. For the EU AI Act, on the other hand, it will be.

The right solution here is to create a class-based retention policy, rather than a system-based one. Yes, you’ll need to classify data according to the regulatory standards it needs to conform to, but that’ll save you a lot of time, effort, and money later.

Who Watches the Watchmen? Not the Agent!

Finally, there’s the identity issue. If the agent can write to the log store, your evidence is meaningless. The separation of duties might be a human concept, but it applies here in the same way.

How will the agent write into the evidence store, then? Ideally, it won’t. Brokers on its path will.

What is the bigger challenge: missing audit evidence or understanding it?

AI agents usually do not fail audits because organizations lack logs. The larger issue is correlation and comprehension: evidence is often spread across disconnected systems that were never designed to work together. A single agent transaction can touch systems such as:

Identity provider
Secrets vault
MCP or tool-call layer
Cloud infrastructure logs
The business system being changed
A second or third agent platform

Many enterprises now run multiple agents across platforms such as Salesforce Agentforce, Copilot Studio, Bedrock, and custom-built environments.

‍

Frameworks such as ISO 42001 and the EU AI Act’s Article 12 make clear that logs must be automatic, tamper-evident, and traceable. They do not, however, explain how to connect evidence scattered across platforms that lack a common schema or identity model.

The hardest problem is not proving what an agent did; it is understanding the lineage of activity and identifying which human authorized the action, especially when one agent delegates to another. No single product solves this end to end. Organizations therefore need AI and NHI discovery tools to show ownership across platforms, gateways to capture tool activity, and identity-layer delegation standards to help prove consent.

Audit readiness must therefore be designed into the architecture before agents go live, rather than reconstructed after the fact.

If you fail, this is likely how it’ll happen:

You’ll assemble evidence at audit time.
You’ll use one shared client for every action.
You’ll let screenshots stand in for continuous operation.
You’ll measure coverage in log sources, not agents.

The ten-question test

Each of these should take under five minutes to answer:

Pick any agent action from 60 days ago.

Can you name the human it acted for?
Can you list every tool it invoked in that session, in order, across all servers?
Can you show the approval record for its current scope, and the date of the last review?
Was the agent included in your most recent access review as a reviewable identity?
Can you produce the reviewer's name and decision for an action that required human approval?
Can you prove the log record has not changed since it was written?
Can the agent itself write to, rotate, or delete that store?
Can you show when its system prompt, tool list, or model last changed?
Can you produce the decommission record and revocation confirmation for an agent you retired?
For any agent in production, can you name its owner today?