Identity vs agency (and why your audit log suddenly feels… philosophical)

At some point, every organization running agents hits the same moment:

“Why did I do that?”
“You didn’t.”
“The audit log says I did.”
“Yeah… about that.”

Welcome to attribution in AI agentic systems: the discipline of proving – later, under stress – who caused what, what actually acted, under what authority, and why it happened.

If you’re thinking “audit logs already do that”, I have good news: you’re about to build a better system.
If you’re thinking “audit logs already do that reliably”, I have… an even more exciting weekend planned for you.

The core problem: identity is not agency

Most enterprise systems were designed around a comforting assumption:

1. A human performs an action
2. The system records the human identity
3. Investigations work backwards from that identity

AI Agents break this because the user becomes the principal (requested/benefited), while the agent becomes the actor (executes), and the connector/API becomes the execution context (does the actual write/send/update).

When those get collapsed into a single “user identity”, investigations become interpretive art.

Three identities you must separate (or your audits will lie)

For AI agent-driven workflows, you should always be able to point to three “who”s:

1. Principal (human)
   The user who requested something, approved something, or benefits from the action.
2. Agent (software identity)
   The orchestrator / assistant / workflow identity that actually took action.
3. Tool identity (execution substrate)
   The connector, plugin, service principal, run-as context, or API client used to perform the action.

The reason this matters is simple: if you only record one identity, the person holding that identity becomes the default culprit for everything the software does.

Why traditional audit logs lose meaning

Audit logs typically answer:

“Which identity token performed this operation?”

But in AI agent land, the bigger questions are:

• Who asked / approved this?
• Which agent version acted?
• Was it delegated authority or app-only authority?
• What was the declared intent?
• What policy allowed/blocked it?
• What chain of tool calls happened after the first action?

Traditional logs often capture one slice of that chain, sometimes two, rarely the “why”, and almost never the full end-to-end causal story. That’s not a knock on audit logging, log management guidance has always warned that you need an enterprise log strategy, not just event capture. (That’s basically the point of NIST’s log management guidance.)

So you can end up with “accurate” logging that is operationally unhelpful. Which is my least favorite kind of accurate.

The failure modes you should assume will happen

Failure mode #1: “Run everything as the user”: Demos great. Investigates terribly. And it turns your user into a liability buffer.

Failure mode #2: “We log the agent name somewhere”: Cool. Now prove why it acted and what it touched. “Because the prompt said so” won’t survive contact with Audit.

Failure mode #3: “No correlation across components”: If you can’t stitch identity → intent → policy decision → tool calls → outcomes, you don’t have attribution. You have multiple unrelated facts.

Part 1 wrap-up

Agents didn’t break auditing. They just exposed that most audit strategies were built for human clicks, not software actors operating at machine speed across multiple systems.

In the next post, we’ll build the pattern that fixes this: User + Agent + Intent binding, plus the one thing that makes investigations boring again: a CorrelationId that survives the whole workflow (and can be propagated using standard trace context conventions).