Configure Claude Code Workload Identity Federation with OIDC

If your infrastructure still authenticates to the Claude API with a long-lived sk-ant-... key stored in a secrets manager, Anthropic has now shipped the mechanism to eliminate that. Anthropic Claude workload identity federation (WIF) lets any OIDC-capable workload — a GitHub Actions runner, a Kubernetes pod, an AWS Lambda function — exchange its cloud identity token for a short-lived Anthropic access token at runtime. There are no static secrets to mint, rotate, or leak, and every API call is attributable to a named service account in your org.

For teams asking how to configure workload identity federation for Claude Code, Claude Code Action, or a routing gateway, the practical answer is: create an Anthropic service account, register the workload's OIDC issuer, bind the claims with a federation rule, and run Claude clients with the WIF environment variables instead of ANTHROPIC_API_KEY.

This matters for routing teams specifically because it changes not just how you authenticate to Claude, but how your gateway or proxy layer should store and inject credentials for downstream Claude API calls.

How to configure Claude Code workload identity federation

The shortest setup path is the Claude Console Settings → Workload identity → Connect workload wizard. Use it for Claude Code Action in GitHub Actions, Kubernetes-hosted Claude Code agents, or a gateway that calls Claude on behalf of developers:

1. Create or choose the Anthropic service account. This is the non-human principal that Claude Code or the gateway will act as. Add it to the target workspace before testing the exchange.
2. Register the workload's OIDC issuer. For Claude Code Action, the issuer is GitHub Actions (https://token.actions.githubusercontent.com). For Kubernetes, use the cluster service-account issuer. For AWS, Google Cloud, Entra ID, Okta, or SPIFFE, choose the matching provider tile or Custom OIDC.
3. Constrain the federation rule. Match the specific GitHub repository/ref, Kubernetes namespace/service account, or cloud workload identity. Avoid a broad subject_prefix that would let unrelated jobs mint Claude tokens.
4. Set the OAuth scope and lifetime. workspace:developer is the normal inference scope. MCP tunnel management needs org:manage_tunnels, so do not reuse the same rule blindly. Start with a 600–3600 second lifetime, then tune after load testing.
5. Inject WIF variables at runtime. Configure ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID, ANTHROPIC_SERVICE_ACCOUNT_ID, ANTHROPIC_WORKSPACE_ID, and ANTHROPIC_IDENTITY_TOKEN_FILE. Then construct the SDK client without api_key.
6. Verify from the real workload. Trigger the Claude Code Action, CI job, pod, or gateway deployment inside the wizard's test window. The exchange must succeed from the actual identity provider, not just from a local shell.

If you are configuring Claude Code Action specifically, the failure mode to avoid is over-trusting all GitHub Actions tokens from an organization. Bind the rule to the exact repository, branch/tag policy, environment, and workflow claims you intend to authorize.

What happened

Anthropic published full documentation for workload identity federation in the Claude Console under Settings → Workload identity. The feature uses a three-resource model that mirrors the pattern established by GCP Workload Identity Federation and AWS IRSA:

Service accounts (svac_...) — non-human identities inside your Anthropic organization. A service account has no email, no password, and no Console login. It becomes active in a workspace when added as a member; at token-exchange time, Anthropic mints a short-lived token scoped to that workspace's rate limits and usage attribution.

Federation issuers (fdis_...) — registered OIDC identity providers. You register one issuer per environment (prod EKS cluster, staging cluster, GitHub Actions are three separate issuers). The issuer record maps an iss claim value to a JWKS source so Anthropic can verify the JWT signature.

Federation rules (fdrl_...) — the bridge: "JWTs from issuer X with claims matching Y may act as service account Z." Rules define match conditions (subject_prefix, audience, exact claim values, or a CEL expression), a target service account, an OAuth scope (workspace:developer by default), and a token lifetime (60–86400 seconds, default 3600).

The exchange flow is standard RFC 7523 jwt-bearer: your workload posts its IdP-issued JWT to POST /v1/oauth/token along with the federation rule ID, org ID, service account ID, and workspace ID. Anthropic returns a sk-ant-oat01-... access token. The Anthropic SDK handles the exchange and auto-refresh loop; your application code constructs the client with no api_key argument and calls the API as usual.

Supported issuers out of the box include AWS IAM, Google Cloud, GitHub Actions, Kubernetes service-account issuers, SPIFFE, Microsoft Entra ID, and Okta. Air-gapped clusters can use explicit_url or inline JWKS mode.

Why it matters for AI engineering teams

Static API keys are the biggest unaddressed credential risk in most AI stacks. The sk-ant-... key is typically stored as an environment variable, a Kubernetes secret, or a CI secret. It never expires. If it leaks — through a git commit, a log line, a container image inspection, or a compromised build artifact — the attacker has indefinite access until you rotate manually. Workload identity federation removes this class of risk entirely for workloads that already have an OIDC identity.

Token lifetime controls give you scoped, time-limited access. The default 3600-second lifetime means a compromised token is valid for at most one hour. You can set it as low as 60 seconds for short-lived CI jobs. For long-running agent workflows, the SDK re-exchanges automatically before expiry.

