How IAM Trust Policy Misconfigurations Enable Privilege Escalation

Read full article here: https://www.token.security/blog/iam-role-trust-policies-misconfigurations-hiding-in-plain-sight/?utm_source=nhimg

Even small misconfigurations in AWS IAM role trust policies can create dangerous privilege escalation risks, allowing unauthorized identities—human or machine—to assume powerful roles. This first article in a three-part series exposes how confusing AWS documentation and subtle design flaws lead to widespread misconfigurations that threaten entire cloud environments.

IAM roles form the foundation of access management in AWS, defining who can assume a role (trust policy) and what that role can do (permission policies). While permission policies are often the focus of least-privilege efforts, trust policies are equally critical—and often misunderstood. A single oversight in a trust policy, such as overbroad principal definitions, can open an organization’s environment to full compromise.

Why Trust Policies Are So Often Misconfigured

Unlike permission policies, trust policies suffer from limited and inconsistent documentation. AWS references them across multiple fragmented pages, using different names such as “trust policy,” “trust relationship,” and “AssumeRolePolicyDocument.” This inconsistency, combined with the lack of a clear standalone guide, leaves many practitioners guessing at best practices. The result: even experienced engineers misinterpret how trust relationships actually function.

The Two Dangerous Misconfigurations Most Organizations Miss

1- Trusting all principals within the same account - A surprisingly common mistake is using the following configuration to allow “all principals” in the same AWS account to assume a role:

"Principal": {"AWS": "arn:aws:iam::<account-id>:root"}

Although this appears to restrict access to the account’s root user, it actually extends trust to every IAM user, role, and service within that account. This is effectively the same as leaving every door unlocked for anyone who gains a foothold in the environment. If any identity in that account can perform sts:AssumeRole, it can exploit this misconfiguration to escalate privileges immediately. This issue is particularly dangerous because AWS Access Analyzer does not alert on it—meaning many organizations remain unaware of the exposure.

2- Combining multiple principals assuming they act together (AND) instead of independently (OR) - Another frequent misunderstanding involves the logical relationship between multiple principals. When multiple principals are listed in a trust policy, AWS evaluates them using OR logic, not AND. This means any one of the specified principals can assume the role, regardless of the others.

For example, a trust policy defining both a service principal (ec2.amazonaws.com) and an account principal (arn:aws:iam::<account-id>:root) allows both independently—not just EC2 instances from that account. This leads to unintended access paths where unrelated entities can assume high-privilege roles, contradicting the original security intent.

Why These Issues Persist

The problem is not just technical, it’s educational. AWS’s documentation gap and naming inconsistencies lead to a fundamental misunderstanding of how role trust is evaluated. Security teams assume least privilege is enforced automatically, but trust misconfigurations operate silently beneath the surface, bypassing even mature IAM review processes. The result is a hidden privilege escalation layer that attackers can exploit without triggering traditional alerting.

The Path Forward

Securing AWS identity requires treating trust policies as first-class citizens in the IAM ecosystem. Organizations must audit every trust relationship, ensure that principals are explicitly scoped, and verify that logical conditions match intended behavior. Awareness is the first step toward eliminating these silent, high-impact misconfigurations.