Prevent it by adding conditions in the role trust policy that tie the assumed role request to the intended caller and account. Use strict trust relationships, avoid broad service principals where possible, and require source conditions when a service assumes the role on behalf of another resource. Review roles for overbroad trust that could let an unintended party assume them.
A confused deputy issue happens when a trusted AWS service or workload can assume a role in a way that does not sufficiently prove which caller actually needs that access. The fix is to make the trust policy specific to the intended principal and context, so the role can only be assumed in the exact path you designed, not by a broader or unintended request path.
What the trust policy must prove before STS allows the assumption
The trust policy is the decision point that decides who may call sts:AssumeRole. If that policy is too broad, the role can be used by a legitimate service for the wrong resource, which is the classic confused deputy pattern. The practical goal is to bind the assumption request to the caller, the source account, and the service context that should be acting on behalf of the workload.
That means treating service principals as a starting point, not the whole control. Where the service can act on behalf of many resources or accounts, add conditions that narrow the delegation path. For cross-account or resource-mediated access, conditions such as source account, source ARN, external ID, or other request attributes are what stop a valid service from becoming an unintended deputy.
When you are reviewing an existing role, look for trust statements that accept a service principal without any accompanying condition logic. Those are often functionally correct for convenience but weak for delegation security, because they allow the trusted service to present itself without proving which upstream resource or tenant is entitled to the assumption.
How to structure the trust boundary so the intended caller is the only caller
A strong trust policy makes the caller identity and the authorization context mutually reinforcing. In AWS terms, that usually means using the narrowest principal possible, then adding conditions that reflect the exact relationship the role is supposed to serve. If the role is meant for one account, one workload, or one source resource, the trust policy should encode that relationship explicitly instead of relying on a broad service trust.
This is especially important when one AWS service is delegating access for another resource, such as a service acting on behalf of a bucket, queue, topic, function, or hosted application. In those cases, the service itself is legitimate, but the underlying resource or account may not be. A confused deputy control works by forcing the trust policy to distinguish those cases.
Role chaining deserves the same treatment. If one assumed role can assume another role, the second trust policy should be examined for whether it permits only the expected upstream role or account path. A chain that is acceptable in one environment can become a privilege path in another if the trust conditions are copied too broadly.
For AWS-specific role and policy analysis, the mechanics are covered in NHIMG’s AWS IAM Policies and Roles Guide, which is useful when you need to reason about trust policies, role chaining, and condition keys together.
What to review after you harden the trust relationship
Once the trust policy is tightened, the next step is to review every role that relies on service-mediated assumption or cross-account delegation. Roles with broad service principals, missing source conditions, or unclear ownership are the ones most likely to fail later during integration, because they appear to work until a different caller or resource starts using the same trust path.
It is also worth checking whether the role can be assumed from unexpected accounts, regions, or source resources, especially in multi-account environments. The question is not only whether the trust works, but whether it works only where intended. If the answer is unclear, the trust policy is probably doing too much implicit work.
When the role sits in a broader workload or cloud identity program, use lifecycle review to catch stale trust relationships and over-permissive delegation paths before they become permanent. NHIMG’s Cloud Workload Identity Guide is the most direct reference for AWS roles, STS, and workload identity patterns that reduce confused deputy exposure.
For teams that want the broader identity-governance lens, NHIMG’s IAM and IGA Basics helps place trust-policy review inside entitlement review, least privilege, and access governance rather than treating it as a one-off IAM exception.
Risk and Threat Considerations
A confused deputy flaw turns a legitimate AWS service into an unintended access path. The risk is not that the service is untrusted, but that it is trusted too broadly and can be induced to act for the wrong resource, account, or tenant. In multi-account and multi-tenant designs, that can create privilege leakage without any obvious credential theft.
Failure mechanism: A role trust policy accepts a principal that is real and valid, but does not bind the request to the intended caller context, so another resource or account can ride the same trust path and obtain the role.
Impact: An unintended party can gain permissions that were supposed to be limited to a different workload, which can lead to unauthorized data access, lateral movement, or cross-account privilege abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-16 — Security Properties of Information | Trust-policy conditions constrain who can assume a role and under what context. |
| IA-2 — Identification and Authentication (Organizational Users) | Role assumption depends on authenticated principals and verified caller identity context. | |
| AC-6 — Least Privilege | Overbroad trust policies grant more assumption paths than the role needs. | |
| Recommendation — Bind role assumption to the intended caller context with explicit trust conditions. Require verified caller identity before allowing role assumption. Minimize who can assume each role and restrict trust to the narrowest viable path. | ||
| CIS Controls v8 | 5 — Account Management | AWS roles and trust relationships are privileged access paths that need review and restriction. |
| Recommendation — Review privileged role trust paths and remove unnecessary assumption routes. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | AWS roles can become overprivileged when trust policies allow unintended assumption paths. |
| Recommendation — Tighten trust conditions so the role cannot be assumed by unintended callers. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Abuse of trust relationships can alter or extend access through valid accounts or roles. |
| Recommendation — Hunt for role-trust abuse that expands access through manipulated delegation paths. | ||
Practitioner Guidance
What to verify: Confirm that every role trust policy expresses both who may assume the role and the context that makes the assumption legitimate. If a service principal is present without a source condition, treat that as a review item, not a finished control.
Common mistake: Teams often stop at “the service principal is correct” and miss the more important question of whether the service is being constrained to the right upstream resource or account. That is where confused deputy failures usually hide.
Decision rule: If the role can be assumed by a service that acts for multiple resources, add the tightest available source-bound condition before you approve the trust. If you cannot express that binding cleanly, redesign the delegation path instead of accepting a broad trust policy.
Practitioner takeaway: The safest AWS trust policy is not the one that merely names the right service, but the one that proves which exact caller context is allowed to use that service path.
Related resources from NHI Mgmt Group
- How should security teams configure AWS role trust policies to avoid accidental privilege escalation in the first place?
- What do teams get wrong about AWS trust policies and role assumption?
- Why do overly broad AWS IAM policies create more risk than clean role names suggest?
- How do you detect S3 Browser being used to create IAM users, keys or bucket policies in AWS?