IAM Policy Permissions Analyzer

Policy name:

Use the IAM role, managed policy, inline policy, or pull request label under review.

Policy scope:

Choose the policy shape you are reviewing before pasting JSON.

Review lens:

Use least privilege for general approvals, or pick a role-specific lens for sharper service exposure cues.

IAM policy JSON:

Paste a policy, browse a JSON/TXT file, or drop it onto the textarea.

Review policy input

{{ error }}

Additional sensitive services:

Examples: bedrock, glue, backup, route53, acm. Leave blank to use only the selected review lens.

Wildcard pressure multiplier:

Use a higher value for strict production reviews, lower for exploratory sandbox policies.

Statement rows:

Show the highest-breadth statements first when reviewing very large policies.

rows

{{ header }}	Copy
No rows for the current policy input.
{{ cell.value }} {{ cell.value }}

No chartable permission rows for the current policy.

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

IAM policy permissions decide which AWS actions a principal can take, which resources those actions can touch, and which request conditions must be true before access is granted. A short policy can still grant a very large permission surface when it uses action wildcards, resource wildcards, broad principals, or exception-based elements such as NotAction and NotResource.

Permission review matters because AWS authorization is cumulative. Identity policies, resource policies, permissions boundaries, session policies, service control policies, and explicit denies can all affect the final decision. A single policy document rarely tells the whole story, but it can still reveal the statements that deserve review before a role, deployment pipeline, bucket policy, key policy, or trust relationship reaches production.

Least privilege means granting only the permissions needed to complete a task. In practice, review starts by looking for breadth: * actions, service-wide wildcards, broad resources, public principals, missing conditions, and actions that can change trust, pass roles, edit key policies, or delegate administration. These signals do not prove that access will succeed in every request context, but they show where a reviewer should slow down.

A policy breadth review is not a replacement for IAM Access Analyzer, policy simulation, CloudTrail-based unused-permission cleanup, or service-specific testing. It is an early screen for risky statement shape, so the reviewer can reduce obvious permission spread before deeper authorization checks begin.

Technical Details:

AWS starts from implicit deny and allows a request only when an applicable policy grants it and no applicable explicit deny overrides it. That makes Effect the first major permission signal. Deny statements can be useful guardrails, while broad Allow statements deserve closer review because they can expand what a principal or resource can do.

The main policy elements work together. Action names the service operations, Resource names the affected objects, Principal appears in resource-style policies to identify who is covered, and Condition tests request-context keys such as principal tags, source ARN, organization ID, transport security, MFA, or resource tags. A statement with broad action and resource scope but no condition has more permission breadth than a statement that names exact actions, exact resources, and meaningful request constraints.

Exception elements need special care. NotAction with Allow can grant every applicable action except the listed actions, and NotResource with Allow can grant access to everything except listed resources. Those patterns are sometimes intentional, but they are harder to review than explicit allow lists because future services, new actions, and resource applicability can change the effective surface.

IAM Review Signals:

IAM policy review signals and why they matter
Signal	Why it raises review pressure	Typical narrowing move
`Action: ""` or `:*`	Can cover every current and future AWS service action that is otherwise applicable.	Replace with exact service actions or a tightly reviewed managed policy.
`service:*`	Grants all actions in one service, including future actions added after approval.	Use the smallest action family needed by the workload.
Partial action wildcard	Patterns such as `iam:*Policy` can include write or administration actions that are easy to miss.	Expand the pattern into named actions for approval-critical roles.
`Resource: "*"` or ARN wildcards	Increases the blast radius when a permission is misused or a workload is compromised.	Scope to ARNs and add tags, source constraints, or account conditions where supported.
Wildcard principal	In resource and trust policies, a wildcard principal can expose access beyond the intended account, role, or service.	Use exact principals, organization conditions, source ARN conditions, or account-scoped constraints.
No `Condition`	The statement lacks request-context guardrails that could restrict when the permission applies.	Add supported context keys such as principal tags, resource tags, source account, source ARN, MFA, or secure transport.
Privilege pivot actions	Actions such as role passing, trust editing, key policy changes, and delegated administration can help create new access paths.	Require exact resources, restrictive conditions, and separate approval for each pivot action.

