AWS IAM Policy Risk Check — Find Over-Broad Permissions in Your Policy

How dangerous is this IAM policy, really?

Paste one IAM policy, role trust policy or bucket/queue/key policy as JSON. You get a score, and every admin wildcard, privilege-escalation action, Allow+NotAction grant and public principal, each with a fix to review.

The text is read in this browser tab. No credentials, no account lookup, no upload.

1. Paste the policy

Choose a .json file …or paste the JSON

Paste a policy or choose a file, then click Check policy. The output of aws iam get-policy-version and get-role works as is.

What it checks, and what it leaves out

Admin — Action "*" on Resource "*".
Escalation — actions that let a principal grant itself more (policy attach/put/version, access keys, login profiles, trust-policy edits, iam:PassRole, sts:AssumeRole), including wildcards that expand to them.
Wildcards — whole-service svc:*, Allow with NotAction or NotResource, write actions on Resource "*".
Secrets — secret, parameter, key and object reads on every resource.
Principals — Principal "*" with or without a Condition, and whole other accounts trusted with no Condition.
Reconciles. The severity counts add up to the findings listed, and the score is 100 minus 25 per critical, 10 per high, 4 per medium.
Not modelled: permission boundaries, SCPs, session policies, what the policy is attached to, whether Conditions are actually safe, and actions that do not support resource-level permissions. Use IAM Access Analyzer as well.

Common questions

Is a policy with Action * and Resource * really that dangerous?

Yes. It is full administrator access: the holder can read every secret, delete every resource, turn off CloudTrail and create new admin users. It is fine for a break-glass human role behind MFA and almost never right for an application, a CI job or a Lambda function.

What is a privilege-escalation path in IAM?

A permission that lets a principal give itself or another identity more access: iam:CreatePolicyVersion, iam:AttachRolePolicy, iam:PutUserPolicy, iam:CreateAccessKey, iam:UpdateAssumeRolePolicy, or iam:PassRole on a wildcard resource. A role that holds one of these on Resource * is effectively an administrator even if it looks narrow.

Why is Allow with NotAction risky?

NotAction with Allow grants every action except the ones listed, including services AWS launches later. It reads like a restriction but works as a very broad grant. Use NotAction in Deny statements instead.

What does Principal * mean in a bucket or trust policy?

It matches every AWS principal on the internet. Without a Condition such as aws:PrincipalOrgID, aws:SourceVpce or aws:SourceArn the resource is public, or the role can be assumed from any account.

Does this tool call AWS or need credentials?

No. You paste the policy JSON and it is checked in your browser. It never sees an account ID you did not paste, and nothing is uploaded.

Does a good score mean the policy is safe?

No. It applies a fixed set of rules to the text of one policy. It does not see permission boundaries, SCPs, session policies, resource policies on the other side, or which identities the policy is attached to. Use IAM Access Analyzer and the policy simulator as well.