The confused deputy problem was described in 1988, long before anything resembling a modern AI agent existed. A program with legitimate authority is tricked by a less-privileged caller into using that authority on the caller's behalf. The deputy is not compromised; it is confused. It does exactly what it was built to do, using permissions it legitimately holds, for someone who should not have been able to invoke them.
AI agents are deputies by construction. They act on behalf of a user, a team, or another agent, and they hold credentials to do so. That makes the confused deputy problem not an edge case for agentic systems but their default security posture unless something is done about it. This post covers why the failure mode is sharper for agents than for conventional software, and the structural controls that address it.
Why the Problem Is Sharper for Agents
Conventional software has a hard boundary between code and data. A web server parses an HTTP request into structured fields; the request body never becomes executable logic unless something has gone badly wrong. That boundary is what makes it possible to reason about who a request is really from.
Language models do not have that boundary. The system prompt, the user's message, a retrieved document, a tool's JSON response, and an error string from a failed API call all arrive as tokens in a single context window. The model has no innate mechanism for treating one span of tokens as authoritative instruction and another as inert data. Provenance is a property the surrounding system must impose; it does not emerge from the model.
Layer autonomy on top of that. An agent decides which tools to call and with what arguments. So the confusion does not merely produce a wrong answer — it produces actions. Tool calls with real side effects, executed under the agent's credentials, at machine speed, in volume.
Then layer delegation. In a multi-agent system, an orchestrator dispatches work to sub-agents, which may dispatch further. Each hop is an opportunity for the asserted principal to drift from the actual one. A sub-agent that says "the orchestrator asked me to do this on behalf of the finance team" is making a claim, and unless that claim is cryptographically bound to something, it is only a claim. This is the mechanism behind A2A delegation abuse.
The Three Shapes It Takes in Practice
Injected-instruction confusion. External content the agent retrieves contains instructions. The agent processes them as if they came from its operator and calls tools accordingly. This is indirect prompt injection, and the confused deputy framing is exactly why it matters: the injection itself is harmless; the agent's ambient authority is what makes it dangerous.
Ambient-credential confusion. The agent holds a long-lived credential — a database password, a cloud role, a broad API key — that grants access to everything any of its callers might need. When it serves caller A, it still holds the authority relevant to caller B. Nothing in the request narrows what the credential can do, so caller A can steer the agent toward B's data. This shape does not require any prompt trickery. Over-broad scope alone produces it, which is why over-broad MCP tool scope is a first-class threat rather than a hygiene issue.
Relay confusion. A low-privilege agent cannot reach a resource directly, so it asks a high-privilege agent to do it. The high-privilege agent complies because the request looks like ordinary internal traffic. The low-privilege agent has effectively borrowed permissions it was never granted. Any system where agents can call each other has this exposure unless each hop is independently authorized.
Capability Authority Instead of Ambient Authority
The 1988 answer still holds: give the deputy the authority along with the request, rather than in advance.
In practical terms, an agent should not hold a standing credential that covers the union of everything its callers might be entitled to. It should receive, per request, a scoped and verifiable token that encodes: who the principal is, what operation is permitted, against which resource, for how long. The token is the authority. Presenting it is how the agent proves it is acting for that principal.
This is what OAuth 2.0 Token Exchange (RFC 8693) exists for — an agent presents evidence of the principal's authority and receives a narrower token bound to that principal and that purpose. The downstream service authorizes the token, not the agent's reputation. See token exchange for agent-to-tool authorization for the mechanics, and how to authenticate AI agents for how this fits the broader identity model.
Two properties matter most. First, the token must be audience-restricted: valid only at the service it was minted for, so a leaked token cannot be replayed elsewhere. Second, it must be non-amplifying: exchanging a token must never produce broader authority than the token presented. Delegation should monotonically narrow. If your exchange endpoint can return a scope the caller did not already hold, you have built a privilege escalation service.
Bounding the Damage When Confusion Still Happens
Capability authority reduces the frequency of confused-deputy incidents. It does not eliminate them, because a legitimately scoped token can still be used for a request the principal did not actually intend. So the second layer bounds blast radius.
Per-connection scoping. Each agent-to-resource link carries its own explicitly enumerated permissions, not a role that happens to cover them. A summarization agent's connection to a document store is read-only on a specific collection. It has no connection at all to the outbound email tool. Confusion cannot produce an action for which no connection exists. This is the enforcement shape described in how to implement least privilege for agents.
Delegation depth and breadth limits. Cap how many hops a delegated request may traverse and which agent types may delegate to which others. Unbounded delegation graphs are unauditable, and they are how a narrow initial compromise turns into cascading failure.
Action-level validation before execution. Inspect the proposed tool call — target, parameters, data volume — against policy at the moment before it executes. This is the last point at which intent is visible and the action is still reversible. Content guardrails in block, redact, or warn modes operate here.
Fail-closed on unresolvable principals. If the system cannot determine which principal an action is for, the action must not proceed. Defaulting to the agent's own identity is precisely how ambient authority creeps back in.
Attribution: The Part Teams Skip
A confused deputy incident is, forensically, a question about identity: which principal was this action attributed to, and which principal actually initiated it? If your logs record only "agent-7 called send_email," you cannot answer it. You know what happened and nothing about why it was permitted.
Every enforcement decision needs both identities recorded: the acting agent and the asserted principal, plus the token or connection that authorized it and the policy that evaluated it. That pairing is what lets an investigator reconstruct the delegation chain and find the hop where the principal drifted. It is also what makes the record useful as evidence rather than as telemetry — see audit trails that hold up and tamper-evident audit logs.
Without dual attribution, the most common outcome after an incident is a scope reduction applied uniformly across all agents, because nobody can identify which specific grant was abused. That is expensive and imprecise, and it usually gets rolled back the first time it breaks a production workflow.
Common questions
Is the confused deputy problem just prompt injection under another name?
No — prompt injection is one way to induce confusion, and confused deputy is the reason injection has consequences. An agent with no ambient authority can be injected all day and accomplish nothing beyond producing wrong text. Conversely, an agent with over-broad credentials can be a confused deputy with no injection involved, purely because its scope covers data the current caller should not reach. Treating them as the same problem leads teams to invest only in input filtering, which addresses the trigger and not the exposure.
Does per-request token exchange add too much latency?
The exchange is a signature verification and a token mint — sub-millisecond to low-single-digit milliseconds when the authorization service is local to the call path, and cacheable for the token's lifetime within a single task. Compare that to model inference latency, typically hundreds of milliseconds to seconds. The overhead is not material at agent timescales. Where teams do hit trouble is minting a fresh token per tool call inside a tight loop; scoping tokens to a task rather than an individual call resolves it without reintroducing standing credentials.
How do I handle agents that genuinely need broad access, like a backup or indexing agent?
Broad access is sometimes legitimate. What makes it dangerous is broad access combined with the ability to serve arbitrary callers. For a genuinely broad-scope agent, remove the second half: it should be invocable only by a small, explicitly enumerated set of principals, ideally system-triggered rather than user-triggered, with no path for a user prompt to influence its targets or parameters. An indexing agent driven by a schedule and a fixed configuration is not a deputy at all, because there is no caller to confuse it.
What about human-in-the-loop approval — does that solve it?
It helps for high-impact irreversible actions, and it is the right control for a bounded set of them. It does not scale as a general answer, because approval fatigue converts human review into rubber-stamping within weeks. Use it where the action is rare, consequential, and hard to reverse; use scoped authority and automated policy for the high-volume remainder. Human-in-the-loop approvals for agents covers where the line usually falls.
How Praesidia approaches confused-deputy containment
Praesidia treats the agent-to-resource connection as the unit of authority rather than the agent itself. Each connection carries its own explicitly enumerated scopes, its own content guardrails, and its own trust-level requirement, so an agent's effective permissions are the union of narrow grants rather than a broad role. Requests flow through OAuth token exchange where the downstream service authorizes a principal-bound, audience-restricted token, so delegation stays scoped to the task rather than inheriting broad authority.
Every enforcement decision is written to a tamper-evident audit record naming both the acting agent and the principal it acted for, which is what makes the delegation chain reconstructable after the fact. For the wider model these controls sit inside, see zero trust for AI agents and the Praesidia documentation.