Conditions are constraints, not decoration. A condition only helps when the target service supports the key and the request context actually supplies a matching value. A missing context key normally fails the comparison, but some operators and qualifiers need careful reading. That is why condition presence is a positive review signal, while condition correctness still needs service documentation and testing.

Breadth Levels Used in the Results:

Permission breadth score levels
Level	Score range	How to read it
`low`	`0` to `24`	No broad allow signal dominates, but normal least-privilege review still applies.
`medium`	`25` to `49`	One or more breadth signals should be checked before routine approval.
`high`	`50` to `74`	Wildcard scope, sensitive services, or privilege pivots are strong enough to require tightening or explicit justification.
`critical`	`75` to `100`	Approval should pause until broad actions, broad resources, and missing guardrails are reduced or formally accepted.
`control`	Deny statement	A deny can provide guardrail evidence, but it does not grant access by itself.

Everyday Use & Decision Guide:

Start with the policy shape. Use Identity policy for user, group, role, managed-policy, and inline-policy reviews. Use Resource policy for bucket, queue, topic, key, function, and similar resource-attached documents. Use Permissions boundary when the document sets a maximum permission ceiling, and use Trust policy when the main question is who can assume a role.

The Review lens changes which services receive extra attention. Least-privilege review is the general default. CI/CD deploy role raises the pressure around deployment and infrastructure services. Read-only baseline is useful when a policy claims to be observational. Resource policy exposure is the better fit when public, cross-account, or service-principal access is the main concern.

Paste the JSON, browse a JSON or TXT file, or drop the file onto the policy box. Use Format JSON when you want the document easier to read before reviewing the rows.
Add Additional sensitive services when your organization treats services such as Bedrock, Glue, Backup, Route 53, or ACM as high-scrutiny areas.
Keep Wildcard pressure multiplier at 1.0 for a normal pass. Raise it for strict production reviews, or lower it for exploratory sandbox policies where broad access is expected temporarily.
Use Statement rows to keep very large policies readable. The visible table can be limited to 10 through 300 rows, while the JSON export still carries the parsed analysis.
Open Privilege Review Queue before approving a change. It groups the statements that triggered wildcard, pivot-action, sensitive-service, missing-condition, principal, or shape findings.

The result does not simulate the final AWS authorization decision. A high score means the statement has broad shape inside the pasted document, not that every request will be allowed after boundaries, session policies, service control policies, resource policies, and explicit denies are considered. A low score means the broad signals were not detected; it does not prove that the policy is correct for the workload.

The analysis runs in the browser. Treat pasted policy text, copied rows, downloaded CSV or DOCX files, chart images, and JSON exports as security review material, especially when the document includes account IDs, role names, bucket names, or infrastructure conventions.

Step-by-Step Guide:

Enter a policy name that matches the role, managed policy, inline policy, resource, or change ticket under review.
Choose the policy scope before reading the findings. Principal checks differ between identity-style and resource-style policies.
Pick the review lens that matches the approval context, then add any organization-specific sensitive service prefixes if needed.
Paste, browse, or drop the IAM policy JSON. If parsing fails, fix the JSON shape before trusting any result.
Read the summary strip for high-risk statement count, wildcard signal count, selected scope, selected lens, and top breadth score.
Use Statement Breadth Ledger to inspect the highest-scoring statements first, then use Privilege Review Queue for grouped remediation notes.
Use Service Exposure Ledger, Permission Breadth Map, and Service Exposure Mix to see which services and statements concentrate the broadest access.
Export CSV, DOCX, chart images, or JSON only after you have removed sensitive policy text that should not leave the review workspace.

Interpreting Results:

The summary strip gives the quickest signal. critical and high-risk counts show how many allow statements crossed the stronger review thresholds. wildcard signal(s) counts action wildcards, resource wildcards, NotAction allows, and NotResource allows. The top breadth score points to the statement that should be reviewed first.