Service accounts make AI API calls auditable. Today most teams attribute Claude API calls to a single API key — which makes it hard to answer "which deployment generated these tokens last Tuesday?" With service accounts, each workload maps to a named principal. Combined with workspace-scoped rate limits, this gives you the same attribution granularity as AWS IAM roles: every call is stamped with the service account that made it.

CEL match conditions enable fine-grained access rules. If your Kubernetes cluster runs both production and staging workloads, you can create separate rules with CEL expressions that match on namespace labels, environment claims, or specific service account names — each mapping to a different Anthropic service account with different workspace membership and rate limits.

The router/operator angle

For teams routing Claude traffic through a gateway or proxy layer, workload identity federation changes the credential model in a specific way that is worth planning now.

Your gateway is the primary candidate for WIF adoption. A routing gateway makes outbound Claude API calls on behalf of many upstream clients. Today it typically holds a static sk-ant-... key and injects it into forwarded requests. If your gateway runs on AWS, GCP, or Azure, it already has an OIDC identity (an IAM role, a service account, or a managed identity). You can register that as a WIF issuer, create a service account for the gateway, set up a federation rule, and configure the SDK to use environment variables instead of a static key:

export ANTHROPIC_FEDERATION_RULE_ID="fdrl_..."
export ANTHROPIC_ORGANIZATION_ID="00000000-0000-0000-0000-000000000000"
export ANTHROPIC_SERVICE_ACCOUNT_ID="svac_..."
export ANTHROPIC_WORKSPACE_ID="wrkspc_..."
export ANTHROPIC_IDENTITY_TOKEN_FILE="/var/run/secrets/anthropic.com/token"

The SDK zero-argument constructor resolves credentials from these environment variables, handles the exchange, and refreshes the token before it expires. The gateway never stores a long-lived key.

Workspace scoping means per-team isolation is now a credential primitive, not just a routing label. If you run separate Anthropic workspaces for different teams or cost centers, WIF lets you create separate service accounts per workspace and separate federation rules per deployment. A request routed to the team-a workspace uses a team-a service account token; a request routed to team-b uses a team-b token. Rate limits, usage attribution, and access controls follow the workspace — not just the routing label you set in your gateway config.

MCP tunnel integration creates a specific scope requirement. If you use Claude Code or other agents via MCP tunnels (org:manage_tunnels scope), the MCP tunnel flow creates federation rules scoped to org:manage_tunnels rather than workspace:developer. If you are building a routing layer that proxies both inference and tunnel management calls, you need separate federation rules (and possibly separate service accounts) for each scope. The default workspace:developer scope does not include tunnel management.

Token-exchange latency is the one operational cost to model. Each WIF exchange is an HTTP round-trip to POST /v1/oauth/token. At 3600-second lifetimes the SDK caches and auto-refreshes, so the overhead amortizes across thousands of requests per token. For gateways handling high request rates the cost is negligible. For gateways with very short-lived request batches or cold-start paths, factor in the exchange latency during capacity planning.

Operator migration checklist for Anthropic WIF:

1. Identify workloads with existing OIDC identities. Check your gateway, CI/CD pipelines, and Claude Code deployments for AWS IAM roles, GCP service accounts, GitHub Actions OIDC, or Kubernetes projected tokens. These are your WIF migration targets.

2. Register one issuer per environment. Create separate fdis_... records for production, staging, and CI. This prevents a staging credential from minting tokens that act in your production workspace.

3. Map one service account per team or cost center. Add each service account to the appropriate Anthropic workspace. Workspace-scoped rate limits and usage attribution will follow the service account automatically.

4. Write CEL conditions for shared issuers. If a single Kubernetes cluster serves multiple teams, use CEL condition expressions to match on namespace or label claims rather than a broad subject_prefix.

5. Update your gateway SDK construction. Replace api_key=os.environ["ANTHROPIC_API_KEY"] with the zero-argument constructor and inject ANTHROPIC_FEDERATION_RULE_ID and related environment variables per-environment.

6. Test token lifetime under load. Set token_lifetime_seconds to 3600 initially. For high-throughput gateways, confirm the SDK's refresh timing is not creating contention under concurrency before lowering the lifetime.

7. Verify MCP tunnel scope separately. If your deployment includes MCP tunnels, confirm that the tunnel federation rule uses org:manage_tunnels scope and maps to a service account with org-level membership, not just workspace membership.

What TheRouter users should watch or try

The workload identity federation model is most actionable for teams running Claude Code or Claude-backed agent workflows through a routing layer. If your deployment runs in a cloud environment with an existing OIDC identity, you can eliminate the stored sk-ant-... key from your AI provider routing configuration and replace it with a token exchange flow per the SDK zero-argument pattern.

For teams using multi-provider routing across OpenAI and Anthropic, it is worth noting that both providers now have OIDC-based keyless auth — but the implementations differ. OpenAI uses its own workload identity federation flow at the organization level; Anthropic uses service accounts + federation rules with CEL match conditions and workspace-level scoping. Teams managing both providers in the same gateway need separate federation configurations per provider.

The Anthropic Claude Console documentation at Settings → Workload identity is the authoritative setup guide. Watch the Anthropic changelog for updates to OAuth scopes, new preset identity providers, and any changes to token lifetime constraints as the feature matures.