Enterprise gateway (pilot)

The AgentShield hook checks each action on the machine where it runs. Some companies also want a control point they own: one that does not depend on what is installed on each laptop.

In the enterprise gateway deployment, Shield sits between your coding agents and the model provider. When the model answers with tool calls ("run this command", "edit this file"), the gateway holds the response and asks Shield about every tool call. Only if all of them are approved does the agent receive the response. Otherwise it gets an error that names the rule, and no tool call is delivered.

Pilot, available to design partners

Our lab tests run real Claude Code (2.1.296) through a reference deployment of each option below. The model provider in those tests is a mock of the Anthropic Messages API. Connecting to the live provider is the first step of a pilot, together with your own policy. We re-ran 182 automated checks across four lab setups and the gateway components on 14 October 2026. Every result on these pages comes from those runs.

Zoomable version: open the interactive gateway architecture.

Two ways to put Shield on the path

	LLM gateway guardrail	Network inspection
How agents reach it	Each agent's API base URL points at your LLM gateway	Your VPN routes provider traffic to a company gateway; agents only need to trust its inspection certificate
What you run	An LLM gateway with the Shield guardrail, and a Shield server	A VPN, a firewall, a TLS inspection proxy and a Shield server on a gateway host
Reference deployment we tested	LiteLLM 1.105.0	WireGuard, an iptables firewall and mitmproxy 12.2.3 on a Linux gateway host (containers in our lab)
Who the record names	The gateway user behind the key	The enrolled user and device, taken from the device's VPN credential
Changing the agent's API URL	Takes that agent off the gateway	Another hostname on Anthropic's address is inspected or refused. In the daily-use design, Anthropic's named websites are the exception: they pass through, on the assumption that they do not serve the API. A relay outside Anthropic's addresses is refused in the full-tunnel design, and goes direct in the daily-use design (see browsing)
Best for	Teams that already run, or want, an LLM gateway	Teams that want enforcement without a gateway URL in each agent

Reference deployments, not the only way

Each option is a design with a short list of requirements, not a choice of product. The gateway, VPN or inspection proxy your company already runs may meet them. For each option we built one reference deployment, listed in the table above, and every result on these pages comes from it.

Another component fits if it meets the requirements on the option's page: what a gateway needs and what the VPN and proxy need. The stream parser, the tool-call mapping and the release rule are shared code. Connecting another gateway or proxy takes an adapter that does the rest for its hooks, and another VPN needs a way to tell the gateway which device holds which address. Building that and re-running these checks against your components is part of a pilot.

Which agents it covers

The gateway checks what the model proposes, on the wire, so the design does not depend on which agent sent the request. Claude Code, on Anthropic's API, is the agent we tested through both options; no other agent is tested yet. Another agent fits the same design once the things below hold for it, and adding one is part of a pilot.

• Its model calls reach a provider API the gateway can inspect. Some agents send their model calls through their vendor's own service rather than to a model provider. The gateway never sees their tool calls.
• The gateway reads its provider's API format and transport. Today the gateway reads the Anthropic Messages API, as ordinary HTTP responses it can hold whole. An agent on another provider's API, such as Codex on OpenAI's, needs a parser for that format. A connection that carries many messages, such as a WebSocket, is not a single response the gateway can hold. On the LLM gateway guardrail, the route that serves the new format must also meet the six gateway properties.
• Its shell tool is mapped to Shield's command checks. The gateway checks a tool named Bash, Claude Code's shell tool, as a shell command. It checks every other tool by its name and arguments. Another agent's shell tool, such as Gemini CLI's run_shell_command, needs its own mapping. Without one, its commands get only the checks for a generic tool. Its other tools are checked by name and arguments, and rules written for Claude Code's tool and argument names may not match another agent's, so a pilot checks its file tools too.
• For network inspection, its provider's traffic reaches the gateway, and the agent trusts the gateway's certificate.

  • Destinations: the proxy's approved hostnames and endpoints are extended to that provider's API. Today they are api.anthropic.com, POST /v1/messages and its token count.

  • Certificate: the agent needs a way to load the inspection certificate. An agent that pins its certificates cannot be inspected.

  • Routing: the daily-use design routes by address. That works for Anthropic because Anthropic's API addresses are in a block registered to Anthropic, so routing them pulls in no unrelated site (see browsing). Other providers differ, as measured on 15 October 2026:

    • The OpenAI endpoints Codex uses, api.openai.com and chatgpt.com, resolved to addresses on Cloudflare's network.
    • Gemini's API resolved to Google's shared front ends, the same addresses as other Google APIs.

    For providers like these, a pilot uses the full tunnel, or another way to send only the agent's traffic to the gateway.

