{{ summaryTitle }}
{{ summaryValue }}
{{ summaryLine }}
{{ badge.label }} {{ badge.value }}
Paste JSON, browse one JSON/TXT file, or drop it onto the textarea.
{{ sourceMeta }}
{{ sourceStatus }}
The label stays in this browser tab and is not written to the share URL.
Choose the attachment or trust context represented by this one JSON document.
Use the general least-privilege lens unless the role has a narrower operating context.
{{ workflowFeedback }}
Optional comma- or line-separated prefixes, for example bedrock, glue, backup. Empty is neutral.
Use 0.5–2.0 for a documented review policy; 1.0 preserves the base model.
×
Show 10–300 highest-pressure statements; the default is 80.
rows
StatementEffectActionsResourcesPrincipalConditionsScoreLevelReview noteCopy
{{ row.statement }}{{ row.effect }}{{ row.actions }}{{ row.resources }}{{ row.principal }}{{ row.conditions }}{{ row.score }}{{ row.level }}{{ row.note }}
PriorityFindingStatementsEvidenceRecommended changeCopy
{{ row.severity }}{{ row.finding }}{{ row.statements }}{{ row.evidence }}{{ row.recommendation }}
ServiceAllow statementsWildcard actionsWildcard resourcesCondition coveragePressureReview focusCopy
{{ row.service }}{{ row.allow_statements }}{{ row.wildcard_actions }}{{ row.wildcard_resources }}{{ row.condition_coverage }}{{ row.pressure }}{{ row.review_focus }}
{{ chartError }}
{{ serviceChartError }}

No Allow statements are available to plot.

Firewall Rule Review Report Review firewall rules for stale use and broad exposure while scoring expiry, ownership and privileged-service evidence into a cleanup queue.
SBOM Component Risk Analyzer Review SBOM components with a transparent risk score and separate queues for vulnerabilities, licenses, and incomplete package identity.
IAM Policy Wildcards Checker Check AWS IAM policy JSON for wildcard permissions and broad PassRole exposure, then rank the statements that need least-privilege remediation.
Terraform Plan Summary Analyzer Analyze Terraform plan JSON or text before apply, flag destructive changes and drift, and rank resources by review risk without uploading plan data.

A short IAM policy can represent a very large permission surface. Action, Resource, and Principal wildcards may cover present and future targets, while NotAction or NotResource can grant the broad remainder outside a small exclusion list. The document must be read for breadth as well as syntax.

AWS Identity and Access Management (IAM) evaluates requests using more than one JSON document. Identity policies and resource policies can contribute allows, permissions boundaries and organization policies can limit them, session policies can narrow a session, and any applicable explicit deny wins. Reviewing one policy therefore finds risky statement shapes; it cannot calculate the principal's effective access.

Policy kindWhere it appliesImportant review question
Identity policyUser, group, or roleWhich actions and resources does this identity receive?
Resource policyAn AWS resourceWhich principals can reach the resource, and under what conditions?
Permissions boundaryMaximum permissions for an identityDoes the boundary cap the intended actions without being mistaken for a grant?
Role trust policyRole assumptionWhich principals may assume the role?

Least privilege means matching the required actions to the smallest supported resource and request context. Removing every wildcard is not a universal solution because some actions do not support resource-level restriction. Conditions also need service-specific validation: the presence of a condition key does not prove that the action uses it or that its value matches a real request.

Privilege paths deserve separate attention from simple breadth. Permissions to pass a role, change a policy or trust relationship, create credentials, add a resource permission, or launch infrastructure can let a principal obtain more access indirectly. A bounded static list can highlight familiar paths, but new services and combinations can create others.

A breadth score is useful for ordering a review, not approving a policy. Final verification needs AWS policy grammar checks, service authorization references, IAM Access Analyzer, simulation where applicable, and a controlled request using the intended principal, resource, and context.

How to Use This Tool:

Review one policy document in the context where it will be attached or used.

  1. Paste or load IAM policy JSON. The document must be a JSON object with at least one Statement. Remove comments, trailing commas, and surrounding shell output if parsing fails.
  2. Choose Policy kind. This changes principal-shape checks: resource and trust policies normally name a principal, while a principal is unusual in identity policies and permissions boundaries.
  3. Select Review lens. The lens changes only which AWS service prefixes receive sensitive-service pressure. Add local prefixes only when they reflect an approved review policy.
  4. Keep Wildcard pressure multiplier at 1.0 unless a documented policy requires 0.5 to 2.0. It affects Action wildcard weights, not resources, principals, pivot matches, or finding priorities.
  5. Investigate direct findings and the highest-scoring statements. Revise the JSON, confirm the evidence changes, then validate the policy with AWS tooling before approval.

Interpreting Results:

The statement score and finding queue answer different questions. The score combines breadth signals on an Allow statement. Findings apply fixed rules to specific patterns, so a High or Critical finding can accompany a lower score.

  • Approval review needed appears when an Allow statement is High or Critical, or when a statement has a policy-shape issue. Its absence is not a safety guarantee.
  • Deny statements receive the Control label and no breadth points. They still need review because an applicable explicit deny can override an allow.
  • Use the statement evidence to inspect actions, resources, principals, and conditions. Service pressure only ranks concentrations for investigation.
  • Verify the exact policy attached in AWS and test the intended request path; pasted JSON alone cannot reveal every contributing policy or request value.

