38  Workload Identity Federation is Now Generally Available

38.1 Overview

On June 17, 2026, Anthropic announced the general availability of Workload Identity Federation (WIF) for the Claude Platform — a security feature that replaced static API keys with short-lived, scoped credentials for machine-to-machine authentication. The GA release marked the culmination of months of development and represented what Anthropic described as the most significant security improvement to Claude’s API authentication since launch.

The problem WIF solved was as old as API keys themselves: static credentials are dangerous. An API key is a long-lived secret that grants access until it is manually revoked. If stolen — through a leaked environment variable, a compromised CI/CD pipeline, a misconfigured log, or a social engineering attack — it can be used by anyone, anywhere, until discovered and rotated. For organizations running Claude in automated systems, CI/CD pipelines, and backend services, static API keys were a persistent security liability.

Workload Identity Federation eliminated this risk by replacing static keys with a model where workloads authenticate using short-lived tokens issued by a trusted identity provider. No static secrets to steal, no rotation schedules to maintain, no “was this key compromised?” investigations after every security incident.

38.2 How Workload Identity Federation Works

38.2.1 The Core Concept

In traditional API key authentication, a workload (a server, a CI/CD job, a Lambda function) holds a static secret that it sends with every request. The API validates the secret and processes the request.

In Workload Identity Federation, the workload holds no static secret. Instead:

1. The workload obtains a short-lived token from a trusted identity provider (e.g., AWS IAM, GitHub Actions, Kubernetes).
2. The workload presents this token to Claude’s WIF endpoint.
3. Claude validates the token against a federation rule that maps the external identity to a Claude service account.
4. If the rule matches, Claude issues a short-lived access token (typically valid for 1 hour) scoped to the service account’s permissions.
5. The workload uses this access token to make API calls.

Traditional (API Key):
┌──────────┐    static key    ┌──────────┐
│ Workload │─────────────────►│  Claude  │
│          │  (lives forever)  │   API    │
└──────────┘                   └──────────┘

Workload Identity Federation:
┌──────────┐                   ┌──────────┐
│ Identity │   short-lived     │ Claude   │
│ Provider │───── token ──────►│   WIF    │
│ (AWS,    │                   │ Endpoint │
│  GitHub, │                   └────┬─────┘
│  K8s...) │                        │ validates
└──────────┘                        ▼
                              ┌──────────┐
┌──────────┐  access token    │ Service  │
│ Workload │◄─────────────────│ Account  │
│          │ (1 hour TTL)     │ (scoped) │
└────┬─────┘                  └──────────┘
     │
     │ scoped API calls
     ▼
┌──────────┐
│  Claude  │
│   API    │
└──────────┘

38.2.2 Service Accounts

At the heart of WIF was the concept of service accounts — non-human identities with their own:

• Identity: A unique identifier (e.g., ci-pipeline@production).
• Roles: Scoped permissions defining what the account can do.
• Audit trail: Every action taken by the service account is logged.

Service accounts were the WIF equivalent of human user accounts, but designed for machines. They could be granted specific model access, rate limits, and spend caps — just like human users, but without the overhead of managing human credentials.

38.2.3 Federation Rules

The bridge between external identity providers and Claude service accounts was the federation rule. A federation rule specified:

• Which external identities are trusted: e.g., “GitHub Actions workflows in the contoso/payments repository.”
• Which service account they map to: e.g., ci-pipeline@production.
• What conditions must be met: e.g., “only on the main branch” or “only from the us-east-1 region.”

# Example federation rule
federation_rule:
  name: "github-actions-payments-ci"
  issuer: "https://token.actions.githubusercontent.com"
  audience: "claude-platform"
  subject_pattern: "repo:contoso/payments:ref:refs/heads/main"
  service_account: "ci-pipeline@production"
  conditions:
    - claim: "repository"
      equals: "contoso/payments"
    - claim: "ref"
      equals: "refs/heads/main"

This rule meant that only GitHub Actions workflows running on the main branch of the contoso/payments repository could obtain a token for the ci-pipeline@production service account. A workflow in a different repository, or on a different branch, would be rejected.

38.3 Compatible Identity Providers

