{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
Match the policy document that will receive this statement set.
Choose the closest operating environment for the principal or resource.
Select only an exception class your review process can document.
Balanced is the general review default; use strict for approval gates.
The checker reviews statement breadth; it does not call AWS or calculate effective permissions.
{{ sourceMeta }}
{{ sourceStatus || 'Browser-local reactive review; no AWS request is made.' }}
{{ workflowFeedback }}
Leave blank for “IAM policy review.”
PriorityStatementWildcard signalEvidenceNext actionCopy
{{ row.severity }}{{ row.statement }}{{ row.signal }}{{ row.evidence }}{{ row.action }}

{{ row.title }}

{{ row.action }}

{{ row.verify }}

Run IAM Access Analyzer policy validation and test the edited policy before production use. This local review does not prove effective access.

Vulnerability Remediation SLA Calculator Turn vulnerability backlog CSV into policy-based due dates and owner-ready remediation priorities with overdue, due-soon and compliance signals.
IAM Policy Permissions Analyzer Review AWS IAM policy JSON for wildcard breadth, privilege paths, and policy-shape issues before validating effective access in AWS.
Kubernetes Resource Requests Checker Check Kubernetes manifests for missing resource requests and invalid limits, with QoS clues and scheduler-footprint evidence before rollout.
RPO/RTO Gap Calculator Compare RPO and RTO targets with measured recovery evidence, flag data-loss and restore-time gaps, and estimate added change or downtime exposure.

An AWS Identity and Access Management (IAM) wildcard can make a policy shorter while granting more reach than its author intended. Action: "*" can cover every applicable action, a service pattern such as s3:* can include future actions, Resource: "*" can span every resource supported by those actions, and a wildcard principal can open a resource or trust policy to identities outside the intended boundary.

Wildcards are not automatically defects. Some AWS actions do not support resource-level permissions, and deny guardrails often need broad scope. The surrounding Effect, policy type, principal, conditions, workload, and service authorization model determine whether a wildcard is necessary, containable, or dangerous. An exception should therefore lower review priority only when its documented conditions actually match the statement.

  • Action breadth asks which operations are permitted, including patterns and NotAction.
  • Resource breadth asks which Amazon Resource Names (ARNs) are in scope and gives special attention to broad iam:PassRole.
  • Principal breadth matters for resource-based and trust policies, where Principal identifies who can receive access.
  • Conditions can narrow access by account, organization, source, tag, region, principal, or service context, but only when the action and service support the chosen key.

A statement-level review cannot calculate effective permissions. Final access also depends on other identity and resource policies, explicit denies, service control policies, resource control policies, permissions boundaries, session policies, and service-specific rules. Treat a low-risk result as a focused wildcard screen, then validate the complete policy and test the intended workload path.

How to Use This Tool:

Match the policy context before reviewing the JSON because principal rules, permission ceilings, and severity cues depend on that context.

  1. Choose Policy type for the document being reviewed. Resource and trust policies evaluate principals; boundaries and organization policies are treated as permission ceilings or guardrails.
  2. Select Workload profile and Review posture. Workload changes which service wildcards receive sensitive-service treatment; posture changes score weights but not matched evidence.
  3. Choose Wildcard exception model only when the review can document the named condition. A matching exception lowers one finding by one severity level and never removes it.
  4. Paste Policy JSON. One policy, a policy-document wrapper, or a larger JSON object containing nested policy documents is accepted up to 262,144 characters. Correct invalid JSON or a missing Statement collection before continuing.
  5. Review Wildcard findings from highest severity downward, edit the named statement, then run IAM Access Analyzer policy validation and a non-production workload test.

Interpreting Results:

The risk score is a capped sum of local finding weights, while the band also honors the most severe finding. Any Critical finding makes the band Critical even when the numeric total is below 75; any High finding makes it at least High; and any Medium finding makes it at least Moderate.

Start with the highest-severity statement and its exact wildcard signal. The exposure profile is useful for seeing which category contributes the most points, but it does not prove exploitability or effective access. After editing, validate the policy with AWS tooling and run the intended action in a test environment; a Low result alone does not establish least privilege.

Technical Details:

Every object containing a Statement element is treated as a policy document, including nested policy-document wrappers. Each statement is normalized into Effect, Action or NotAction, Resource or NotResource, Principal or NotPrincipal, and condition-key evidence before the policy-type and workload rules are applied.

Rule Core:

Wildcard permission-breadth findings are attached to Allow statements. A missing Action or NotAction is still High severity for any statement, while broad Deny statements are reported separately as guardrails.

SignalConditionBase severity
Missing action elementNeither Action nor NotAction is presentHigh
Negated AllowAllow uses NotAction or NotResourceCritical
Global action wildcardAllow contains Action "*"Critical
Action patternAllow contains * or ? in an actionHigh for sensitive, write-like, or global-resource scope; otherwise Medium
Global resource wildcardAllow contains Resource "*" outside a trust policyCritical for PassRole, sensitive, or write-like scope; otherwise High
Resource ARN patternAllow contains a non-global resource wildcardHigh for sensitive or PassRole scope; otherwise Medium
Broad PassRoleBroad resource scope can match iam:PassRole without iam:PassedToServiceCritical
Wildcard principalApplicable resource or trust policy allows every principalCritical for trust policy; otherwise High
Condition gapA broad Allow has no Condition blockHigh for wildcard trust principal; otherwise Medium
Deny guardrailDeny contains broad action or resource scopeLow for policy guardrails; otherwise Info

PassRole matching expands action patterns against iam:PassRole. A write-like wildcard is one whose operation begins with a mutating verb such as create, delete, pass, put, run, set, start, stop, or update. The selected workload supplies the list of services that receive sensitive treatment.

Exception Rules:

ExceptionMatches only when
Exact action requires Resource "*"The finding is Resource breadth, Resource is global, actions are explicit with no wildcard, and at least one condition exists.
Read-only resource prefixAll actions begin with get, list, describe, or read; the resource wildcard is not global; and at least one condition exists.
Conditioned organization or source boundaryA Principal, Resource, or Condition-gap finding has a recognized organization, account, source, principal, tag, or region boundary key.
Deny guardrail wildcardThe finding is a broad Deny guardrail.

A matching exception moves severity down exactly one level: Critical to High, High to Medium, Medium to Low, or Low to Info. Evidence remains in the finding register.

Formula Core:

Each finding starts with a severity weight, multiplied by the selected review posture and rounded to the nearest whole point. The total score is capped at 100.

pi=round(wi×m) S=min(100,∑i=1npi)
PartValues
Severity weightCritical 35; High 22; Medium 12; Low 5; Info 0
Posture multiplierStrict 1.25; Balanced 1; Advisory 0.75
Critical bandAny Critical finding or score ≥ 75
High bandOtherwise, any High finding or score ≥ 45
Moderate bandOtherwise, any Medium finding or score ≥ 20
Low bandNo stronger severity or threshold applies

The score ranks local remediation work; it is not an AWS security rating. Several findings from one statement can add points, and the score cap means two different high-risk policies can both display 100 while having different evidence.

Privacy Notes:

Policy JSON is parsed in the browser and no AWS account or service is contacted. The page does not resolve attached policies, account resources, principal identities, or effective permissions. Policy documents can reveal account IDs, role names, resource names, conditions, and architecture, so review copied or downloaded evidence before sharing it.

Worked Examples:

Broad deployment role

An Allow statement containing iam:PassRole with Resource "*" produces a Critical resource-breadth finding. Without an iam:PassedToService condition it also produces the separate Broad iam:PassRole finding. Scope the role ARNs, add the intended service boundary, validate the policy, and test the deployment path.

Wildcard deny guardrail

A Deny statement with wildcard scope is recorded as a guardrail rather than as granted access. It is Low severity for boundaries, SCPs, and RCPs, or Info for other policy types. For those guardrail policy types, the documented deny-guardrail exception lowers Low to Info and keeps the finding visible.

References: