What is the confused deputy problem?
By Identra · Updated
The confused deputy problem occurs when a trusted program misuses its legitimate authority on behalf of a party that is not entitled to that action. An attacker can exploit the program's access without stealing its credentials by getting it to act on the wrong instructions or resource.
Key numbers
- 1988: the year Norm Hardy named and documented the confused deputy problem (Hardy, ACM SIGOPS Operating Systems Review, 1988)
- May 2025: a malicious GitHub issue coerced an agent using the GitHub MCP server into leaking private repository data through a public pull request (Invariant Labs, 2025)
- The 2025-06-18 MCP specification made RFC 8707 resource indicators mandatory for MCP clients and banned token passthrough by servers (Model Context Protocol specification, 2025)
How does the confused deputy problem work?
A deputy is a program that performs actions for someone else. It might be a reporting service, a cloud integration, or an AI assistant. The failure occurs when it accepts a caller's input but uses authority that the caller is not entitled to direct.
Consider a reporting service with access to every customer's records. A customer submits a report request containing another customer's account identifier. If the service checks only whether its own database account can read those records, it may return them. The missing check is whether this caller may request this operation on this customer's data.
The program does not need to acquire new permissions. Its existing access is enough. Secure delegation binds the caller, permitted action, and target resource together. Authentication alone establishes who is calling. It does not establish that the requested use of the deputy's authority is allowed.
Why are AI agents vulnerable to confused deputy attacks?
An agent may read external content while also holding permission to search internal documents, send messages, or change files. Those capabilities create a trust boundary: content the agent encounters should not gain control over the authority assigned to its task.
Indirect prompt injection can cross that boundary. Instructions hidden in a document or tool response may redirect the agent toward an unauthorized action. The injection is the input attack. The confused deputy failure is the resulting misuse of trusted authority.
A distinct AI agent identity helps establish accountability, but identity alone does not make an action legitimate. The system must also establish whose request the agent is serving and which resources that request permits it to use. An agent is not automatically a confused deputy simply because it uses tools.
What does an enterprise confused deputy attack look like?
Consider a hypothetical support assistant that reads customer tickets, searches internal documentation, and posts replies. A customer places instructions in a ticket asking the assistant to retrieve an internal incident report and paste it into the response. The text claims that the report is necessary to diagnose the issue.
If the assistant obeys, the customer has redirected access intended for internal support work. The customer never needed the assistant's credentials. A successful login and a valid API token would not establish that the customer should receive the report.
A safer workflow restricts retrieval to material approved for the customer's context and checks the destination before publishing. If internal material is needed, the assistant can prepare a response for an authorized reviewer. Approval should show the actual content and recipient, with access checks enforced outside the model.
How is it different from prompt injection or token theft?
These terms describe different parts of an attack and can overlap. Prompt injection describes a way to influence an AI system. Confused deputy describes a failure to keep delegated authority attached to its authorized purpose. Neither requires the attacker to possess a credential.
Confused deputy attacks can also produce privilege escalation from the attacker's perspective. It is misleading to say that no security boundary is crossed simply because the deputy's own permissions remain unchanged.
Confused deputy
- What goes wrong
- A trusted intermediary exercises authority for an unauthorized request
- Example
- A reporting service returns another customer's records
Prompt injection
- What goes wrong
- Untrusted text redirects an AI system's behavior
- Example
- A ticket tells an assistant to ignore its assigned task
Token theft
- What goes wrong
- An attacker obtains someone else's credential
- Example
- A stolen access token is used to call an API
Excessive permissions
- What goes wrong
- An identity has more access than its task needs
- Example
- A support assistant can export every internal document
How does the problem affect cloud services and MCP?
A cloud provider integration may serve many customers while holding access to their environments. It must prevent a customer from directing that access at someone else's resources. AWS documents external IDs for third-party role assumption and source conditions for applicable service integrations as defenses against this pattern. Their correct use depends on the integration. See the AWS confused deputy guidance.
MCP security also requires keeping authorization boundaries intact. Accepting a token meant for another service, or forwarding a received token without the appropriate authorization relationship, can blur who authorized access. The MCP security guidance identifies token passthrough as a security risk.
Audience validation helps ensure that a token is accepted only by its intended resource server. It does not determine whether a particular tool action matches the user's task. Caller authorization, resource ownership, and permitted destinations still need separate checks.
How do you defend against confused deputy attacks?
Start with workflows where a program can reach more than its caller can. Apply least privilege to reduce the possible damage, then enforce authorization at the point where an action occurs. Instructions telling an agent to behave safely cannot replace those checks.
Test the boundary with adversarial requests. Substitute another tenant's resource identifier, insert instructions into retrieved content, and attempt to send internal data to an unapproved destination. Good behavior means the operation is denied or routed for specific authorization before any protected data leaves.
- Bind requests to a verified caller and tenant. Check access to the actual resource instead of trusting a caller-supplied account identifier.
- Scope credentials and tools to the task. Separate internal retrieval from external publishing when the workflow allows it.
- Validate token issuer, intended audience, expiration, and applicable permissions. Use an authorized downstream credential flow for each integration.
- Treat retrieved text as data. Enforce tool permissions and destination restrictions outside the model.
- Require explicit approval for sensitive actions. Bind approval to the exact target and content, and request new approval if they change.
- Record the initiating user, acting service or agent, resource, action, authorization decision, and outcome in an AI audit trail. Use those records to investigate misuse.
How Identra thinks about it
Identra helps keep agent authority tied to its intended use. On managed devices, AI agent tool calls are checked against policy before they run, and each agent run is recorded with the user, device, AI client, and outcome. Across identity providers, teams can see which connected apps hold admin rights or access to company data, and analysts can revoke risky OAuth grants with the result recorded.
Go deeper: AI security, built on identity
Frequently asked questions
Does a confused deputy attack require stolen credentials?
No. The attacker can persuade a trusted program to use credentials it already holds. The failure is unauthorized use of that authority.
Is every prompt injection a confused deputy attack?
No. A prompt injection might only change the wording of an answer. It becomes a confused deputy pattern when the system misuses trusted authority on behalf of the attacker.
Can a service with read-only access be a confused deputy?
Yes. Reading confidential records and returning them to an unauthorized caller is enough. Write access is not required for a data disclosure.
Does least privilege prevent the problem?
It limits what a deputy can misuse, but permitted access can still be exercised for the wrong caller or purpose. Resource authorization and delegation checks remain necessary.
Can human approval stop a confused deputy attack?
It can help when the reviewer sees the exact action, target, and data involved. A generic approval to continue gives little assurance if the agent can later change the destination or content.