Bedrock guardrails in the Claude apps gateway: set input_tagging

Amazon Bedrock's documentation says its prompt attacks filter needs input wrapped in guardrail tags, and by default the Claude apps gateway adds none. Before Claude Code 2.1.316, it had no setting to add them. If your developers reach Claude on Bedrock through the gateway and you attached a guardrail expecting it to catch jailbreaks and prompt injection, that filter has not been running on gateway traffic. Version 2.1.316 adds guardrail.input_tagging, which tags prompts so the filter can run. The decision now is which of its four values to set.

BaristaLabs recommendation: start with user_messages, the value the gateway docs use in their example. The gateway docs say to try input_tagging on a test gateway first, because once tags are present every filter in the guardrail evaluates only tagged text.

What changed in Claude Code 2.1.316?

The Claude Code changelog entry for 2.1.316 reads: "Added guardrail.input_tagging on Claude apps gateway Bedrock upstreams, which wraps prompts in the input tags that an Amazon Bedrock guardrail's prompt attacks filter needs; all_messages_and_system also tags the system prompt."

The Claude apps gateway is Anthropic's self-hosted service that sits between developers' Claude clients (Claude Code and Claude Desktop) and your model provider. It has been able to attach a Bedrock guardrail to each Bedrock upstream since v2.1.281, through a guardrail block with an ID and version. The gateway configuration docs list the rules that come with that block:

• Every Bedrock upstream or none. The gateway refuses to start on a mix, because failover could send a request to a Bedrock upstream without a guardrail.
• Bedrock only. Requests to another provider in upstreams go out without the guardrail, and the gateway refuses to start if that provider is mantle.
• IAM. The principal that signs the upstream's requests needs bedrock:ApplyGuardrail on the guardrail.
• No client overrides. A /v1/messages request whose body carries an amazon-bedrock-* field, such as amazon-bedrock-guardrailConfig, gets a 400 instead of being forwarded.

The new input_tagging key needs Claude Code v2.1.316 or later on the gateway server, and every Bedrock upstream must have the same value, or the gateway refuses to start. An older gateway exits at startup with Unrecognized key(s) in object: 'input_tagging'.

Why doesn't the prompt attacks filter run by default?

On the InvokeModel and InvokeModelWithResponseStream APIs, Bedrock guardrails let callers mark which parts of a prompt to evaluate with tags such as <amazon-bedrock-guardrails-guardContent_xyz>, where xyz is a suffix the caller supplies in tagSuffix. According to Amazon Bedrock's input tag documentation, a prompt with no tags is processed in full by the guardrail, with one exception: the prompt attacks filters, which "require input tags to be present." The prompt attacks page says to always use input tags with the InvokeModel and InvokeModelWithResponseStream APIs, and adds: "If there are no tags, prompt attacks for those use cases will not be filtered."

The gateway docs say so too: "By default the gateway adds no input tags to prompts, so a guardrail filter that Amazon Bedrock applies only to tagged input doesn't run on traffic through the gateway."

Tags also narrow what the guardrail sees. Citing Amazon's documentation, the gateway docs warn that "every filter in the guardrail stops evaluating untagged content once a request carries input tags." Turning on tags so the prompt attacks filter runs also narrows what your content, denied-topic and word filters see.

Which input_tagging value should you set?

The four values differ in what gets tagged and in what happens after the guardrail blocks a prompt. This table restates the gateway docs:

Scroll sideways to see all 3 columns.

input_tagging	What the gateway tags	After a block
last_message	user messages since Claude's last reply	In Claude Code, the next prompt can pass, and Claude then receives the blocked prompt as part of the conversation
user_messages	All user messages	Later prompts in the session can be blocked too, until the developer removes the blocked prompt
all_messages	user and assistant messages	Same as user_messages
all_messages_and_system	The system prompt and every message, including mid-conversation system messages	Same as user_messages

The docs add that with last_message, a tool call counts as a reply, and if the user messages since Claude's last reply hold no text to tag, the gateway tags the mid-conversation system messages since that reply instead.

BaristaLabs interpretation: the "after a block" column decides it. With last_message, the docs say a prompt the guardrail blocked once can reach Claude anyway on the next turn. The docs don't say why, though last_message tags only text since Claude's last reply. That makes last_message a weak block: sending another prompt can be enough to get the blocked text to Claude. user_messages tags every user message, so the blocked text is screened again on each request until the developer removes it.

