AI Agent Audit Trails: What to Capture Before It Counts as Proof

Last week I asked where your AI policy actually fires LINK: Your AI Policy Isn’t a Control Until It Fires. This week I want to ask what happens after it fires.

Can you prove it did?

Here’s the scenario I keep coming back to. An agent in your environment changes something it shouldn’t have. Maybe it’s a permission, maybe a config, maybe a record in a system of record. Someone from audit, or legal, or the board’s risk committee asks a very simple question: who authorized this?

Most organizations think they can answer that. The data says otherwise.

Riverbed just published a survey of 1,200 business decision-makers, IT leaders, and technical specialists across seven countries, conducted by Coleman Parkes in July. 77% say their organization is hesitant to let AI make operational decisions without human approval. That’s a good instinct. But the same survey found 51% lack enough oversight of AI agent performance and reliability.

Delinea’s 2026 Identity Security Report, which we dug into last week, makes the gap sharper. Just 36% of IT leaders can always trace a sensitive AI access event back to a named human authorizer, “even though nearly all organizations require named-individual approval for at least some sensitive use.” Delinea’s own conclusion: “The gap lies in execution rather than in the rules.”

So nearly everyone requires approval. About a third can prove who gave it.

Approval is a control. The record is the evidence.

I want to pull those two things apart, because I think they get treated as one.

An approval step is a control. It’s the moment a human says yes or no. A record of that approval is evidence. It’s what lets you show, later, that the yes happened, who said it, and what exactly they said yes to.

Most programs build the first and assume they get the second for free. They don’t. If the approval happens in a chat thread, or a ticket that isn’t linked to the action, or in someone’s head because “the agent only does that one thing,” you have a control with no evidence behind it. When the question comes, you’ll be reconstructing the answer from memory and screenshots.

And the question will come. Regulators are already paying attention to agent behavior, auditors are learning to ask about it, and boards want to know who’s accountable. “Our policy allows it” isn’t an answer. Policy says what was permitted in general. Evidence says what was authorized in this case.

What attribution looks like from the outside

If you want to see what it looks like when you can’t answer “who did this,” look at what happened to the Wikimedia Foundation.

On October 5^th, Wikimedia said it found activity by agents it believes were operated by OpenAI. Most were test edits in sandbox areas. But some edits targeted the configuration of a citation tool in what Wikimedia thought could be attempts to turn it into a proxy, and agents unsuccessfully tried to use the foundation’s public Etherpad to fetch data from other sites. The traffic ran to millions of API requests and millions of crawled pages, and may have contributed to a partial outage of the Wikidata Query Service in May.

Wikimedia found no evidence its systems or data were compromised. What it did flag was “the difficulty and effort involved in investigating and attributing this activity.”

A few days earlier, SecurityWeek covered research from Transluce and others on agents probing US and Canadian government sites. More than 200,000 requests hit a Department of Education site, including one basic SQL injection probe. More than 10,000 of those requests carried a tag beginning with “oai,” which the researchers said could indicate OpenAI involvement.

Notice the language. Believes. Likely. Could indicate.

That’s what attribution sounds like when you’re on the receiving end and the only evidence you have is whatever the agent chose to send you. Wikimedia’s ask was modest: AI companies’ systems “should operate in a way that non-profit website owners like us can easily identify.”

Here’s the point for enterprise teams. Inside your own environment, you aren’t on the receiving end. You issue the identity. You set the scope. You own the logs. You don’t get to settle for “likely.”

The borrowed-credential problem

The trouble is that even inside the enterprise, logs often can’t tell a person from an agent.

Eric Woodruff, Chief Identity Architect at Semperis, walked through this in Dark Reading with a coding agent working in Azure. When the agent used his own account, the result was exactly what you’d expect: “Claude did the work but Azure activity logs show the user’s context.” The log said Eric did it. Eric didn’t do it.

Giving the agent its own account helps, but Woodruff showed how fragile that is on a shared endpoint. The agent shares the user’s context, so after switching accounts he had to sign out and back in “if I want to ensure that audit logs continue to accurately persist who I am.” And he asked the question every audit team should be asking: “What if AI just took off with whatever authenticated context it already finds (as occasionally happens)?”

His conclusion: “log ambiguity is not what you want when trying to understand why something happened.”

That’s the core of this week’s argument. A log that records a human identity for an action an agent took isn’t just incomplete. It’s wrong. And it’s wrong in the most damaging direction, because it puts a named person on the hook for something they didn’t do, while the actual actor disappears.

Don’t build audit theater

Before I go further, I want to head off the obvious overcorrection, which is “log everything.”

Ann Barron-DiCamillo, CISO at U.S. Bank, said something in a Help Net Security interview this month that’s worth taping to the monitor of anyone building an agent audit program: “many organizations still over-invest in compliance activities that provide evidence of security rather than security itself.”

She wasn’t talking about agents specifically. But the warning applies directly. You can generate terabytes of agent telemetry and still not be able to answer the one question that matters. Volume isn’t evidence. A log that records “an action happened” without telling you whether a person or an agent took it, who stood behind it, and whether it was in scope is paperwork. It satisfies a checklist and fails you in an incident.

The test I’d use is simple. Can this record answer “who authorized this?” for one specific action, quickly, without a forensic project? If yes, it’s evidence. If no, it’s noise with a retention policy.

We already know what an audit record needs

Here’s the encouraging part, and it’s the same point we’ve made all series. We don’t need a new framework for this. We need to check our reins and saddles on the one we already ride.

NIST SP 800-53 has told us what an audit record has to contain for years. Control AU-3, Content of Audit Records, says each record should establish what type of event occurred, when, where, the source, the outcome, and the “identity of any individuals, subjects, or objects/entities associated with the event.”

