Auditing rests on a basic promise: the company can explain what happened, who did it, who approved it, what changed, and show evidence that the control actually worked. That promise gets a lot harder to keep when the actor is not a person using a system, but an AI agent moving across systems, calling tools, drawing on memory, and making decisions inside a workflow.
Introduction
Most audit programs were built for a simpler evidence model: stable users, defined roles, known systems, and artifacts collected after the fact. Access reviews, change tickets, screenshots, exports, sign-offs, and logs usually pointed back to either a human decision or a deterministic system action. AI agents do not fit that model. They interpret goals, retrieve context, choose tools, hand work to other agents, and often act through service accounts or API tokens that were never designed to represent independent actors. The control may still exist on paper, but the evidence may stop answering the auditor’s real question. A screenshot can show that an approval existed. It cannot show whether the agent’s recommendation was based on current, complete, and authorized information. A log can show that an API call happened. It cannot show whether the agent should have been allowed to make that call. Traditional audit evidence captures the state. Agentic risk lives in the movement between states. That is why auditing AI agents requires more than screenshots, tickets, and logs. It requires evidence that follows the decision path.
THE SHIFT Traditional audit evidence captures state. Agentic risk lives in movement so evidence has to become replayable and tied to the decision path, not a snapshot of the result.
Access reviews are where this starts to break
A traditional access review asks whether a user, role, group, or service account has appropriate access. That works when access maps to a human job responsibility. It is much weaker when an agent acts through an API key, a delegated token, a workflow integration, or an orchestration layer.
An auditor can confirm that the service account was approved and still miss the control question that matters. The real question is whether the agent was authorized to perform this action, for this purpose, with this data, at this point in the process. An agent allowed to read vendor data for analysis is not, by that fact, an agent that should be updating vendor records, drafting a payment recommendation, or combining invoice history with bank-account changes. Old access testing asks, “Does this account have access?” Agentic workflows force a harder question: “Should this agent be using this authority right now?”
An API key is not an accountable actor. It proves something authenticated. It does not prove who acted, what goal the agent was pursuing, what context shaped the decision, or whether the authority was even still valid when the action occurred.
THE SHIFT An API key is not an accountable actor. Each agent needs its own owner, purpose, approved scope, permitted tools, and an authority boundary that expires so accountability never disappears behind a shared credential.
Segregation of duties becomes a workflow problem
Segregation of duties assumes responsibility can be separated cleanly: one person creates the vendor, another approves the payment; one person writes the code, another approves the release. That logic becomes harder to apply when work moves through a chain of agents. One agent may gather data, another summarize exceptions, another draft a recommendation, and another move the workflow forward. On a process map, the steps look separate. But the agents may share memory, context, tool access, or authority passed from an earlier step. Take a vendor exception. A vendor received a temporary approval last quarter because its banking documentation was incomplete but being remediated. Months later, an agent retrieves that record, treats the exception as still valid, summarizes the vendor as previously approved, and sends the case forward for payment review. Each step may look reasonable. The problem is that the chain changed the meaning of the evidence. A ticket can show that a change was approved, tested, and deployed through the right process. It does not show how the change was formed. If an agent wrote part of the code, recommended the configuration, or generated the pull request from stale documentation, the approval may be reviewing the output without examining the reasoning behind it. The control can look clean while the real risk sits upstream. Auditors will need evidence of the agent’s instruction, sources, assumptions, testing, and reviewer visibility. For agent-generated changes, the question is not only whether the change was approved. It is whether the reviewer had enough context to approve it intelligently.
THE SHIFT Three (or four) individually permitted actions can combine into an outcome that is not. Controls must evaluate the chain, not just each link.
Static evidence has to become runtime evidence
Screenshots and logs still matter, but they are no longer enough. A screenshot can show that an approval existed or that a ticket had the right status. It cannot show the path the agent took to get there, what context it used, whether it relied on stale memory, or whether another agent shaped the decision. Logs have the same gap. They can show that an API call happened, a report was generated, or a record was updated. They often cannot show why the agent acted, what authority it used, or whether the action should have been allowed in the first place.
That is why audit evidence has to move closer to the moment of risk. Auditors will need replayable evidence tied to the decision path: the instruction, context, memory source, tool call, policy check, handoff, human review, and final action. The control also has to move earlier. For high-risk actions, such as updating vendor bank details, deploying code, approving payments, or accessing restricted data, the system should evaluate the action before it runs. The question is not only whether the action was logged. It is whether the system challenged, approved, blocked, or escalated it at the right moment.
THE SHIFT From after-the-fact evidence to runtime guardrails. The question is no longer only whether the action was logged: it is whether the system challenged, approved, blocked, or escalated it at the right moment.
What auditors should expect next
The audit response cannot be another AI checklist. Auditors will need evidence that shows how the agent was designed, how it behaves, and what controls operated at the moment it acted. That starts with clearer agent identity: who owns the agent, what it can touch, and when its authority expires. It also means looking past access listings. Behavioral access controls should define what an agent can do based on purpose, context, data sensitivity, and workflow stage, not just whether a credential was granted.
Evals become part of the evidence package. An evaluation report should show how the agent performed against expected behavior, unsafe tool use, prompt injection, stale data, and segregation-of-duties conflicts. For higher-risk workflows, those evals can’t be one-time tests. They have to be rerun whenever prompts, tools, models, or connected systems change. Runtime security evidence carries the same weight. When an agent tries to update a vendor bank account, approve a payment, deploy code, or reach restricted data, auditors should be able to see what the system did about it before the action ran, whether it let the action through, blocked it, or escalated.
Most companies won’t be short on evidence. Screenshots, tickets, approvals, and logs will all still exist, and none of it will prove the agent was allowed to act when it did. That is the evidence auditors will need: the kind that follows the decision path.
