A confused deputy AI agent is an agent that holds broader or delegated permissions than a specific request warrants and is manipulated, through untrusted input, tool output, or a chained sub-agent call, into using that authority on behalf of a party it was never authorized to serve.
Technical Guide

Confused Deputy in AI Agent Architectures

How delegated permissions and tool-call authority recreate the classic confused deputy vulnerability in AI agents, MCP proxies, and multi-agent chains, and which controls reduce the risk.

Explore Runtime Governance Talk to an Expert

What Is the Confused Deputy Problem

The confused deputy problem was formally defined by Norm Hardy in 1988 to describe a specific failure mode in privilege-separated systems: a program that holds more authority than the party requesting an action is manipulated into misusing that authority on the requester's behalf. The deputy is not compromised in the traditional sense. It executes exactly the operation it was built to perform, but does so based on an input it should not have trusted. This distinction matters. Confused deputy failures are authorization failures, not code-execution failures, and patching a software defect does not resolve them. The fix requires correcting how authority is delegated, scoped, and verified between a caller and the intermediary holding elevated privilege on that caller's behalf.

How Tool-Calling Agents Recreate the Pattern

AI agent architectures reproduce this structure at machine speed. An agent that executes tool calls, queries APIs, or invokes downstream services typically holds a single credential, API key, or service token that spans many unrelated requests. This is the ambient-authority pattern that made the original confused deputy problem possible: one broad grant of privilege used across many tasks, with no mechanism confirming that a given action was authorized for the specific caller making it.

Untrusted inputs compound the risk. A retrieved document, a tool response, or content returned by a third-party service can function as an indirect instruction to the agent. When the agent treats that content as sufficient basis for invoking a privileged tool, it becomes the deputy, correctly performing its function while extending authority to an input that was never entitled to it.

Governance and Audit Implications

Least-privilege enforcement for AI agents is an access-control governance requirement, not solely a matter of model behavior or prompt design. Organizations running multi-agent workflows should document which party, whether the end user, a service, or the agent itself, is accountable for authorizing each class of tool-call action. Third-party components and sub-agents introduced into a chain warrant the same permission-scoping review applied to any external API integration rather than default trust because they operate inside the agent framework.

Audit trails matter as much as prevention. Because confused deputy failures involve an authorized action executed on behalf of the wrong party, reconstructing after the fact which identity actually authorized a privileged action depends on logging that preserves the original requester's identity through every hop of a delegation chain.

Where MCP and Multi-Agent Chains Introduce Risk

Two architectural patterns in current agent deployments create specific conditions for confused deputy exploitation.

  1. MCP servers as OAuth proxies

    The Model Context Protocol specification identifies a scenario where an MCP server sits between a client and a third-party authorization server. If it relays authorization without verifying token audience, it can be tricked into acting for a party it was never authorized to represent.

  2. Blind token pass-through

    MCP security guidance advises against servers forwarding tokens to downstream APIs without checking that the token was issued for the current request. Pass-through without audience validation conflates the requester's identity with the proxy's own identity.

  3. Sub-agent permission inheritance

    In multi-agent orchestration, a sub-agent invoked for a narrow sub-task often inherits the orchestrator's full permission scope rather than receiving a credential minted for that task, expanding the blast radius if it is manipulated.

  4. Ambient credential reuse across sessions

    Shared agent infrastructure that reuses one credential across tenants or sessions increases the consequence of a single manipulated instance, since the same grant of authority applies to every request it handles.

Historical and standards context

The same failure mode appears across decades of systems research and current agent guidance.

1988 origin

Norm Hardy formally defined the confused deputy problem in capability-based systems research.

MCP OAuth proxy risk

The Model Context Protocol specification names a confused-deputy scenario in server-mediated OAuth relay.

Excessive agency

OWASP's LLM Top 10 identifies excessive permission and autonomy as a named agent risk category.

Least privilege

Scoped, audience-restricted credentials are the core mitigation across current standards guidance.

Controls That Reduce Confused Deputy Risk

These controls address how authority is minted, verified, and bound to a specific request rather than to the agent process as a whole.

Per-request scoped credentials

Issue narrowly defined credentials for each request rather than one long-lived credential covering all downstream tool calls.

Audience and purpose checks

Require tools and downstream APIs to verify a token was issued for the specific caller and purpose before honoring a request.

Independent policy enforcement

Mediate tool execution through an explicit enforcement layer rather than allowing direct, unmediated invocation from agent reasoning output.

No blind token relay

Proxy and gateway components, including MCP servers, should validate tokens rather than relay them between clients and third-party services.

Task-scoped sub-agent credentials

Give sub-agents credentials minted for their specific sub-task instead of inheriting the orchestrator's full permission set.

Session-bound tool authority

Tie tool-call authority to the specific user session and request, not to the agent process as a whole.

Evaluation Questions Before Deploying Tool-Calling Agents

Use these questions to pressure-test permission design before production rollout.

  • Does the platform issue narrowly scoped, audience-restricted tokens per tool call, or rely on one broad credential shared across tasks?
  • How does the system prevent token pass-through when an agent or MCP-style proxy sits between a client and a third-party API?
  • Is there a policy enforcement point that mediates tool execution independently of the agent's own reasoning output?
  • How is the original requester's identity preserved and verifiable through multi-agent delegation chains?
  • What audit logging exists to reconstruct which identity authorized a specific privileged tool-call action after the fact?

Reduce Confused Deputy Risk in Agent Deployments

Runtime governance and least-privilege enforcement help ensure agents act only within the authority granted for a specific request, not the broader scope of the credential they hold.

Explore Runtime Governance