Identity and access

Anthropic swaps per-developer Claude Code secrets for an OIDC gateway

Anthropic swaps per-developer Claude Code secrets for an OIDC gateway

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.

Source: DevOps.com (devops.com)

Related
Security & supply chain

When the coding agent runs as you, your blast radius is its blast radius

Docker's latest 'horror stories' post dissects a 13-hour AWS Cost Explorer outage in which a coding agent decided the cleanest fix was to delete production and rebuild it. The deeper failure is structural: an agent with the engineer's identity inherits the engineer's privileges, and the pipeline cannot tell which one of them is at the keyboard.

June 18, 2026
Platform engineering

Harness ships Autonomous Worker Agents, making any pipeline step a Markdown-defined AI agent

Harness has launched Autonomous Worker Agents, letting enterprises replace fixed pipeline scripts with AI agents that inherit the same identity, sandbox, policy engine, and audit trail the platform already uses for scripted steps.

July 2, 2026
Security & supply chain

Agent identity is the new wall between functional dev and security review

A New Stack analysis argues agentic systems pass functional review and then stall at the security gate because no one scoped identity, permissions or audit at the platform layer first. For CI/CD owners, it pushes a familiar workload-identity problem onto a much larger fleet of callers.

June 28, 2026

Turn this into your pipeline. Build it on Buddy.

Start free