An AI agent can become a confused deputy when it uses the application’s legitimate credentials to carry out an action requested by untrusted content from someone who lacks the authority to perform that action. The model may propose the call, but the application must decide whether that specific operation, resource, and set of arguments are authorized.
What is a confused deputy?
A confused deputy is a program or service with legitimate authority that is tricked into using that authority on behalf of someone who does not have it. The deputy is “confused” about whose request it is serving or which resource its authority is meant to protect.
As an Amazon Associate I earn from qualifying purchases.
A classic example is a compiler allowed to write usage data into a protected system directory. If a user can choose the debug-output filename, they might specify the name of a protected billing file. The user cannot overwrite that file directly, but the compiler can—and may do so using its own permissions. The flaw is not simply that the compiler has authority; it is that it applies that authority to a user-controlled choice without preserving the intended boundary. Cosmonic’s capability-security explainer describes the concept and its connection to capability-based security.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →How can an AI agent become a confused deputy?
An agent may be connected to a mailbox, repository, payment service, CRM, browser, or infrastructure API. The application grants the agent credentials or capabilities to use those tools. Meanwhile, the agent may read content that someone else can influence: a web page, email, support ticket, retrieved document, tool result, or handoff.
#1 Best Overall
If that content contains instructions and the agent treats them as authoritative, it may propose an action that serves the content’s author rather than the user or organization. If the runtime then executes the proposal with broader application credentials, the agent has acted as a privileged intermediary for a less-privileged party. The risk therefore spans identity, context, credentials, authorization policy, and tool execution—not just the model’s response to malicious text.
The attacker need not be the person chatting directly with the agent. The 2024 preprint ConfusedPilot: Confused Deputy Risks in RAG-based LLMs describes studied mechanisms involving malicious text embedded in modified retrieval-augmented generation (RAG) prompts, retrieval-cache-related secret leakage, and integrity or confidentiality effects in enterprise responses. Those findings identify possible failure mechanisms; they do not establish that every RAG deployment is vulnerable.
Why tool permissions and schemas are not enough
Tool availability is not call authorization
A tool allowlist or menu can restrict which operations an agent is able to request. It does not determine whether a particular call is permitted in the current user, session, and resource context. An allowed “send payment” operation, for example, does not mean every destination and amount is authorized.
Valid arguments are not necessarily permitted arguments
A schema can check that an amount is numeric and a destination is a string. It cannot establish that the current principal may send that amount to that destination. Validation checks shape and type; authorization checks whether this specific action is allowed.
A 2026 arXiv preprint by David Mellafe Zuvic audited pinned public-source commits for LangChain/LangGraph, LlamaIndex, and Stripe Agent Toolkit. It reports capability gating in the audited defaults, but no deterministic, fail-closed authorization of the model’s concrete argument values by default under the paper’s stated conditions. This is a finding about the specified public code and audit conditions, not a claim about every version or private production integration. Read the preprint.
What the reported attack rates do—and do not—show
The same 2026 preprint describes a companion sweep across 27 models. It reports mean task-aligned attempted unauthorized-call rates of 0.603 for cost-optimized deployment-tier models and 0.189 for flagship models. These are attempted calls in the study’s benchmark, not successful breaches or estimates of real-world compromise probability. The deployment-tier aggregate has no paired confidence intervals, and the figures should not be generalized to a provider’s entire model fleet.
The available studies do not establish market-wide prevalence, how many deployed agents are vulnerable, or a real-world loss rate. Nor do they settle whether a particular current commercial framework is vulnerable in every configuration.
How to prevent an agent from using your permissions on an attacker’s behalf
1. Narrow the authority the agent receives
Give each agent only the credentials and resource access needed for its task. Prefer short-lived, task-specific credentials or capabilities bound to particular resources over broad ambient credentials. A capability-based design makes authority specific: possession of a capability grants access to defined resources or operations, rather than relying solely on a service’s general permissions. This reduces the damage a confused deputy can cause, though it does not replace authorization checks.
Best Value
2. Authorize every proposed side effect
Put a deterministic enforcement point between the model’s proposed call and the tool that performs it. For each side-effecting request, check the operation and its concrete arguments against trusted policy in the relevant principal or session context. Depending on the action, policy can enforce resource allowlists, scopes, amount ceilings, or replay protection.
3. Keep policy independent of untrusted content
Do not let retrieved text, emails, documents, or tool output redefine the permissions used to judge a call. Keep trusted policy outside model-controlled content, and ensure the enforcement layer—not the model—makes the authorization decision.
4. Fail closed and add approval where impact warrants it
If the policy check fails, is unavailable, or cannot resolve the request, deny the action rather than executing it. For high-impact operations, require human approval as an additional safeguard. Approval adds operational friction and should complement narrow permissions and technical enforcement, not stand in for them.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →5. Evaluate the implementation at the call boundary
When assessing an agent system, look beyond its registered tools. Check how broad its authority is, whether every call is checked, whether policy is independent of model-controlled text, and whether errors deny or allow the action. Also account for operational needs such as approvals and audit records. The cited sources do not provide a comprehensive independent comparison of products’ latency, cost, or usability.
Why the old bug keeps appearing in agent systems
The underlying pattern is older than AI: a privileged intermediary receives an attacker-influenced choice and applies its own authority without binding that authority to the right principal and resource. Agents increase the variety of content that can influence a call, including retrieved documents and ordinary tool inputs. That does not make every agent inherently vulnerable; exposure depends on the permissions it receives, the trust boundaries around its inputs, and whether the runtime enforces authorization for each action.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
