Score privilege-escalation exposure from PassRole wildcards, policy-write holders and role-chaining depth.
Escalation is rarely one permission; it is a permission plus something to point it at. iam:PassRole on a wildcard lets a principal hand any role to a service it can start, policy-write permissions let it rewrite its own boundary, and each extra AssumeRole hop multiplies what a single stolen credential can reach. An identity with no admin permissions and one escalation path is functionally an administrator, so counting escalation paths tells you the real number of privileged accounts rather than the one on the org chart.
Privilege Escalation Risk
risk = 1.2 × exposure rate + 8 per wildcard PassRole holder + 6 per policy-write holder + 7 per extra chain hop, minus 15 when MFA gates privileged actions.
Reach of a single compromised identity
blast radius = escalation paths × 2^(chain depth − 1).
risk = 1.2 × exposure rate + 8 per wildcard PassRole holder + 6 per policy-write holder + 7 per extra chain hop, minus 15 when MFA gates privileged actions. Escalation is rarely one permission; it is a permission plus something to point it at. iam:PassRole on a wildcard lets a principal hand any role to a service it can start, policy-write permissions let it rewrite its own boundary, and each extra AssumeRole hop multiplies what a single stolen credential can reach.
An identity with no admin permissions and one escalation path is functionally an administrator, so counting escalation paths tells you the real number of privileged accounts rather than the one on the org chart.
This calculator takes 6 inputs: Identities in the account or tenant, Identities holding a known escalation permission, Principals with PassRole on a wildcard resource, Principals that can write IAM policy, Deepest role-assumption chain, MFA enforced on every privileged action. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
In AWS the recurring set is iam:PassRole combined with a compute service such as lambda:CreateFunction or ec2:RunInstances, iam:CreatePolicyVersion or AttachUserPolicy on yourself, iam:UpdateAssumeRolePolicy on a privileged role, and sts:AssumeRole into a role whose trust policy is too broad.
Constrain PassRole to specific role ARNs, add iam:PassedToService conditions, put every human and workload principal under a permissions boundary, keep assumption chains one hop deep, and require MFA or session tags in the trust policy of any role that can write IAM.