Sooner or later someone asks the question that the architecture has to be able to answer: for this specific action, was it a human or an AI, and who is accountable for it? It comes from a security review, a SOC 2 auditor, a customer's procurement team, or your own incident retro. And in most agent setups the honest answer is "we can't tell," because the audit log says the user did everything.
That ambiguity is fine right up until it isn't. The moment an agent action causes a problem, or a regulator asks how AI is governed in the product, "the user did everything" stops being a convenience and becomes a liability. Audit and compliance for agents is the discipline of being able to answer that question precisely, for every action, after the fact.
The failure mode: agents that act as the user
If your agents run with the human's credentials, your audit log is lying by omission. Every row carries the human's name, whether the human took the action or the model did. You cannot reconstruct who actually did what, you cannot prove an AI was or wasn't involved, and you cannot bound an investigation to the agent that misbehaved. The data to answer the auditor's question was never recorded, because the system was never designed to distinguish the two.
This is the agents-borrowing-human-credentials anti-pattern viewed through a compliance lens. It is cheap to build and expensive exactly once: the first time you need the log to be trustworthy and discover it isn't.
Dual-keyed audit: the model that answers the question
The fix follows directly from giving each agent its own identity. Once an agent is a distinct principal with an owning human, every audit row can carry two identifiers:
- the agent principal id (which agent took the action), and
- the owning user id (which human is accountable for that agent).
That single change makes the auditor's question answerable. "Did a human or an AI do this?" is now a column, not a guess. "Who is accountable?" is the owner link. "Show me everything this agent did between these timestamps" is a query, not a forensic reconstruction. And critically, you can prove a negative: you can demonstrate that a human took an action and no agent was involved, which is often the more important compliance claim.
The owner link is what turns attribution into accountability. An agent id alone tells you a piece of software acted; the owner id tells you which human is answerable for it. Compliance frameworks care about accountability, and accountability needs a person.
What to log, beyond who
Attribution is the foundation, but a defensible agent audit trail records more than identity:
- The action and its target. What was done, to what resource, with what result. Standard, but it has to be tied to the agent principal, not flattened to the owner.
- Authorization context. Which scopes the agent was operating under, and for dangerous operations, the consent token that authorized it. When an agent moves money or widens access, the log should show the explicit confirmation that allowed it.
- Provenance for sensitive changes. For actions a regulator cares about, enough context to reconstruct intent: the task the agent was running, the human who initiated it, the inputs it acted on.
- Immutability and retention. Audit rows are append-only and retained per policy. An audit log you can quietly edit is not an audit log.
Making it survive an actual audit
A model is only compliant if it holds up when someone external pokes at it. Three properties matter:
Completeness. Every privileged action goes through the same gate, so there are no side doors that write actions without attribution. If some code path lets an agent act without recording the dual key, that path is where the audit fails. This is why attribution belongs in a single shared write path, not bolted onto each feature.
Continuity across rotation and role changes. When an agent's credential is rotated, its principal id is stable, so the audit trail is continuous across the rotation. When an owner's access changes, the cascade is recorded. The log tells one coherent story even as the underlying credentials and permissions move.
Answerability. The real test is whether you can answer the three questions on demand: was this a human or an AI, who is accountable, and what exactly did this agent do over this window. If the data model carries the dual key and the log is complete, all three are queries. If it doesn't, no amount of dashboards will save the review.
FAQ
What's the minimum to be "audit-ready" for agents?
Two things: every agent is a distinct principal with an owning human, and every privileged action records both the agent id and the owner id through a single shared write path. With those, the three core questions (human or AI, who's accountable, what did it do) are answerable. Everything else is refinement.
Do regulators actually require AI-specific audit trails?
Frameworks increasingly expect you to govern and attribute automated decision-making, and customers' security teams ask directly. Even where it isn't a hard line item yet, "we can prove which actions were taken by AI and who is accountable" is rapidly becoming table stakes in enterprise procurement. Building it in is cheaper than retrofitting it under deadline.
Why log the owner and not just the agent?
An agent id attributes the action to software; it doesn't establish accountability. Compliance is ultimately about which human answers for what happened. The owner link is what makes the trail accountable rather than merely descriptive.
Can we add this to an existing product without a rewrite?
Usually it's a data-model change plus routing every privileged write through one gate: add the agent principal and owner id to the audit schema, give each agent a real identity, and ensure no write path bypasses the gate. It's focused work, not a rewrite, and it's the same migration described in service accounts vs agent identities.
Part of the agent-identity stack
This is one spoke of the agent identity cluster. Auditability is the payoff of the principal model: because each agent is a distinct principal with an owning human, the log can carry the dual key that makes actions provable. Read agents are principals, not delegated tokens for the identity model underneath, and consent gates for dangerous operations for how high-risk actions get the extra provenance an audit wants.