IAM Policy Simulator (logic-based)

Reading a multi-statement IAM policy and mentally tracing through what a specific action + resource + condition-context combination would actually resolve to is slow and error-prone, especially once Deny statements and Condition blocks are involved. IAM Policy Simulator (logic-based) lets you paste a policy document, describe one request — an action, a resource ARN, and any condition-key context values you want to supply — and see the resulting decision, which statements actually applied, and exactly what was uncertain, all computed locally with the same core evaluation logic AWS itself follows.

The evaluation walks every statement in the document and, for each one, checks whether its Action/NotAction matches the requested action (case-insensitive glob matching, since AWS treats action names case-insensitively) and whether its Resource/NotResource matches the requested resource ARN (case-sensitive glob matching, since ARNs are case-sensitive). A statement that matches both is then checked against its Condition block, if it has one, using the context key/value pairs you supplied through the "Add context key" rows. Statements matching on Action and Resource but whose condition definitively evaluates to false are excluded; among what remains, an explicit Deny always wins over any Allow — the single most important rule in real AWS policy evaluation, and the one this tool implements faithfully. If nothing applies at all, the result is Implicit Deny, matching AWS's default-deny posture.

The condition evaluation is deliberately narrow and says so plainly: only four operators are actually evaluated — StringEquals, StringNotEquals, StringLike, and Bool. Any other operator (IpAddress, DateGreaterThan, ArnLike, NumericLessThan, and the rest of AWS's much larger operator set) is treated the same way as a condition key you never supplied a value for: as unevaluatable. Crucially, an unevaluatable condition does not silently resolve to true or false — the statement is conservatively marked as possibly applicable, its condition result comes back indeterminate rather than a guess, and a caveat is added to the results explicitly naming which key or operator could not be evaluated. This matters because a policy simulator that silently assumes an unknown condition is satisfied (or unsatisfied) gives you false confidence; this one tells you precisely where its answer is uncertain and why, so you can supply the missing context and get a definitive read.

What this tool does not do deserves equal emphasis, prominently, not buried in a footnote: it is not the real AWS IAM Policy Simulator and does not call any AWS API. It evaluates exactly one policy document against one request in isolation — it has no model of Service Control Policies, permission boundaries, resource-based policy combination (an S3 bucket policy plus an IAM identity policy plus a VPC endpoint policy, evaluated together), session policies, or cross-account trust relationships, all of which materially affect what actually happens in a real AWS account. It also has no catalog of real AWS actions or services — an Action or Resource string is matched purely as a wildcard pattern, with no validation that the action or service name is real. Treat this as a fast, local, first-pass sanity check on a single policy document's own internal logic — a way to catch "wait, does my Deny statement actually cover this case?" while writing or reviewing a policy — not as a substitute for AWS's actual evaluation engine or for testing against a real account before granting production access.

The request-builder UI mirrors this scope: one action field, one resource field, and a dynamic list of context key/value rows you add one at a time, since this tool has no real caller identity or request metadata to draw from — you supply exactly the condition-relevant facts you want evaluated, and nothing more is assumed. The matched-statements table shows every statement whose Action and Resource matched, its effect, and whether its condition was satisfied, not satisfied, or indeterminate, so the reasoning behind the final decision is fully visible rather than a single opaque verdict.

• Paste one policy document and build one test request — action, resource, and dynamic context rows.
• Explicit Deny always wins over Allow, matching real AWS evaluation order.
• Implicit Deny when no statement applies.
• Evaluates exactly 4 condition operators — StringEquals, StringNotEquals, StringLike, Bool — honestly, with everything else marked unevaluatable.
• Missing context produces a caveat, never a silent guess.
• Matched-statements table showing effect and condition-evaluation status per statement.
• Persistent scope notice in the results area, not just in the docs — this is a local approximation, not the real AWS simulator.
• Dynamic "Add context key" rows for building request context.
• Sample policy and sample request demonstrating Allow, Deny-wins, and a missing-context caveat.
• One-click clear.
• 100% client-side — nothing is uploaded.

1. Paste your policy JSON, or click the sample.
2. Fill in the request — an action like s3:GetObject and a resource ARN.
3. Add context key/value rows for any condition keys your policy's Condition blocks reference (e.g. aws:MultiFactorAuthPresent = true).
4. Click Simulate.
5. Read the decision badge — Allow, Deny, or Implicit Deny.
6. Check the matched-statements table to see which statements applied and why.
7. Read any caveats — they name exactly which context was missing.
8. Add the missing context and re-run for a definitive answer.

Example 1 — plain Allow. A single-statement policy allowing s3:GetObject on arn:aws:s3:::my-bucket/*, tested against action s3:GetObject and resource arn:aws:s3:::my-bucket/report.pdf with no context needed, decides Allow.

Example 2 — explicit Deny wins. A policy with an Allow * statement and a separate Deny s3:DeleteObject statement, tested against action s3:DeleteObject, decides Deny — the matched-statements table shows both statements matched, and the Deny took precedence.

Example 3 — missing-context caveat. A policy that Allows an action only when aws:MultiFactorAuthPresent is true, tested with no context rows filled in, decides Allow (conservatively, since the condition could not be disproven) but shows a caveat naming aws:MultiFactorAuthPresent as the unsupplied key — add a context row with that key set to false and the decision flips to Implicit Deny.

Example 4 — Implicit Deny. Testing an action no statement's Action field matches at all (e.g. iam:CreateUser against an S3-only policy) decides Implicit Deny with an empty matched-statements table.

Example 5 — unevaluatable operator. A Condition using IpAddress (not one of the 4 evaluated operators) always produces a caveat regardless of context supplied, since this tool cannot evaluate that operator at all.

• Traces multi-statement Allow/Deny interaction instantly instead of by hand.
• Never silently guesses on an unevaluatable condition — always surfaces a caveat.
• Shows its work — every matched statement and its condition status, not just a verdict.
• Honest, persistent scope notice — never presented as equivalent to AWS's real simulator.
• Fast local iteration while writing or reviewing a policy.
• Private — policy and request context never leave your browser.