How to Check an AWS IAM Policy for Risks (Free, No Signup)

Most risky AWS access is technically valid. IAM does not error on an over-broad policy, so the danger slips past terraform apply and human review alike. You do not need an account or any credentials to catch the common cases though — here is the checklist we use, and three free tools that run entirely in your browser to flag each pattern.

1. Permission policies: wildcards and escalation

On an identity or resource policy, scan for the patterns that quietly grant far more than intended:

• Wildcard actions. Action: "*" or service:* (for example s3:* when you only call s3:GetObject).
• Privilege-escalation actions. iam:PassRole, iam:CreatePolicyVersion, iam:AttachUserPolicy, iam:UpdateAssumeRolePolicy and similar let a principal grant itself more. See the IAM privilege escalation reference for each path.
• NotAction with Allow. This permits everything you did not list — usually far broader than intended.
• Wildcard resources. Resource: "*" where specific ARNs would do.

Paste a policy into the free IAM Policy Linter and it flags all of these instantly, with no signup.

2. Trust policies: who can assume the role

A role's trust policy is evaluated independently of its permissions, so an over-broad principal silently widens who can step into that access. Check for a Principal: "*" with no condition, an entire account trusted for third-party access without an sts:ExternalId (the confused deputy problem), and service principals missing an aws:SourceArn guard. The Trust Policy Explainer spells out exactly who can assume the role and flags these gaps. Background: what a trust policy is.

3. S3 bucket policies: public exposure

Public buckets remain one of the most common cloud data leaks. A bucket policy with Principal: "*" and no condition exposes the bucket to the internet; public write or s3:* is worse. The S3 Bucket Policy Checker tells you what a policy grants and whether it is public. Note that account-level Block Public Access can override a public-looking policy, so keep it enabled unless you genuinely need public access.

When to go deeper than a checklist

Static checks catch the obvious cases, but real escalation is often an interactionbetween permissions that are individually fine — PassRole plus a compute service, or a chain across roles. That needs reasoning about the whole policy in context. Shieldly's AI-Powered analyzer reads the full document, explains why each finding matters in plain English, and returns the tightened policy. It is free to try with no signup, and ships as a web app, CLI, VS Code extension, GitHub Action, and @shieldly/cdk-guard construct so you can run the same check in a pull request.

Amazon Web Services (AWS) is a trademark of Amazon.com, Inc. Shieldly is not affiliated with, endorsed by, or sponsored by Amazon Web Services.