Does the gateway support the Anthropic SDK's defaults?

The Anthropic SDK reads the base_url from configuration. Pointing it at the gateway URL changes the destination without changing any other line of code. The SDK's streaming, batching, and tool-use behaviors all work over the gateway.

How does the gateway handle prompt caching cost optimization?

Prompt caching at the Anthropic level continues to work over the gateway. Anthropic's cache identifier is based on the prefix content. The gateway forwards the prefix unchanged, so the cache hit rate stays the same as it would be in a direct connection. The gateway adds its own classification cache on the prefix to avoid re-classifying the same prefix on every request.

What happens to existing Anthropic rate-limit headers?

Anthropic returns rate-limit information in response headers. The gateway forwards those headers to the caller unchanged, so the application's rate-limit handling remains valid. The gateway can apply its own per-user or per-route limits on top, which the application's rate-limit handling can be made aware of via custom headers.

Can the gateway run policy on Claude's reasoning content?

The Anthropic API returns reasoning content as part of the response in models that emit it. The gateway treats reasoning content as response content for classification and policy purposes. Policy can permit, redact, or block reasoning content the same way it does for the user-facing response text.

Does the gateway work with the Anthropic vision capability?

The /v1/messages endpoint accepts image content blocks alongside text. The gateway extracts image bytes, runs a vision-capable classifier against them, and the policy evaluates the resulting labels alongside the text-side classification. The vision classifier is a deployer-chosen component; the gateway accommodates a deployer-supplied classifier or a default one.

Anthropic API Gateway: Identity, Policy, and Claude API Evidence

An Anthropic API gateway sits in the HTTP path before the Claude Messages API. It gives each routed request an identity-aware policy decision and a per-decision audit record, covering the prompt, model destination, active policy, and result. The request path starts with an authenticated user or agent, continues through the application, and ends at api.anthropic.com; changing the application's base_url sends that Claude API traffic through the gateway.

I want to walk through the inspection points across each Anthropic API surface, how identity attaches on top of static Anthropic API keys, and how policy enforces against Claude-specific patterns like prompt caching and computer-use tool calls.

TL;DR

An Anthropic API gateway governs Claude API traffic that an application deliberately routes through it. It can record the verified caller, policy version, model destination, and outcome for each request, while tool endpoints retain authorization responsibility for actions after the model response.

What the gateway intercepts

The gateway intercepts the HTTP request body, the headers, the streamed response, and any file uploads referenced by the request.

The Anthropic /v1/messages request body contains the messages array (the user and assistant turns), the system prompt block, the tools array (for tool use), and image content blocks the user attached. Prompt-level classification runs against the text content of the user turns and the system block. The image content blocks are extracted and classified through the vision-capable classifier, if the deployer has one configured.

The headers carry the Anthropic API credential (x-api-key), the API version (anthropic-version), and any custom identity-bearing headers the application supplies. The gateway extracts the identity context from the application-supplied header, evaluates policy against it, and attaches the corporate identity to the per-decision record.

The response stream is the model's output, delivered as a sequence of message_delta and content_block_delta events. The gateway runs response-side classification against the streamed content and can block or redact specific blocks before they flow to the caller.

How Anthropic's API surfaces map to inspection points

The Anthropic API has three request surfaces that change the evidence a gateway should record.

The first is the /v1/messages endpoint, Anthropic's primary completion surface. Each request is stateless: the application sends the full conversation history every call. Inspection runs against the full payload in one pass.

The second is the batch API (/v1/messages/batches). Batch requests submit many message payloads for asynchronous completion. The gateway inspects each batch item at submission time, applies policy per item, and writes the per-decision record for each. The asynchronous completion fires back through the same gateway URL, so the response side gets inspected on completion.

The third is the computer-use beta. The computer-use tool gives Claude an interactive surface that takes actions on a virtual computer (clicks, keystrokes, screenshots). The gateway treats the tool calls as part of the inspection scope: each computer_use tool invocation in the response is evaluated against policy. The policy can deny specific action categories (e.g. visit a specific URL, type credentials, take a screenshot of a sensitive screen).

