You add a Deny statement to an AWS IAM policy with a Condition using StringEquals on a request context key, and it denies nothing. Why can an absent context key make a statement silently not apply, and what do the IfExists operator suffix and the Null operator do about it?

## Where condition keys come from Every IAM authorization decision is made against a **request context**: a bag of key/value pairs assembled from the signed request, the calling principal, the session, and the service being called. `aws:SourceIp` is there because the request arrived over the network; `aws:PrincipalTag/team` is there because the calling role carries that tag; `s3:prefix` is there only when the call is an S3 list operation that supplied a prefix. The crucial property is that the context is **sparse**. A key that does not apply to this request is not present with a default value — it is not present at all. Policies are written as though every key is always available, and that mismatch is where the bug lives. ## What an absent key does to a statement When a condition operator is evaluated against a key that is not in the request context, the comparison yields false. Every operator block inside a `Condition` must be true for the statement to match, so one absent key is enough to make the whole statement inert. That asymmetry matters: - In an **Allow**, an inert statement grants nothing. You lose access, you notice immediately, you fix it. Fail-closed. - In a **Deny**, an inert statement denies nothing. Nothing breaks, no error appears, and the control you believed you had is decorative. Fail-open — and it will be discovered by an auditor or an incident, not by your tests. ## The canonical example: MFA ```json { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } } } ``` With plain `Bool`, this statement catches sessions that were created without MFA — but a call signed with a long-term IAM user access key does not populate `aws:MultiFactorAuthPresent` at all, so the key is absent, the condition is false, and the very requests with the weakest authentication sail past. `BoolIfExists` treats "key absent" as satisfying the condition, so those calls are denied too. AWS documents this pattern explicitly for MFA enforcement, and it is the example worth memorising because it captures the whole class. ## The two tools **The `...IfExists` suffix** can be appended to almost any operator (`StringEqualsIfExists`, `ArnLikeIfExists`, `NumericLessThanIfExists`). Semantics: if the key is present, compare normally; if it is absent, the block evaluates true. Read it as "and if the key is missing, do not let that stop this statement from applying". That is what you want in a Deny. It is usually *not* what you want in an Allow, where it quietly widens the grant to requests missing the key you meant to require. **The `Null` operator** tests presence itself rather than a value. `{"Null": {"aws:TokenIssueTime": "true"}}` matches when the key is absent — a well-known way to distinguish long-term credentials from temporary ones, since `aws:TokenIssueTime` exists only for temporary credentials. `{"Null": {"aws:TokenIssueTime": "false"}}` matches when it is present. Note the inversion that trips people: the value `"true"` means *is null*, not *is true*. ## Related evaluation rules worth having straight - Multiple operator blocks in one `Condition` are **ANDed**. Multiple values for a single key inside one block are **ORed**. - Multiple keys inside one operator block are ANDed with each other. - For multivalued context keys you must use the set prefixes `ForAllValues:` or `ForAnyValue:`. Their absent-key behaviour differs from the norm: `ForAllValues:` evaluates **true** when the key is missing and `ForAnyValue:` evaluates **false**, which is why `ForAllValues:` in an Allow statement is a documented over-permission hazard. - String operators are case-sensitive unless you use the `...IgnoreCase` form; `StringLike` adds `*` and `?` wildcards; ARNs should be compared with `ArnEquals`/`ArnLike` rather than string operators so that ARN structure is respected. ## How to avoid the whole class of bug Write Denies with the assumption that the key might be missing, and decide deliberately: `...IfExists` when a missing key should still be caught, `Null` when the missing key *is* the thing you are detecting. Then verify rather than assume — issue the exact call you meant to block with the exact credential shape you are worried about, and confirm it is refused. A guardrail that has never been observed failing a request is a guardrail you have not tested.