Claude Killed the API Key

On May 4, 2026, @ClaudeDevs posted what looked like a routine security update. It was the most consequential release of the month for anyone running Claude in production.

Translation: the sk-ant-… era is over. Anthropic just shipped Workload Identity Federation, which means production AI inference can finally inherit the same identity model as the rest of your cloud — short-lived tokens minted from your existing IdP, no static secrets to mint, store, rotate, or leak.

This is the announcement that quietly graduates Claude from "that one weird service that uses an API key" to a first-class cloud workload. If you've been waiting on security to approve production AI rollouts, the wait just got shorter.

Two flavors of keyless

There are two distinct things bundled in this announcement, and the difference matters.

Browser CLI auth (for humans)

When you run claude on a fresh machine, it now opens a browser, walks you through OAuth 2.0 authorization code grant, and stores the resulting credentials in your OS keychain. Same pattern as gh, heroku, vercel — every developer CLI that takes its security seriously. For headless environments where browsers don't exist, claude setup-token walks you through a one-time auth flow and prints a one-year OAuth token you can stash in CLAUDE_CODE_OAUTH_TOKEN. Boring. Standard. The way it should have always been.

Workload Identity Federation (for everything else)

This is the actual news. Workload Identity Federation lets your production workloads authenticate to the Claude API by presenting an OIDC JWT that they already have — issued by AWS IAM, the Google Cloud metadata server, Azure IMDS, GitHub Actions, your Kubernetes cluster, Okta, Microsoft Entra ID, or any standards-compliant OIDC provider. Anthropic's token endpoint accepts the JWT, validates it, and returns a short-lived sk-ant-oat01-… access token bound to a service account in your org.

The flow is RFC 7523 jwt-bearer grant — the same standard pattern Google, AWS, and every serious cloud uses for cross-domain service-to-service auth. Anthropic just plugged into the existing rails.

How it actually works

Three primitives in the Claude Console express the entire system:

• Federation issuer (fdis_…) — registers an OIDC provider with your org. Anthropic fetches the issuer's JWKS to verify JWT signatures.
• Service account (svac_…) — a non-human identity inside your Anthropic organization. The principal that minted tokens act as. Lives at the org level, becomes active in a workspace via membership.
• Federation rule (fdrl_…) — the bridge: "JWTs from issuer X with claims that look like Y mint a token for service account Z with scope S." Match conditions can be subject prefix, exact audience, claim equality, or a CEL expression.

At runtime, the SDK reads an ambient identity token from a file path you set via ANTHROPIC_IDENTITY_TOKEN_FILE, posts it to /v1/oauth/token with the federation rule ID, and gets back a short-lived access token that the SDK then caches and refreshes automatically. Two-tier refresh schedule modeled on botocore: advisory at expiry minus 120 seconds, mandatory at expiry minus 30 seconds. The SDK re-reads the token file on every exchange so rotated Kubernetes projected tokens just work.

If you've ever set up GCP Workload Identity Federation for service-to-service auth, the mental model is identical. If you haven't, just know: the magic is that the workload presents proof of who it is from an identity provider Anthropic trusts, and gets a session token in return. No shared secret in either direction.

What this kills

To understand why this matters, list every place an sk-ant-… key currently lives in a serious team's environment:

• HashiCorp Vault, AWS Secrets Manager, Doppler, 1Password Connect
• GitHub Actions secrets (organization-scoped, repo-scoped, environment-scoped)
• Kubernetes secrets, Sealed Secrets, External Secrets Operator
• .env.production in three different microservices, each with a slightly different rotation cadence
• The Slack DM where a senior engineer pasted the key to help a junior debug "real quick"
• Local dev shells that copied the production key for "just one test against real data"
• The CI log that printed it in plaintext that one time before the redaction PR landed
• A handful of forgotten "dev-test-temp" keys that nobody can identify but nobody wants to revoke

Every one of those is a leakage surface. Every one needs a rotation playbook. Every one represents a moment where somebody's git push briefly exposed your blast radius. Federation collapses all of it into nothing — there is no static secret to leak, because the workload's cloud identity is the credential.

Why it's bigger than it looks

