Delegation Is the Hard Part: When Your Agent Becomes a Confused Deputy
The Model Context Protocol made it trivial to hand an agent a tool. It did nothing to record who authorized the agent to use it, or on whose behalf. That missing answer is where the next class of agent incidents lives.
There is a forty-year-old bug class in security called the confused deputy. A program holds authority to do something powerful. A less-privileged caller asks it to act. The program, unable to tell whose intent it is really serving, uses its own authority to carry out the caller's request. The authority was real; the deputy was simply confused about whom it was working for. Every classic instance — the compiler tricked into overwriting a billing file, the proxy tricked into reaching an internal host — is the same shape: legitimate power, ambiguous delegation.
The Model Context Protocol industrialized this shape for AI agents. MCP made it trivial to hand an agent a tool: a connector, a database client, a shell, a payments API. What it did not make trivial — what nothing in the common stack makes trivial — is recording who authorized the agent to hold that tool, and on whose behalf each individual call is made. The tool grant is concrete and durable. The delegation behind it is implicit and lost.
The Four Claims, and the One Everyone Skips
An authorized agent has to substantiate four claims: which agent is acting (identity), what it is permitted to do (authorization), who conferred that authority (delegation), and proof that the boundary held (proof). Teams shipping agents today can usually gesture at the first two. The third — delegation — is the one that quietly goes unanswered, and it is the one the confused deputy exploits.
Consider a support agent wired through MCP to a refunds tool and a customer-records tool. It authenticates with a service account. From the refunds API's perspective, every call is "the support service, which is allowed to issue refunds." That is true and useless. The question that matters is: is this specific refund being issued because a verified customer asked for it through a legitimate channel, or because a paragraph of text the agent read somewhere told it to? The API cannot tell. The service account flattens every delegation into the same valid credential. The deputy is confused by design.
The Lethal Trifecta Is a Delegation Failure
The security researcher Simon Willison named the dangerous combination precisely: an agent with access to private data, exposure to untrusted content, and the ability to communicate externally. Hold all three at once and a single poisoned input can turn the agent into an exfiltration tool — it reads the secret, follows the injected instruction, and sends the data out, every step using authority it legitimately holds.
It is tempting to file this under prompt injection and reach for a better input filter. That treats the symptom. The disease is that the agent was delegated three powerful capabilities with no boundary expressing that they should never be exercised together on untrusted input — and no record of who decided the agent should hold all three. A model-level defense asks the agent to be careful. An authorization boundary makes the dangerous combination unreachable regardless of what the agent decides. Only one of those survives an adversary who controls the agent's input.
Proof Is Not a Log
When delegation is implicit, the fourth claim — proof — collapses too. After an incident, "the support service issued a refund" is what the audit log says, and it explains nothing. It cannot tell you which human or upstream agent the action traces back to, because that information was never part of the call. A tamper-evident record that an action occurred is not proof the action was authorized. Proof requires the delegation chain to have been captured at the moment of the act, not reconstructed by guesswork afterward.
This is why delegation is the hard part. Identity can be issued. Permissions can be scoped. But delegation has to be threaded through every hop — human to agent, agent to sub-agent, agent to tool — and preserved at each call, or the chain breaks and the deputy is free to be confused. MCP gave agents reach without giving the ecosystem a way to carry that chain.
Start by Seeing the Grants
You cannot govern a delegation chain you cannot see. The first move is the same as everywhere else in this thesis: look. The Agent Environment Review enumerates, for each agent, which tools it can call over MCP, what those tools can reach downstream, and which of them combine into a lethal trifecta — private data, untrusted input, and an exfiltration path held by the same principal. It does this from metadata, without uploading source or secrets. It does not score you. It shows you the deputies you have already deputized, and the boundaries that were never drawn around them.
Read the Full Argument
The Authorized Agent: Identity, Authorization, and Audit for AI Agents in Production is Book One in the DeepSweep.ai Thesis series. It develops delegation and proof from first principles into a runtime authorization model for production agents.
Available now on Amazon: https://www.amazon.com/dp/B0GWV9FGDF
DeepSweep is the productized thesis. The book is where it begins.