Anthropic WIF — Your Claude Agents Just Lost Their API Keys

Anthropic made Workload Identity Federation generally available on June 17, 2026. Every Claude API endpoint — including the first-party SDKs and Claude Code — now accepts short-lived OIDC tokens from AWS IAM roles, GCP service accounts, Azure managed identities, GitHub Actions, Kubernetes, Okta, or any OIDC-compliant identity provider. No more sk-ant-… keys sitting in your CI secrets. The feature shipped cleanly: one GA release, full Admin API for infrastructure-as-code provisioning, and audit logging per service account out of the box. But there is a credential precedence footgun buried in the migration path that will cause real incidents for teams who do not read the fine print.

TL;DR

• What: Anthropic WIF GA — short-lived OIDC tokens replace static API keys for all Claude API endpoints, SDKs, and Claude Code
• Footgun: ANTHROPIC_API_KEY silently overrides federation if present in the environment — teams will think they migrated when they have not
• Model: Per-workload service accounts with individual identity, roles, and audit trail — the right architecture for agent pipelines
• Action: Migrate CI/CD and agent workloads to WIF, but verify ANTHROPIC_API_KEY is fully unset before declaring victory

Keyless Claude — What Shipped

The core mechanism follows the same pattern GCP and AWS have used for cross-service authentication for years: your workload presents a signed JWT from its existing identity provider, Anthropic validates the token against federation rules you configure in the Claude Console, and issues a short-lived access token scoped to a specific service account. Every exchange gets recorded in audit logs tied to that service account — not to a shared org-wide key.

Three resources must be provisioned before any workload can federate: a federation issuer (your IdP), a service account (the workload’s identity on the Claude Platform), and a federation rule that binds specific token claims to that service account. The rule also sets token_lifetime_seconds, configurable from 60 to 86,400 seconds with a default of 3,600 (one hour). New Admin API endpoints let you create and manage all three resources programmatically, so Terraform and Pulumi workflows are first-class citizens from day one.

What makes this release notably clean compared to how other AI API providers handle auth: WIF covers the entire API surface in one release. SDKs, Claude Code, raw API calls — it all works. There is no “WIF for the chat endpoint but not for fine-tuning” situation. And static API keys continue to work alongside WIF, so migration can proceed one workload at a time without a flag day.

Why This Matters

Static API keys are the lowest-common-denominator authentication mechanism in the industry, and they fail in predictable ways. They get committed to repos. They get copy-pasted into Slack. They sit in CI secrets with no rotation schedule until someone runs git log --all -S "sk-ant" and discovers six months of exposure. We covered exactly this class of vulnerability when a compromised npm package in the Axios supply chain attack harvested environment variables — including API keys — and exfiltrated them to a command-and-control server. We also documented how Claude Code’s config file handling created an RCE surface where a malicious .claude.json in a cloned repo could execute commands under the user’s API key. In both cases, the blast radius was defined by what a static key could access, which was everything the key’s organization had access to.

WIF changes the blast-radius math fundamentally. A compromised token expires — in the default configuration, within an hour. A compromised service account has only the roles explicitly assigned to it. And critically for agent pipelines running subagents, each workload gets its own identity. When your orchestrator agent spawns three tool-calling subagents and one of them gets prompt-injected into making unauthorized API calls, you can trace exactly which service account was involved, what it was authorized to do, and when the token was issued. With a shared sk-ant-… key, that forensic trail does not exist.

This matters most for teams running Claude Code in CI/CD. Before WIF, every GitHub Actions workflow calling Claude Code needed a static key stored as a repository or organization secret. That key had no expiration, no per-run scoping, and no audit trail beyond “someone used the org key.” Now a GitHub Actions workflow can present its OIDC token — which GitHub already mints for every workflow run — and receive a scoped, short-lived Claude token in return. No secret to rotate, no credential to leak.

The silent override footgun: ANTHROPIC_API_KEY sits above federation in the SDK’s credential precedence order. If that environment variable is present — even as an empty string — the SDK selects it over WIF. Anthropic documents this explicitly, but most teams will not read the migration docs carefully enough. If you are migrating from static keys, you must verify the variable is fully unset in every environment where the workload runs: container env vars, CI secret stores, shell profiles, .env files, Docker Compose overrides. Run your workload, check the audit logs, and confirm requests appear under the service account identity — not the old API key. If you skip this step, you will believe you are keyless when you are not.

The Take

I would use WIF immediately for any CI/CD pipeline or automated agent workflow calling the Claude API. The implementation is clean, the IdP coverage is broad enough to cover every major cloud and CI platform, and the per-workload identity model is the correct architecture for agent systems where blast-radius containment actually matters.

But I want to push back on a narrative that will inevitably form around this launch: “We secured our AI workloads.” No, you secured the Claude API connection. That is real progress — and Anthropic deserves credit for shipping this as a complete, GA-quality release rather than a beta that covers half the API surface. But your agent pipelines probably also call OpenAI (API key), Snowflake (service account password), your internal APIs (Bearer tokens from 2023), and a data warehouse with credentials that predate your current team lead. WIF solves one link in a chain where every other link is still a static secret.

The three-resource provisioning model (issuer → service account → federation rule) maps directly to how GCP handles workload identity for GKE. If your team already manages GCP WIF, the mental model transfers one-to-one. If you have never set up workload identity federation anywhere, start with a single non-critical CI pipeline — not your production agent fleet.

The credential precedence issue is the more immediate concern. I have watched teams do “zero-trust migrations” where the old credentials stayed in the environment for months as a “fallback.” With most systems, that is just technical debt. With Anthropic’s WIF, it is an active security gap: the old key silently wins, your audit logs show nothing under the service account, and you have no signal that federation is not actually being used. The fix is simple — unset the variable, verify the audit logs — but simple fixes are the ones teams skip because they assume the migration “just worked.”

WIF is the right call. Migrate your workloads. But treat the migration as verified when audit logs confirm it, not when your Terraform plan applies cleanly.

Related

• Axios npm Supply Chain Attack — The class of credential exfiltration that WIF eliminates for Claude API keys
• Claude Code RCE via Config Files — Why per-workload identity matters when config files can execute under your credentials
• Best Secrets Management Tools 2026 — For every other credential in your stack that WIF does not cover