IAM condition keys are the Condition block of a policy: extra tests that must pass before an allow or deny applies. They are how AWS policies express context — "only from this region," "only with this tag," "only this product." For Claude on Bedrock, teams usually reach for condition keys wanting one thing: to restrict a principal to specific Claude models. It's worth knowing that the primary documented mechanism for that is actually resource scoping, with condition keys as the complement for everything resource ARNs can't express.
Model restrictions: resource ARNs first
AWS's Bedrock policy examples restrict models by listing foundation-model ARNs in the Resource element — arn:aws:bedrock:*::foundation-model/{model-id}, where the model ID is the Bedrock-prefixed form such as anthropic.claude-sonnet-5. Because the model ID is part of the ARN, an allow statement scoped to two Claude ARNs is a model whitelist, no condition key required:
{
"Effect": "Allow",
"Action": ["bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"],
"Resource": [
"arn:aws:bedrock:*::foundation-model/anthropic.claude-sonnet-5",
"arn:aws:bedrock:us-east-1:111122223333:inference-profile/*"
]
}Include inference-profile ARNs when traffic flows through cross-region inference profiles — the documented minimal policy requires both resource types. You may also encounter model-scoped condition keys (such as a bedrock:ModelId-style key) referenced in policy discussions; condition-key support evolves, so verify the current list and semantics in the AWS Service Authorization Reference before relying on one. Resource-ARN scoping, by contrast, is stable, explicitly documented for Bedrock, and easier to audit.
The condition keys the Bedrock docs do lean on
| Condition key | What it gates | Typical use |
|---|---|---|
aws-marketplace:ProductId | Which models aws-marketplace:Subscribe may enable | Let platform teams enable only approved Claude models account-wide |
bedrock:BearerTokenType | What kind of bearer token may authenticate | Deny bedrock:CallWithBearerToken unless the token is short-term |
aws:RequestedRegion | Which regions requests may target | Region pinning; must allow "unspecified" for global inference profiles |
Each solves a problem resource ARNs can't. Subscription control happens before any model resource exists, so it needs the Marketplace product condition. Bearer tokens — the least-preferred auth path for Claude in Amazon Bedrock, minted with the aws-bedrock-token-generator and passed as x-api-key — are constrained by token type, not resource. And region conditions govern routing behavior: geographic inference profiles need all destination regions allowed, while global routing requires the special unspecified value, a subtlety covered in SCP controls.
Assembling a fine-grained policy
A production-grade grant for one workload typically stacks three layers: an allow on the narrow inference actions (bedrock:InvokeModel*, or bedrock-mantle:CreateInference for the newer surface, which uses its own action namespace) scoped to approved model and profile ARNs; conditions for context (region stance, bearer-token restrictions where humans are involved); and organization-level SCPs above it all, so no account-local policy can widen the boundary. VPC endpoint policies can repeat the action scoping at the network layer — AWS documents endpoint policies allowing, for example, only bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on the runtime endpoint, or bedrock-mantle:CreateInference on the mantle endpoint.
Test the denies, not just the allows
Fine-grained policies fail quietly: a missing inference-profile ARN or an over-broad region condition surfaces as a generic access-denied error deep inside a workload. Before rollout, exercise both directions from a test role — confirm the approved Claude model responds and that an unapproved model ID is refused. CloudTrail records every Bedrock API call with the caller identity, giving you the evidence trail that the restrictions hold in practice.
Where to go next
Apply these patterns to compute identities in service role patterns, and to the organization boundary in SCPs for Bedrock. For the broader philosophy, see least-privilege IAM for Claude.