{"version":"2.1.315","anchor":"gateway-validates-the-model-against-role-allowdeny-lists-up","canonical_anchor":"bedrock-guardrail-gets-input-tagging-option","heading":"Gateway: Bedrock guardrail input tagging, and model checks that cover the whole request","tier":"use","area":"Gateways","scope":"org","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.315\/e\/gateway-validates-the-model-against-role-allowdeny-lists-up","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.315","markdown":"### Gateway: Bedrock guardrail input tagging, and model checks that cover the whole request\n\nThe bundled gateway supports input_tagging for Bedrock guardrails, requires it to match across upstreams, and checks every model named in a request\n\n**Unclear.** It is not clear whether this gateway code runs for ordinary Claude Code users or only on gateway servers.\n\n**What**\n\nThese changes are in the inference gateway bundled with Claude Code, a proxy that routes model requests to providers such as Amazon Bedrock. A guardrail is a content filter that Bedrock applies to requests, and an upstream is one of the provider back ends the gateway forwards to.\n\n- The Bedrock `guardrail` setting, which already took `id` and `version`, gains an optional `input_tagging` field. It is passed to the Bedrock client as `inputTagging`.\n\n- When a request goes to a Bedrock upstream that uses input tagging, the gateway rewrites the request first. If that rewrite fails, the request is refused with a 400 error: \"the request could not be prepared for the guardrail this gateway applies to Bedrock requests, so it was not sent\".\n\n- Configuration checks now require the same `guardrail.input_tagging` value on every Bedrock upstream, with the message \"set the same guardrail.input_tagging on all bedrock upstreams\". The reason given is that failover could send a request to an upstream that tags it differently. Before, the only check was that a guardrail was set on all Bedrock upstreams or none.\n\n- The check of the requested model against a role's `availableModels` and `deniedModels` now runs through one shared check, and it also covers model values nested inside the request body, not only the top-level model. Before, only the top-level model was checked, with separate messages for denied and not-allowed models.\n\n**Why**\n\nGateway operators can use Bedrock guardrail input tagging and get stricter enforcement of which models each role may use. Watch for configurations that loaded before with mixed `input_tagging` values across Bedrock upstreams: they now fail validation.\n\n- Area: Gateways\n- Names: `availableModels`, `deniedModels`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 2\/5\n- Scope: org\n- Heads-up: yes"}