Every laptop with Claude Code on it tends to collect long-lived secrets like lint. A cloud key here, a service credential there, an API token in a dotfile that outlived two employees. That is the surface area we told ourselves was fine, because the alternative was another SSO round trip and a queue of tickets from developers. Anthropic just moved that trade-off. On July 1, DevOps.com (byline Tom Smith) reported that Anthropic has introduced a self-hosted Claude apps gateway for enterprises running Claude Code on Amazon Bedrock or Google Cloud.
What actually shipped
Per DevOps.com, the gateway is a single stateless container backed by a PostgreSQL database. It sits between Claude Code and the two hyperscaler backends, and it acts as an OpenID Connect relying party. That means it federates sign-in through whichever IdP you already run: Google Workspace, Microsoft Entra ID, Okta, or any standards-compliant OIDC provider. The sessions the gateway hands back are short-lived, and they replace the long-lived per-developer secrets that used to live on developer machines to reach the two cloud backends.
The gateway also centralizes identity, policy enforcement, usage tracking and spend management for Claude Code. If you want to know who ran which agent against which model, how much it cost, and whether they were allowed to do that, the gateway is the point in the topology where you find out.
The trust boundary that moved
Here is the awkward question we keep dodging: what is the blast radius of a Claude Code install on a developer laptop? Before this, if the laptop got imaged at a coffee shop, so did whatever cloud role it carried. After this, revoking the OIDC session in the IdP cuts access without touching cloud IAM. The place where a token dies is finally the same place that already dies when an employee leaves.
Is that new engineering? No. Every platform team already runs this pattern for CI runners: workload identity federation, short-lived tokens, an IdP as the eventual authority. What is new is that a coding agent, the thing that reads your source and writes to your branches, is being pulled into that same discipline rather than left as a special case with its own key management.
Fitting it into a pipeline
The concrete change for a platform team is what you provision and what you stop provisioning. You stop shipping developers per-project Bedrock or Google Cloud credentials. You stop rotating them. You provision the gateway once, point it at your OIDC issuer, and configure the group and policy mappings that decide who can call which model and how much they can spend. The gateway hands out sessions. The sessions carry the cloud call.
Because the container is stateless, the interesting operational state is the database. That has the usual implications. Back it up. Put it behind your standard Postgres runbook. Treat the gateway itself as an ordinary stateless workload you can scale horizontally.
Where the wink comes in
Federated identity does not remove trust. It relocates it. Your IdP is now the throat you are choking. If your OIDC provider has a bad afternoon, so does every Claude session against Bedrock and Google Cloud. That is a familiar failure mode, and it is also the reason most orgs already treat their IdP as a tier-zero service. Fine. Just do the math with your eyes open.
The other thing worth reading carefully: policy enforcement lives in the gateway. That is convenient when the policy you want to enforce is one the gateway exposes. It is less convenient when the policy is one it does not. Ask early which knobs are configurable and which are baked in. A gateway you cannot bend is still better than a laptop full of static keys, but it is not a substitute for reading the reference before you rely on a specific control.
The kicker
Long-lived per-developer credentials for coding agents were always temporary architecture that outstayed their welcome. This is the retirement notice. Take it.
Top comments (0)