all_messages also tags Claude's own replies. The docs don't say how that changes block rates. BaristaLabs interpretation: a reply that quotes a suspicious file or web page could then trip the filter, so test it before you use it.

all_messages_and_system carries a documented risk. Amazon's guidance for the prompt attacks filter is to tag user input and exclude the system prompt, and the gateway docs warn that "a filter that flags Claude Code's own system prompt can block requests."

What the tags still don't cover

No value makes the guardrail evaluate the whole request. The gateway docs list what stays outside it:

• Untagged content: messages your value leaves out, tool definitions, tool call inputs, images and PDFs, among others. Unless you set all_messages_and_system, the system prompt is untagged too.
• Tool results: file contents, web pages and other output Claude's tools return. In Anthropic's testing, a word filter didn't evaluate them, with or without tags. Amazon's prompt attacks page says the filter "does not evaluate tool results."
• Deliberate evasion: "No input_tagging value stops a developer who deliberately puts text where no tag goes."

BaristaLabs interpretation: that leaves a real gap for indirect prompt injection. A malicious instruction inside a repository file or a fetched web page can arrive as a tool result, which the prompt attacks filter does not evaluate. Under user_messages, the guardrail screens text in user messages, including what developers type, but not what Claude Code reads through its tools. Defending against that takes controls on tools, permissions and what Claude Code can reach, covered in when Amazon Bedrock Guardrails should inspect boundaries instead of every chunk.

On model tokens and caching, Anthropic reports that in its testing "a tagged session kept its prompt cache reads from one prompt to the next, and the tags added no input tokens." If your AWS account or organization enforces a guardrail, check Amazon's enforced guardrails documentation for how that guardrail treats input tags.

How to turn it on without blocking your own developers

BaristaLabs recommendation: treat this as a guardrail change with its own test plan, not a one-line config edit.

1. Upgrade a test gateway to Claude Code 2.1.316 or later. Confirm that every Bedrock upstream already has a guardrail block and that the signing principal has bedrock:ApplyGuardrail.
2. Set input_tagging: user_messages on every Bedrock upstream and restart the gateway.
3. Run ordinary work through it. The docs note that user messages can hold text Claude Code adds, such as system reminders, so check that normal sessions aren't blocked. Include long sessions, pasted logs and code review prompts, not just short chat.
4. Run known-bad prompts from your red-team set to confirm the prompt attacks filter now fires, and check that a blocked prompt stays blocked on the next turn. To see which filter fired, set guardrail_trace: true on the upstream (v2.1.314 or later) and read the guardrail.trace events in the audit log.
5. Recheck your other filters. Every filter in the guardrail, including content, denied-topic and word filters, now evaluates only tagged input. If a policy depended on screening the system prompt or earlier assistant messages in the request, it no longer will under user_messages.
6. Write down what the guardrail doesn't cover (tool results, tool definitions, tool call inputs, images and PDFs, among others) next to the controls that do, then roll the setting out to the gateway developers use.

For testing method, testing AI guardrails on multi-turn traffic covers false positives and full conversations. For the rest of the gateway rollout (identity, spend and offboarding), see putting the Claude Code gateway in writing, and for spend controls in the same release, Claude apps gateway pooled budgets.

Sources and scope

• Claude Code changelog, 2.1.316, October 31, 2026 (also in the CHANGELOG on GitHub)
• Claude apps gateway configuration: Apply an Amazon Bedrock guardrail, accessed November 4, 2026
• Amazon Bedrock: Apply tags to user input to filter content, accessed November 2, 2026
• Amazon Bedrock: Detect prompt attacks with guardrails, accessed November 2, 2026

This post covers Claude apps gateway traffic to Amazon Bedrock upstreams only. The guardrail doesn't apply to other providers in the gateway's upstreams. Claims about cache reads, token counts and word filters on tool results come from Anthropic's own testing as reported in its docs, and the prompt attacks filter's handling of tool results comes from Amazon's documentation. BaristaLabs did not run a gateway for this post. Lines marked BaristaLabs interpretation or recommendation are ours, not the vendors'. For help setting up guardrails and agent controls for your teams, see AI consulting.