Replace Your Claude API Keys with Workload Identity Federation — Anthropic WIF Is Now GA

If you have an sk-ant- key sitting in a .env file, a CI secret store, or — worse — committed to a repo somewhere, you have a permanent security risk. That key doesn't expire. If it leaks, it's valid until someone manually revokes it.

Anthropic just fixed this. Workload Identity Federation (WIF) is now generally available on the Claude Platform, and it eliminates static API keys entirely for production workloads. Your AWS Lambda, GitHub Actions workflow, or Kubernetes pod now authenticates to the Claude API the same way it authenticates to everything else in your stack — with short-lived OIDC tokens issued by an identity provider you already operate.

This is a meaningful security improvement, and it's worth understanding even if you're not a security engineer. Here's the complete picture: what WIF is, how it works, and how to migrate your Claude integrations away from static keys.

What Is Workload Identity Federation — and Why Does It Matter for Claude?

Traditional API key authentication has a fundamental problem: the credential is static. You mint an sk-ant- key in the Claude Console, copy it somewhere, and it stays valid until you explicitly revoke it. In practice, this means:

• Keys get checked into source control accidentally
• Keys get copied into too many places (CI pipelines, developer machines, staging environments)
• Key rotation is manual and often skipped
• Audit logs show "API Key X was used" but not which system used it

Workload Identity Federation replaces this model with short-lived tokens issued on demand. Instead of a permanent secret, your workload presents a signed JWT from an identity provider (AWS IAM, Google Cloud, GitHub Actions, Azure Entra ID, Okta, Kubernetes) and exchanges it for a Claude API access token that expires in minutes.

The result: there is no static secret to create, store, rotate, or accidentally leak. A leaked token is useless minutes after it's issued.

How Claude Platform WIF Works

The flow has three steps, and once configured it's completely transparent to your application:

Every cloud workload already has an identity. An AWS Lambda function has an IAM role. A GitHub Actions workflow gets an OIDC token automatically. A Kubernetes pod can have a service account. These identities issue signed JWTs that prove "this workload is what it claims to be."

Your workload sends a POST request to /v1/oauth/token with the JWT from its identity provider. Anthropic validates the token against federation rules you've configured in the Claude Console — essentially, "trust JWTs from this AWS account with this IAM role" or "trust tokens from this GitHub Actions repository."

Anthropic validates the JWT, matches it against your federation rules, and returns a Claude API access token scoped to a service account in your organization. This token expires in minutes. The Anthropic SDK refreshes it automatically before expiry — your application code sees no difference.

Every exchange is logged against the service account in your audit trail, so you know exactly which workload made which Claude API calls.

Supported Identity Providers

WIF works with any OIDC-compliant identity provider. Anthropic has first-class support in the Console for the most common ones:

If your provider issues OIDC-compliant JWTs (which most modern IdPs do), it will work.

Setting Up WIF: GitHub Actions Example

GitHub Actions is the most common immediate use case — CI pipelines that call the Claude API for code review, test generation, or documentation. Here's the complete setup:

yamlname: Claude Code Review

on:
  pull_request:
    branches: [main]

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

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Request Anthropic token via WIF
        id: auth
        uses: anthropics/claude-code-action@v1
        # No ANTHROPIC_API_KEY needed — WIF handles it
        with:
          task: "Review the changed files for bugs and security issues"

The anthropics/claude-code-action handles the OIDC token exchange automatically when WIF is configured. There is no ANTHROPIC_API_KEY secret to create, rotate, or accidentally expose in logs.

Setting Up WIF: AWS Lambda Example

For AWS workloads, WIF binds to an IAM role ARN. The Lambda function's execution role becomes its Claude identity.

json{
  "issuer": "https://sts.amazonaws.com",
  "audience": "api.anthropic.com",
  "subject_claim": "arn:aws:sts::123456789012:assumed-role/MyLambdaRole/*"
}

pythonimport boto3
import anthropic

def handler(event, context):
    # Get OIDC token from AWS STS
    sts_client = boto3.client('sts')
    token_response = sts_client.generate_presigned_url(
        'assume_role_with_web_identity',
        Params={
            'RoleArn': context.invoked_function_arn,
            'RoleSessionName': 'claude-wif-session',
            'WebIdentityToken': get_oidc_token()  # via instance metadata
        }
    )
    
    # The Anthropic SDK handles token exchange automatically
    # when ANTHROPIC_WIF_TOKEN env var is set
    client = anthropic.Anthropic()  # No api_key= needed
    
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        messages=[{"role": "user", "content": event['prompt']}]
    )
    
    return response.content[0].text

When the ANTHROPIC_WIF_TOKEN environment variable is set (or the SDK detects AWS execution context), it automatically exchanges the workload token for a Claude API token. Your application code stays identical to the API key version.

Service Accounts: Per-Workload Identity and Audit Trails

WIF pairs with a new Service Accounts feature that gives each workload its own named identity in your organization.

Instead of multiple workloads sharing one API key (with a single audit entry "API Key X was used"), you create separate service accounts for each environment:

Service Account: prod-content-pipeline
  → Rate limit: 500K tokens/day
  → Permissions: messages:create
  → Audit logs: all requests logged under this identity

Service Account: ci-code-review
  → Rate limit: 100K tokens/day
  → Permissions: messages:create
  → Audit logs: separate from prod

Service Account: staging-testing
  → Rate limit: 50K tokens/day
  → Permissions: messages:create, admin: false

When something goes wrong — unexpected spend, a flagged output, a security incident — your audit log tells you exactly which workload made which request, at what time, from what identity.

Federation rules bind to service accounts, so you control the blast radius. A compromised GitHub Actions token can only act as the ci-code-review service account — it can't impersonate your prod workload.

Migrating from API Keys to WIF

WIF and API keys work in parallel, so migration is safe and incremental. Anthropic explicitly supports migrating one workload at a time.

The Admin API exposes endpoints for programmatic management of issuers, service accounts, and federation rules — useful if you're managing WIF configuration across many environments via Terraform or similar.

WIF vs. API Keys: When to Use Each

WIF is the right choice for almost all production workloads. The exception is interactive local development — where you're making API calls from your laptop, WIF adds overhead with no benefit. API keys remain the right choice for local development.

Key Takeaways

• Anthropic Workload Identity Federation (WIF) is now generally available on the Claude Platform as of June 2026
• WIF replaces static sk-ant- API keys with short-lived OIDC tokens that expire in minutes
• Supported identity providers: AWS IAM, Google Cloud, GitHub Actions, Microsoft Entra ID, Kubernetes, Okta, and any OIDC-compliant issuer
• New Service Accounts give each workload its own identity, rate limits, and audit trail
• The Anthropic SDK handles token exchange and refresh automatically — no code changes required beyond removing the api_key= parameter
• Migration is incremental — WIF and API keys work in parallel, so you can migrate one workload at a time
• For CI/CD (GitHub Actions especially), WIF eliminates secrets entirely with zero workflow code changes

Learning WIF for the CCA Exam

Authentication, authorization, and secure API design are covered in the Claude Certified Architect (CCA) exam, and WIF represents the current best practice Anthropic recommends for production workloads. Expect CCA exam questions around:

• When to use WIF vs. API keys in a system design
• How service accounts enable per-workload audit trails
• The security properties of short-lived tokens vs. static secrets
• Federation rule design for multi-environment organizations

If you're preparing for the CCA, AI for Anything's practice test bank covers the full authentication and security domain, with scenario-based questions that match the exam format.