Read that last item again with agents in mind. Individuals, subjects, or entities. An agent is a subject. If your record only captures the individual, it fails AU-3 for agent actions.

AU-10, Non-Repudiation, goes further. It calls for “irrefutable evidence that an individual (or process acting on behalf of an individual) has performed” the covered actions. A process acting on behalf of an individual. NIST wrote the agent problem into the control catalog before anyone called them agents. The record has to bind both: the process that acted and the person it acted for.

ITIL change management gives you the same structure from the operations side. A change record already captures who requested the change, who approved it, what was changed, and whether it followed a pre-approved template or went through review. Last week we mapped agent actions onto ITIL’s standard, normal, and emergency changes. This week’s job is making sure each one leaves the same kind of record a human change would.

You don’t need to adopt a whole new world view here. You need one filter: look at your existing audit and change records and ask whether they’d still make sense if the actor were an agent.

What an agent action record has to capture

If you’ve followed the Artificial Identity work LINK: FuBAC and Artificial Identity, most of this will look familiar. The nine attributes we defined for an agent identity aren’t just for provisioning. They’re the fields your evidence has to reference.

For every consequential agent action, the record should capture five things:

1. The agent’s own identity. Not the human’s session, not a shared service account. A discrete identity, tied to the agent’s defined Purpose and Capabilities, that it can’t borrow its way out of.
2. The accountable owner. The named person who authorized this agent and its purpose. This is the Owner attribute, and it’s the answer to “who authorized this?” If the agent was acting for a specific user in this action, record that too, separately.
3. The policy decision at the moment of action. What was evaluated, against which rule, and the result. Record denials as well as approvals. A blocked action is evidence the control fired, and it’s often the evidence you most need.
4. The scope in force. Which credential, which tool, which permission set applied when the action ran. This is where Conditionals and Credentials show up in the record.
5. The end of access. When the task or session closed, and proof the access went with it. This connects back to Lifecycle and Termination conditions, and to the week 14 lesson about credentials nobody retires.

That’s it. Five fields, all of which map to attributes you’ve already defined. The work is wiring them into the record at the moment the agent acts, instead of trying to reconstruct them afterward.

The platforms are starting to help

You don’t have to build all of this from scratch, and the tooling is moving in the right direction.

Microsoft Entra’s Agent ID logs now carry an agentType property on the initiatedBy, performedBy, and target resource fields. Microsoft’s documentation says “A value other than notAgentic indicates agent involvement,” and distinguishes an agent identity from an agent’s user account, which “lets an agent act as a user with user-delegated permissions.” That’s exactly the person-versus-agent distinction Woodruff’s example was missing. Note the caveat in the same docs: because agents can sign in with delegated or app-only permissions, their sign-ins may show up across all four sign-in log types. You’ll still need to pull them together.

Microsoft’s 2026 Digital Defense Report also lists agent identity, appropriate access, authentication between agents, attribution, and the ability to revoke access among the security considerations for agents. When a major platform vendor puts attribution on the same list as identity, it’s a signal auditors will follow.

On the open-source side, Help Net Security covered Tuskira’s AI Agent Gateway, which sits between agents and their MCP tools and model providers. It checks a role-bound key and profile on each call, attaches the real credential only for allowed calls, and logs denied calls without letting them reach the backend. That’s the policy decision becoming a record. It also shows the limit: the article doesn’t describe tying calls to individual human users, and an unbound key can name any profile. A call log is a start. It isn’t the same as tying an action to an accountable person.

None of these is a complete answer, and I’m not recommending any of them. They’re useful because they show where the evidence can come from.

Where the real work is

In TechVision’s five-layer agent governance model, evidence isn’t a separate layer. It’s what the other layers leave behind. Discovery and attribution tells you the agent exists and who owns it. Discrete identity gives it a name the log can use. Runtime enforcement makes the policy decision. Behavioral monitoring and termination closes the loop. If each layer writes its piece to the record, you get proof as a byproduct.

What we see in our advisory work is that each piece exists in a different system. The owner is in a spreadsheet or a governance tool. The identity is in the IdP. The policy decision is in a gateway or nowhere. The action is in the application log. Nothing joins them. So every “who authorized this?” becomes a manual investigation, which is a small version of what Wikimedia went through. If that’s where you are, the fastest win usually isn’t a new tool. It’s agreeing on a common identifier that every one of those systems records, and making sure it’s the agent’s identifier, not the human’s.

Five steps from policy to proof

1. Pick one agent and run the test. Choose a single consequential action from last week and try to name who authorized it. Time it. That number is your baseline.
2. Give every agent its own identity in the logs. No shared service accounts, no borrowed human sessions for consequential work. If your platform supports an agent identity type, use it and filter on it.
3. Record the owner and the on-behalf-of user separately. The person accountable for the agent and the person it’s acting for in this action aren’t always the same. Capture both.
4. Log the policy decision, including denials. If the decision isn’t in the record, you can’t show the control fired.
5. Check your existing audit records against AU-3 and AU-10. Ask whether they’d still hold if the actor were an agent. Where they wouldn’t, that’s your gap list.

The bottom line

Almost every organization has decided a human should approve sensitive agent actions. That’s the right call. But an approval nobody can prove is just a story you tell the auditor.

The good news is that we already know what proof looks like. NIST told us what an audit record has to contain, and it anticipated a process acting on behalf of a person. ITIL told us how a change record ties requester, approver, and action together. The Artificial Identity attributes tell us which fields the agent’s record needs to reference.

So here’s the question I’d bring to your next governance review. Not “do we require approval for agent actions?” You almost certainly do. Ask instead: for the last thing an agent did, how long would it take us to name who authorized it?