How to read IAM policy analyzer result areas
Result area	What it answers	Review action
`Statement Breadth Ledger`	Which statements have the broadest action, resource, principal, condition, and score signals.	Start at the highest score and narrow the statement before moving down the list.
`Privilege Review Queue`	Which finding categories were triggered, which statements caused them, and what change is recommended.	Use it as an approval checklist for wildcard permissions, pivot actions, and shape issues.
`Service Exposure Ledger`	Which service prefixes concentrate allow statements, wildcard actions, resource wildcards, open conditions, and pressure.	Split sensitive services into narrower statements and confirm each service belongs in the role.
`Permission Breadth Map`	How the top statements compare on the 0 to 100 breadth scale.	Use the 50 and 75 markers as pause points for high and critical review.
`Service Exposure Mix`	How allow counts, wildcard actions, resource wildcards, and unconditioned allows stack by service.	Look for one service carrying many broad signals, then reduce that service first.
`JSON`	The full parsed result, selected parameters, statement details, findings, and service exposure data.	Use it for review records, but do not confuse it with an AWS simulator result.

Treat Policy shape issues as a stop signal. Missing Effect, missing Action or NotAction, a missing principal in a resource-style policy, or a principal inside an identity-style policy can make the review misleading until the JSON matches the intended policy type.

Worked Examples:

Deployment role with broad IAM access

A statement named RoleAdministration that allows iam:* and sts:AssumeRole on * should land near the top of the breadth review. The action scope is service-wide for IAM, the resource scope is global, and the role-assumption action can become a privilege pivot if the trust and resource constraints are not tight.

The practical fix is to split role administration from normal deployment work. Keep only the exact IAM actions needed, scope them to named role ARNs where possible, and add conditions or separate approval for pass-role and trust-policy changes.

S3 deployment artifact access with conditions

A statement that allows s3:GetObject, s3:PutObject, and s3:ListBucket on one deployment bucket is easier to reason about than s3:* on every bucket. A condition such as a principal tag can further reduce when the permission applies, although the reviewer still needs to confirm that the tag source is controlled and that object and bucket ARNs are both present where needed.

Trust policy with wildcard principal

For a trust policy, Principal: "*" is a much stronger warning than the same field being absent from an identity policy. The selected scope changes the interpretation because trust and resource policies are supposed to name who can use the permission path. Replace the wildcard with exact AWS accounts, role ARNs, service principals, organization conditions, source-account checks, or source-ARN checks that match the intended caller.

FAQ:

Does this replace AWS IAM Access Analyzer?

No. It is a local breadth review for the pasted policy document. Use AWS IAM Access Analyzer, policy validation, policy simulation, CloudTrail access data, and service-specific testing when you need an AWS-backed answer.

Why does a Deny statement show as control?

An explicit deny can limit access and override allows, so it is treated as guardrail evidence rather than broad granted permission. You still need to confirm that the deny applies to the intended actions, resources, principals, and request context.

Why can a low score still be unsafe?

The score focuses on broad statement shape. A policy can have exact-looking actions and resources but still be wrong for the workload, missing a required condition, attached to the wrong principal, or combined with other policies that change the final result.

What should I do with a critical finding?

Pause approval, identify the statement that caused the finding, replace broad actions or resources with explicit scope, add supported conditions, and document any remaining exception. Critical should mean deliberate acceptance, not routine merge.

Can it review permissions boundaries?

Yes, choose Permissions boundary for that scope. Remember that a boundary limits the maximum permissions an identity-based policy can grant. It does not grant permissions by itself.

Does the policy leave the browser?

The parsing, scoring, tables, charts, and exports are built in the browser for this tool. The generated export files and copied rows are still under your control, so handle them as review artifacts that may reveal account and infrastructure details.

Glossary:

Action: The AWS service operation or operations that a statement allows or denies, such as s3:GetObject or iam:PassRole.
Resource: The ARN or set of ARNs that the statement covers. * means all applicable resources for that action.
Principal: The account, role, user, federated identity, or service covered by a resource-style policy or trust policy.
Condition: A request-context test that must match before the statement applies.
Privilege pivot: An action that can help create, delegate, pass, or alter access beyond the immediate operation being reviewed.
Permissions boundary: A managed policy that sets the maximum permissions an identity-based policy can grant to an IAM user or role.

References:

IAM JSON policy element reference, AWS Identity and Access Management.
How AWS enforcement code logic evaluates requests to allow or deny access, AWS Identity and Access Management.
IAM JSON policy elements: NotAction, AWS Identity and Access Management.
IAM JSON policy elements: Condition, AWS Identity and Access Management.
Security best practices in IAM, AWS Identity and Access Management.