Confused Deputy Attacks in AI Agent Systems

Confused deputy attacks in AI agent systems turn untrusted content into actions backed by trusted credentials. An agent can read data as instructions while holding authority that the data’s author was never given. Defending that boundary requires authorization outside the model, with identity and scope checked at the point of action.

What the confused deputy problem is and why AI agents recreate it structurally

A deputy is a trusted intermediary that acts for someone else, while a principal is the identity whose authority should govern an action. Norm Hardy’s original 1988 formulation described a compiler with write access to a statistics directory, SYSX, which a less-privileged caller tricked into overwriting a billing file in that directory. The compiler had legitimate access, but the caller did not have the right to use that access for this purpose. The failure was therefore not a lack of credentials. It was the use of the deputy’s authority without checking whether the caller was entitled to the action.

An enterprise AI agent is in the same position when an operator gives it OAuth tokens, API keys, shell-execution rights, or cloud credentials. Those grants let the agent do useful work on the operator’s behalf. They also give it power that an author of an email or document does not hold. An injection vector is a channel through which that author can place malicious instructions before the agent. If the agent follows those instructions, it becomes the bridge between an untrusted source and a privileged action.

The Cloud Security Alliance’s 2026 research note identifies the structural cause of that bridge [1][16]. LLM-based agents use the same inference pathway for natural language instructions and natural language content, with no built-in way to keep a command apart from a document to read. Every token in the context window is available for interpretation as an instruction, although that does not mean every token will be obeyed. Broad permissions then amplify the consequences of a mistaken interpretation, potentially making them irreversible. Multi-agent architectures add paths through which that mistake can travel beyond the first agent.

How the attack chain unfolds across an agent's input channels

The first step requires a way to write content that the agent will process. An email body can carry the instruction, as can a GitHub issue or a tool response. From the operator’s perspective, these are inputs to the task. From the model’s perspective, however, their language remains available to influence what happens next.

The Cloud Security Alliance describes a four-stage chain that explains how this influence becomes an access-control failure [1][16]. An adversary first introduces malicious instructions into an input channel. The agent then reads that content through the same pathway it uses for operator instructions. If it follows the embedded instruction, it executes an action using its delegated authority. At the system level, the resulting operation is indistinguishable from one sanctioned by the operator.

The agent must therefore recognize suspicious text, and the system must also establish who is entitled to request the resulting action. A valid credential establishes the agent’s access, but it does not establish the content author’s right to direct that access. As the agent gains more integrations and broader credential grants, a successful injection can reach more consequential operations. The same permissions that increase usefulness enlarge the potential damage.

This differs from the classical operating-system case in ways that complicate defense. The decision procedure is probabilistic rather than deterministic, so the agent’s interpretation is not a fixed access-control rule. The authority chain also runs across humans, operators, runtimes, subagents, and services. Finally, the adversarial request arrives as content, leaving its author’s authority unavailable for the direct check possible with an explicit API call. Those differences make the boundary between reading and obeying the central point of failure.

Documented incidents that show the attack pattern in production

The Cloud Security Alliance’s account of the Cline AI coding assistant compromise shows the chain from untrusted input to software distribution. A GitHub issue title crafted to carry a malicious instruction brought it into an authenticated Claude coding session. The instruction triggered installation of an attacker-controlled package, which was subsequently distributed as an official update. The issue title supplied the direction, while the coding session supplied the authority.

Other documented research shows that the mechanism is not confined to coding tools. Researchers at the Spark Research Lab at the University of Texas at Austin showed how ConfusedPilot worked against RAG-based systems, including Microsoft 365 Copilot, in 2024. One variant put malicious text in the RAG prompt to corrupt the responses from the LLM. A second used the caching mechanism during retrieval to leak secret data. Here, the relevant boundary was the point at which retrieved material could affect a trusted response or the handling of confidential information.

Debi, Zhu, and Sen Gupta’s 2026 “Whispers of Wealth” red-team work demonstrated prompt injection against Google’s Agent Payments Protocol. The importance of this example lies in the authority attached to the agent. A payments-capable agent exposes financial consequences to the same class of injection that affects productivity tools. This was a demonstration with no evidence in the notes of a completed financial loss. It nevertheless extends the pattern beyond the integrity and confidentiality of data.

ScreenSwap’s 2026 research extends it beyond text. Researchers demonstrated a compromised agent intercepting a screenshot and swapping pixel content between an “Acknowledge Alert” button and an admin credential-reset button. The LLM then clicked the admin action on the basis of the manipulated screen. The deputy’s perception, rather than a written instruction alone, became the route to privileged execution. Taken together, the production compromise and research demonstrations show why defenses cannot be limited to one tool type or one form of input.

How multi-agent delegation multiplies confused deputy risk

