{"version":"2.1.281","anchor":"gateway-bedrock-guardrail-header-block-and-per-user-assumed","canonical_anchor":"gateway-bedrock-guardrail-header-block-and-per-user-assumed","heading":"Gateway: Bedrock guardrail header block and per-user assumed role","tier":null,"area":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/gateway-bedrock-guardrail-header-block-and-per-user-assumed","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Gateway: Bedrock guardrail header block and per-user assumed role\n\nThe built-in gateway now refuses `amazon-bedrock-*` headers when a Bedrock guardrail applies, and can use a separate AWS role per user\n\n**What**\n\nClaude Code has an embedded gateway that passes requests on to Amazon Bedrock, Amazon's service for running models. A guardrail is a Bedrock rule set that filters what goes in and out. Two changes apply:\n\n- When a guardrail applies to a request to `\/v1\/messages`, any request header starting with `amazon-bedrock-` is refused with a 400 error. A header is an extra piece of information sent with a request.\n\n- The gateway can now take on a separate AWS role for each user (an \"assume-role\" client). If Bedrock answers with a 401 or 403 permission error, it gets fresh credentials for that client.\n\n**Why**\n\nBlocking those headers stops a request from changing or skipping the guardrail. Per-user roles let each person's requests run with their own permissions, and the refresh keeps expired credentials from causing repeated failures."}