Skip to main content
  1. Articles/

Claude Apps Gateway: Anthropic Ships the Control Plane Enterprises Were Building Themselves

·1031 words·5 mins·
Author
Florent Clairambault
CTO & Software engineer

Claude Apps Gateway: Anthropic Ships the Control Plane Enterprises Were Building Themselves

Every large engineering org that has rolled out Claude Code has, at some point, built the same internal tool: a thin proxy in front of the API that handles SSO, enforces spend limits per team, and logs who used what model for how much. Anthropic just shipped that tool for you. The Claude apps gateway, launched June 29, is a self-hosted control plane for running Claude Code against Amazon Bedrock and Google Cloud with the governance layer enterprises actually need — and, notably, it doesn’t require sending anything through Anthropic’s own infrastructure.

What It Actually Is
#

The gateway is a single stateless container that an organization deploys on its own Linux infrastructure, backed by a PostgreSQL database it also controls. It’s built into the same claude binary developers already run — the gateway and the client are designed together, so policy enforcement happens consistently whether a developer is on the CLI, the desktop app, or a headless CI job. There’s no separate client to install and no new protocol to learn; the binary just points at your gateway instead of Anthropic’s endpoint.

That architectural choice — stateless container plus a database you own — is the part worth pausing on. It means the gateway can be redeployed, scaled, or torn down without losing state, and it means the audit trail lives in infrastructure your security team already has access to, not in a SaaS dashboard you have to trust.

Four Things It Actually Does
#

Identity. The gateway acts as an OpenID Connect relying party, so it plugs into Google Workspace, Microsoft Entra ID, Okta, or any standards-compliant IdP. Developers get short-lived session tokens instead of long-lived API keys sitting in a .env file on a laptop — the same problem Workload Identity Federation solved for machine-to-machine API traffic, now solved for interactive developer sessions.

Policy. Role-based access control determines which models a given user or group can call, and centrally managed settings get pushed to clients at sign-in — no more relying on every developer’s local config being correct. An admin can restrict a contractor’s access to Haiku-tier models while giving a senior team Opus and Fable access, enforced at the gateway rather than on the honor system.

Money. Per-user cost attribution plus daily, weekly, and monthly spend caps, settable per organization, per group, or per individual. This is the feature that finance teams have been asking every AI vendor for since usage-based billing became the industry default, and it’s the one most competing tools still handle with a dashboard you check after the damage is done rather than a hard limit enforced before the call goes out.

Routing. The gateway holds the upstream credentials and routes inference to the Claude API, Amazon Bedrock, or Google Cloud, with optional failover between providers. An org that’s mid-migration from Bedrock to direct API access — or that wants Bedrock as a failover path if the direct API has an incident — gets that without touching client configuration.

The Privacy Claim Is the Real Headline
#

Buried in the announcement is the line that matters most for regulated industries: “The gateway does not send inference traffic or usage data to Anthropic unless you configure it to use the Claude API.” If you’re routing exclusively through Bedrock or Google Cloud, your prompts, completions, and usage telemetry stay inside your own cloud tenancy and your own OTLP collector — Anthropic sees none of it. That’s a meaningfully different trust model than a SaaS admin console, and it directly answers the objection enterprise security teams raise every time a vendor asks them to route developer traffic through a third party: where does the data actually go, and who can see it in transit.

Why This Lands Now
#

This isn’t a random infrastructure drop — it’s the connective tissue for the enterprise push Anthropic has been running all year. The Seoul office, TCS partnership, and DXC alliance all involve deploying Claude Code to tens of thousands of engineers inside organizations with existing SSO, existing compliance requirements, and existing multi-cloud commitments. You can’t sell a 50,000-engineer rollout to a bank’s CISO without an answer to “how do we control who can spend what, and where does our code go.” Before this week, the honest answer was “you build that yourself” or “you use our SaaS admin console and trust us.” Now there’s a third option that keeps the control plane inside the customer’s own infrastructure while still using Anthropic’s models.

It also quietly closes a gap with the multi-cloud story Amazon and Google have been telling. Bedrock and Vertex AI have long offered their own IAM and cost-governance primitives, but those are cloud-specific — a company running Claude Code across both AWS and GCP had to reconcile two separate governance systems. The apps gateway is a single control plane that sits above both, plus the direct API, with one policy model and one spend-limit system regardless of which backend actually serves the request.

What to Do With It
#

If your org already built an internal proxy for exactly this purpose — SSO plus spend caps plus audit logging in front of Claude Code — this is very likely a smaller, better-maintained replacement for it, and worth a migration evaluation rather than continued in-house upkeep. If you haven’t built one and you’re running Claude Code on Bedrock or Google Cloud at team scale without per-user spend visibility, this is the fastest path to getting it: deploy the container, point it at your PostgreSQL instance and your IdP, and set forceLoginGatewayUrl in your managed settings so clients route through it by default.

The gateway is available now, documented at code.claude.com/docs/en/claude-apps-gateway. For teams still manually reconciling per-user API spend in a spreadsheet — and there are more of those than anyone likes to admit — that alone justifies the deployment effort.


Sources:

Related