AWS IAM Policy Explainer

What this tool does

Paste any AWS IAM policy — identity policy, resource policy, or trust policy — and this tool will walk through each statement in plain English and flag the patterns that commonly grant more access than the author intended. It runs entirely in your browser: nothing is sent to our servers, nothing is logged. Open your dev tools Network tab while you click Explain to verify.

When should I use this tool?

• Reviewing a teammate's PR. Someone added a new IAM policy and you want a second pair of eyes on the wildcards.
• Auditing an existing role. You pulled the policy with aws iam get-role-policy and want a quick sanity check before you log into CloudTrail to investigate.
• Understanding a vendor's required policy. A SaaS gave you a JSON blob to paste into a cross-account role. Read it carefully before you do.
• Debugging an AccessDenied. The plain-English summary often makes it obvious that a specific action or resource isn't covered.
• Teaching IAM. Easier to show the decoded shape than to describe it.

IAM gotchas this tool flags for you

Action: * on Resource: *

This is administrator access. We flag it as critical because the only legitimate place for this combination is the AdministratorAccess managed policy itself — anywhere else, it's almost always a mistake.

iam:PassRole with Resource: *

iam:PassRole lets a principal hand a role to an AWS service like Lambda or EC2. If Resource: * is allowed and no iam:PassedToService condition is present, the principal can typically escalate to whatever roles exist in the account. This is one of the most common privilege-escalation primitives in real-world IAM, so we call it out specifically.

Allow + NotAction

Effect: Allow combined with NotAction means "allow every action except the listed ones" — including AWS APIs that don't exist yet. The right place for NotAction is a Service Control Policy with Deny, not an identity policy with Allow.

Cross-account trust without sts:ExternalId

A trust policy that allows sts:AssumeRole from another account's principal should require sts:ExternalId, aws:PrincipalOrgID, or aws:SourceArn. Without one, you're vulnerable to the "confused deputy" pattern: a third party who knows your role ARN can have their service assume it on your behalf.

Principal: "*" on a resource policy

A principal of * means anyone, including outside your AWS account. On an S3 bucket policy, a KMS key policy, or a Lambda resource policy, this is almost never what you want without an accompanying Condition on aws:SourceArn, aws:PrincipalAccount, or aws:PrincipalOrgID.

Old policy Version

Policies with "Version": "2008-10-17" (or no version field) don't support policy variables like ${aws:username}. Always use "Version": "2012-10-17".

What this tool does not do

This is a static analyzer, not a simulator. It won't tell you whether a specific principal can perform a specific action against a specific resource — for that, use the IAM Policy Simulator or IAM Access Analyzer's ValidatePolicy API, which we also use during engagements. The point of this tool is to surface the patterns experienced IAM reviewers look for first, fast, with no AWS account or signup.

Frequently asked questions

Is it safe to paste a production policy here?

Yes. The policy is analyzed entirely client-side in JavaScript. No request is made to our server when you click Explain, and nothing is stored in cookies or localStorage. Your browser's Network tab will show zero requests during analysis.

Does this work for SCPs, permissions boundaries, and session policies?

Yes — the document shape is the same. The semantic rules differ (SCPs only restrict; they don't grant), so a NotAction with Deny in an SCP context is reasonable, not a warning. We flag it as info rather than treat it as a risk.

Does it understand condition keys?

It reads them and surfaces them in the statement detail, and several findings look for specific keys (iam:PassedToService, sts:ExternalId, aws:PrincipalOrgID, aws:SourceArn) to suppress false positives. It doesn't currently validate that a condition key is supported for a given action — for that, use IAM Access Analyzer's ValidatePolicy.

Will you add support for resource ARN parsing?

Yes, an ARN parser is on the short list. If you'd find it useful, mention it in the contact form — it helps us prioritize.

Can you review the real policies in my AWS account?

That's the consulting side of Warren IT. We run scoped IAM reviews using Access Analyzer, CloudTrail, and an attacker-graph approach. If that's interesting, the contact form goes straight to me.