Technical Details:

Every statement is normalized into effect, action and resource forms, principal values, condition keys, service prefixes, wildcard classes, pivot matches, and policy-kind shape issues. Only Allow statements accumulate breadth points. A missing or unsupported Effect is treated as Allow-shaped with a shape issue so malformed input is not mistaken for a harmless deny.

Formula Core

The breadth model adds applicable pressures, subtracts a limited condition credit, rounds once, and clamps the result to 0 through 100.

S=clamp(0,100,round( W+20R+30NA+18NR +Sens+Pivot+7U+22P+8H−6C ))
TermConditionContribution
WStrongest Action wildcard class with multiplier m46m global; 32m service-wide; 18m partial; otherwise 0
RAny Resource or NotResource value contains *20
NAAllow uses NotAction30
NRAllow uses NotResource18
Senss sensitive service prefixes match0 if s = 0; otherwise min(28, 10 + 5s)
Pivotp privilege-pivot patterns match0 if p = 0; otherwise min(34, 18 + 4p)
UNo condition operator and key are present7
PWildcard principal in resource or trust context22
HAt least one policy-kind shape issue8
CA condition exists and the pre-credit score is greater than 8−6

Binary terms are 1 when their rule applies and 0 otherwise. Scores are nonnegative, so half-point values round upward before the 0-to-100 clamp. A condition credit recognizes only that condition structure exists; it does not validate the operator, key, value, or action support.

Service pressure is a separate ranking. It starts with the highest statement score for that service, then adds concentration signals.

Q=clamp(0,100,round(M+6A+5R+3U))

M is the service's maximum statement score; A, R, and U count Allow statements with action wildcards, resource wildcards, and no conditions. Service pressure never changes a statement score or finding.

Lookup Core

The review lens supplies the sensitive service set. Valid additional prefixes extend the selected row.

LensService prefixes
Least privilegeiam, sts, organizations, kms, cloudtrail, s3, secretsmanager
CI/CD deployiam, sts, cloudformation, lambda, ecr, ecs, eks, kms, secretsmanager
Read onlyiam, s3, kms, secretsmanager, organizations, cloudtrail
Resource exposureiam, sts, kms, s3, lambda, sqs, sns, secretsmanager

The bounded privilege-pivot lookup covers these exact patterns:

  • iam:PassRole, iam:CreatePolicyVersion, iam:AttachRolePolicy, iam:PutRolePolicy, iam:UpdateAssumeRolePolicy, iam:CreateAccessKey, and iam:UpdateLoginProfile
  • sts:AssumeRole, organizations:*, kms:PutKeyPolicy, s3:PutBucketPolicy, and lambda:AddPermission
  • cloudformation:CreateStack, cloudformation:UpdateStack, and ec2:AuthorizeSecurityGroupIngress

Matching is case-insensitive and honors * and ? wildcards in an action being reviewed. The list is intentionally finite and must not be read as a complete catalog of escalation paths.

Rule Core

LevelBoundaryMeaning
LowS < 25Continue normal IAM review and request testing
Medium25 ≤ S < 50Check least-privilege fit and supported conditions
High50 ≤ S < 75Tighten wildcard and scope evidence
CriticalS ≥ 75Resolve broad access before approval
ControlDeny statementVerify the guardrail and its request context

Direct findings do not inherit those bands. They use the following fixed triggers:

FindingPriorityTrigger
Global action wildcardCriticalAllow action is * or *:*
Service-wide action wildcardHighAllow action matches service:*
Partial action wildcardMediumAnother Allow action contains a wildcard
Wildcard resourceHighAllow Resource or NotResource contains *
Allow with NotAction / NotResourceHigh / ReviewThe corresponding exclusion element is present
Privilege-pivot actionCriticalAn Allow action matches the bounded pivot lookup
Sensitive serviceReviewAn Allow touches the selected or extended service set
Unconditioned broad allowMediumAn Allow has S ≥ 25 and no condition
Wildcard principalCriticalA resource or trust Allow has a wildcard principal
Policy shape issueReviewRequired statement elements are missing or conflict with policy kind

Policy input accepts 1 to 2,000 statements in a document no larger than 2 MiB. The visible statement limit of 10 to 300 changes only the displayed ledger; all statements still contribute to counts, findings, service totals, and rankings.

Limitations and Privacy:

Policy parsing and scoring remain in the browser, and no AWS account is queried. The label and JSON are excluded from the share URL, but copied or downloaded evidence may contain account IDs, role names, resource names, principals, and organization details.

  • The breadth model is a repository-authored heuristic, not an AWS authorization result, risk score, or approval decision.
  • Condition presence does not establish service support, correct operators, or matching request values.
  • The sensitive-service and pivot lookups cannot cover every service-specific access path.
  • Effective permissions may change through policies and controls outside the supplied document.
  • Use IAM Access Analyzer and service-specific testing before applying a policy to a production identity or resource.

References: