Cloud IAM Policy Analyzer

Review AWS IAM, Azure role or GCP IAM policy documents for wildcards, excessive permissions, privilege-escalation combinations and missing conditions.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Drop a policy document

AWS IAM policy JSON, an Azure role definition, or a GCP IAM policy (get-iam-policy output). Analysed in your browser - no cloud access needed or requested.

Or paste the JSON

Provider

Your organisation's domain (GCP, optional)

Wildcards, escalation paths and missing guard-rails

For AWS, every Allow statement is checked for Action: "*", service-wide wildcards, NotAction and NotResource allow lists, write actions on Resource: "*", and Principal: "*" in resource policies (with the conditions that genuinely limit it recognised). Actions are then matched, through their wildcards, against more than twenty known privilege-escalation paths from published research. Examples:

iam:PassRole plus ec2:RunInstances;
iam:CreatePolicyVersion;
lambda:UpdateFunctionCode;
ssm:SendCommand.

A policy that says iam:Put* is caught as surely as one that spells the action out.

For Azure custom roles, the analyzer checks:

* actions and provider-wide wildcards;
data-plane wildcards;
assignable scopes at the root or a management group;
actions that let a role grant itself more, such as role assignment writes, VM run-command and storage key listing.

For GCP policies, it flags:

allUsers and allAuthenticatedUsers;
the basic Owner and Editor roles;
default service accounts holding Editor;
escalation-capable roles such as Service Account User or Token Creator;
members outside your domain, if you name it.

What static analysis cannot see

A policy is only part of the answer. Permission boundaries, service control policies, resource policies, session policies, Azure deny assignments, GCP deny policies and organisation constraints can all narrow what is actually allowed. Findings here are what this document grants on its own. Use your provider's access analyzer on real accounts to confirm effective permissions.

Frequently asked questions

Do I need to give it credentials?

No, and it will never ask. Export the policy with your usual tooling (for example aws iam get-policy-version, az role definition list, gcloud projects get-iam-policy) and paste it here.

Is a privilege-escalation finding always exploitable?

Not always - a Resource or Condition may restrict it, and the target roles may not exist. It means the grants line up with a known path and should be justified or narrowed.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.