WIF was designed to work with any OIDC-compliant identity provider, making it compatible with the full range of infrastructure platforms that enterprises already used:

Provider	Use Case	Token Source
AWS IAM	EC2, ECS, Lambda workloads	IAM role OIDC tokens
GCP	Compute Engine, Cloud Run, Cloud Functions	GCP service account tokens
Kubernetes	In-cluster workloads	Service account tokens
Azure	Azure VMs, AKS, Azure Functions	Azure AD tokens
GitHub Actions	CI/CD pipelines	GitHub OIDC tokens
Okta	General-purpose workforce identity	Okta OIDC tokens
GitLab CI	CI/CD pipelines	GitLab OIDC tokens
CircleCI	CI/CD pipelines	CircleCI OIDC tokens

Note

The “any OIDC provider” compatibility was a deliberate design choice. Rather than building bespoke integrations with each platform, Anthropic implemented standard OIDC federation — the same standard that Google Cloud, AWS, and Azure use for workload identity. This meant any platform that could issue an OIDC token could authenticate to Claude without static keys.

38.4 Practical Examples

38.4.1 GitHub Actions

One of the most common use cases was replacing static API keys in GitHub Actions workflows:

# Before: static API key (insecure)
# env:
#   ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

# After: Workload Identity Federation (secure)
name: Code Review with Claude
on:
  pull_request:
    branches: [main]

permissions:
  id-token: write  # Required for OIDC token
  contents: read

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Authenticate via WIF
        run: |
          # Exchange GitHub OIDC token for Claude access token
          claude auth wif \
            --issuer https://token.actions.githubusercontent.com \
            --audience claude-platform \
            --service-account ci-pipeline@production
      - name: Run Claude code review
        run: claude review --pr ${{ github.event.pull_request.number }}

With this setup, the GitHub Actions workflow held no API keys. Instead, it used GitHub’s built-in OIDC token, which was automatically generated for each workflow run and was valid only for that specific execution.

38.4.2 AWS Lambda

For serverless workloads on AWS, WIF integration used IAM role OIDC tokens:

import boto3
import anthropic

def lambda_handler(event, context):
    # Get short-lived token from IAM role
    sts = boto3.client('sts')
    oidc_token = sts.get_caller_identity()['...']

    # Exchange for Claude access token via WIF
    wif_client = anthropic.WorkloadIdentityFederation(
        issuer='https://sts.amazonaws.com',
        service_account='lambda-processor@production',
        token=oidc_token,
    )
    access_token = wif_client.exchange_token()

    # Use scoped access token
    client = anthropic.Anthropic(access_token=access_token)
    response = client.messages.create(
        model='claude-haiku-4-5',
        messages=[{'role': 'user', 'content': event['prompt']}],
    )
    return {'result': response.content[0].text}

38.4.3 Kubernetes

In-cluster workloads could use Kubernetes service account tokens:

# Kubernetes service account with WIF annotation
apiVersion: v1
kind: ServiceAccount
metadata:
  name: claude-worker
  annotations:
    claude.ai/federation-rule: "k8s-worker@production"
    claude.ai/audience: "claude-platform"
---
# The pod's service account token is automatically
# projected as a volume mount
apiVersion: v1
kind: Pod
metadata:
  name: claude-processor
spec:
  serviceAccountName: claude-worker
  containers:
    - name: app
      image: my-app:latest
      env:
        - name: CLAUDE_WIF_TOKEN_PATH
          value: /var/run/secrets/tokens/claude-token

38.5 Claude Console Guided Setup

Anthropic provided a guided setup wizard in the Claude Console that walked administrators through creating service accounts and federation rules step by step:

1. Create a service account: Name it, assign roles, set spend limits.
2. Choose an identity provider: Select from pre-configured templates for AWS, GCP, Kubernetes, GitHub Actions, etc.
3. Define the federation rule: Specify which external identities map to the service account.
4. Test the configuration: The wizard generated a test command to verify the federation worked.
5. Deploy: Copy the configuration into your workload.

Tip

The guided setup included templates for common scenarios — “GitHub Actions CI/CD,” “AWS Lambda processing,” “Kubernetes cron job” — that pre-filled most of the configuration. For standard patterns, setup took less than five minutes.

