The Confused Deputy: AI Agents and Delegated Authority
AI agents act through authority assigned by people and systems. When that authority crosses company boundaries, its origin, scope and owner can disappear.
By the time an AI agent’s action reaches the system that can move the money, release the records or send the message, the person whose authority started it can be three hops away, behind a boundary nobody in the incident review can open. A few weeks ago I wrote that someone still has to answer for what an agent does, and that the someone has to be a named human. This is where that goes next.
That works, at least conceptually, while the agent stays inside a system you control. Then it calls another company’s agent. That agent calls a tool hosted somewhere else.
That is where this goes next.
Not the agent that acts alone. The agent that hands off.
An agent has no inherent self
Start with a thing that sounds like philosophy and is mostly plumbing: an AI agent has no inherent legal or authorization identity.
We can assign it one. A workload identity. A service principal. An API credential. An auth token saying it’s acting for a user. But those are identities and permissions that people and systems place around the agent. They don’t arise from the model itself.
When an agent takes an action, the system receiving that action still has to decide what identity and authority to recognize. Is this the user acting through an agent? The application itself? A service account? Another agent in a delegation chain? And even if the credential is valid, is the actor trustworthy in this context, or has it been compromised, manipulated or turned into part of the threat?
Take away that answer and the agent can’t cross a protected boundary. Give it the wrong answer and it may be able to do everything the borrowed identity could do.
This isn’t a new class of failure. It’s one of the oldest access-control problems we have, and it already has a name.
In 1988, Norm Hardy published a short paper called “The Confused Deputy.” The story was based on events at Tymshare, a commercial timesharing company. Its compiler needed permission to write statistics into a protected system directory. It also let users name a file for debugging output.
Someone supplied the name of the system’s billing file.
The user couldn’t write to that file. The compiler could. When the compiler opened the requested path, the operating system checked the compiler’s authority rather than the caller’s intent. The compiler then overwrote the billing information.
It wasn’t compromised in the usual sense. It used legitimate authority for the wrong purpose because the request carried a filename but not a trustworthy account of which authority should apply to it.
Swap the compiler for an agent and the shape of the problem looks uncomfortably current.
How we get it wrong now
The fastest way to ship an agent is often to let it borrow an identity that already works.
Sometimes that’s the user’s session. Sometimes it’s an OAuth token. Sometimes it’s a service account with enough access to cover every task the agent might encounter. The demo works because the credential already opens the doors.
The trouble begins when the authority is broader than the task.
An agent reads a document, message or webpage containing an instruction it shouldn’t trust. It’s then induced to do something the credential technically permits but the person never intended: retrieve another customer’s records, approve a refund, export a database or send information outside the company.
The credential is valid. The action is allowed. The purpose is wrong.
The Model Context Protocol’s authorization specification addresses one version of this directly. An MCP server must accept tokens intended for that server, validate their audience and avoid passing the client’s token unchanged to a downstream API. When the server calls another protected service, the specification says it should use a separate token issued for that upstream resource.
That boundary matters. A token created for one service shouldn’t become a skeleton key merely because an agent carried it somewhere else.
Service accounts aren’t automatically the wrong answer. A narrowly scoped workload identity can be exactly the right control. The problem is the shared service account that stands in for every agent, every user and every purpose. Once that happens, the identity may tell you which application made the call while telling you almost nothing about whose authority it was exercising or why.
The actor remains visible.
The authorization story disappears.
The part that breaks at the property line
Inside one company, you can compensate for some of this with common identity systems, centralized policy and logs you are allowed to inspect.
The harder version begins when the chain crosses a boundary you don’t own.
Anita Srinivasan described the legal shape of this problem in a June 2026 Berkeley Technology Law Journal Blog article. Agent A, built by Company X, delegates to Agent B at Company Y, which invokes Agent C at Company Z. The particular combination may be selected at runtime rather than designed in advance by any one human.
That doesn’t mean the law has no way to assign responsibility. Product liability, agency, contract, negligence and joint-liability theories may all matter depending on the facts and jurisdiction. It does mean the clean picture of one principal directing one identifiable agent becomes harder to apply.
Srinivasan’s argument is that doctrines built around a legible principal-agent relationship strain when the delegation chain crosses providers and no participant has a complete record of the interaction. A court may need to determine which developer, deployer, operator or tool provider contributed to the harm before the infrastructure can even show which systems participated.
The authorization hasn’t literally vanished. Credentials were accepted. Calls were permitted. Systems acted.
What vanished was the legible connection between the final act and the original grant of authority.
I have started calling that authority laundering.
Not fraud, necessarily. Not even deliberate concealment. It’s what happens when authority passes through enough intermediaries that its origin, limits and accountable owner become difficult to reconstruct.
Each hop can look reasonable locally. Agent B received a valid request from Agent A. Agent C received one from Agent B. The final service saw a valid credential from Agent C.
Every system can explain the hand immediately before it.
Nobody can explain the whole chain.
What actually holds
More logging helps, but logging alone is not the answer.
A log can prove that a call ran. It can show which service account signed it, when it arrived and what it returned. It may still leave the most important question untouched: on whose behalf was this specific action taken?
That has to become a first-class property of the request, not a story reconstructed after the incident.
OAuth already contains part of the machinery. RFC 8693, published in 2020, defines OAuth token exchange and an act claim for identifying an actor operating on behalf of a subject. The claim can be nested so that a token retains a history of prior actors in a delegation chain.
There is an important limit here. RFC 8693 says the current actor and the token’s top-level claims are what a recipient uses for access-control decisions. Earlier nested actors are informational. The history can help preserve provenance, but it does not automatically prove that every prior delegation was valid, preserve every restriction imposed at every hop or make the whole chain cryptographically undeniable.
So act is not a complete agent-authorization architecture.
It is evidence that we already know how to represent the question.
Who is the subject? Who is acting? For which audience? With what scope? Until when?
Pair that with resource-bound tokens, short expirations, explicit delegation policy and an identity for each participating workload, and the agent’s authority can approach the overlap of two things: what the principal is allowed to do and what this particular agent is allowed to do for that principal in this context.
Not the union.
The overlap.
That one distinction closes a surprising amount of the hole.
Call it attenuation: authority narrows as it moves downstream, instead of quietly widening.
Final thoughts
I did not expect the law to arrive at almost the same shape as the token.
On June 29, 2026, Senator Mark Warner released a discussion draft of the Artificial Intelligence Access, Gatekeeper Exchange, and Nondiscriminatory Transfer Act, or AI AGENT Act. It is a discussion draft, not enacted law and not yet a formally introduced bill.
The proposal would let users designate “custodial user agents” to interact with large online platforms on their behalf. Its definition requires that relationship to be transparent, documented, limited in scope and revocable.
The draft goes further. It calls for verifiable requests, auditable records, agent identity verification, real-time revocation and scope-limited delegation credentials. It would also restrict an agent from transferring a user’s authority to another entity or AI system without the user’s express, specific and revocable authorization.
That is not merely a vague call for responsible AI.
It is the outline of a delegation system.
The draft is not describing RFC 8693 specifically, and it would be too strong to claim that a Senate office independently wrote an OAuth implementation guide. But the convergence matters. Security architecture and proposed public policy are circling the same requirements because they are encountering the same underlying problem.
Authority has to be attributable.
Its scope has to remain visible.
Delegation has to be explicit.
Revocation has to travel fast enough to matter.
And the record has to survive the handoff.
An agent has no inherent authority of its own. Everything it can do inside a protected system comes from an identity, credential or policy somebody else placed around it.
The work of the next few years is making sure the original grant remains legible, narrow and attached when the request crosses the property line.
Because the danger is not only that an agent will act without permission.
It is that every system in the chain will be able to show that somebody gave permission, while nobody can tell you whose permission it was.
That is the identity problem.
And it is where the rest of this arc lives.
Resources
Norman Hardy, “The Confused Deputy (or why capabilities might have been invented)”, ACM SIGOPS Operating Systems Review, Vol. 22, No. 4, October 1988. An accessible author-hosted version is also available at Cap-Lore.
Model Context Protocol, Authorization specification, June 18, 2025. See the requirements for token audience validation, resource indicators and the prohibition on token passthrough.
IETF, RFC 8693: OAuth 2.0 Token Exchange, January 2020. See Sections 1.1, 4.1 and 4.4 for delegation, the
actclaim and themay_actclaim.Anita Srinivasan, “Multi-Agent AI is Outpacing the Liability Frameworks Built for Single-Agent Systems”, Berkeley Technology Law Journal Blog, June 2, 2026.
U.S. Senator Mark Warner, “Warner Unveils Discussion Draft of Legislation to Create Innovative Market for Secure Artificial Intelligence Agents”, June 29, 2026.
U.S. Senator Mark Warner, AI AGENT Act discussion draft, full text, June 2026.
DLA Piper, “Senator Warner’s discussion draft on securing AI agents: Top points”, July 1, 2026.
Previously in this series: Who Answers for the Agent: AI Accountability.
The confused deputy framing is the most useful one available for this problem, and it earns its keep by locating the failure precisely: the agent's authority is real, its identity is real, and the harm happens anyway. That is a category of failure no credential can address, because nothing in the credential is false at the moment of misuse.
Which is why I would push on the remedy. Scoping down delegated authority reduces blast radius. It does not create the ability to distinguish a deputy that is about to be confused from one that is not. Both present the same token. The distinguishing information is behavioral and historical, and it lives outside the request entirely: how has this agent handled comparable authority across prior interactions, and what did it cost anyone when it got it wrong.
The confused deputy problem in its original setting was solved by making authority unforgeable and unambiguous. The agent version cannot be solved that way, because the ambiguity is not in the authority, it is in the intent behind an instruction that arrived through a channel the deputy cannot audit. So the workable move is to stop trying to make each individual grant safe and instead price the counterparty: a machine-readable behavioral prior that binds to identity, compounds across validated interactions, and is forfeit on defection. Least privilege bounds the damage. Only stake changes the incentive.
I set out why trust is a separate gate from identity, and what a behavioral prior has to satisfy, here: https://wulfkaal.com/2026/07/24/podcast-episode-trust-and-agents-on-the-web/