IAM Policy Analyzer
Paste an AWS IAM policy and get severity-ranked findings — wildcard actions and resources, NotAction / NotResource foot-guns, admin-equivalent grants, missing conditions, and the known privilege-escalation actions and combinations (iam:PassRole + compute-create, iam:CreatePolicyVersion, and more). Each finding comes with a plain-English risk and a least-privilege fix. Everything runs in your browser; nothing is uploaded.
Runs entirely in your browser — nothing is uploaded. Your IAM policy is parsed and analyzed locally with JavaScript; it never leaves this page, so it is safe to paste a production policy without sending it to any server.
What this tool is
- Paste an AWS IAM policy (a full document, a single statement, or an array of statements) and get severity-ranked findings in your browser — no signup.
- Flags over-permission patterns: wildcard actions ("*" and "service:*"), wildcard resources ("Resource":"*"), admin-equivalent grants ("Action":"*" on "Resource":"*"), and Allow + NotAction / NotResource foot-guns.
- Detects the well-known IAM privilege-escalation actions and combinations — iam:PassRole paired with a compute-create (lambda:CreateFunction, ec2:RunInstances, …), iam:CreatePolicyVersion, iam:AttachUserPolicy / PutUserPolicy, iam:CreateAccessKey, iam:UpdateAssumeRolePolicy and more.
- Every finding comes with a plain-English explanation of the risk and a concrete least-privilege fix you can apply.
- Runs 100% client-side — your policy is parsed and analyzed with JavaScript in the browser and is never uploaded, so you can safely paste a production policy.
What an IAM policy is
An IAM policy is a JSON document that says what a principal — a user, group, or role — may or may not do in AWS. It is a list of statements, each with an Effect (Allow or Deny), an Action (API operations such as s3:GetObject), a Resource (the ARNs it applies to), and optional Condition clauses. AWS evaluates every applicable policy together: an explicit Deny always wins, and anything not explicitly allowed is implicitly denied.
Least privilege
Least privilege means granting an identity only the permissions it actually needs, on only the resources it actually touches, and no more. It is the single most effective way to shrink the blast radius of a leaked or compromised credential: if an access key only lets you read one bucket, that is the worst a thief can do with it. The opposite — broad "*" grants "to get things working" — is how a single exposed key becomes a full account takeover. This analyzer exists to catch the gap between what a policy grants and what least privilege would allow.
Common over-permission patterns
- Wildcard actions.
"Action":"*"grants every operation in every service;"s3:*"or"iam:*"grants every operation in one service, including destructive and privilege-granting ones. - Wildcard resources.
"Resource":"*"lets the actions hit every resource in the account rather than the ones the workload owns. - Admin-equivalence.
"Action":"*"on"Resource":"*"is the same as attaching AdministratorAccess. - Allow + NotAction / NotResource. An Allow with
NotActiongrants everything except the listed actions — an inside-out allow-list that silently widens as AWS adds services. - No Condition on sensitive grants. Sensitive actions (PassRole, AssumeRole, secrets, KMS) allowed with no guardrail such as MFA, source IP, or
iam:PassedToService.
The known privilege-escalation actions
Some permissions are dangerous not because they are labelled "admin", but because they let a principal grant itself more access. The canonical catalogue is Rhino Security Labs' research "AWS IAM Privilege Escalation – Methods and Mitigation". This tool checks for that real, named set:
- Policy manipulation.
iam:CreatePolicyVersion,iam:SetDefaultPolicyVersion,iam:AttachUserPolicy/AttachGroupPolicy/AttachRolePolicy,iam:PutUserPolicy/PutGroupPolicy/PutRolePolicy. - Credential & identity takeover.
iam:CreateAccessKey,iam:CreateLoginProfile,iam:UpdateLoginProfile,iam:AddUserToGroup,iam:UpdateAssumeRolePolicy. - PassRole + compute-create.
iam:PassRolepaired withlambda:CreateFunction,ec2:RunInstances,glue:CreateDevEndpoint,cloudformation:CreateStack,datapipeline:CreatePipelineorsagemaker:CreateTrainingJob— pass a privileged role to a resource you control, then run code as it. - Code overwrite on a privileged role.
lambda:UpdateFunctionCodeandglue:UpdateDevEndpointrun your code as an existing resource's role.
Scope note: this is a heuristic linter on the policy JSON only. It does not evaluate resource-based policies, permission boundaries, Service Control Policies, or session context, so it can neither prove a privilege-escalation path is exploitable nor prove a policy is safe. Treat it as a fast first pass, then confirm with IAM Access Analyzer and your account's last-accessed data before shipping changes.
Frequently asked questions
What is an AWS IAM policy?
An IAM (Identity and Access Management) policy is a JSON document that defines what a principal — a user, group, or role — is allowed or denied to do in AWS. Each policy has one or more statements, and each statement has an Effect (Allow or Deny), an Action (the API operations, like s3:GetObject), a Resource (the ARNs the actions apply to), and optional Condition clauses that narrow when the statement takes effect. AWS evaluates all applicable policies together: an explicit Deny always wins, and anything not explicitly allowed is implicitly denied. Writing policies that grant only what a workload actually needs — least privilege — is one of the highest-leverage things you can do to limit the blast radius of a compromised credential.
What does this analyzer check for?
It parses the policy text and reports over-permission patterns and known escalation paths: wildcard actions ("Action":"*" and service-wide wildcards like "s3:*" or "iam:*"), wildcard resources ("Resource":"*"), administrator-equivalent statements ("Action":"*" on "Resource":"*"), Allow statements that use NotAction or NotResource (which grant everything except what is listed), sensitive grants with no Condition guardrail, and the documented IAM privilege-escalation actions and combinations. Each finding is ranked critical / high / medium / low and paired with a least-privilege remediation. It is a heuristic linter on the policy JSON only — it does not evaluate resource policies, permission boundaries, SCPs, or session context, so it cannot prove a path is or is not exploitable.
What is an IAM privilege-escalation path?
A privilege-escalation path is a set of permissions that, although not labelled "admin", let a principal grant itself more access and ultimately reach higher privilege. The canonical catalogue comes from Rhino Security Labs' research "AWS IAM Privilege Escalation – Methods and Mitigation". Examples include iam:CreatePolicyVersion (rewrite a policy you are attached to), iam:AttachUserPolicy / PutUserPolicy (attach or inline AdministratorAccess onto yourself), iam:CreateAccessKey or iam:UpdateLoginProfile (take over another user), iam:UpdateAssumeRolePolicy (make a privileged role assumable by you), and — most commonly — iam:PassRole combined with a compute-create action such as lambda:CreateFunction or ec2:RunInstances, which lets you attach a privileged role to a resource you control and run code as that role. This tool detects those real, named actions and the PassRole combinations.
Is my policy uploaded or stored anywhere?
No. The analysis runs entirely in your browser using client-side JavaScript. Your policy JSON is parsed and evaluated locally and is never sent to PlayCISO or any third party — there are no network calls in the analysis. That makes it safe to paste a real production policy. The only data the page records is an anonymous usage count in your browser (used for the free-run meter), which contains none of your policy content.
What is the difference between NotAction and a Deny?
They are easy to confuse and behave very differently. A Deny statement explicitly refuses the listed actions and always overrides any Allow. NotAction, by contrast, is a matching element used inside an Allow or Deny: an Allow with NotAction grants every action EXCEPT the ones listed — effectively an allow-list turned inside out. That is dangerous in an Allow statement because every new AWS service and action is automatically permitted, so the grant silently widens over time. The safe pattern is to write Allow statements with an explicit Action allow-list, and reserve NotAction for Deny statements (e.g. "deny everything except these read-only actions"). This analyzer flags any Allow + NotAction (and Allow + NotResource) for exactly that reason.