An IAM Permissions Boundary Fails to Block Decrypt Access Granted by a KMS Key Policy

Symptom

A workload assumes an IAM role carrying an explicit permissions boundary intended to cap the role to a single AWS account’s resources. Despite the boundary, the role successfully calls kms:Decrypt against a customer-managed KMS key that lives in a second, unrelated AWS account. CloudTrail records the call as Allowed, and no boundary-related Deny appears anywhere in the event’s policy evaluation detail. Nothing about the role’s own identity-based policies was changed before the access appeared.

False Assumption

The team that attached the permissions boundary assumed it would cap every permission the role could ever exercise, from any source, because that is how boundaries are commonly described in informal terms: as a hard ceiling on the role. On that assumption, a boundary limiting actions to one account’s resources was treated as sufficient to prevent any cross-account data access, without separately auditing resource-based policies attached to resources the role might be granted access to from the other side.

Root Cause

An IAM permissions boundary is a managed or inline policy that limits the maximum permissions an identity-based policy can grant to the IAM entity it is attached to. It is evaluated only against identity-based policy grants for that entity. It does not evaluate, intersect with, or override resource-based policies, such as a KMS key policy, an S3 bucket policy or an SNS topic policy, that separately grant permissions to the same principal from the resource side. If a KMS key policy in another account names the role’s ARN as a principal and grants kms:Decrypt, that grant is evaluated independently of the role’s own permissions boundary. The boundary constrains what the role’s identity-based policy can hand out; it has no authority over what a resource owner in a different trust boundary hands back in. This is a widely documented characteristic of IAM policy evaluation logic, but it is easy to miss when a boundary is treated informally as a universal cap rather than a one-sided constraint.

Impact

The immediate impact is that a role believed to be contained to one account can read encrypted data protected by a key in another account, undermining the isolation the boundary was meant to enforce. Because the access is technically authorised by two independent, correctly evaluated policies, no policy-evaluation error or explicit deny is generated, so the exposure is unlikely to surface through routine access-denied alerting. The blast radius depends on what the key protects; where the key wraps sensitive data such as customer records or credentials, this qualifies as a high-severity identity boundary failure even though every individual policy statement is syntactically valid.

Diagnosis

Confirm the mechanism before changing anything. First, retrieve the role’s attached policies and boundary to confirm what the boundary actually restricts.

Correction

The fix is not to modify the permissions boundary, which is already working exactly as designed; it targets the key policy that grants the unintended access.

Validation

Validation must confirm the specific unwanted grant is gone without breaking legitimate same-account decrypt operations that depend on the key.

Rollback

If removing the cross-account principal breaks a dependency that was not fully mapped, restore the exact prior key policy captured during diagnosis rather than improvising a new one.

Prevention

Treat permissions boundaries and resource-based policies as two independent control planes that must both be reviewed, not one substituting for the other. Maintain an inventory of resource-based policies (KMS key policies, S3 bucket policies, SNS/SQS policies, Secrets Manager resource policies) that name cross-account or wildcard principals, and review it whenever a boundary is introduced or a role’s scope changes. Where an organisation-wide backstop is needed regardless of individual resource policies, use an AWS Organizations service control policy, which does apply across accounts, rather than relying solely on a per-role permissions boundary to achieve that effect.