iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An AI agent becomes a confused deputy when it uses authority it legitimately holds—such as a user token or service identity—to carry out an action that an untrusted party has induced it to perform. Prompt injection can be part of that chain, but it is not by itself proof of a confused-deputy exploit. The decisive failure is authorization: the action boundary does not verify that this caller may perform this specific action on this specific resource.
What is a confused deputy in an AI agent?
A deputy is a component with more authority than the person or process asking it to act. It becomes “confused” when it cannot correctly distinguish whose request it is carrying out, or whether the requested use of its authority is legitimate. AWS defines the classic problem as a less-privileged entity coercing a more-privileged one into performing an action the first entity cannot perform itself.
In an agent system, the deputy may be an orchestrator, tool server, or agent with a user token, workload identity, API credential, or broad service permission. A webpage, email, issue, retrieved document, tool response, or message from another agent can supply untrusted content. If that content influences the agent to call a tool, the call may execute with the agent’s authority—not the content author’s.
That is why a tool being available to a model is not the same as every use of that tool being authorized. A prompt that says “be careful” can guide behavior, but it cannot enforce permission at execution time.
#1 Best Overall
How can prompt injection turn into an authorization failure?
Prompt injection is a way untrusted content may influence an agent. A confused-deputy exploit requires more than an instruction hidden in a page or document: the system must expose that content to an agent, give the agent relevant authority or a side-effecting tool, and fail to bind the requested action to the right principal, resource, and purpose.
A typical failure chain
- The agent receives untrusted content. For example, an email, webpage, retrieved file, tool result, or inter-agent message contains an instruction to take an action.
- The agent can act with meaningful authority. It has access to a credential, identity, connector, or tool capable of making the change or sending the information.
- The content influences a tool call. The agent treats the content as a direction rather than merely data to assess.
- The execution layer checks too little. It may check only that a tool is enabled, or trust the agent’s broad credentials, rather than verifying the requested operation, arguments, target, caller, and context.
- The action inherits the deputy’s privilege. The system performs an operation the content author could not have performed directly.
For example, imagine an agent authorized to read a team’s documents and send messages on an employee’s behalf. A document contains instructions to send a confidential file to an outside address. If the agent follows them and the sending service checks only the agent’s broad permission to send mail, the document has influenced an action executed with someone else’s authority. The vulnerability is not simply that the document contained hostile text; it is that the action boundary did not enforce whether this particular send was permitted.
What controls prevent an agent from acting outside its authority?
Put authorization where actions are executed, then limit what the agent can do if that check fails. Microsoft’s agent security guidance emphasizes per-action, per-resource permission checks and warns against relying solely on a server’s own execution identity.
Authorize the concrete action at the boundary
For every tool call, evaluate the tool and operation, its arguments, the target resource, the originating principal, and relevant session context. A check that a tool is enabled—or that the agent has some permission to use it—is not enough. Separate the identity a server uses to execute from the caller whose rights must be checked.
Rank #3
Keep identities and delegated permissions narrow
Give each connector or tool only the permissions it needs. Prefer narrow delegated or on-behalf-of identities where available instead of broad standing credentials. In multi-agent workflows, treat a handoff as a trust boundary: do not silently pass a parent agent’s broad authority to a child. Establish and verify what the receiving agent is allowed to do.
Treat content as data, not authorization
Keep provenance attached to retrieved documents, emails, webpages, tool outputs, and agent-to-agent messages. They may provide information for the agent to evaluate, but they cannot grant permission or override an authorization decision. Reapply input-safety checks at handoffs between agents; these checks complement, but do not replace, authorization at the tool boundary.
Add review and operational safeguards
- Require human approval for sensitive or irreversible actions, including writes, deletes, payments, production changes, and external sends.
- Log tool invocations with the identity, inputs, outputs, and authorization decision context needed for an audit.
- Sandbox code execution and browsing tools, and restrict their filesystem and network access.
- Isolate agent and tenant memory so one user’s context cannot become another user’s authority or instructions.
- Control outbound network access so a tool or agent cannot send data to arbitrary destinations merely because it can reach them.
How do cloud confused-deputy protections apply?
Cloud IAM offers concrete patterns, but these controls are specific to supported services and configurations. They are not a universal authorization layer for every agent framework or tool server.
AWS cross-account and cross-service access
In AWS’s cross-account example, a third-party service that receives a role ARN could be tricked into using that role for a different customer. AWS recommends binding the role trust to a unique external identifier generated and controlled by the third-party service. For cross-service access, AWS documents resource-policy conditions such as aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, and aws:SourceOrgPaths where supported. The applicable condition and protections depend on the service; AWS advises checking the relevant service documentation.
Best Value
Azure MCP Server deployments
Microsoft’s deployment guidance recommends narrow RBAC roles, enabling only needed tools, and using managed or workload identities where possible. It also calls for checking permissions per caller rather than relying only on the server’s identity. An enforcement gateway, endpoint validation, and sandboxing can add controls around execution. Malicious tool metadata or responses remain potential prompt-injection paths, so those inputs must not be treated as authorization.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How do authorization approaches differ?
| Approach | What it checks | What can go wrong |
|---|---|---|
| Prompt or planner instruction | Asks the model to follow safety rules. | It is guidance, not deterministic permission enforcement; untrusted content may still influence a call. |
| Tool availability check | Whether the agent can see or invoke a tool. | Availability does not establish that this caller may perform this operation on this resource. |
| Execution-boundary authorization | The operation, arguments, resource, caller, and session context for each call. | Requires the gateway or execution layer to have enough identity and policy context to make the decision. |
| Human approval for consequential actions | A person reviews a proposed sensitive or irreversible action before execution. | It adds review friction and should supplement, not replace, automated authorization. |
Responsibility for these controls varies by deployment. In a managed platform, some infrastructure controls may be handled by the provider while the customer remains responsible for identity scope, permissions, and the agent’s configuration. Self-hosted deployments place more of the execution and operational controls with the operator. Microsoft’s shared-responsibility guidance describes these distinctions; the exact split depends on the service and deployment.
What do recent reports establish—and what do they not?
The Cloud Security Alliance AI Safety Initiative’s note, published March 23, 2026, reports that an attacker-controlled package in the described Cline incident was distributed as an official update to approximately 4,000 developer machines. That is the figure reported by the CSA note; it should not be treated as independently confirmed here, nor does it establish how often agent deployments experience confused-deputy failures.
Recommended Free Tools
A June 27, 2026 arXiv preprint by David Mellafe Zuvic reports a cross-framework, sandboxed 27-model sweep with mean attempted unauthorized-call rates of 0.603 for its cost-optimized deployment-tier grouping and 0.189 for flagship models. These are bounded experimental measurements reported by the preprint, not breach rates or estimates of production incident frequency. The authors also report that their proposed control had 0/48 static bypasses and 0/29 unauthorized attempts in an adaptive run, with 0/10 benign false-denies. Those results are author-reported, not independently replicated; the page states that no live third-party service was tested and no CVE is asserted. They do not show that every current framework or production deployment has the same weakness.
What should you check in an agent system?
- Can untrusted documents, messages, webpages, or tool results influence an agent that has side-effecting tools?
- Does each tool call receive a deterministic authorization check for its operation, arguments, target, caller, and context?
- Are credentials narrowly scoped, and are permissions re-established rather than inherited silently at agent handoffs?
- Do sensitive actions require approval, and can operators audit who initiated a call and why it was allowed?
- Are memory, code execution, browsing, and outbound network access isolated and limited to the intended user or tenant?
If the only safeguard is a prompt telling the model not to misuse its tools, the system does not have an authorization control at the action boundary. The key question is whether the execution layer can independently reject a request that the current caller is not allowed to make.
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.
