In 1988, Norm Hardy described a problem he called the confused deputy. A privileged program is tricked by a less privileged caller into using its authority on the caller’s behalf. The program is not compromised. The access policy is not violated in any technical sense. The system simply has no way to check whether the person asking deserved the access the program provided.
For three decades this stayed an edge case. It took deliberate engineering to trigger, and most enterprises never encountered it.
Then we started deploying AI agents, and the edge case became the default configuration.
How It Happens Without Anyone Deciding It Should
The mechanism is unremarkable, which is exactly why it spreads.
An agent is not a passive tool. It holds credentials: OAuth grants, service account keys, API tokens. When a user invokes that agent, the agent acts using its own stored credentials, not the user’s. If those credentials reach data the user is not authorized to see, the user gets the data anyway. The access boundary that was supposed to stop them was never consulted.
Now scale that. One agent, shared across a department, effectively holds the union of everything its credentials can reach, available to everyone who can invoke it. The agent’s permissions were sized for the broadest task it might ever need to perform. Each individual user’s permissions were sized for their role. Those two numbers are not close.
Nobody designed this. It is a byproduct of two entirely reasonable decisions made in different rooms. The identity team scoped user permissions carefully. The team shipping the agent gave it the access it needed to work.
Why the Agent Got Broad Access in the First Place
Ask why an agent is over-permissioned and the honest answer is usually speed.
Narrow permissions are hard to specify at deployment time, because nobody knows in advance every data source the agent will need to touch. Broad permissions work immediately. So an existing service account gets reused, or an IAM role from a previous project gets copied, and the agent ships.
Then it happens again. The same role gets attached to the second agent, and the third. Permissions stack. Nobody tracks the aggregate, because no single decision looked unreasonable at the time. By the fourth agent, the blast radius of one compromised credential extends well past any workflow that credential was meant to serve.
This is not negligence. It is deployment moving faster than governance, which is the ordinary condition of every enterprise that has ever adopted a new technology quickly. What makes this instance different is the multiplier. Machine identities already outnumber human ones in most large organizations by a wide margin, and agentic workloads are multiplying them again, faster than the review cycles built to govern them.
The survey data reflects the gap. Most organizations agree that governing AI agents is critical to enterprise security. Fewer than half have implemented any policy to do it. And only a minority can trace an agent’s actions back to the human who authorized them across all their environments, which means that for most enterprises, the audit trail for agentic data access does not currently reach a person.
What the Logs Do Not Tell You
That last point deserves its own paragraph, because it is the part that surprises people.
When an agent acts, downstream systems record the agent’s credential. They do not record who asked. The log shows an authorized service account performing an authorized operation, which is accurate and almost useless. The human or system that initiated the request lives in a different log, in a different system, and in most environments nothing connects the two.
So the question “who accessed this data” becomes unanswerable in the only form that matters. You can say which credential touched it. You cannot say on whose behalf, for what purpose, or whether that person was entitled to it. For a regulated organization, this is not an inconvenience. It is a gap in the evidentiary chain that auditors are beginning to ask about directly.
The Intersection Principle
The fix is easier to state than to build, but stating it clearly matters, because most of the industry is currently solving an adjacent problem instead.
An agent’s effective authority for any action should never exceed the intersection of what the agent is permitted to do and what the requesting user is permitted to do.
If Alice cannot query the customer table, the agent should not query it on Alice’s behalf, even when the agent’s own credentials technically allow it. The agent’s permissions define a ceiling. The invoker’s permissions define the operative limit. Every request is evaluated against both.
Notice what this is not. It is not agent authentication, which answers whether the agent is who it claims to be, and says nothing about whether this particular request should be honored. It is not sandboxing, which constrains where the agent can operate, not what it may retrieve for whom. Both matter. Neither closes this gap, because this gap is not about the agent’s trustworthiness. It is about whose authority is being exercised.
That makes it a policy problem rather than an identity problem, and the distinction has architectural consequences. Enforcing an intersection at request time requires a layer that knows three things simultaneously: the agent’s entitlements, the invoker’s entitlements, and the sensitivity and purpose context of the data being requested. Identity systems hold the first. Access governance holds the second. Only a policy layer that sits across both can evaluate them together, at the moment of the request, fast enough that nothing waits on it.
What This Asks of Enterprises Now
None of this requires waiting for a new category of tooling to mature. Three things are worth doing immediately, and all of them are governance decisions rather than purchases.
Give each agent a distinct identity tied to a named owner. Shared roles across agents destroy attribution during an incident and expand blast radius silently.
Record the invoker alongside the credential on every agent-initiated request. If the audit trail cannot reach a person, it is not an audit trail.
And treat agent entitlements as a ceiling rather than a grant. The agent’s permissions describe what is possible. Policy should decide what is permitted, per request, in context.
The organizations that get this right will not be the ones that deployed agents most cautiously. They will be the ones that understood early that an agent is not a user with a service account. It is an instrument through which many users act, and governing it means governing the relationship between the instrument and the hand, continuously, at machine speed.
The confused deputy is thirty-eight years old. We are the first generation to deploy it at scale on purpose.
See how policy-based access control governs agent-initiated data access – book a demo.
