> ## Documentation Index > Fetch the complete documentation index at: https://ai.brokenguardrail.com/llms.txt > Use this file to discover all available pages before exploring further. # Confused Deputy Problem > When a requester without permission exercises authority through a deputy that has it The confused deputy problem is one where **a requester without permission gets a more privileged entity to exercise that permission on their behalf**. It isn't specific to AI agents but a classic problem, and the spread of agents has made it a realistic threat again. ## Definition The [AWS IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) defines the problem this way. > The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. The deputy is only acting within the permissions it was given, exactly as instructed. But it lacks the context of who it's acting for right now, so authority gets granted indirectly and unintentionally. ## The confused deputy problem in AI agents Two properties of AI agents make permissions easy to mismanage. * The permissions available to an agent are wide ranging: service accounts, API keys, connected MCP servers, RAG, and more * The same permissions are often used without regard to who issued the instruction This grew more severe as context engineering took hold. Encouraged to give agents more context, teams granted them permissions across a wide range of data sources. But data comes with its own permission structure, and those boundaries don't carry over automatically when you deploy an AI agent. Implementations that overlook this make the confused deputy problem easy to hit. ## Concrete examples ### An internal MCP server configured with a shared machine user When you build an MCP server against an internal knowledge base, the easiest approach is to grant uniform permissions through a machine user or service account. But the knowledge base holds confidential documents that only certain departments such as HR or finance can read. Configure that MCP server with a machine user that can read everything, expose it to all employees, and someone in another department can use that server to reach documents their own account permissions would never allow. ### RAG that spans departments RAG is especially prone to the confused deputy problem. If the original permission metadata is lost when the index is built, no access boundary exists at retrieval time, and the system can't tell whether the person issuing the query was ever allowed to read the document. ### Shared credentials in a multi-user environment Agent platforms serving multiple users sometimes store access tokens for third-party services in a shared credential store. Without controls over which user may use which credential, one user can start a session that specifies another user's credential. The agent then reaches the external service with the credential owner's permissions rather than the requester's. Engineers must not read the HR team's personnel records, and the sales team has no need to reach the development team's internal repositories. Notion, Slack, GitHub, and similar services already enforce these boundaries through their own access controls, so being able to use someone else's permissions bypasses that enforcement entirely. ## Concepts it gets confused with ### Least privilege **Following least privilege does not solve the confused deputy problem.** Least privilege tells you to grant a deputy no more permission than it needs, which governs the **total amount** of the deputy's authority. The confused deputy problem asks about **attribution** rather than amount: does this authority belong to the person currently asking? ### Privilege escalation The confused deputy problem is classified as a form of privilege escalation, but unlike ordinary escalation, **neither the attacker nor the deputy escalates anything**. The attacker's permissions never change, and the deputy uses only the authority it already held. Because of that, the activity looks like normal operation in permission audits and logs, which makes it hard to detect. ### Prompt injection These are independent problems, and the damage compounds when both hold at once. Prompt injection is an attack that makes an agent **execute instructions it was never meant to**. The confused deputy problem is a structure in which an agent **exercises authority that doesn't belong to the requester**. With the confused deputy problem, confidential data leaks with no injection at all, because a legitimate user asking a legitimate question is enough. Conversely, if authority is correctly bound to the requester, a successful prompt injection still can't push the agent outside that requester's own permissions. **Fixing attribution also limits the blast radius of prompt injection.** ## Countermeasures Two principles underpin everything else. * Handle only data that the user and every viewer of the output already has permission to see. Otherwise, grant access through an authorization mechanism such as OAuth that respects the original permissions * Based on the data and permissions the agent handles, control who may use it and what access its output destination has ### Delegate the requester's authority This is the most fundamental fix. Rather than running the agent on its own fixed permissions, run an OAuth flow per user to obtain **an access token guaranteed to be a subset of that user's existing permissions**, and use only that token to reach the backend. Existing access boundaries survive intact. ### Bind credentials to the requester A system that stores per-user credentials is generally called a **token vault**. Storage alone isn't enough. The vault's job is to enforce the mapping of which user may use which credential. Give end users an interface where they can register and use only their own credentials, and close off any path to specifying someone else's. ### Verify the requester on every request Agents and tool servers must verify the requester's identity on each request and process it with the permissions bound to that identity. ### Design permissions to cover the output destination Attribution isn't only an input-side concern. Who can see an agent's output also determines effective access. Publish an agent that summarizes personnel records to every user in your company chat, and at that moment every user has read access to those records. ## References * [The confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) * [Confused deputy problem](https://en.wikipedia.org/wiki/Confused_deputy_problem) * [ConfusedPilot: Confused Deputy Risks in RAG-based LLMs](https://arxiv.org/abs/2408.04870) * [Security Best Practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices) * [MCP Authentication and Authorization: Current State and Future](https://hi120ki.github.io/blog/posts/20250728/) * [AI Security Challenges in 2026](https://hi120ki.github.io/blog/posts/20260103/) * [How Secure Are Claude Managed Agents?](https://hi120ki.github.io/blog/posts/20260413/)