How identity context attaches at the gateway

The Anthropic API credential authenticates the application to Anthropic. That credential does not authenticate the natural person or agent on whose behalf the application is calling Claude.

The gateway closes the gap the same way it does for any LLM provider. The Anthropic API credential is held by the gateway, not passed through from the application. The application authenticates to the gateway with the corporate identity (SSO session, agent identity, role). The gateway authenticates to Anthropic with the team's credential. The decision record carries the corporate identity. Anthropic billing reflects the team-level credential.

The split satisfies NIST AI agent identity Pillar 1 (verified identity travels with the request) without changing the Anthropic billing structure.

Prompt caching and the inspection model

Anthropic's prompt-caching feature reuses a cached prefix across multiple requests. The cached prefix is a portion of the system prompt or the user history that the application marks for caching via the cache_control field.

Inspection of cached prefixes runs once at cache creation and recurs on prefix invalidation. The gateway records the cached prefix's classification labels and reuses them on subsequent requests that hit the same cache. The record per decision still fires on every individual request, even when the prefix is cached: the cached prefix is part of the request context the decision was made against, and the record links to the cache entry.

This matters because the cached prefix can contain regulated content. If a cached system prompt includes customer-specific data or internal documentation, the cache entry inherits the same classification the live request would have produced. The gateway treats the cache entry as policy-evaluated content for the lifetime of the cache.

Computer-use tool policy

The computer-use tool gives Claude action capabilities outside the conversation. Each action Claude takes is a tool_use block in the response with parameters describing the action: a coordinate, an input sequence, a URL, or a screenshot request.

Policy at the gateway can evaluate each emitted action against a named rule and policy version. A credential-typing rule can inspect a computer input action for secret patterns and block the response block before it reaches the application.

A destination rule can inspect typed URL text against a deny list and block the matching response block. A screenshot rule can classify a requested screenshot for secrets and redact the screenshot bytes when the policy requires it.

The policy fires on the response side because the tool-use blocks are emitted by Claude as part of the response stream. The gateway buffers the block, runs policy against it, and either permits, redacts, or blocks before the block reaches the application that initiated the call. The tool endpoint still needs its own authorization decision before it executes a permitted call; the gateway's evidence covers the routed LLM request and response, not local execution.

Deployment trade-offs

The deployment patterns for the Anthropic gateway mirror the OpenAI gateway shapes: SaaS-hosted, VPC-isolated, sidecar.

The Anthropic-specific consideration is the streaming-response path. Anthropic's SSE event stream emits content blocks at high frequency, and the gateway needs low overhead on each event to avoid degrading the perceived response latency. The VPC-isolated deployment usually sits one network hop away from the application, which keeps the streaming overhead in the low-millisecond range.

The computer-use beta drives the sidecar pattern for some deployers. The buffering and classification work on screenshots is heavier than text inspection, and a sidecar shape keeps the work close to the calling application's compute budget.

Performance characteristics

Enforcement overhead on text completions measures under 50 ms per request in production tests on internal DeepInspect benchmarks. Streaming-response overhead adds milliseconds per event, dominated by the classifier inference cost on each emitted content block.

The end-to-end perception by the user matches the cached-prefix case from Anthropic's own performance documentation: the model dominates the timing, the gateway adds a small constant overhead, and the cache-hit cases shave the prompt-encode time off the critical path on both sides.

DeepInspect

This is the Anthropic API gateway DeepInspect was built to provide. DeepInspect sits inline between authenticated users or agents and any Anthropic endpoint. Every /v1/messages call, every batch submission, every computer-use action, and every streamed content block passes through one inspection point. Identity attaches at the request layer. Prompt and response classification fire at the boundary. Policy decides per request. The signed per-decision record commits before the response returns to the application.

The same AI gateway architecture can sit in front of OpenAI, Azure OpenAI, Bedrock, Vertex, and self-hosted endpoints. Streaming responses through an AI gateway need the same request correlation and policy record. Anthropic is one entry point among several.

Book a demo today.