Networking, Identity & Private Connectivity

Anthropic's Native Workload Identity Federation for the Claude API

Long-lived API keys are the credential your security team least wants to see in a secrets manager. Anthropic's Workload Identity Federation lets your workloads trade the identity tokens they already have for short-lived Claude credentials — no stored key at all.

Claude 3P 101 · Updated July 2026 · Unofficial guide

The cloud platforms solved this problem for their own services years ago: instead of copying a secret into every workload, the workload proves who it is with a token from its identity provider and receives temporary credentials in exchange. Google calls it Workload Identity Federation; AWS has web identity federation. Anthropic now offers the same mechanism natively for the first-party Claude API — so a GitHub Actions job, a Kubernetes pod, or an EC2 instance can call Claude without any sk-ant-... key ever being written down.

The exchange in one paragraph

Your workload obtains a short-lived OIDC JWT from an identity provider it already trusts — AWS IAM, Google Cloud, GitHub Actions, Kubernetes, SPIFFE, Microsoft Entra ID, Okta, or any standards-compliant OIDC issuer. It presents that JWT to Anthropic's token endpoint (POST /v1/oauth/token, using the standard RFC 7523 jwt-bearer grant) and receives back a short-lived token with the prefix sk-ant-oat01-.... That token is what the SDK sends on Messages API calls. When it expires, the workload simply exchanges a fresh JWT. Nothing long-lived exists to leak, rotate, or offboard.

Three resources you configure in the Console

The trust chain is built from three resource types, each with its own tagged ID:

ResourceID prefixWhat it does
Service accountsvac_...The non-human principal your workload becomes. Activated per workspace; calls follow that workspace's rate limits and usage attribution.
Federation issuerfdis_...A registered OIDC provider, with a source for its signing keys (JWKS).
Federation rulefdrl_...The matching logic: which incoming JWTs map to which service account, with what scope and lifetime.

Issuers support three ways to locate the JWKS that verifies token signatures: standard OIDC discovery (Anthropic follows the issuer's well-known metadata), an explicit JWKS URL, or an inline JWKS document — the option for air-gapped Kubernetes clusters whose API server is unreachable from the internet. You paste the cluster's public keys into the Console instead of pointing at a URL.

Rules decide who gets in. A rule can match on a subject prefix, the token's audience, specific claims, or a CEL condition, and maps matching tokens to a target service account and OAuth scope. The default scope, workspace:developer, grants the same access a workspace API key would — so the blast radius of a federated workload is bounded by the workspace it lands in, exactly like a key.

Token lifetimes

A rule's token_lifetime_seconds ranges from 60 to 86,400 seconds, defaulting to 3,600 (one hour). There is one extra guardrail worth knowing: the minted Anthropic token never outlives twice the remaining lifetime of the IdP JWT you presented. Present a JWT with five minutes left and you get at most a ten-minute Anthropic token, whatever the rule says. Short-lived input, short-lived output.

The migration gotcha: credential precedence

The SDKs resolve credentials in a fixed order across all languages: constructor arguments, then ANTHROPIC_API_KEY / ANTHROPIC_AUTH_TOKEN, then an explicit ANTHROPIC_PROFILE, then the federation environment variables, then the implicit active profile. Notice where federation sits: below the API-key variable.

Watch for this: a leftover ANTHROPIC_API_KEY in a deployment environment silently shadows federation. Everything works, the metrics look fine — and you are still authenticating with the long-lived key you thought you had retired. Make deleting the env var an explicit step in the migration checklist, then verify by revoking the old key.

Who can set this up

The Admin API endpoints for service accounts, federation issuers, and federation rules require an OAuth bearer token with the org:admin scope — regular Admin API keys (sk-ant-admin...) are not accepted on these endpoints. The distinction between the two credential types is covered in Admin API keys vs. OAuth org:admin tokens.

One scoping note: this is a first-party Claude API feature. The 3P platforms have their own equivalents — cloud IAM federation on Claude Platform on AWS, Google's WIF for Vertex AI, managed identity on Foundry — so pick the mechanism native to the door you use.

Where to go next

The SDK-side setup guide covers wiring this into application code; the deployment checklist has the broader credential-hygiene items.

Sources