What breaks when AWS trust policies are too permissive?

When AWS trust policies are too permissive, the role’s receiving side no longer controls who can assume it. That means a strict PassRole policy can still be undermined if the target role accepts broad principals or services, creating confused deputy risk and expanding the blast radius of compromise.

Why This Matters for Security Teams

Too-permissive AWS trust policies break the control boundary on the receiving side of an IAM role. Even when a strict PassRole policy exists, the role can still be assumed by principals or services that were never intended to use it, which creates confused deputy risk and widens the blast radius of any compromised workload identity. This is not a theoretical IAM issue; it is a practical trust problem that shows up when identity governance is treated as a one-time configuration instead of a living control.

For security teams, the operational impact is straightforward: an attacker who gains a foothold in one workload can often chain that access into other roles if the trust policy is broad enough. That is why NHI governance has to cover both what can pass a role and what a role will accept. The risk is amplified when secrets are long-lived or poorly rotated, which is why NHIMG highlights how Lifecycle Processes for Managing NHIs and the Top 10 NHI Issues both emphasise continuous review rather than static provisioning. In practice, many security teams discover the trust-policy gap only after an assumption path has already been abused, rather than through intentional design review.

How It Works in Practice

A secure AWS role assumption path has two sides: the caller side, controlled by permissions such as PassRole, and the receiver side, controlled by the role trust policy. Both must be restrictive. If the trust policy allows broad principals, wildcard service access, or overly general conditions, the role becomes assumable by identities that should never have been eligible in the first place.

Current guidance suggests treating the trust policy as the primary gate for who may assume the role at runtime. That means narrowing NIST Cybersecurity Framework 2.0 access control expectations into concrete AWS conditions, such as binding the role to a specific AWS service, account, external ID, source ARN, or source identity where appropriate. For non-human identities, the stronger pattern is to pair trust policy constraints with lifecycle controls: short-lived credentials, scoped role chaining, and explicit revocation when the workload is decommissioned.

• Allow only the minimum principal set that must assume the role.
• Use conditions to bind assumptions to the intended account, service, or request context.
• Review whether the role can be assumed indirectly through another trusted service.
• Pair trust-policy hardening with rotation, offboarding, and secret inventory controls.
• Log and alert on unexpected assume-role activity, especially cross-account paths.

NHIMG’s research on the 230M AWS environment compromise shows how quickly identity exposure becomes an environment-wide problem when access paths are too open. These controls tend to break down in multi-account environments with shared deployment tooling because inherited trust relationships are easy to forget and difficult to audit.

Common Variations and Edge Cases

Tighter trust policies often increase operational overhead, requiring organisations to balance deployment speed against identity precision. That tradeoff is real, especially in platform engineering, CI/CD, and cross-account automation where teams want reusable roles for many services. Best practice is evolving, but there is no universal standard for this yet: some environments can enforce very specific source conditions, while others need a staged approach to avoid breaking legitimate automation.

One common edge case is service-linked or brokered access, where a role must trust an intermediary service rather than a human or application directly. Another is third-party integration, where external IDs and explicit account scoping become essential because generic trust relationships are too easy to abuse. AWS trust policies also need special scrutiny when roles are reused across dev, test, and prod, since a permissive trust rule in one environment can become the easiest escalation path into the next.

For governance alignment, current practice is to combine identity reviews with the Regulatory and Audit Perspectives guidance and to treat every broad trust statement as a compensating-control trigger. The practical rule is simple: if a role would still be assumable after a caller is compromised, the trust policy is not narrow enough. In shared services and legacy cloud estates, that assumption fails most often because trust was granted for convenience and never revisited after the first deployment.

Related resources from NHI Mgmt Group

• What breaks when SSO trust is too permissive across identity providers?
• Why do non-human identities create compliance risk even when policies exist?
• When should organizations review their NHI policies?
• When does an NHI become too risky to keep as-is?