Gateway: Bedrock guardrail input tagging, and model checks that cover the whole request

What

These 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.

• 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.
• 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".
• 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.
• 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.

Why

Gateway 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.