IAM Condition Key Validator

IAM condition keys are easy to typo and easy to misremember — is it aws:sourceIp or aws:SourceIp? Is the tag-scoped key aws:PrincipalTag or aws:PrincipalTag/ with a trailing slash and a tag name? IAM Condition Key Validator scans every Condition block in a pasted policy document and reports, key by key, whether it matches one of a curated list of common AWS global condition keys — so a casing mistake or made-up key name is flagged for a second look rather than silently shipped in a policy.

The mechanics are straightforward: the tool walks every statement in the Statement array, and for each statement that has a Condition object, it walks every operator block inside it (StringEquals, StringLike, IpAddress, Bool, and so on — any operator name at all, since this check does not care which operator a key is paired with) and every key inside each block. Each key is checked against a curated list of roughly 29 commonly used AWS global condition keys: identity and session keys like aws:PrincipalArn, aws:PrincipalOrgID, aws:userid and aws:username; network and transport keys like aws:SourceIp, aws:SourceVpc, aws:VpcSourceIp and aws:SecureTransport; MFA keys like aws:MultiFactorAuthPresent and aws:MultiFactorAuthAge; time keys like aws:CurrentTime and aws:EpochTime; tag-based keys — aws:PrincipalTag/, aws:RequestTag/, aws:ResourceTag/ — matched as prefixes so any tag name after the slash counts; and a small set of common service-scoped keys like sts:ExternalId, sts:RoleSessionName, s3:x-amz-acl and s3:prefix. Every key found is reported in a table with its statement index, the operator it appeared under, the key name itself, and a known/unknown badge, plus a summary count of how many keys matched and how many did not.

The honesty of the "unknown" label matters more here than in most tools in this category, so it is worth stating plainly and repeatedly: AWS documents hundreds of condition keys across its services — DynamoDB alone has keys like dynamodb:LeadingKeys and dynamodb:Attributes, S3 has dozens more beyond the two included here, EC2, KMS, and nearly every other service define their own service-specific condition keys that show up in real, correct, well-written policies every day. This tool's curated list covers the common global keys that apply broadly across services, not that full universe. A key flagged "unknown" is not a verdict that the key is invalid or wrong — it is a signal that this tool's small list does not happen to include it, which is expected and normal for anything service-specific. Treat an unknown result as a prompt to check the specific service's IAM condition-key documentation, not as a confirmed error in your policy.

What this tool does check reliably is the exact key name string, which is where the highest-value, easiest-to-miss mistakes live: a casing slip (aws:sourceip instead of aws:SourceIp), a missing trailing slash and tag name on a tag-based key, or a condition key copy-pasted from an unrelated context that does not actually exist. Those mistakes fail silently in AWS — a condition referencing a key that is spelled wrong or does not apply simply never matches, quietly making a Deny or an Allow condition ineffective without any error at policy-attach time. Catching that class of typo before it reaches AWS is the entire value of this tool.

This does not check condition values, does not check whether an operator is a sensible pairing for a given key (for example, using IpAddress with a non-IP-shaped key), and does not call any AWS API. It is a fast, local, honest first pass over condition key spelling — nothing more, and it says so.

• Scans every Condition block across every statement in a pasted policy.
• Curated list of ~29 common AWS global condition keys, including prefix-aware tag keys.
• Per-key results table — statement index, operator, key name, known/unknown badge.
• Known vs. unknown summary counts.
• Explicitly honest about scope — "unknown" never means "invalid".
• Handles multiple operator blocks per statement.
• Handles multi-statement documents of any size.
• Sample policy with both known and unknown keys.
• One-click clear.
• 100% client-side — nothing is uploaded.

1. Paste your policy JSON, or click the sample.
2. Click Check condition keys.
3. Review the summary — total keys found, how many known vs. unknown.
4. Scan the table for any key marked unknown.
5. Look up unfamiliar keys in AWS's service-specific condition-key docs before assuming they are wrong.
6. Fix obvious typos (casing, missing slash) and re-check.

Example 1 — known global key. "Condition":{"StringEquals":{"aws:SourceIp":"203.0.113.0/24"}} reports aws:SourceIp as known.

Example 2 — known tag-prefix key. "Condition":{"StringLike":{"aws:PrincipalTag/team":"eng*"}} reports aws:PrincipalTag/team as known, matched via the aws:PrincipalTag/ prefix.

Example 3 — casing typo. "aws:sourceip" (lowercase) reports as unknown, since the curated list stores the exact AWS casing aws:SourceIp.

Example 4 — legitimate service-specific key not in the list. "dynamodb:LeadingKeys" reports as unknown — not because it is invalid (it is a real, documented DynamoDB condition key), but because this tool's curated list does not include DynamoDB-specific keys.

Example 5 — multiple statements. A two-statement policy where statement 0 has a Condition block and statement 1 has none produces rows only for statement 0; statement 1 contributes nothing.

• Catches condition key typos that AWS fails on silently instead of rejecting outright.
• Flags tag-key format mistakes (missing slash, wrong prefix).
• Never overclaims — "unknown" is always presented as a coverage gap, not a verdict.
• Works across multi-statement, multi-operator documents.
• Fast local first pass before deeper per-service documentation review.
• Private — policy content never leaves your browser.