Overbroad IAM Trust Policy Principal Lets Unintended Identities Assume a Role

Symptom

A role intended for one workload can be assumed by identities that nobody planned to authorise, and nothing fails to warn you.

The role works for the intended workload, so functional testing passes. The exposure appears only when someone reviews the trust policy or finds unexpected AssumeRole events in audit logs.

False assumption

The common assumption is that a working trust policy is a correct one. A successful assumption by the intended caller says nothing about who else is permitted.

A second assumption is that a permission boundary on the role’s own policies limits who may assume it. The trust policy is a separate control: it defines who may assume the role, while the permissions policy defines what the role can do afterwards.

Root cause

The trust policy names a principal broader than the workload, for example an account root or a wildcard. AWS documents that an account principal in a trust policy delegates the decision to that account, where any identity granted sts:AssumeRole can then assume the role. Confirm exact evaluation behaviour in the AWS IAM documentation, as this article draws only on general documented behaviour. Related reading: the account root principal in IAM trust policies and wildcard principals in IAM trust policies.

Impact

The blast radius equals the role’s permissions multiplied by every identity able to reach it. Any compromised or over-permissioned identity in the trusted scope becomes a route to the role’s access, which weakens least privilege and complicates incident scoping. Severity is rated high on this basis, not on difficulty.

Diagnosis

Use read-only inspection in a non-production account first. Retrieve the trust policy and review each Principal and Condition element.

1. Fetch the role’s trust document and note every principal.
2. Flag any account root, wildcard or shared-role principal.
3. Check whether Conditions restrict the caller, for example by external ID or source identity.
4. Review audit logs for AssumeRole calls by callers outside the expected set.

A related pattern for resource policies is described in account ARN principals granting every role.

Correction

Replace the broad principal with the specific role or service principal that needs access, and add conditions where the use case supports them. Save the existing trust document first so it can be restored. Apply in non-production, then confirm the intended caller still succeeds. Be aware that adding conditions such as an external ID can itself cause AccessDenied if the caller does not supply the value.

Validation

The correction is validated when the intended workload assumes the role and an identity outside the intended set is refused.

• The intended caller obtains temporary credentials.
• A deliberately unauthorised test identity receives AccessDenied.
• Audit logs show only expected callers after the change.

Rollback

Rollback restores the saved original trust document, which is the only state this change alters.

Stop and roll back if the intended workload loses access and cannot be fixed by correcting the principal. Re-apply the saved document, then confirm the intended caller succeeds again. Remember that restoring it also restores the exposure, so treat rollback as temporary and escalate to a human reviewer.

Prevention

• Review trust policies as carefully as permissions policies.
• Prohibit account root and wildcard principals by default, with documented exceptions.
• Alert on new AssumeRole callers.
• Test negative cases, not only the intended caller.

Confirm version-specific details in the AWS documentation listed in the sources. The next safe decision is to inventory roles with broad principals, ranked by the permissions they grant.