Paste an IAM policy document and see which statements grant more than they should: full administrator access, service-wide wildcards, actions that let a principal raise its own privileges, and resource policies open to everyone.
SponsorThis spot is open to one DevOps or AI tooling company at a time. Ask about sponsoring
116 of 118 run entirely in your browser (Weather Widget uses Open-Meteo; What's My IP asks this site's server).
Share on XShare on LinkedInMost over-permissive policies are not written carelessly. They start as a narrow policy, hit an AccessDenied during a deploy, and get a wildcard added to make the error go away. Six months later nobody remembers which action was actually needed, and the wildcard stays. The statements worth finding are the ones where that wildcard quietly became administrator access: Action "*" on Resource "*", every action in IAM or KMS, or an Allow written with NotAction, which grants every action AWS ships in future as well.
The less obvious risk is privilege escalation. A policy that looks narrow can still include iam:PassRole, iam:AttachRolePolicy, iam:CreatePolicyVersion, or iam:CreateAccessKey, each of which lets the holder obtain permissions the policy never lists. This analyzer flags those actions, including when they hide behind a pattern such as iam:Put*. It reads the document only: it does not evaluate Condition blocks, permission boundaries, or service control policies, so treat a clean result as the absence of common mistakes and use IAM Access Analyzer for proof.
Paste an AWS IAM policy document. It is checked for administrator access, wildcards, privilege escalation paths, public principals, and sensitive actions that apply to every resource. The policy is read in your browser and never sent anywhere.
Sid ManageRolesiam:PassRole, iam:AttachRolePolicy can be used to gain permissions this policy does not grant, and the statement applies to every resource. Limit Resource to specific roles or users, and add a permissions boundary.
Sid Everythingec2:* on Resource "*" includes delete and permission-changing actions. List the specific actions the workload calls; IAM Access Analyzer can generate that list from CloudTrail activity.
Sid ReadSecretssecretsmanager:GetSecretValue applies to all resources in the account. Replace "*" with the ARNs this workload needs.
Checks identity and resource policies. Deny statements are skipped. It does not evaluate Condition logic, permission boundaries, or service control policies.