Three implications I don't see being discussed yet:

1. AI inference becomes a first-class cloud workload

Until last week, every "how to deploy AI to production" tutorial assumed an API key in an env var. That assumption put AI provider auth on a different — and worse — security tier than every other cloud service the team used. Your Postgres connection used IAM roles. Your S3 access used IAM roles. Your Pub/Sub used service accounts. Your AI inference used a flat string that could end up on Stack Overflow.

Now Claude lives on the same auth tier as the rest of your stack. The sk-ant-… pattern is starting to look like the AKIA… hardcoded AWS access key did circa 2015 — technically supported, mostly indefensible if your security team sees it.

2. Per-service bounded identities become possible

In a federation-native architecture, each microservice that calls Claude can have its own service account, with its own audit trail, its own rate limit slice, and (when scope granularity gets richer) its own permission boundary. No more "shared org API key" pattern where the recommendation engine and the support chatbot are using the same credential and you can't tell from the audit log which one made the call that broke prod.

This is the architectural unblock for AI-as-microservice. Internal services calling Claude with bounded, attributable identities is what mature cloud-native AI deployments are going to look like by end of year.

3. The enterprise unblock just shipped

If you've talked to a CISO at any regulated organization in the last 12 months about AI adoption, the conversation eventually circled around credential management. "How do you prevent the API key from leaking? Where does it live? Who has access? How fast can we revoke it? What's the audit story?" The answers were defensible but not great. Federated identity is the answer they actually wanted.

Anthropic just removed the single most cited security objection to enterprise Claude deployment. Watch for procurement velocity to pick up. The teams that have been waiting on security sign-off are going to start shipping.

Provider matrix

Migration in five steps

If you're running Claude in production today on an sk-ant-… key, the migration path is mechanical:

1. Configure federation in parallel. In the Claude Console, register your IdP as a federation issuer, create a service account, write a federation rule. Leave the existing API key in place.
2. Smoke-test which credential wins. Run ant auth status from inside the workload. ANTHROPIC_API_KEY sits above federation in the credential precedence chain, so the API key still wins at this stage.
3. Unset the API key everywhere. CI secrets, container env, shell profiles, the place you forgot. Re-run ant auth status until federation is the source.
4. Verify in flight. Watch your dashboards. Same usage attribution, same rate limit profile, no errors. Tokens are minted fresh every ~hour, transparent to the application.
5. Revoke the API key. Delete it in the Console. The era is over for that workload.

Repeat per workload. The order matters: federation set up first, key revoked last, with a verification step between them. The ANTHROPIC_API_KEY-shadows-federation gotcha is the only real foot-gun here — if you skip the unset step, you'll think you migrated but you actually didn't.

The deeper signal

Anthropic does not announce things this carefully unless they're playing a long game. Read the doc page on federation closely and you'll notice the language: "service account," "federation rule," "workspace member," "OAuth scope," "token lifetime," "credential precedence." That's not the vocabulary of a feature. That's the vocabulary of a platform.

Combine this with the recent shipping of the Claude Constitution (a 23,000-word governance document) and the Sinapt-shaped product unification, and the pattern is consistent: Anthropic is becoming an enterprise AI platform with the rigor of an enterprise platform. Federated identity is one more proof point that the company has decided what it's going to be when it grows up.

If you're shipping AI-native software, this changes how you should architect the integration. Stop treating ANTHROPIC_API_KEY as a credential primitive. Treat it as a legacy fallback for local dev. In production, your services should have identities, and those identities should mint tokens on demand from the same IdP that issues your other cloud credentials.

The sk-ant-… pattern in your .env file is starting to look like a tell — the same way a hardcoded AKIA… did a decade ago. The teams that adopt federation first are going to look, in retrospect, like they saw the future. The teams still rotating shared API keys in 2027 are going to look like they were doing AI integration the way you do shell scripts in 2015 — possible, supported, definitely not what serious operators do.

Anthropic killed the API key. The smart move is to bury it before someone has to find yours in a public commit.

Related Reading

• HIPAA for Software Engineers
• Claude's Constitution
• Sinapt: Two Products, Not One
• The Cockpit