Claude Code's gateway now layers every matching policy: what that means for LLM gateway security - Barndoor AI | Secure Access and Governance for AI and MCP

TL;DR: On October 31, 2026, Claude Code v2.1.316 changed how the Claude apps gateway applies policy: in layered mode, every policy that matches a developer applies, not only the first. It also added shared group budgets, prompt tagging for Amazon Bedrock guardrails, and a check on every model a request names. These are the right ideas for LLM gateway security, scoped to Claude Code. Your other models, agents and MCP servers need the same policy, in one place.

Key takeaways

First-match policy is a quiet risk: when only the first matching rule applies, a broad “allow” listed early can hide a stricter rule below it.
Layered policy fixes the order problem: every matching policy applies, so a restriction isn’t lost to a wider rule.
Budgets are a security control: a leaked key or runaway agent shows up as spend first.
Guardrails need correct wiring: Bedrock’s prompt attack filter needs tagged input.
One tool’s gateway covers one tool: policy, budgets and logs must span every model and agent.

What changed in Claude Code v2.1.316

Anthropic published Claude Code v2.1.316 on October 31, 2026. Four items change how the Claude apps gateway, the Claude Code LLM gateway, enforces policy.

Layered policies. The release adds managed.policy_mode: layered. In the release’s words, “every policy that matches a developer applies, each merged over the ones listed below it, not only the first.”
Pooled group budgets. A new pooled_budget setting on the spend limits admin API sets “one monthly budget that a group’s members share, on top of each member’s own limit.”
Guardrail input tagging. guardrail.input_tagging on Bedrock upstreams wraps prompts in the input tags that an Amazon Bedrock guardrail’s prompt attacks filter needs. The all_messages_and_system option also tags the system prompt.
A model check fix. The gateway now checks every model a request names against availableModels, deniedModels and models. A request that names a blocked model gets a 400 naming the field. Before the fix, a request naming more than one model could get past the check.

What is LLM gateway security?

Definition: LLM gateway security is the set of controls an LLM gateway enforces on every request: who can call which model, how much they can spend, what data and prompts can pass, and a record of all of it. Security is set once, centrally, instead of inside each app.

An LLM gateway sits between your people, apps and agents and the model providers. An MCP gateway does the same for agent tool calls to MCP servers. Agents need both.

Why first-match policy is a security gap

Picture two rules. Rule one: “All engineers: allow every approved model.” Rule two: “Contractors: deny model X.” A contractor in the engineering group matches rule one first, so gets model X. No policy allowed it. The order did.

How first-match policies fail

The broad rule wins: general rules tend to sit near the top, so they match first and specific restrictions below them never run.
Order becomes security-critical: moving one rule changes who can do what, and looks harmless in review.
Edits break it quietly: a new rule in the wrong place overrides every exception below it, with no error.

How layered policies should combine

Layered policy evaluates every matching rule and combines them, typically organization, then group, team and user. Additive settings, such as allowed tools, merge; a narrower scope can tighten a broader one. Decide up front what a deny does: usually an explicit deny at any level should win, so membership in a second group can’t undo a restriction. Test the combined result per person, not rule by rule.

Check every model a request names

The v2.1.316 fix is a real bypass a gateway has to close. If a request can name several models and the gateway checks only some, the allow list has a hole. A secure LLM gateway inspects the whole request, rejects it if any named model is blocked, and says why.

Budgets are a security control too

Spend is often the first sign of trouble. A leaked key, a looping agent or a retrying script all show up as a jump in tokens.

Two limits work together. Each person or agent gets their own limit, so one runaway job is capped. A shared group budget, like pooled_budget, caps the team, so twenty people each under their own limit can’t push the group past its monthly total. That’s what rate limiting in an LLM gateway should do for security: stop damage, not just smooth traffic.

An LLM gateway with cost tracking shows spend by user, team, agent and model, so a spike points to a cause, not an invoice surprise.

Guardrails only work if the gateway feeds them correctly

The guardrail.input_tagging item looks small, but it carries a lesson. According to the Amazon Bedrock Guardrails documentation, content outside input tags isn’t processed by guardrails, and the prompt attack filters require input tags to be present. If nothing tags the prompt, that filter has nothing to inspect.

A guardrail you didn’t wire up isn’t running. For each provider and guardrail, confirm what input it needs and whether your gateway supplies it, system prompt included.

Data protection follows the same rule: sensitive data must be caught in the request path, the job of an LLM gateway with data loss prevention. An LLM gateway proxy doing PII filtering for compliance belongs in that same inline step.

Claude apps gateway vs. a company-wide LLM gateway

Here is how one tool’s gateway compares with what a company-wide LLM gateway needs.

