AWS IAM Policy Evaluation Edge Cases with ForAllValues and Null Conditions

Using ForAllValues in an IAM policy Allow statement without a corresponding Null condition set to false creates a vacuous truth vulnerability that evaluates to TRUE when context keys are missing, potentially granting unintended access.

The aws/agent-toolkit-for-aws repository provides authoritative guidance on IAM policy authoring through its core IAM skills. Understanding the interaction between ForAllValues set operators and Null conditions is critical for preventing over-permissive policies that bypass intended security controls due to missing array-typed context keys.

Understanding ForAllValues and Array-Typed Context Keys

The ForAllValues condition operator is designed exclusively for array-typed context keys (e.g., ArrayOfString, ArrayOfARN). According to the guidance in skills/core-skills/aws-iam/references/common-pitfalls.md at lines 30-33, applying these set operators to non-array keys produces undefined behavior and should be strictly avoided. The operator validates that every value in the request's array meets the specified criteria, but this logic assumes the key exists and contains a valid array structure.

The Vacuous Truth Problem in Allow Statements

Why Missing Keys Evaluate to True

When an Allow statement uses ForAllValues and the referenced context key is missing or null, the operator evaluates to TRUE due to vacuous truth semantics. As documented in skills/core-skills/aws-iam/references/common-pitfalls.md at lines 86-89, this creates an "open-door" effect where IAM grants access even when the condition key is absent from the request context.

Security Implications

This behavior means that policies intended to restrict access based on tags or other array attributes can inadvertently permit actions when those attributes are omitted. Without explicit safeguards, requests missing the context key bypass the intended restriction entirely, violating least-privilege principles.

Correct Pattern: Pairing ForAllValues with Null Conditions

To mitigate the vacuous truth vulnerability, you must pair every ForAllValues clause in an Allow statement with a Null condition on the same key set to false. This pattern forces the key to be present and non-null before evaluation proceeds, as required by the policy generation reference in skills/core-skills/aws-iam/references/aws-iam-policy-generation.md at lines 251-253.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "ForAllValues:StringEquals": {
          "aws:TagKeys": ["environment", "project"]
        },
        "Null": {
          "aws:TagKeys": "false"
        }
      }
    }
  ]
}

Common Pitfalls to Avoid

When implementing ForAllValues and Null conditions in IAM policies, avoid these specific errors:

• Applying ForAllValues to scalar keys: Using the operator on non-array keys like aws:username causes undefined evaluation. Switch to standard operators like StringEquals or use the array-typed counterpart if available.

• Omitting the Null guard in Allow statements: Without "Null": {"<key>": "false"}, missing keys trigger vacuous truth and unintended access. Always include this check when the Effect is Allow.

• Testing only with present keys: Assuming single-value arrays behave like scalars misses the edge case. Validate policies using the AWS IAM Policy Simulator with both present and absent key scenarios.

Agent Toolkit Implementation

The Agent Toolkit's IAM-related skills automatically enforce these security patterns. When the aws-iam skill generates policy fragments, it inserts the required Null condition alongside any ForAllValues operator in Allow statements, as implemented in the utilities referenced in skills/core-skills/aws-iam/references/aws-iam-policy-generation.md. This ensures that every generated policy respects the vacuous truth semantics documented in skills/core-skills/aws-iam/SKILL.md at line 66, which summarizes the recommended pattern and warnings.

Summary

• ForAllValues only operates correctly with array-typed context keys such as aws:TagKeys or aws:VpceOrgPaths.
• Vacuous truth causes ForAllValues to evaluate to TRUE when keys are missing, creating security risks specifically in Allow statements.
• Mitigation requires pairing ForAllValues with a Null condition set to false on the identical key.
• Deny statements are less vulnerable to this issue but still benefit from the Null guard for consistency.
• The aws/agent-toolkit-for-aws automatically injects these safeguards into generated policies.

Frequently Asked Questions

What happens if ForAllValues references a missing context key?

When the context key is missing or null, ForAllValues evaluates to TRUE due to vacuous truth. In an Allow statement, this grants access unintentionally, which is why the aws/agent-toolkit-for-aws documentation in skills/core-skills/aws-iam/references/common-pitfalls.md explicitly warns against using this operator without a corresponding Null check.

Is the Null condition required in Deny statements?

While not strictly necessary for security in Deny statements—since vacuous truth would correctly deny access when keys are missing—adding the Null condition remains a best practice for policy consistency. The skills/core-skills/aws-iam/references/service-authorization.md reference emphasizes using array-typed keys consistently across all statement types.

Can I use ForAllValues with scalar condition keys like aws:username?

No. The service-authorization.md file at line 41 clarifies that ForAnyValue and ForAllValues must only be used with array-typed keys. Applying them to scalar keys produces undefined results and may cause policy validation failures or incorrect evaluation behavior.

How does the AWS Agent Toolkit handle these edge cases?

The toolkit's IAM policy generation utilities automatically insert the required Null condition whenever ForAllValues appears in an Allow statement, as specified in skills/core-skills/aws-iam/references/aws-iam-policy-generation.md at lines 251-254. This ensures generated policies follow AWS security best practices without requiring manual intervention.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}