Security Tools

AWS IAM Policy Viewer & Analyzer

Turn IAM policy JSON into readable statement cards with plain-English conditions, see which services and actions it touches, flag risky patterns like admin wildcards and public principals, and test an action against it with a simplified simulator.

Private by design: anything you enter is processed in your browser only. It is never uploaded to or logged on our servers. Policies are parsed locally; nothing is sent to AWS. Share links contain the policy JSON, so remove account IDs first if they are sensitive.

Accepts a full policy, a single statement, an array of statements, or AWS CLI output that wraps the document (PolicyDocument, AssumeRolePolicyDocument).

Summary

Findings

    Actions by service

    Statements

    Simulate a request

    Simplified simulation: it evaluates only this policy's Action and Resource elements (explicit deny > allow > implicit deny). Conditions, principals, SCPs, permissions boundaries, session policies and other policies are ignored, and policy variables are not substituted. Use the AWS IAM policy simulator for an authoritative answer.

    About AWS IAM policies

    AWS Identity and Access Management (IAM) policies are JSON documents that decide whether a request is allowed. Each policy holds one or more statements, and each statement says which Effect (Allow or Deny) applies to which Actions on which Resources, optionally limited by Conditions. Identity-based policies are attached to users, groups and roles; resource-based policies such as S3 bucket policies, SQS queue policies and KMS key policies are attached to the resource and name a Principal; a role's trust policy is a resource-based policy that controls who may call sts:AssumeRole.

    Policies are easy to write and hard to read: wildcards like s3:Get* hide dozens of actions, NotAction inverts the meaning of a statement, and condition blocks combine operators, keys and value lists with rules that are not obvious (keys are AND-ed, values inside a key are OR-ed). This viewer lays each statement out as a card, translates common condition operators into plain English and groups the actions by service so you can see the blast radius at a glance.

    The findings panel highlights patterns that commonly cause incidents: full "Action": "*" on "Resource": "*", service-wide wildcards, iam:PassRole on any role (a classic privilege-escalation path), Allow combined with NotAction or NotResource, public "Principal": "*" without conditions, trust policies that let anyone assume a role, missing or legacy Version values, and S3 bucket policies that do not deny plain HTTP. They are heuristics for review, not a replacement for IAM Access Analyzer.

    Restricting by network? Work out aws:SourceIp CIDR blocks with the subnet calculator. Policies stored in CloudFormation or Terraform YAML can be converted with the JSON/YAML converter, syntax errors are easier to locate in the JSON validator, and you can pull specific statements out of large documents with the JSONPath tester. Before pasting logs that contain access keys into a ticket, run them through the secrets & PII scrubber.

    Reference Guide

    How AWS evaluates a request (single account, simplified):

    1. Every request starts as an implicit deny.
    2. If any applicable policy has a matching explicit Deny, the request is denied. Nothing can override it.
    3. Service control policies (SCPs), resource control policies (RCPs), permissions boundaries and session policies only limit permissions: when one of these applies, it must also allow the action.
    4. An Allow in an identity-based policy or a resource-based policy grants access, subject to the limits above.
    5. If nothing allows the request, the implicit deny stands.

    Cross-account access needs an Allow on both sides: the caller's identity policy and the resource policy (or role trust policy) in the other account.

    Policy elements:

    ElementMeaningNotes
    VersionPolicy language versionUse 2012-10-17. Without it the policy is treated as 2008-10-17, where policy variables like ${aws:username} are literal text.
    StatementOne statement object or an array of themStatements are evaluated independently
    SidOptional statement labelMust be unique within the policy
    EffectAllow or DenyCase-sensitive
    Principal / NotPrincipalWho the statement applies toOnly in resource-based and trust policies. "*" means everyone, including anonymous users.
    Action / NotActionservice:Action, wildcards allowedAction names are case-insensitive. NotAction matches everything except the list.
    Resource / NotResourceARNs the statement coversRequired in identity policies; omitted in trust policies
    Condition{ operator: { key: value(s) } }All operators and keys must match (AND); multiple values for one key match if any does (OR)

    Condition operators:

    OperatorMatches whenExample
    StringEquals / StringNotEqualsExact, case-sensitive string (in)equality"aws:PrincipalTag/team": "data"
    StringEqualsIgnoreCaseEquality ignoring case"aws:RequestTag/env": "prod"
    StringLike / StringNotLikePattern with * and ? wildcards"s3:prefix": "home/*"
    NumericLessThan, NumericGreaterThanEquals…Number comparison"s3:max-keys": "10"
    DateGreaterThan, DateLessThan…Date comparison (ISO 8601 or epoch)"aws:CurrentTime": "2025-01-01T00:00:00Z"
    BoolBoolean key is true/false"aws:SecureTransport": "false"
    IpAddress / NotIpAddressSource IP inside / outside CIDR ranges"aws:SourceIp": "203.0.113.0/24"
    ArnEquals / ArnLikeARN equality or wildcard match"aws:SourceArn": "arn:aws:sns:*:123456789012:*"
    Nulltrue: key is absent; false: key is present"aws:TokenIssueTime": "true"
    …IfExistsSame check, but also true when the key is missingBoolIfExists on aws:MultiFactorAuthPresent
    ForAnyValue: / ForAllValues:For multi-valued keys: at least one / every request value matches. ForAllValues is also true when the key is missing or empty.ForAllValues:StringEquals on aws:TagKeys

    ARN format: arn:partition:service:region:account-id:resource, where the resource part is resource-type/resource-id or resource-type:resource-id depending on the service.

    ResourceARN
    S3 bucket / objectsarn:aws:s3:::example-bucket, arn:aws:s3:::example-bucket/logs/* (no region or account)
    IAM rolearn:aws:iam::123456789012:role/AppRole (global, no region)
    DynamoDB tablearn:aws:dynamodb:us-east-1:123456789012:table/Orders
    Lambda functionarn:aws:lambda:us-east-1:123456789012:function:resize-image
    Other partitionsarn:aws-cn:… (China), arn:aws-us-gov:… (GovCloud)

    Example input

    {
      "Version": "2012-10-17",
      "Statement": [
        { "Sid": "ReadAppBucket", "Effect": "Allow",
          "Action": ["s3:Get*", "s3:ListBucket"],
          "Resource": ["arn:aws:s3:::example-app-assets", "arn:aws:s3:::example-app-assets/*"] },
        { "Sid": "DeployLambda", "Effect": "Allow",
          "Action": ["lambda:UpdateFunctionCode", "iam:PassRole"], "Resource": "*" },
        { "Sid": "DenyDeleteProd", "Effect": "Deny",
          "Action": "s3:DeleteObject", "Resource": "arn:aws:s3:::example-app-assets/prod/*" }
      ]
    }

    This sample loads automatically when you open the tool. Use Load Sample to bring it back.

    Frequently Asked Questions

    An explicit Deny always wins. Otherwise an action is allowed only if some policy explicitly allows it; everything else is implicitly denied. Permission boundaries and SCPs can further limit what is allowed.

    It grants full administrator access to every service and resource in the account. Grant only the specific actions and resources a role needs.

    No. It is a simplified check of Allow and Deny statements with wildcard matching. Use the AWS IAM policy simulator or IAM Access Analyzer for authoritative results.