The IAM Blind Spots That Keep Showing Up in Cloud Assessments

Almost every cloud assessment starts the same way: pull the IAM policy set, map the trust relationships, and within an hour there’s usually a path from a low-privilege service role to full account takeover. Not because the team is careless — because IAM complexity grows faster than anyone’s mental model of it.

The pattern that keeps repeating

Three issues account for the overwhelming majority of the privilege-escalation paths found in real assessments:

• Wildcard actions on scoped resources. A policy that looks tightly scoped on the resource ARN but grants iam:* or s3:* on it is functionally unscoped the moment that resource can be reached from anywhere else.
• Role chaining nobody mapped. A CI/CD role can assume a deploy role, which can assume an infra role, which can modify IAM. Each hop looks reasonable in isolation.
• Stale permissions from deprecated services. Permissions granted for a service that was decommissioned eighteen months ago, still attached, still exploitable.

Why scanners miss this

Static policy scanners are good at flagging individual over-permissioned statements. They are much worse at reasoning about chains — the sequence of assumable roles and cross-account trust policies that turn “this role can only touch one bucket” into “this role can eventually touch everything.”

That’s the gap between an automated cloud posture score and an actual offensive assessment: a human (or an attacker) tracing the graph, not just the node.

What actually fixes it

1. Treat sts:AssumeRole chains as a graph, and review the graph — not the individual policies — on a recurring cadence.
2. Default every new role to deny-by-default, then add exactly the actions a CloudTrail audit shows it actually uses.
3. Kill roles tied to decommissioned services in the same sprint the service is removed, not “eventually.”

None of this requires new tooling. It requires treating IAM as an architecture decision instead of a checkbox during provisioning.