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
{{ cell.value }} {{ cell.value }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A short IAM policy can grant a large access surface when one Allow statement combines broad actions, broad resources, weak principal scope, and no request conditions. The risky part is not only the number of lines in the JSON. It is the shape of each statement and the AWS services that the statement can touch.

IAM policies are made from statements. Each statement says whether it allows or denies access, which actions are in scope, which resources are covered, and, in resource-style policies, which principals are included. A Condition can narrow when the statement applies, but only if the service supports the condition key and the live request supplies matching context.

Common IAM policy review signals and why they matter
Review signal	Why reviewers care
`Action: ""` or `service:`	Future service actions can become allowed without another policy edit.
`Resource: "*"` or wildcard ARNs	The same action may reach more buckets, keys, roles, queues, or other targets than intended.
`NotAction` or `NotResource` with `Allow`	The statement allows everything applicable except the named exclusions, which is easy to misread.
Wildcard principals in trust or resource policies	Cross-account and public-style access can slip in unless exact principals and source constraints are used.
No useful condition guardrails	There may be no request-context check for tags, source identity, source account, source ARN, MFA, or organization membership.

IAM statement fields flowing into wildcard, sensitive-service, and privilege-pivot review signals.

A least-privilege review looks for the smallest permissions that still let the workload run. That does not always mean every wildcard is wrong. Some AWS actions require Resource: "*", and some resource patterns are normal for object prefixes or log groups. The important question is whether the broad part is deliberate, documented, and guarded by the right service-specific condition keys.

Static policy review is only the first pass. Effective access depends on identity policies, resource policies, permissions boundaries, session policies, organization guardrails, explicit denies, and the request context. Use broad-shape findings to fix obvious spread, then validate the final behavior with AWS policy checks, simulation, and live tests in the target account.

How to Use This Tool:

Run one policy document at a time so the policy label, warning rows, service exposure totals, charts, and exports all describe the same approval item.

Enter a Policy name that matches the role, managed policy, inline policy, resource policy, trust policy, or change ticket under review. The name appears in the summary line and exported artifacts.
Choose the Policy scope before reading any findings. Pick Identity policy or Permissions boundary for policies attached to identities, and pick Resource policy or Trust policy when the document should name a principal.
A missing Principal matters for resource-style scopes, while a Principal inside an identity-style policy is treated as an unusual shape signal.
Select the Review lens that matches the approval context. Use Least-privilege review for general checks, CI/CD deploy role for deployment automation, Read-only baseline for audit-style roles, and Resource policy exposure for public or cross-account access reviews.
Paste IAM policy JSON, browse a JSON or TXT file, or drop the file onto the textarea. If the warning area says the policy failed to parse, fix missing commas, comments, trailing commas, or shell wrappers before using the result tables.
Browser file loading rejects policy files larger than 2 MiB. The Format JSON button only becomes available after the pasted policy parses successfully.
Open Advanced only when the normal review needs tuning. Add organization-specific prefixes in Additional sensitive services, leave Wildcard pressure multiplier at 1.0 unless the gate is intentionally stricter or looser, and set Statement rows when a large policy would crowd the visible ledger.
Review the summary and Privilege Review Queue first. A review before approval badge, a critical or high row, or a policy-shape warning means the policy needs correction or separate justification before attachment.
Use Statement Breadth Ledger, Service Exposure Ledger, Permission Breadth Map, and Service Exposure Mix to trace the exact statement or service prefix behind each warning, then copy or download CSV, DOCX, chart images, or JSON only after the warning rows match the review you intend to hand off.
The JSON export excludes the raw pasted policy text and keeps normalized inputs, summary counts, table artifacts, chart rows, warnings, and recommendations for audit notes.

Interpreting Results:

The summary counts statements, service areas, wildcard signals, and high-risk or critical allow statements. A critical result means the policy shape deserves review before approval. It does not prove that a live request will succeed, because other AWS policy types or an explicit deny can still block access.

Statement Breadth Ledger is the statement audit trail. Use Score, Level, and Review note together, then check the action, resource, principal, and condition columns to see which signal raised the score.

Privilege Review Queue groups the strongest findings. A pass row means no broad wildcard, NotAction, sensitive-service, wildcard-principal, or shape signal crossed the queue rules; it does not remove the need to test production data access, key administration, role assumption, or cross-account trust.

Service Exposure Ledger shows concentration by service prefix. High pressure for IAM, STS, KMS, S3, Organizations, Secrets Manager, or an added sensitive service should lead to a service-specific check of resource ARN support and condition key support.

Use the two chart tabs for review triage, not as evidence by themselves. Confirm the exact statement row before editing a policy, and run AWS policy validation or simulation when the result will affect a production account.

Technical Details:

AWS authorization starts from implicit deny. A request is allowed only when an applicable policy grants it and no applicable explicit deny overrides it. Identity-based and resource-based policies can add permissions together, while permissions boundaries and organization policies can reduce the final set. That is why a single policy document can show risky breadth without proving final access.

The scoring model focuses on statement shape. Action and NotAction describe operation coverage. Resource and NotResource describe target coverage. Principal and NotPrincipal matter for resource-style and trust policies. Condition records request-context checks, but condition presence lowers pressure only modestly because service support and live request values still matter.

Rule Core:

IAM policy statement parsing rules used by the analyzer
Policy element	How it affects the review	Important boundary
`Effect`	`Deny` statements are kept as control evidence; other or missing effects are treated as allow-shaped for scoring.	Missing `Effect` is also reported as a policy shape issue.
`Action`	Global, service-wide, and partial wildcards raise the statement score.	Wildcard scoring is multiplied by the selected wildcard pressure multiplier.
`NotAction`	`Allow` plus `NotAction` raises pressure because unlisted applicable actions may be allowed.	`Deny` plus `NotAction` is not scored as added allow breadth.
`Resource`	`*` or wildcard ARNs raise the score.	Some AWS actions require all resources, so the row is a review signal rather than an automatic defect.
`NotResource`	`Allow` plus `NotResource` is queued for review because all other applicable resources may be allowed.	The action set determines which resources are applicable.
`Principal`	Wildcard principals raise pressure for resource and trust policy reviews.	A principal in an identity policy is flagged as unusual for that scope.
`Condition`	Condition entries reduce score slightly when another signal has already raised pressure.	A condition key that is unsupported or absent from the request may not protect the access path.

Formula Core:

Each allow statement receives a bounded breadth score from the sum of matching signal weights. The final score is rounded and clamped from 0 to 100.

\begin{matrix} rawScore & = & \sum_{i = 1}^{n} w_{i} \\ score & = & \min (100, \max (0, round (rawScore))) \end{matrix}

Here, w is a triggered signal weight such as global action wildcard, resource wildcard, sensitive service, privilege pivot action, missing condition, wildcard principal, or policy shape issue. The wildcard pressure multiplier is clamped from 0.5 to 2.0 and applies only to action-wildcard weights.

IAM permission breadth signal weights
Signal	Score effect	Review meaning
`Action: ""` or `:*`	`+46 x multiplier`	All current and future service actions may be in range.
`service:*`	`+32 x multiplier`	Every action in one service may be allowed.
Partial action wildcard	`+18 x multiplier`	Patterns such as `iam:*Policy` can include write or administrative actions.
Wildcard resource	`+20`	The action may affect a broader target set.
`Allow` with `NotAction`	`+30`	Unlisted applicable actions may still be allowed.
`Allow` with `NotResource`	`+18`	Unlisted applicable resources may still be allowed.
Sensitive service hit	`+10` to `+28`	The selected lens treats the service prefix as approval-sensitive.
Privilege pivot action	`+18` to `+34`	Actions such as role passing, policy editing, key policy editing, access-key creation, trust assumption, and delegated administration can create new access paths.
No condition	`+7`	No request-context guardrail is present in the statement.
Wildcard principal in resource or trust scope	`+22`	A public or broad principal may be able to use the resource-style statement.
Policy shape issue	`+8`	The statement is missing an expected element for the selected policy scope.
Condition present	`-6` when score is above `8`	A guardrail exists, but it does not erase broad action or resource scope.

Statement levels use inclusive lower bounds: low is 0 to 24, medium is 25 to 49, high is 50 to 74, and critical is 75 to 100. Deny statements are labeled control because they do not add allow breadth.

Service pressure is a separate service-level view. It starts from the highest statement score for that service and adds extra pressure for wildcard actions, wildcard resources, and unconditioned allow statements.

servicePressure = clamp (maxStatementScore + 6 wildcardActions + 5 resourceWildcards + 3 unconditionedAllows, 0, 100)

Policy scope checks and consequences
Selected scope	Shape check	Consequence
Identity policy	`Principal` is unusual.	The identity that carries the policy supplies the principal, so the pasted policy may be the wrong type.
Permissions boundary	`Principal` is unusual, but allow breadth is still scored.	The boundary limits maximum permissions only when intersected with identity policies.
Resource policy	`Principal` or `NotPrincipal` is expected.	A missing principal makes the policy shape suspect before the score is trusted.
Trust policy	Wildcard principals receive extra pressure.	Role assumption should usually name exact accounts, roles, services, organization IDs, source ARNs, or source accounts.

Privacy and Accuracy Notes:

The policy scan runs in the browser and does not call an AWS account or a server-side evaluator. File loading uses the local browser file reader, and large files are rejected before analysis.

Do not paste secrets, access keys, production-only comments, or policy material you would not put into a browser session.
Some entered values may appear in generated or shared URLs. Avoid sharing or reloading a URL after entering confidential policy JSON.
The result does not inspect CloudTrail activity, Access Analyzer findings, service control policies, resource policies elsewhere in the account, or whether a service supports a particular resource ARN and condition key pair.
Use the findings as review triage, then test effective permissions in AWS before deploying a sensitive policy change.

Advanced Tips:

Use the CI/CD deploy role lens when a policy can pass roles, update stacks, publish containers, change functions, or write secrets; those services receive sharper sensitive-service attention than the general least-privilege lens.
Add prefixes such as bedrock, backup, glue, route53, or acm in Additional sensitive services when your organization treats those services as approval-sensitive even if they are not in the selected lens.
Raise Wildcard pressure multiplier toward 2.0 for production approval gates that block broad actions by default. Lower it toward 0.5 only for sandbox drafts where the goal is triage rather than approval.
Check Service Exposure Ledger before editing a large policy. A high pressure service with several allow statements is often easier to fix by splitting statements by service and resource type.
Use the chart exports for meeting notes, but make policy changes from the statement and service tables. The charts show concentration and breadth; they do not replace exact action, resource, principal, and condition review.
Run AWS policy validation, simulation, and a low-risk live test after the static review. The analyzer does not know the account's service control policies, resource policies elsewhere in the account, last-accessed activity, or whether each condition key is supported for the selected action and resource.

Worked Examples:

These cases show how common policy shapes should change the review result and the next policy-editing step.

CI/CD role with broad IAM access

A deploy role that allows iam:* and sts:AssumeRole on Resource: "*" should produce a high or critical Level in Statement Breadth Ledger. Privilege Review Queue should call out service-wide wildcard, wildcard resources, sensitive-service exposure, and privilege-pivot actions. The practical fix is to name only the required IAM and STS actions, scope role ARNs, and add source or tag conditions that the workflow actually supplies.

Conditioned S3 artifact access

An artifact statement that allows s3:GetObject and s3:PutObject on one narrow object path with an aws:PrincipalTag/team condition should carry less pressure than a bucket-wide wildcard. If the object ARN still ends in /*, the Resource scope and Score fields explain why the row is not treated as fully narrow.

Trust policy with a wildcard principal

A trust policy reviewed with Principal: "*" should create a wildcard-principal finding in Privilege Review Queue. The Statement Breadth Ledger row points to the principal and condition columns. Replace the wildcard with exact AWS accounts, roles, services, organization constraints, source accounts, or source ARNs, then test assumption with the intended caller.

Malformed JSON or mismatched scope

If the warning area reports a parse failure, repair missing commas, trailing commas, comments, or shell quoting before reviewing results. If a resource policy is missing Principal or an identity policy contains Principal, check the selected Policy scope before treating the score as final review evidence.

FAQ:

Does a critical level mean access is definitely exploitable?

No. A critical level means the pasted allow statement has broad shape signals such as global wildcards, wildcard resources, privilege-pivot actions, or wildcard principals. Effective access still depends on the full AWS policy set and request context.

Why can a condition still leave a statement risky?

The Conditions column shows that a guardrail exists, but the condition key must be supported by the service and present in the request. Verify the condition against AWS service documentation before relying on it.

What should I do with an Allow plus NotAction finding?

Treat it as a broad allow pattern. NotAction with Allow can permit all applicable actions except the listed exclusions, so an explicit Action list is usually easier to review and approve.

Can I tune the sensitive-service list?

Yes. Pick the closest Review lens, then add comma-separated prefixes in Additional sensitive services. Those prefixes are merged into the sensitive-service checks for the current analysis.

Why did the JSON fail to analyze?

The analyzer expects a JSON object with one Statement object or an array of statements. Remove comments, trailing commas, broken quoting, and pasted shell wrappers, then use Format JSON once the source parses.

Is it safe to paste confidential policies?

Use a sanitized policy when possible. Analysis runs in the browser, but entered values can appear in shared URLs, and copied or downloaded artifacts can include policy names, actions, resources, principals, warnings, and findings.

Glossary:

Allow: A statement effect that can grant access when no applicable explicit deny or boundary blocks the request.
Explicit deny: A deny statement that overrides an allow during AWS policy evaluation.
Principal: The AWS account, role, user, service, or federated identity covered by a resource-style or trust policy.
Permissions boundary: A policy that limits the maximum permissions an identity can receive from identity-based policies.
Request context: The action, resource, principal, condition keys, and environmental details AWS evaluates for a request.
Service prefix: The part before the colon in an IAM action, such as s3, iam, or kms.
Wildcard: The * pattern that can match many actions, resources, or principals depending on where it appears.

References:

IAM JSON policy element reference, AWS Identity and Access Management User Guide.
Policy evaluation logic, AWS Identity and Access Management User Guide.
IAM JSON policy elements: NotAction, AWS Identity and Access Management User Guide.
IAM JSON policy elements: NotResource, AWS Identity and Access Management User Guide.
IAM JSON policy elements: Condition, AWS Identity and Access Management User Guide.
Actions, resources, and condition keys for AWS services, AWS Service Authorization Reference.
Validate policies with IAM Access Analyzer, AWS Identity and Access Management User Guide.
IAM policy testing with the IAM policy simulator, AWS Identity and Access Management User Guide.
How to create a programmatic access user in AWS IAM, Simplified Guide.
How to assume an IAM role using AWS CLI, Simplified Guide.
How to check the current caller identity in AWS CLI, Simplified Guide.