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
A confused deputy is a privileged program or service that a less privileged party manipulates into using its own permissions on that party’s behalf, against a target the caller could not reach directly. The deputy is not broken. It is doing what it was built to do, but it has been given a request without enough context to tell whose behalf it is acting on. The defense is to bind every privileged action to the caller, account, and resource it was meant for.
How the attack works
A deputy is an intermediary that is trusted to act for other parties. It typically holds more authority than any single caller: a cross-account role it can assume, a read path into a private data store, or a credential it can use to call an API. Callers without that authority send it requests and rely on it to apply the authority correctly.
AWS describes the confused deputy problem as an entity without permission coercing a more privileged entity into performing an action. In the AWS IAM User Guide, the entry on this problem explains that the caller borrows the deputy’s authority rather than acquiring it. The attacker does not need to steal the deputy’s credentials; they only need to shape the request so the deputy uses them in the wrong context.
Two conditions have to line up. The first is that the deputy has access the caller lacks. The second is that the deputy cannot reliably tell which customer, account, resource, or end user a given request is for. When the second condition fails, the deputy’s correct permissions become the attacker’s path to the target.
#1 Best Overall
Why the deputy cannot tell the difference
In most real incidents the deputy’s logic is not obviously wrong. The gap is missing context at the moment of the privileged call. Common forms of that gap include:
- A role or credential reference supplied by the caller is accepted without confirming that the caller owns it.
- A service principal is trusted by name alone, with no condition limiting which resource or account it acts for.
- A retrieval or lookup step returns data without applying the requesting user’s own access rules.
- One credential is shared across several callers, so the deputy has no separate identity to check.
Example one: third-party cross-account role assumption
An organization can authorize an outside service provider to assume an IAM role in the organization’s account. This is a normal pattern for monitoring, backup, and security tooling. The trouble starts when the provider serves many customers.
Suppose customer A has given the provider access by trusting the provider’s role. Customer B, who is also a client of the provider, learns the role ARN from customer A’s environment, perhaps from a shared template or a leaked configuration file. If the provider’s system accepts a role ARN from customer B’s request and assumes it without checking which customer the request belongs to, the provider has become a confused deputy. Customer B has used the provider’s trust relationship to reach customer A’s account.
The role ARN is not a secret in this scenario. The control that matters is binding the role assumption to the correct customer context. AWS’s guidance for this case is to add a unique external ID to the role’s trust policy, using the sts:ExternalId condition. The provider generates and controls that value, assigns a distinct one to each customer, and includes it every time it assumes the role on that customer’s behalf. A request that names customer A’s role but carries customer B’s external ID then fails the trust check.
Keep in mind that the external ID only helps if the provider stores the mapping correctly and never reuses or exposes it across customers. It is a binding mechanism, not a substitute for the provider’s own tenant isolation.
Example two: service principals writing to your resources
A resource policy can grant access to an AWS service principal, such as CloudTrail writing logs to an S3 bucket. The service then acts on behalf of many accounts. If the bucket policy grants that principal access without conditions, the service could be induced to write on behalf of an account that should not be allowed to use the bucket.
AWS recommends limiting service-principal access with supported source context condition keys. Each key narrows the scope of the service’s action in a different way:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →| Condition key | What it binds the request to | Typical use |
|---|---|---|
| aws:SourceArn | One specific resource that is making the call | Narrowest option when the calling resource is known in advance |
| aws:SourceAccount | The AWS account that owns the calling resource | Stops cross-account misuse when the account is fixed but resource names vary |
| aws:SourceOrgID | The AWS Organizations identifier of the caller’s organization | Allows any account in one organization without listing each account |
| aws:SourceOrgPaths | A path within the organization structure | Limits access to a branch of the organization, such as one business unit |
Use the narrowest key that fits your design. Whether a given service accepts a given key is a service-specific matter, so confirm support in that service’s documentation before depending on it. Some services add safeguards beyond these keys, and the service’s own guidance should be followed alongside them.
Rank #3
Example three: retrieval in RAG and generative AI applications
A retrieval-augmented generation application often has a service role that can read a large private document store. End users usually cannot read that store directly. If the application lets any user ask questions and then retrieves documents using only the application’s own permissions, the application is the deputy, and the user is the caller.
Where the authorization gap sits
AWS’s security guidance on generative AI data authorization, in its part 1 post on effective data authorization mechanisms, states that prompting and model guardrails are not authorization mechanisms. A system prompt that says “only answer using documents the user may see” does not stop the model from being shown documents the user should not see. Authorization must happen in the application flow itself, which means filtering retrieval results against the requesting user’s access before any content reaches the model.
A practical check is to ask at which step the system decides whether a given document may be used. If the answer is “the model decides,” the design has no enforcement point.
Free tools Windows power users keep installed
One-click scans. No signup required.
Injected and cached content
The 2024 ConfusedPilot preprint by Ayush RoyChowdhury and colleagues, posted to arXiv with a date of 2024-08-09, discusses confused deputy risks in RAG-based large language models. It describes integrity and confidentiality concerns, including malicious text placed in content the system later retrieves, and leakage that can occur through retrieval caching. This is a study of a threat class, and it does not show that every RAG system has these weaknesses. Treat it as a reason to test how your own retrieval layer handles untrusted content and cached results.
Credential brokers and deputy separation
A credential broker exchanges one credential for another and hands out access on behalf of callers. It is a classic confused deputy because it holds powerful credentials and releases them based on what a caller asks for. NIST’s guidance on API protection for cloud-native systems addresses this directly.
NIST SP 800-228-upd1, Guidelines for API Protection for Cloud-Native Systems, June 2025, section 2.7.6, defines the problem this way: “A ‘confused deputy’ is a type of privilege escalation where a privileged entity (the ‘deputy’) is tricked into using its authority on behalf of another, less privileged entity.” The same guidance recommends breaking a deputy into more narrowly scoped entities, each holding one credential and mapping closely to one application or service. A broker that mixes caller identities without strong authentication and authorization before credential release is the pattern to avoid.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to spot a confused deputy in your own design
Use these questions when reviewing any privileged intermediary, whether it is a cross-account role, a service integration, a broker, or an AI retrieval layer:
- Who is the caller, and how does the deputy verify that identity before acting?
- Which account, customer, or resource does this request belong to, and where is that value checked?
- Can a caller supply a role, ARN, or resource identifier that the deputy then uses without confirming ownership?
- Does a trust policy or resource policy restrict a service principal to a specific source, or does it accept any source?
- Is authorization enforced on the data path, such as retrieval filtering or credential release, rather than delegated to a prompt or a model?
- Does one credential serve several callers? If so, can it be split into narrower credentials?
A “no” to any of the first four questions is a reason to review the design before the next privileged call is made.
Best Value
Controls compared
Each risk pattern has a different binding control and a different enforcement point. The table below separates them so a mitigation for one pattern is not assumed to cover another.
| Risk pattern | Binding control | Enforcement point | Check before relying on it |
|---|---|---|---|
| Third-party cross-account role assumption | Unique external ID per customer in the trust policy, generated and controlled by the provider | The trust check at role assumption | Provider stores and sends the correct ID for each customer and never shares it across tenants |
| Cross-service resource access | Source ARN, source account, or source organization conditions | The resource policy evaluating the service principal’s request | The specific service supports the chosen condition key |
| Credential brokering | Caller authentication and authorization before credential release, with separate credentials per application or service | The broker, before it issues or exchanges any credential | No single broker credential can act for every caller |
| RAG and generative AI retrieval | Filtering retrieved documents by the requesting user’s access rights | The retrieval step, before content reaches the model | Prompts and guardrails are not counted as the control |
Across all four patterns, the question is the same: which caller and which resource relationship caused this privileged action, and where was that relationship verified?
Keep permissions narrow
Narrow permissions reduce the damage when a deputy is confused, even if binding controls fail. A deputy that can reach only one resource, for one account, under one credential, gives an attacker far less to borrow. Review each privileged role periodically and remove permissions the task no longer requires.
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.
