IAM Policy Simulator (Offline) - Client-Side IAM Decision Diamond Evaluator

First Published:
Last Updated:

Simulate AWS IAM policy evaluation entirely in your browser - across all seven stages of the IAM Decision Diamond (Explicit Deny, RCP, SCP, Resource-based, Identity-based, Permission Boundary, Session policy) with same-account vs cross-account semantics - no sign-in, no account, no data sent to AWS.

All processing is performed entirely in your browser using client-side JavaScript. No data is transmitted to any server. Your policies and request context never leave your device.

  • This tool is provided "AS IS" without any warranties of any kind.
  • This tool approximates IAM policy evaluation logic - including the Organization (SCP / RCP), Permission Boundary, and Session policy ceilings and the same-account / cross-account split. Results may still differ from live AWS in fine-grained edge cases (see Important Notes below).
  • Use the AWS-hosted IAM Policy Simulator for authoritative results.
  • By using this tool, you accept full responsibility for any outcomes.

This tool uses client-side JavaScript for all processing. No data is transmitted to servers, no files are uploaded online, all processing happens locally in your browser. Once loaded, this tool continues to work even without an internet connection. For more details, please refer to our Web Tools Disclaimer.

Sample Policies

Account Context

Policies

Organizations SCP (caller-side ceiling). Modeled as a deny-list with the FullAWSAccess baseline: an SCP Deny blocks at this stage; conditionless and condition-bearing Deny statements are both evaluated.

Organizations RCP (resource-side ceiling). RCPs are deny-list only with the RCPFullAWSAccess baseline: a matching Deny blocks at this stage. Statements carry a Principal.

Permission Boundary (ceiling on the principal). The effective permission is the intersection of the identity policy and the boundary; if the boundary does not Allow the action, the result is an implicit deny.

Session policy (passed at AssumeRole time). Intersects with the role's effective permissions; it can only narrow, never grant.

Request

Context Keys

Add condition context keys referenced by your policies (e.g. aws:SourceIp, aws:MultiFactorAuthPresent). For multi-value context, enter comma-separated values.

Features

  • Seven-stage IAM Decision Diamond: Evaluates Explicit Deny, RCP, SCP, Resource-based, Identity-based, Permission Boundary, and Session policy in AWS order, with a stage-by-stage breakdown that shows exactly where the decision was made.
  • Same-account vs cross-account: A toggle switches the Resource/Identity combinator between union (either side suffices) and intersection (both sides required).
  • Six policy types: Register any number of Identity-based, Resource-based, SCP, RCP, Permission Boundary, and Session policies. Resource-based and RCP statements are matched against the provided Principal ARN.
  • Allow / ExplicitDeny / ImplicitDeny: Explicit Deny short-circuits everywhere; ceiling stages intersect; granting stages union (same-account) or intersect (cross-account).
  • Full Statement matching: Action / NotAction, Resource / NotResource, Principal / NotPrincipal (including bare account-id and :root principals), Condition.
  • AWS-style wildcards: * and ? in Action and Resource patterns, with case-insensitive action matching.
  • 20+ Condition operators: String (Equals / NotEquals / EqualsIgnoreCase / NotEqualsIgnoreCase / Like / NotLike), Numeric (Equals / NotEquals / LessThan / LessThanEquals / GreaterThan / GreaterThanEquals), Bool, Date (all six variants), IpAddress / NotIpAddress (IPv4 CIDR), ArnEquals / ArnNotEquals / ArnLike / ArnNotLike.
  • Operator modifiers: IfExists suffix and ForAllValues: / ForAnyValue: prefixes for multi-value context keys.
  • Evaluation trace: Every statement is traced with match / skip status and per-element reasons for Action, Resource, Principal, and every Condition operator.
  • Worked-case presets: The four starter policies plus six presets that reproduce the IAM Policy Evaluation Logic article's cases (cross-account vs same-account resource grant, SCP deny, Permission Boundary cap, Session policy narrowing, RCP block).
  • 100% client-side: No network calls, no account required, works offline after first load.

How to Use

  1. Click any Sample Policies button to load a preset, or paste your own policy JSON into the Identity-based or Resource-based tab.
  2. Use + Add Identity Policy / + Add Resource Policy to register additional policies. Each textarea accepts a complete IAM policy document ({"Version":"2012-10-17","Statement":[...]}).
  3. Fill in the Request: the Action you want to simulate (e.g. s3:GetObject), the target Resource ARN, and - for resource-based policies - the Principal ARN making the request.
  4. Add any Context Keys referenced by your Conditions. Use comma-separated values when a key has multiple values (for ForAllValues: / ForAnyValue:).
  5. Click Evaluate. The decision badge shows Allow / ExplicitDeny / ImplicitDeny, followed by the matched statements and a full evaluation trace.
  6. Click Copy Result to copy the decision, summary, and trace to your clipboard.

Important Notes

  • SCP / RCP modeling. SCPs and RCPs are treated as deny-list ceilings on top of the FullAWSAccess / RCPFullAWSAccess baseline - they block via a matching Deny. Allow-list SCPs that remove FullAWSAccess are not modeled, so add an explicit Allow if you rely on that pattern.
  • Boundary / Session scope. Permission Boundary and Session policy cap the identity-derived path. The nuance where a resource policy grants directly to a role ARN (which a boundary does limit) vs to a user ARN / role session (which it does not) is simplified - see the article's section 5.3.
  • Cross-account is modeled as the both-sides-required intersection via the Account Context toggle; the tool does not infer which account each ARN belongs to - you select same vs cross.
  • Not modeled: VPC endpoint policies, Organizations declarative policies, and service-specific authorization quirks (e.g. the KMS key-policy "Enable IAM User Permissions" requirement).
  • Dynamic tag-based authorization (e.g. aws:ResourceTag/*, aws:PrincipalTag/*) is not resolved automatically - provide tag values via Context Keys.
  • IP matching supports IPv4 / CIDR only; IPv6 is not handled.
  • Policy variables (e.g. ${aws:username}, ${aws:PrincipalTag/Team}) are not expanded - supply the resolved value as a Context Key.
  • For authoritative results, always verify using the AWS-hosted IAM Policy Simulator against your real account.

References:
IAM Policy Evaluation Logic Step-by-Step - the IAM Decision Diamond this tool implements.
IAM Policy Least Privilege Analyzer - static lint for overly permissive patterns.
Tech Blog with curated related content
Web Tools Collection

Written by Hidekazu Konishi