Delegation makes the same boundary harder to follow because the agent that encounters untrusted content may not be the agent that acts. A low-privilege retrieval agent can read material, summarize it, and send it to a high-privilege execution agent. The agent that receives it may then act with authority that the original source of the content never held. In a multi-agent pipeline, that path can cross from one organization to another without a person reviewing each step. Limited privileges on the first agent do not, by themselves, contain the resulting action.

The failure surface is therefore the relationship between agents as much as the permissions of each one. A system that trusts peer agents by default has no mechanism to distinguish a reliable handoff from one shaped by compromise, hallucination, or error. Agent impersonation, confused-deputy permission inheritance, and cross-agent prompt-injection propagation are different ways that trust can fail. Uncontained blast radius and gateway or registry sprawl further complicate the boundaries. These are composition risks, which arise from how the parts work together.

The Model Context Protocol, or MCP, is the dominant agent-to-tool connector standard, and its server can hold credentials for upstream tools while acting for an LLM client. If the server does not propagate client identity into upstream calls, authorization decisions are made against the wrong principal. The server’s access then stands in for the caller’s entitlement.

The Crew Scaler study found that Non-Determinism and Data Leakage were the most under-addressed categories across the frameworks it reviewed, with mean scores well below the expected minimum. Those gaps matter because, in delegation, agents pass information to one another while how they read it can vary. A summary can pass on an injected instruction even when the summarizing agent cannot execute it.

Why existing frameworks and security tools miss this threat surface

Many frameworks assume deterministic control flow, bounded trust boundaries, stateless execution, and adversarial inputs that can be identified as such. Multi-agent systems instead share persistent memory, pass tool authority through delegation chains, and influence one another through shared context. A suspicious request may lose its form as a request as it moves through that system. It can become part of how another agent reasons about a task that seems legitimate.

The Crew Scaler comparison found that no framework achieved majority coverage of any single threat category in its evaluation. A 2026 analysis placed the OWASP Agentic Security Initiative in the overall lead at 65.3% coverage, still less than two-thirds of the taxonomy. Governance designed around more stable boundaries leaves important behavior between agents unaddressed. Knowing about prompt injection does not by itself create an authorization boundary that the system can enforce.

The NCSC states that there is no inherent distinction between data and instruction inside an LLM and that prompt injection may never be totally mitigated. That limits what a defense based on model judgment can promise. KAUST’s research on self-state attacks shows a similar limit in generic operating-system defenses. Those defenses can enforce, observe, attribute, and recover self-state changes, but they lack the decision context needed to distinguish malicious updates from legitimate ones. Visibility into a change is not the same as knowing whether that change was justified.

The paper “Capability Gates Are Not Authorization” makes this distinction explicit through its audit of LangChain/LangGraph, LlamaIndex, and the Stripe Agent Toolkit. It found that capability gates do not constitute authorization decisions. Knowing what a tool can do is different from deciding what it should do for a particular caller. Treating those questions as the same leaves the deputy free to use its authority for someone else’s request. The missing control is a principal-aware decision.

What controls actually close the architectural gap

Authorization belongs in a policy layer that checks the verified identity of the principal, the scope of each action, and the resource being accessed. The model can propose an action, but its interpretation should not establish permission to execute it. This separates the question of what the agent thinks it should do from what the caller is allowed to have done. The OWASP Top 10 for Agentic Applications 2026 names the confused deputy under Identity & Privilege Abuse, ASI03, and recommends identity propagation and per-action authorization as primary controls.

Least privilege must apply to each action and resource throughout a session. A token minted to summarize a customer’s open tickets should be useless for refunding their last order. That limit keeps the damage in check even if malicious content changes the agent’s plan. For MCP, servers should be treated as OAuth 2.0 resource servers, with guidance pointing to OAuth 2.1, PKCE, and audience-bound tokens. These controls address the risk of a server using its own broad privileges for a caller who does not hold them.

Delegation also needs clear consent and context that can be checked without taking another agent’s word for it. Controls for each client, a consent screen users can see, and approval that expires let users check tool access and the scope of data read/write before an MCP client goes ahead. Verifiable identity for every agent answers who is making the request. A shared governed context layer that both agents can check on their own lets them check whether the information being passed is up to date, approved, and correct. Neither layer substitutes for the other.

For irreversible actions, the gate should sit outside the LLM’s context and require human confirmation that the agent cannot satisfy through conversation alone. Monitoring vendor AI assets at all times and using real-time AI threat detection help make these decisions visible, but watching them must stay apart from granting authorization. KAUST’s findings likewise support self-state-aware mechanisms that add more context than generic file and process signals provide. Effective protection is layered, combining narrow credentials, explicit identity, independent policy enforcement, informed approval, and context-aware monitoring.