IAM Policy analyzer
Paste an AWS IAM policy to find overly broad permissions, privilege escalation paths and confused-deputy risks, and simulate requests.
Runs in your browser · nothing is sentAWSNew
Everything runs in your browser. Nothing is sent anywhere, including account IDs, role names and resource ARNs in your policy.
How to use
- Export a policy with "aws iam get-policy-version --policy-arn ... --version-id ..." or copy it from the console.
- Paste the JSON into the tool.
- Review the findings and the statements table.
- Use "Simulate a request" to check one action and resource, then export the report if needed.
Common scenarios
Check whether a role has wildcard actions, a wildcard resource on sensitive actions, or privilege-escalation permissions before attaching it.
Paste a role's trust policy to confirm it uses sts:ExternalId or aws:SourceArn, not just a bare account ID, before trusting a third-party vendor.
About this tool
Paste one or more AWS IAM policy documents (a single policy, the output of "aws iam get-policy-version", or a map of every policy attached to one role or user) and the tool checks every statement for common risks: full administrator access, wildcard actions and resources, privilege-escalation actions, a wildcard Principal in a resource-based policy, and cross-account trust without a confused-deputy guard. It lists every statement in a table and lets you simulate whether the pasted policy would allow a specific action on a specific resource. Everything runs locally; the policy JSON never leaves your browser.
🔒 Your input stays in your browser and is never sent anywhere.
Frequently asked questions
Does this connect to my AWS account?
No. There are no credentials and no API calls. You export the policy yourself with the AWS CLI or console and paste the JSON here.
What does the simulation actually check?
It evaluates only the policy document(s) you pasted against the AWS evaluation logic (an explicit Deny always wins, otherwise at least one Allow is needed). It does not know about other policies, permission boundaries or service control policies (SCPs) attached elsewhere in the account, so a real request could still be denied even if this tool says "allowed".
What is a confused-deputy risk?
It happens when a role trusts another AWS account or an AWS service without checking sts:ExternalId, aws:SourceArn or aws:SourceAccount. A third party who learns the role exists could potentially trick a service into assuming it on their behalf.
Why is a wildcard action flagged even though the resource is restricted?
A wildcard like "s3:Get*" also grants any matching action AWS adds to that service in the future, which is harder to audit over time than an explicit list, even when the resource itself is scoped correctly.
What to do next
Found a problem or have a suggestion? Tell us