Control	What Claude apps gateway v2.1.316 does	What a company-wide LLM gateway needs	Why it matters for security
Policy combination	`managed.policy_mode: layered` applies every matching policy	Combined policy across org, group, team and user for every tool	A broad rule can’t hide a restriction
Model allow/deny	Checks every model a request names; 400 on a blocked one	The same check for every provider and model	Closes multi-model bypasses
Budgets	Individual limits plus `pooled_budget` per group	Individual and group budgets with hard limits, by user, team, agent and model	Caps leaked keys and runaway agents
Guardrails and DLP	Tags prompts for Bedrock’s prompt attack filter	Inline DLP and correctly fed guardrails on every provider	Unwired guardrails don’t run
Providers covered	Claude Code traffic, including Bedrock upstreams	OpenAI, Anthropic, Google and others, self-hosted models included	Policy shouldn’t stop at one vendor
Agents and MCP servers	Not covered by this release	Agents and MCP tool calls under the same policy	Agents act, not just answer
Audit trail	Not covered by this release	Every request and the policy that governed it, sent to the SIEM	Security can answer “who used what”
Keys	Not covered by this release	Real provider keys vaulted, virtual keys issued	A leaked key can be revoked in one place

The gap: policy that’s limited to one vendor

Developers use Claude Code, but also Cursor, ChatGPT and Gemini, internal apps calling OpenAI or Bedrock models, and agents connected to MCP servers. A gateway per tool means separate policy sets, budgets and logs. A contractor restriction in one is missing from the next; a group budget in one tool ignores spend in another.

Then security asks: who used which model, with what data, last Tuesday? With per-tool gateways, no single place can answer. Model-only gateways share the limit; Cloudflare AI Gateway, for example, covers model traffic, not agent actions on MCP servers. An LLM security gateway should apply the same policy to every model and agent, across providers, in one place.

An LLM gateway security checklist

Policy combination: you know whether your gateway uses first-match or layered policy, and you’ve tested the combined result for real users.
Every model checked: a request naming any blocked model is rejected, not only the first model in it.
Deny wins: an explicit deny can’t be undone by membership in another group.
Budgets with hard limits: per user, agent and group.
Guardrails and DLP inline: running on every provider, and fed the input they need.
Keys vaulted: real provider keys stay in the gateway; people and agents get virtual keys.
Audit trail to the SIEM: every request and the policy that applied.
Agents have their own record: no agent runs on a shared human key.

How Barndoor applies one policy set to every model and agent

Barndoor is the AI Gateway for enterprises. Barndoor LLM Gateway governs model traffic and Barndoor MCP Governance governs agent tool calls, under one policy set.

Combined policy: when more than one policy matches, such as organization, group and user, Barndoor applies all of them, not only the first.
Least-privilege access: scope access from the user, role, group and MCP server down to the individual tool, model, data point and action.
People and agents: people are scoped from your existing IdP roles, and every agent gets its own AgentProfile, a unique record of what it may do.
Runtime enforcement: policy is enforced on every request, and unauthorized actions are stopped before they execute.
Budgets: see spend by user, team, agent and model, set hard limits and budgets, and give a group a shared budget on top of each member’s own limit.
Barndoor data protection: sensitive data is redacted, tokenized or blocked inline.
Keys: real provider keys stay in the Barndoor vault; developers, agents and AI apps get virtual keys.
Audit: a complete audit trail of every AI and agent action and the policy that governed it, streamed to your SIEM.
Catalog: a governed catalog of every model and MCP server, with 100+ pre-built MCP servers.

Definition of AgentProfile: Barndoor’s unified record binding an agent’s identity, credentials, MCP tool access, and LLM spend into a single, policy-enforced profile.

Developers can send Claude Code traffic through LLM Gateway, so the same policy, budgets and audit trail cover it and every other model you use. That’s the point of an enterprise LLM gateway: one place to set policy and prove it.

LLM gateway security: FAQs

What is LLM gateway security?

The controls an LLM gateway enforces on every model request: who can call which model, spending limits, what data and prompts can pass, and an audit record, set centrally instead of in each app.

What changed in the Claude apps gateway in Claude Code v2.1.316?

Released October 31, 2026, it added managed.policy_mode: layered (every matching policy applies), pooled_budget (a shared monthly group budget), guardrail.input_tagging for Bedrock guardrails, and a check of every model a request names.

What is the difference between first-match and layered policies?

With first-match, the gateway stops at the first rule that matches, so rule order decides access and a broad rule can hide a stricter one. With layered policy, every matching rule applies and the results are combined, so a group or user restriction still takes effect.

Is Claude Code’s gateway enough to secure LLM use across a company?

It secures Claude Code traffic, and v2.1.316 makes it stronger. Most companies also use other AI tools, providers, agents and MCP servers, which need the same policy, budgets and audit trail.

What is the difference between an MCP gateway and an LLM gateway?

An LLM gateway governs requests to models: access, spend, data and logging. An MCP gateway governs what agents do through MCP servers, such as reading a CRM record or opening a ticket. Agents use both, so AI gateway security needs policy on both paths.

How do budgets and rate limits in an LLM gateway improve security?

They cap the damage from a leaked key, a looping agent or a bad script. Per-user and per-agent limits stop one source; a shared group budget stops many small ones adding up. Cost tracking shows where a spike came from.

Does an LLM gateway stop prompt injection?

Only if a guardrail that detects prompt attacks runs in the request path and gets the input it needs. Amazon Bedrock’s prompt attack filter, for example, needs tagged input. Without that, the gateway won’t stop prompt injection.

What should an LLM gateway log for an audit?

Who made the request (person or agent), which model and provider, when, tokens and cost, whether data protection changed anything, the result, and which policy applied. Send it to your SIEM.