Workload Identity for the Claude API

Anthropic’s Workload Identity Federation brings identity-backed authentication to Claude API workloads. It is useful when a service already has a trusted platform identity and should not carry a long-lived provider API key.

The change is an additional authentication option. API keys remain supported. Eligible workloads can exchange an identity assertion for a short-lived Anthropic access token instead of distributing a static Claude API key.

This can simplify credential lifecycle management. Whether it meets an organization’s requirements depends on the full identity chain, access controls, audit evidence and deployment configuration.

Two flavors of keyless

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

Browser CLI auth (for humans)

For the Claude Platform CLI, the documented interactive command is ant auth login. It opens a browser authorization flow and stores credentials in the CLI configuration directory. This is separate from Claude Code’s claude login or setup-token workflows; a coding-agent subscription token is not the federation mechanism described here.

Workload Identity Federation (for everything else)

A workload obtains a suitable signed identity token from a configured provider and exchanges it for an Anthropic access token. The assertion source is provider-specific: for example, AWS STS GetWebIdentityToken or an EKS projected token, rather than an AWS access-key pair passed as though it were an OIDC JWT.

Anthropic documents an RFC 7523 jwt-bearer exchange at /v1/oauth/token. This is distinct from obtaining the upstream assertion: that first step depends on the platform and identity provider.

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.

The supported SDKs perform the token exchange and refresh. Configure the required federation identifiers and a supported identity-token source, then verify the effective credential route. Avoid depending on undocumented refresh timing or assuming every SDK version has identical behavior.

The two credentials are the upstream identity assertion and the resulting access token. Both need protection. Their short lifetimes reduce one exposure window; they do not make theft, logging mistakes or excessive permissions harmless.

What changes in secret management

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

Federation can remove the long-lived Claude API key from those locations. The workload still handles sensitive assertions and access tokens, and its upstream identity may itself depend on credentials. Protect logs, scope the trust relationship, and review who can obtain a token.

Why it's bigger than it looks

Three architectural considerations follow from the change.

1. AI inference becomes a first-class cloud workload

Provider authentication can follow the workload’s existing identity lifecycle. This reduces the need for a separate static secret, but the application still needs least-privilege access and observable failures. Existing identity infrastructure is an input to the design, not proof that the resulting integration is secure.

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

Use separately attributable workload identities where the platform supports them. Verify the actual service-account and workspace boundaries, including usage attribution and authorization scope, instead of assuming one service account creates a dedicated rate-limit or security boundary.

A useful acceptance test is whether operators can identify the acting workload, constrain its access, and revoke or disable that access without changing unrelated services.

Deployment requirements beyond authentication

Credential management is one deployment requirement among several. Federation can improve that part of the design; it does not establish data-retention compliance, network isolation or authorization correctness for the rest of the application.

Evaluate the integration with the team responsible for those requirements. Do not treat an authentication feature announcement as evidence of faster procurement or automatic security approval.

Provider matrix

Migration in five steps

For a supported workload, migrate in stages and retain a rollback path until the federated route has been verified.

1. Configure federation in parallel. Register the issuer, service account and scoped trust rule. Preserve the working credential route and establish a recovery procedure.
2. Inspect credential selection. CLI status can help diagnose its own route. Independently check the deployed application’s SDK and configuration; CLI selection does not prove which credential the application uses.
3. Test an isolated canary. Remove the API key only from that canary. Verify actual application calls, token renewal, attribution and failure behavior under the federated identity.
4. Roll out the verified configuration. Expand deliberately, monitor failures and access boundaries, and retain the recovery procedure until every affected consumer is verified.
5. Retire the old key. Check all consumers before revocation. Revoke it only when the replacement route and recovery procedure are established.

Credential precedence is one migration risk: an API key can shadow federation. Also test the issuer, audience, subject and workspace rules, token renewal, failure reporting and revocation behavior before retiring the old credential.

The deeper signal

Identity-backed access is a useful platform capability. Its value is concrete: shorter-lived credentials and centralized trust decisions can be easier to manage than separately distributed static secrets.

The rest of the integration still needs explicit boundaries. Decide which workload can call which service, what information it may send, and how failures and access changes will be observed.

Prefer federation when the workload has a suitable identity provider and the deployment supports it. Keep supported API-key workflows where they are appropriate, with scoped access, secure storage and rotation. The choice should follow the system’s requirements.

Review authentication independently from model capability or product branding. A working token exchange proves that one trust rule accepted one assertion; it does not validate every surrounding control.

The practical outcome is less long-lived provider-secret management, with continued responsibility for protecting the identity chain.

Primary documentation: Anthropic WIF, ant CLI authentication, AWS integration, and AWS STS GetWebIdentityToken. Checked 20 September 2026.