38.6 Admin API Compatibility

WIF was fully compatible with the Admin API, meaning all service account and federation rule management could be scripted:

# Create a service account via Admin API
curl -X POST "https://api.anthropic.com/v1/admin/service-accounts" \
  -H "Authorization: Bearer $ADMIN_API_KEY" \
  -d '{
    "name": "ci-pipeline",
    "environment": "production",
    "roles": ["model:invoke", "batch:create"],
    "model_access": ["claude-sonnet-4-6", "claude-haiku-4-5"],
    "spend_limit": {
      "monthly_usd": 5000
    }
  }'

# Create a federation rule
curl -X POST "https://api.anthropic.com/v1/admin/federation-rules" \
  -H "Authorization: Bearer $ADMIN_API_KEY" \
  -d '{
    "service_account_id": "sa_abc123",
    "issuer": "https://token.actions.githubusercontent.com",
    "audience": "claude-platform",
    "subject_pattern": "repo:contoso/*:ref:refs/heads/main"
  }'

This enabled infrastructure-as-code patterns where service accounts and federation rules were defined in Terraform, Pulumi, or similar tools:

# Terraform example
resource "anthropic_service_account" "ci" {
  name       = "ci-pipeline"
  environment = "production"
  roles      = ["model:invoke"]
}

resource "anthropic_federation_rule" "github" {
  service_account_id = anthropic_service_account.ci.id
  issuer             = "https://token.actions.githubusercontent.com"
  audience           = "claude-platform"
  subject_pattern    = "repo:contoso/*:ref:refs/heads/main"
}

38.7 Gradual Migration: API Keys Work Alongside WIF

Anthropic recognized that organizations couldn’t migrate all their workloads to WIF overnight. Some systems had deeply embedded API key usage, and some legacy applications couldn’t easily be modified to support OIDC token exchange.

To enable gradual migration, API keys and WIF worked side by side:

• Existing API keys continued to work without modification.
• New workloads could be configured with WIF from the start.
• Individual workloads could be migrated one at a time.
• API keys could be phased out as each workload was converted.

Note

Anthropic recommended a migration strategy of: (1) Deploy WIF for all new workloads going forward. (2) Migrate high-risk workloads (CI/CD pipelines, public-facing services) first. (3) Gradually migrate remaining workloads. (4) Once all workloads use WIF, disable remaining API keys. The coexistence model meant there was never a “big bang” migration deadline.

38.8 Security Benefits Summary

Property	Static API Keys	Workload Identity Federation
Credential lifetime	Long-lived (months/years)	Short-lived (1 hour)
Rotation	Manual process	Automatic (every request)
Scope	Account-wide	Service-account-specific
Theft risk	High (usable if stolen)	Low (expired quickly)
Audit trail	Tied to key (shared)	Tied to service account (unique)
Revocation	Manual rotation	Automatic (remove federation rule)
Conditional access	None	Subject/claim-based conditions

38.9 Key Takeaways

• WIF replaces static API keys with short-lived, scoped credentials. No more long-lived secrets to steal, rotate, or worry about.
• Works with any OIDC provider. AWS IAM, GCP, Kubernetes, Azure, GitHub Actions, Okta, GitLab CI, CircleCI — any platform that issues OIDC tokens.
• Service accounts give machines their own identity. Each workload has a unique identity with scoped roles, spend limits, and an independent audit trail.
• Federation rules bind external identities to service accounts. Administrators control exactly which external workloads can obtain tokens, with conditions like repository, branch, and region.
• Claude Console provides guided setup. Pre-built templates for common scenarios make configuration a five-minute task for standard patterns.
• Fully compatible with the Admin API. All management is scriptable, enabling infrastructure-as-code with Terraform or similar tools.
• API keys coexist with WIF for gradual migration. No big-bang deadline — migrate workloads one at a time at your own pace.
• Security benefits are substantial. Short-lived credentials, automatic rotation, scoped permissions, reduced theft risk, and richer audit trails compared to static keys.
• WIF is the recommended authentication model for all machine-to-machine Claude usage. New workloads should use WIF from the start; existing workloads should migrate as priorities allow.