Every team running Claude Code at scale has the same problem in their CI configuration: a static API key sitting in a secrets manager, or worse, in a .env file committed to a private repo that’s now not quite as private as it once was.
The sk-ant-... key is long-lived by design. Create it once, paste it into every environment that needs it, rotate it when something looks wrong. It’s the same pattern we’ve used for every API since Stripe popularized it in 2010. It works until it doesn’t — and when it doesn’t, it tends to fail loudly in the form of billing anomalies or unauthorized access.
Anthropic’s Workload Identity Federation (WIF) is now generally available on the Claude Platform. It replaces static API keys with short-lived OpenID Connect (OIDC) tokens issued by identity providers you already operate. No static credentials to create, store, rotate, or leak.
What WIF Is, Without the Marketing#
The mechanism is straightforward. Your workload authenticates with the identity system it already has — an AWS IAM role, a GCP service account, an Azure managed identity, a GitHub Actions token, a Kubernetes service account, a SPIFFE SVID, or any OIDC-compliant provider including Okta and Microsoft Entra ID.
That identity system issues a signed OIDC token. Your workload posts that token to POST /v1/oauth/token on the Claude Platform, which verifies the token against your configured federation rules and issues a short-lived Anthropic access token. Token lifetime is configurable from 60 to 86,400 seconds; the default is 3600.
The Anthropic SDK handles the exchange automatically. You configure it once; the SDK manages refresh before expiration. From the application’s perspective, it’s the same API it was calling before, just with credentials that expire.
This covers all Claude API endpoints — including when accessing them through Claude Code.
The Enterprise Problem This Actually Solves#
The API key model has two failure modes that matter for production agentic deployments.
Shared identity. In a traditional setup, a single API key covers all workloads: local development, staging, CI, production pipelines, the multi-agent orchestrator, and the individual subagents it spawns. When something goes wrong — an unauthorized request, an unexpected cost spike, a data exfiltration concern — your audit log tells you “API key sk-ant-abc123 made 4,000 requests.” It does not tell you which workload, which agent, or which user triggered those requests.
Static credential exposure. Long-lived keys accumulate. They get pasted into CI systems, committed to config files, copied into staging environments that share credentials with production, and sometimes posted to Stack Overflow. CISA’s 2025 cloud security guidance listed AI API key exposure in the top five credential incident categories. The rotation burden is real: rotating a key that’s embedded in a dozen pipelines requires coordinated updates across multiple systems, so teams defer it, and deferred rotation means more exposure window.
WIF addresses both. Each workload authenticates with its native identity — the IAM role that was already scoped to that workload for S3 access, the same GitHub Actions OIDC token that authenticates your CI to ECR. The Claude Platform maps that identity to a service account you’ve configured, with roles and permissions scoped to that specific workload. Every exchange and request is logged against that service account in your audit trail.
Service Accounts: Per-Agent Identity at Scale#
WIF ships alongside a service account model for the Claude Platform. Instead of one API key for all workloads, each workload gets its own service account: its own identity, its own role, its own audit trail.
This has an obvious application for multi-agent architectures. A Claude Code orchestrator spawning ten subagents in parallel shouldn’t share a single identity across all of them. With service accounts, you can scope each subagent to the minimum permissions it needs — read-only access to source code for analysis agents, write access to the PR API for review agents, no access to billing endpoints for any of them. If a subagent behaves unexpectedly, the audit log identifies exactly which service account made which calls.
This matters especially as Recursive Agent Nesting landed in Claude Code v2.1.172 — five levels of sub-agent spawning means chains of agents acting autonomously over extended periods. Shared-key architectures don’t give you the visibility to understand what happened after the fact. Service accounts do.
Connecting to Enterprise MCP#
The Anthropic enterprise expansion announced alongside WIF includes managed MCP connectors with Okta as a supported IdP. That’s not incidental — it’s the same WIF model applied to MCP tool authentication.
When a Claude Code agent invokes an MCP tool that connects to a corporate data source (Salesforce, ServiceNow, Jira, internal APIs), that invocation needs to authenticate with the enterprise system using credentials scoped to the specific user or role making the request. WIF through Okta provides the bridge: the agent’s identity flows through the OIDC chain to the MCP connector, which can enforce user-level authorization on the corporate side without requiring a separate credential handoff.
This closes a security gap that teams running enterprise MCP deployments have been patching manually: the gap between “the agent has access to this MCP server” and “the agent has access to this MCP server on behalf of this specific user with this specific authorization level.”
Migration: Zero-Downtime Parallel Rollout#
Anthropic’s documented migration path is designed for gradual adoption. API keys work alongside WIF — you don’t cut over all at once.
The practical sequence:
- Configure a federation issuer for your identity provider in the Claude Platform admin console (or via the Admin API, which exposes programmatic issuer/service-account/rule management)
- Create a service account and federation rule that matches your workload’s token claims
- Test the OIDC exchange in a non-production workload
- Confirm the short-lived token flow works with your existing SDK integration
- Remove the static
ANTHROPIC_API_KEYfrom that workload’s environment - Repeat for each workload
The federation configuration is fully programmatic. Organizations operating at scale — hundreds of microservices, automated agent pipelines — can manage federation rules via the Admin API rather than through the console.
What WIF Doesn’t Solve#
WIF addresses credential management. It doesn’t address everything.
Aembit, a non-human identity security company, made the point directly in their WIF analysis: Anthropic’s implementation handles the authentication leg cleanly, but authorization decisions about what a given service account can do are still configured in the Claude Platform, not in your existing policy-as-code infrastructure. Teams running OPA, Cedar, or similar policy engines don’t yet have native integration points for Claude service account permissions.
There’s also a usability ceiling for teams that aren’t already running a supported IdP. GitHub Actions coverage is broad — most CI pipelines already use OIDC for cloud authentication. But local development environments don’t have a natural identity anchor. Anthropic’s recommendation for local dev is to continue using API keys and reserve WIF for automated workloads, which is reasonable but means the “no static keys anywhere” goal requires additional tooling for developer machines.
The Bigger Pattern#
WIF is infrastructure, not a headline feature. It won’t show up in benchmark tables or marketing one-pagers. But it marks a significant maturation in how Anthropic thinks about the enterprise deployment model.
Serious production AI deployment requires the same security infrastructure as any other production system: principle of least privilege, short-lived credentials, per-workload identity, clean audit logs, integration with existing IAM. The AI tools that dominate enterprise adoption long-term will be the ones that fit into existing security infrastructure rather than requiring exceptions to it.
The sk-ant-... key was a developer convenience. WIF is an enterprise requirement. The transition being generally available matters not because it’s exciting, but because it removes the last major reason enterprise security teams had to treat Claude-based deployments as a special category requiring special exception handling.
Your AI agent doesn’t need a secret. It just needs an identity.
Sources:
- Claude API Docs: Workload Identity Federation
- Anthropic Blog: Workload Identity Federation is now generally available
- DEV Community: Your AI Agent Doesn’t Need an API Key — Entra Agent ID and Anthropic’s Workload Identity Federation
- Aembit: Anthropic Workload Identity Federation — What It Gets Right and What It Still Doesn’t Solve
- Security Boulevard: Anthropic Workload Identity Federation