• Its records and errors fit it. The pilot labels every guardrail record as Claude Code, and network inspection recognises only Claude Code from the User-Agent. A block reaches the agent as an HTTP 400, chosen for how Claude Code reports errors. Adding an agent includes its label, and checking how it shows and retries that error.

Until an agent has been added, the AgentShield hook is how Shield covers it, where the hook supports that agent. The hook runs in Codex, Gemini CLI and other agents; in Codex and Gemini CLI it checks shell commands only.

What the gateway guarantees

These hold in the default mode, enforce; observe mode is the opt-in alternative. Both options implement the same rule. On the LLM gateway guardrail (LiteLLM), every case below has an automated check except the 5-second timeout. On network inspection, the lab covers a block, a blocked call among several, a Shield outage and an injected proxy error, and unit tests of the proxy cover the other cases except the timeout. Each option's page lists its checks.

• Nothing is released early. The gateway holds the provider's entire response, streamed or not, until Shield has answered for every tool call in it. No part of the response reaches the agent while Shield is deciding.
• A block withholds the whole response. If any tool call is blocked or needs approval, the agent gets an HTTP 400 that names the rule, and none of the calls run. If a response proposes two calls and one is blocked, neither runs.
• It fails closed. If Shield cannot be reached, reports a degraded ruleset, or is not in enforce mode, a response that contains a tool call is withheld. A response with only text has nothing to check and is released. Each step of a Shield call (connect, send, read) has a 5-second timeout. A malformed, truncated or oversized response is also withheld, and so is one that contains a tool the provider runs itself.
• It enforces the same policy as the hook. Shell commands go through Shield's analyzer pipeline. Every other tool the agent declares, such as Read, Write, Edit or an MCP tool, goes through MCP policy with its name and arguments. That is the split the AgentShield hook for Claude Code uses, so the gateway has the hook's coverage, including its gaps. Managed-mode protections for AgentShield's own files on a laptop are hook-only.

Start in observe mode

New AgentShield installs start in audit-only, and the gateway can start the same way. Set SHIELD_GATEWAY_MODE=observe on the gateway, and run the Shield server with --mode audit-only.

• Every response is released. Shield still evaluates each tool call. What it would have blocked is recorded as AUDIT, with the rule and the original decision BLOCK, so you see what enforcing would have stopped before you turn it on. Access controls still apply: gateway keys, approved destinations and VPN enrollment refuse exactly as in enforce mode.
• What the gateway cannot inspect is released and logged. Examples are a Shield outage or a malformed response. The gateway logs each one as unevaluated, so a gap in the record is visible.
• A block Shield returns still stands. Whatever mode the Shield server reports, a call it returns as blocked or needing approval is withheld. Observe never releases a call that Shield returned as blocked. One known case: in the pilot's Shield server, value-limit rules (spending caps on payment tools, for example) still return a block in audit-only mode. That is a Shield bug being fixed, and until then those calls are withheld in observe mode too.

Only the exact value observe turns this on. Anything else, including a typo, enforces. To move to enforcement, remove the setting and run Shield with --mode enforce.

Tested on the LiteLLM reference deployment with real Claude Code. A would-be block is released and recorded as one, and Claude Code runs it. With Shield stopped, the response is released and logged as unevaluated. On network inspection, observe mode is covered by unit tests of the proxy; the network lab runs in enforce mode.

What it does not do

• It checks proposed actions, not executed ones. The gateway sees the tool call the model proposed. It does not see what the agent finally runs, or the working directory it runs in. Keep the AgentShield hook on laptops for execution-time evidence. The two together are defence in depth.
• Tools the provider runs itself are not available. Web search runs at the provider before the response reaches the gateway. The gateway cannot gate it, so it withholds responses that contain it, and an agent's provider-run web search fails behind the gateway in the pilot.
• Responses are not streamed to the agent. Text and tool calls arrive together, once Shield has answered, so long answers appear all at once.
• The tested agent is Claude Code, on the Anthropic Messages API. Another agent or provider needs the additions in which agents it covers, and is not tested yet.
• Requests are not inspected. Checks apply to what comes back from the model. Prompts and files sent to the provider pass through unchanged.
• Records stay on the gateway, best effort. Shield writes its decisions to a hash-chained audit log on the gateway. In the pilot that write is best-effort: if the log cannot be written, Shield still answers, so monitor it. Durable delivery, and sending records to AI Agent Lens Cloud, are not part of the pilot yet.

Next

• LLM gateway guardrail: what a gateway needs, the LiteLLM set-up, what developers see, and what we tested.
• Network inspection: what the VPN and proxy need, how identity is attributed, and what changes for browsing.