{"version":"2.1.315","anchor":"bedrock-guardrail-gets-input-tagging-option","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":"Bedrock","scope":"org","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.315\/e\/bedrock-guardrail-gets-input-tagging-option","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.** Which values `input_tagging` accepts is not stated.\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: Bedrock\n- Names: `input_tagging`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 2\/5\n- Scope: org\n- Heads-up: yes"}