The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →A confused deputy is a privileged program or service that a less privileged caller manipulates into using its own authority on that caller’s behalf, in a context the caller could never access directly. The deputy is not hacked or broken. It does exactly what it was built to do, but it cannot tell which caller, account, or resource a given request is really meant for. The fix is to bind each privileged action to the identity and target the request is supposed to serve.
Why the deputy is trusted and why that trust is the weakness
The term describes a trust relationship. A program holds more permissions than the people or systems that call it, because its job is to act for them: reading a bucket, assuming a role, querying a database, or fetching a document for a chatbot. A caller without those permissions can still benefit from them if it can persuade the deputy to act on its behalf.
As an Amazon Associate I earn from qualifying purchases.
Amazon Web Services defines the problem as an entity without permission coercing a more privileged entity into performing an action. The IAM User Guide page “The confused deputy problem” uses this framing for cross-service and cross-account cases. The NIST guidance on API protection for cloud-native systems (NIST SP 800-228-upd1, June 2025, section 2.7.6) describes it as a type of privilege escalation in which a privileged entity, the “deputy,” is tricked into using its authority on behalf of another, less privileged entity. Both descriptions point to the same underlying fault: the privileged party acts without knowing whose request it is serving.
Recommended Free Tools
That distinction matters for diagnosis. Looking for a leaked password or a stolen key will not reveal a confused deputy, because nothing was stolen. The deputy’s credentials are valid and its permissions are intended. What is wrong is the mapping between the request and the authority used to fulfill it.
#1 Best Overall
How the mix-up happens
Three conditions usually have to be present together:
- The deputy holds permissions the caller lacks.
- The deputy accepts input that names a target, such as a role, account, bucket, customer, or document, and the caller controls that input.
- Nothing in the authorization check binds the target back to the caller’s legitimate context. The check asks “is the deputy allowed?” rather than “is this caller allowed to reach this target through the deputy?”
When all three hold, the deputy’s own permissions answer the check, and the caller gets the result. The caller never needed to escalate its own privileges. It only needed to supply the wrong name at the right moment.
Worked patterns
Third-party cross-account role assumption
A common setup lets a third-party service assume an IAM role in a customer’s account so it can do work there. Suppose that provider serves many customers. Another customer who knows the first customer’s role ARN could supply it to the provider and cause the provider to assume that role while acting for the wrong customer. The ARN is not a secret, so hiding it does not solve the problem. The gap is that role assumption is not tied to the customer the provider is acting for.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
AWS’s documented control is an external ID. The customer’s role trust policy requires a unique external ID, which the provider generates and controls for each customer and includes whenever it assumes that customer’s role. A caller who only knows the ARN can no longer make the provider assume the role for a different customer, because the provider will not send the correct ID for that customer’s context.
Service principals acting on resources
A resource policy can grant access to an AWS service principal, such as CloudTrail writing logs to an S3 bucket. If the grant has no conditions, the service may act on behalf of an account that should not be able to use this bucket. The concern is not that CloudTrail is compromised. It is that the service cannot tell, from the grant alone, which account’s activity it is recording into this target.
AWS recommends narrowing the grant with supported source context condition keys: aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, or aws:SourceOrgPaths. These let the policy state which resource, account, or organization the service must be acting for. Support differs by service, so confirm which keys a given service honors in that service’s own documentation before relying on one.
Rank #3
Credential brokers
A broker that holds several credentials and hands them out on request is a deputy by design. If it releases a credential without authenticating the caller or checking that the caller is entitled to that particular credential, one caller can receive another caller’s access. NIST’s guidance addresses this by splitting a broad deputy into more narrowly scoped entities. Each one holds one credential and maps closely to one application or service, so a request cannot be redirected to a different credential set.
Retrieval-augmented generation (RAG) applications
An AI application often has broad read access to a document store so that it can answer questions from it. An end user may have no direct access to some of those documents. If the application retrieves whatever is relevant without applying that user’s permissions to the results, the application becomes a confused deputy and can return content the user should not see.
AWS’s Security Blog post on data authorization for generative AI applications (part 1) makes the key point: prompting and model guardrails are not authorization mechanisms. Access control has to be enforced in the application flow, most importantly by filtering retrieval results against the requesting user’s permissions before anything reaches the model.
Security researchers have also studied the threat directly. The 2024 arXiv preprint “ConfusedPilot: Confused Deputy Risks in RAG-based LLMs” by Ayush RoyChowdhury and colleagues describes integrity and confidentiality risks in RAG systems, including malicious text planted in retrieved context and leakage through retrieval caching. It is a preprint describing a class of attacks, not a finding that every RAG product has these weaknesses.
How to recognize a confused deputy in your own design
Ask these questions of any component that acts with more authority than its callers:
- Which caller initiated this action, and does the deputy record that identity in the authorization decision?
- Can a caller influence a parameter that selects a role, account, resource, tenant, credential, or document?
- If the caller supplied a different target, would the deputy still succeed? If yes, the target is not bound.
- Does the trust policy or resource policy restrict which service, account, or organization may act, or does it grant access to any caller that presents the right principal?
- Is any filtering done by the model or prompt, rather than by a deterministic authorization check?
Controls that bind a request to its intended context
The right control depends on where the deputy sits. The table below separates the four patterns above by the binding each one needs.
Best Value
| Pattern | Risk | Binding control | Where it is enforced | Caveat |
|---|---|---|---|---|
| Third-party cross-account role assumption | Provider assumes a customer’s role while serving a different customer | Unique external ID in the role trust policy, generated and controlled by the provider and sent when assuming that customer’s role (AWS IAM User Guide) | IAM trust policy at role assumption | The provider must generate and send the correct ID for each customer |
| Service principal acting on a resource | Service writes or reads for an account that should not reach the target | Source context conditions: aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, aws:SourceOrgPaths |
Resource policy | Support varies by service; check that service’s documentation |
| Credential broker | One caller receives another caller’s credential | Authenticate the caller and authorize before releasing a credential; split the deputy so each credential has its own narrowly scoped entity (NIST SP 800-228-upd1) | Broker, before credential release | Requires redesigning the broker, not only adding a check |
| RAG application | Retrieved documents exceed the user’s access | Filter retrieval results by the requesting user’s permissions; enforce across the whole data flow (AWS Security Blog, part 1) | Retrieval layer, before content reaches the model | Prompts and guardrails do not enforce access control |
Practical rules for keeping the deputy honest
- Bind delegated authority to the caller’s context, not only to the deputy’s identity.
- Scope every privileged role or credential to one application, customer, or service where the design allows it.
- Prefer supported conditions that name the expected source resource, account, or organization over broad principal grants.
- Perform authorization in deterministic code at the point where data or credentials are accessed.
- Log the caller identity alongside each privileged action so that an unexpected target can be traced to the request that produced it.
Recognizing the pattern is the first step. The controls above only work when each privileged action can be tied back to a specific caller and a specific intended target.
Confused deputy flaws are a structural issue in how authority is delegated between components. They are easy to miss in design review because every individual permission looks reasonable on its own. Checking that each deputy’s authority is bound to the caller it serves is what keeps a trusted program from being turned against its own users.
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.
