The Anthropic API and inline LLM security
The Anthropic SDKs document a base_url option and an ANTHROPIC_BASE_URL variable — the cleanest attachment point there is, and what still gets past it.
If your application calls the Anthropic Messages API through an official SDK, the attachment point for an inline security layer is a documented client option and an environment variable. That is about as low-friction as this gets — which makes it worth spending the rest of the page on the parts that are not frictionless: what routes around the setting, what the retry and timeout defaults do to a gateway, and how to keep a request traceable across the hop.
We publish no tested-compatibility claim for the Anthropic API. Our own tested support belongs in the supported models and frameworks matrix, which is not filled in yet. Everything below is either documented by Anthropic and linked, or follows from where a control sits.
The documented attachment point
The Anthropic Python SDK documents a base_url client option alongside a http_client override, with the environment variable named in the sample itself:
import httpx
from anthropic import Anthropic, DefaultHttpxClient
client = Anthropic(
# Or use the `ANTHROPIC_BASE_URL` env var
base_url="http://my.test.server.example.com:8083",
http_client=DefaultHttpxClient(
proxy="http://my.test.proxy.example.com",
transport=httpx.HTTPTransport(local_address="0.0.0.0"),
),
)Two things follow that are useful operationally. First, ANTHROPIC_BASE_URL means the redirection can be made at deployment time, as configuration, without touching application code — which matters when the services you need to cover are owned by teams you do not manage. Second, the same SDK family is published for Python, TypeScript, C#, Go, Java, PHP and Ruby, so one gateway can serve a polyglot estate rather than needing a per-language shim.
Anthropic also publishes distinct clients for the platform routes — AnthropicVertex, AnthropicBedrock, AnthropicBedrockMantle, AnthropicAWS and AnthropicFoundry. Those go to a different endpoint, so a base URL set for the direct API does not cover them; see Amazon Bedrock and Vertex AI for where a control attaches on each of those paths.
Source: Anthropic Python SDK documentation, read 13 August 2026. Options move; check it before you build.
What still gets past it
A base URL is a per-client setting, and nothing in the language enforces that every client in your estate is constructed with it. The gaps, in the order they usually appear:
- Clients constructed elsewhere. A background worker, a notebook, a small service someone added, a vendored copy of an example from the docs. Set
ANTHROPIC_BASE_URLin the environment rather than in code where you can, and then enforce it at the network: allow egress to the model API only from the gateway, so a misconfigured client fails loudly instead of silently skipping the control. - Non-model traffic. Retrieval, tool execution and index writes never touch the Messages API. Authorisation for those is enforced at the retriever and at the tool — RAG security and AI agent security explain why an inline layer cannot stand in for either.
- Anything the SDK is not carrying. A control on the request path sees the request. It does not see what your application did with the response afterwards.
Operational details a gateway has to get right
These are the ones that produce confusing incidents six weeks in, and all of them are documented SDK behaviour rather than guesswork.
Retries. The SDK retries certain errors twice by default with exponential backoff, including connection errors, 408, 409, 429 and 5xx. A gateway that returns 5xx when it cannot make a decision will therefore be retried automatically, tripling the load on a layer that is already struggling. Decide what status code a policy block returns and make sure it is not in the auto-retry set — a block is a decision, not a transient failure, and it should not be retried at all.
Timeouts. The documented default is ten minutes, and the SDK raises if a non-streaming request is expected to exceed roughly that without streaming. A gateway sitting in that path needs its own timeout to be shorter and deliberate, and the behaviour on hitting it needs to be the failure mode you chose rather than the one you inherited — see what happens when the layer is unavailable.
Streaming. The SDK supports server-sent events, and a gateway must decide whether to buffer a streamed response before releasing it or to inspect it incrementally. This is the single most consequential design decision on the list; the trade-off is set out in latency and performance.
API version header. The SDK sends an anthropic-version header automatically and warns that overriding it may produce undefined behaviour. A gateway should pass it through untouched rather than normalising it.
Traceability. Responses expose a _request_id taken from the request-id response header. Log it on the gateway side against your own correlation id. When you need to reconstruct what happened, being able to line up your policy decision with the provider's record of the same call is the difference between an investigation and a guess.
What this buys you beyond detection
Worth stating because it often carries the decision on its own: when the gateway holds the credentials, the application never does. Key rotation becomes one change in one place, a compromised service cannot exfiltrate a usable API key, and per-team usage is attributable at the gateway rather than reconstructed from a single shared account. That is true whether the gateway is ours, someone else's, or fifty lines you wrote yourself — see build versus buy, which is honest about when the last option is right.
What to ask us before you commit
- Do you support a base-URL gateway in front of the Messages API today, and does that include the Bedrock and Vertex client routes?
- What status code does a policy block return, and is it outside the SDK's auto-retry set?
- How are streaming responses handled?
- Is the
request-idcorrelated in your logs, and what is retained?
Evaluation and security review has the rest of the list.