AWS IAM Policy Explainer

Paste an AWS IAM policy JSON and instantly see what it allows or denies in plain English — who can do what to which resources, any conditions attached, and which statements are dangerously broad. Dangerous patterns like Action: "*" with Resource: "*", NotAction, and wildcard resources on sensitive services are flagged in red.

How to use the AWS IAM Policy Explainer

Paste a complete AWS IAM policy document — the JSON object with a Version and Statement array — into the text area. Click Explain Policy or load the Example to see it in action.

Each statement is rendered as a plain-English sentence: "Effect [Principal] to [Actions] on [Resources] [when Conditions]". If the principal is omitted (identity-based policy), only the account the policy is attached to can exercise it. Conditions are noted but not deeply expanded.

Dangerous patterns are flagged in red:

  • Full admin grant: Effect: Allow with Action: "*" and Resource: "*" — equivalent to root access.
  • Wildcard action on sensitive service: iam:*, s3:*, ec2:* etc. on all resources.
  • NotAction / NotResource: These are inverted constraints. NotAction allows everything except the listed actions — easy to get wrong and very broad. Always worth auditing.
  • Broad Allow without conditions: Any Allow statement with a wildcard resource and no Condition block on sensitive services.

A summary line at the top shows the total count of Allow vs Deny statements and the number of red flags found.

About AWS IAM Policies

AWS Identity and Access Management (IAM) policies are JSON documents that define permissions. Every API call in AWS is authorized by evaluating the applicable policies against a set of rules: explicit Deny always wins, then explicit Allow, then implicit Deny (default). Policies attach to IAM users, groups, roles (identity-based) or directly to resources like S3 buckets (resource-based). Understanding what a policy actually grants is non-trivial because statements compose, conditions interact, and wildcards multiply scope.

The most dangerous patterns in IAM are well-known but still appear regularly in audits. Action: "*", Resource: "*" with Effect: "Allow" grants full administrator access — equivalent to AWS root. NotAction and NotResource are inverted constraints that allow everything except the listed items, which is almost always broader than intended. Wildcard actions on iam:* are especially dangerous because they allow creating new users and policies, effectively granting privilege escalation.

A policy with Condition blocks is not automatically safe — conditions can be bypassed if misconfigured (e.g. requiring MFA only on the console, not the API). This tool highlights structural patterns; for a full security audit of IAM permissions, use tools like AWS IAM Access Analyzer, Cloudsploit, or Prowler in conjunction with this human-readable view.

Common use cases

  • Security review — quickly understand what a customer-managed policy grants before approving a pull request or attaching it to a production role.
  • Onboarding — help new team members understand the IAM policies on their developer role without requiring AWS console navigation.
  • Audit preparation — produce plain-English descriptions of all IAM policies for a compliance review or penetration test briefing.
  • Debugging access errors — paste the policy to confirm it grants the action that is failing; cross-reference with the Access Denied error message.
  • Third-party policy review — evaluate the permissions an SaaS vendor or open-source tool requests in its CloudFormation stack before deploying.

Frequently asked questions

What is the difference between an identity-based and resource-based policy?
Identity-based policies attach to IAM users, groups or roles and define what the identity can do. Resource-based policies attach to resources (S3 buckets, SQS queues, Lambda functions) and define who can access the resource. Resource-based policies require a Principal element; identity-based policies do not.

Why is NotAction dangerous?
NotAction allows ALL actions except the listed ones. If you write NotAction: ["s3:DeleteObject"], you are allowing every other action on every service — including iam:CreateUser. It is easy to intend a narrow restriction and accidentally create a very broad allow. NotResource has the same inversion problem.

Does Effect Deny override an Allow in another policy?
Yes. An explicit Deny in any applicable policy always overrides an Allow anywhere else in the policy evaluation. This is a fundamental IAM rule: Deny always wins. This makes Deny statements a reliable way to enforce guardrails (SCPs, permission boundaries) regardless of what identity-based policies allow.

What are SCPs (Service Control Policies)?
SCPs are organizational-level policies applied to AWS accounts via AWS Organizations. They define the maximum permissions an account can have — even if an IAM policy in that account allows something, an SCP Deny blocks it. SCPs do not grant permissions themselves; they only restrict the ceiling.

How do I find which policy is causing an Access Denied error?
Check the CloudTrail event for the API call — the error message often names the policy type that denied it. Use IAM Policy Simulator to simulate calls against the policies on a role. AWS IAM Access Analyzer can also show which policy evaluations occur for a given identity.