AWS IAM Policy Analyzer (Explain, Wildcards and Escalation Risks)

About the AWS IAM Policy Analyzer (Explain, Wildcards and Escalation Risks)

Paste an AWS IAM policy — an identity-based policy, a resource-based policy such as a bucket or key policy, a role trust policy or a service control policy — and read what it really allows:

• Every statement in plain English: “Allows s3:GetObject (Read) on arn:aws:s3:::example-assets/*, when the request uses HTTPS.” Wildcards such as s3:Get* or iam:*AccessKey* are expanded to the real actions with their access levels (List, Read, Write, Permissions management, Tagging), taken from AWS’s machine-readable Service Authorization Reference; NotAction is counted as everything it does not exclude.
• Findings in the four kinds IAM Access Analyzer uses — errors, security warnings, warnings and suggestions: full administrator access, NotAction, NotResource or NotPrincipal in an Allow, iam:PassRole on every role, the published privilege-escalation combinations, policies and trust policies open to "Principal": "*", trust in a shared OIDC provider (GitHub Actions, GitLab, HCP Terraform, Buildkite, Pulumi and the others IAM lists) without the claim that names your organization, service principals without aws:SourceArn, unknown actions and condition keys, wrong operators and values, actions that can never match the resources listed (s3:ListBucket on …/*), and policies over the size limit.
• A least-privilege rewrite for review: wildcards narrowed to the access levels you keep, and actions that support only "Resource": "*" moved to a statement of their own.
• A policy builder: choose a service, access levels or single actions, resources and conditions (MFA, HTTPS, source IP, organization, Region).

IAM Access Analyzer in your AWS account remains the authority: it checks a policy against your own account, resources and organization, which no page outside AWS can see. Everything here runs in your browser. Without a pass the analysis is a free preview: every count with the first statements and findings, and the first lines of the rewrite and of a built policy; the rest, the copies and the downloads unlock with a Pro pass.

Common uses

• Reviewing a policy in a pull request before it reaches an account.
• Finding out what a managed or vendor policy with many wildcards really allows.
• Checking a bucket, queue or key policy for public access, and a trust policy for who can assume the role.
• Writing a first least-privilege policy for a workload, then tightening it with IAM Access Analyzer’s policy generation.

How the access levels and actions are known

The page carries a snapshot of AWS’s machine-readable service reference: every service prefix, every action, the resource types each action supports with their ARN formats, and each service’s condition keys. AWS publishes four properties per action; the level shown follows them: Permissions management when an action changes permissions or credentials, Tagging when it only changes tags, Write when it changes resources, List when it lists them, and Read otherwise. An action that AWS added after the snapshot is reported as unknown — check its name in the Service Authorization Reference before you remove it.

What the checks follow

• Grammar: the IAM JSON policy element reference — Version, Statement, Sid, Effect, Action and NotAction, Resource and NotResource, Principal and NotPrincipal, Condition — and the SCP syntax, in which Allow statements take only "Resource": "*" and no Principal.
• Conditions: the condition operators and the global condition keys with their data types and whether they hold several values (ForAllValues with a missing key is true, so an Allow should add a Null check).
• Sizes: IAM quotas — 6,144 characters without white space for a managed policy, 2,048 for a role trust policy by default — and 10,240 for an SCP (AWS Organizations quotas).
• Finding kinds and names follow IAM Access Analyzer’s policy check reference; trust in shared OIDC providers follows IAM’s identity-provider controls: for GitHub Actions a condition on sub or job_workflow_ref, for GitLab, HCP Terraform, Buildkite and most others on sub, for Pulumi Cloud, Vercel and Amazon Cognito on aud, which IAM requires before it saves a new or changed trust policy; a wildcard where your organization’s name belongs is reported too.
• Privilege escalation: the permission combinations published by Rhino Security Labs, such as iam:CreatePolicyVersion alone, or iam:PassRole with ec2:RunInstances.

Reading a least-privilege rewrite

The rewrite changes only what the snapshot can prove: a wildcard is replaced by the actions of the levels you keep — written as verb wildcards such as s3:Get* where every action they match is kept, and by name otherwise — and an action that supports only "Resource": "*" leaves a statement that names ARNs, where it never matched. It never narrows a Deny (that would allow more), never rewrites NotAction or "Action": "*", and never invents ARNs: the notes say where your resource names belong. Check the result with IAM Access Analyzer before you use it.

Limitations

• The page knows the policy, not your account: it cannot tell whether a role or bucket exists, whether another policy grants or denies the same thing, or whether an account ID is yours. IAM Access Analyzer in your account remains the authority.
• Actions, resource types and condition keys come from a snapshot of the Service Authorization Reference; ones added since are reported as unknown.
• Privilege-escalation checks look at the permissions this one policy allows, not at what the principal’s other policies, permission boundaries or SCPs allow.
• Condition keys of individual services are checked by name only; their data types are not.

Privacy

On this device: nothing is sent

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.