Claude API Without Static Keys: Workload Identity Federation Guide (2026)

You've done it. You've hardcoded an ANTHROPIC_API_KEY into a GitHub Actions workflow, or pasted it into a .env file that somehow ended up in version control. It happens to everyone — and it's exactly the class of credential leak that causes real security incidents.

On June 17, 2026, Anthropic made that entire problem optional. Workload Identity Federation (WIF) is now generally available on the Claude Platform, letting your workloads authenticate to the Claude API with short-lived, scoped credentials — no static sk-ant-... key required. This guide covers what it is, how it works, and how to set it up today.

Why Static API Keys Are a Problem Worth Solving

Static API keys — the sk-ant-... strings you copy from the Claude Console — have one critical weakness: they don't expire. If one leaks into a public repository, a Docker image layer, a Slack message, or a log file, it remains valid until you manually rotate it. In a multi-team organization running dozens of automations, that rotation is easy to forget and hard to audit.

The numbers back this up. GitHub's secret scanning data consistently shows that API keys are the most common credential type exposed in public repositories. Anthropic's own blog post on WIF notes the pattern bluntly: "a static secret string that gets pasted into scripts and then leaks out of them."

WIF solves this at the architecture level rather than the process level. Instead of a shared secret that lives forever, each request is authenticated with a short-lived OIDC token tied to the specific workload, repository, or cloud identity that requested it.

What is Workload Identity Federation?

Workload Identity Federation is an authentication pattern where your workload proves its identity using a token issued by an identity provider (IdP) you already control — then exchanges that token for a scoped, short-lived credential to call an external service (in this case, the Claude API).

The core components:

• Identity Provider (IdP): The system that vouches for your workload's identity. Anthropic supports AWS IAM, Google Cloud, GitHub Actions, Kubernetes, SPIFFE, Microsoft Entra ID, and any standards-compliant OIDC issuer.
• OIDC Token: A signed JSON Web Token (JWT) your IdP issues at runtime, proving "this request is coming from job X in repository Y on branch Z."
• Federation Trust Rule: A configuration in the Claude Console that says "trust OIDC tokens from this issuer that match these claims."
• Anthropic Access Token: A short-lived token Anthropic issues after validating the OIDC token, used to call the Claude API.

The flow takes milliseconds and is fully automated — your code never handles a static secret.

How the WIF Flow Works End to End

Here's the complete authentication sequence when your CI pipeline calls the Claude API with WIF:

The key security property: if this credential leaks, it expires. There's nothing to rotate because nothing persists.

Setting Up WIF: GitHub Actions Walkthrough

GitHub Actions is the most common WIF setup for Claude API users. Here's the exact flow.

Step 1: Create a Service Account

In the Claude Console, navigate to Settings → Service accounts and create a new service account. Service accounts are prefixed with svac_ and represent a workload identity, not a person. Each service account has its own roles and audit trail.

Assign the service account to the relevant workspace and grant it the model access it needs (e.g., claude-opus-4-8, claude-sonnet-4-6).

Step 2: Configure the Federation Rule

Go to Settings → Workload identity → Connect workload, then select the GitHub Actions tile.

The wizard asks for:

• Repository: your-org/your-repo (pin this to the specific repo, not *)
• Branch or ref pattern: e.g., refs/heads/main for main branch only
• Service account: the svac_ account you just created

The resulting trust rule looks approximately like:

json{
  "issuer": "https://token.actions.githubusercontent.com",
  "subject_prefix": "repo:your-org/your-repo:ref:refs/heads/main"
}

Step 3: Update Your GitHub Actions Workflow

Add id-token: write permission to your workflow so it can request OIDC tokens, then let the Anthropic SDK handle the exchange automatically:

yamljobs:
  run-claude:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4

      - name: Run Claude API call
        env:
          ANTHROPIC_SERVICE_ACCOUNT_ID: svac_your_service_account_id
          ANTHROPIC_WORKLOAD_IDENTITY_PROVIDER: your_provider_id
        run: |
          python your_script.py

In your Python script, use the standard Anthropic SDK — it detects the WIF environment variables and handles token exchange automatically:

pythonimport anthropic

client = anthropic.Anthropic()  # No api_key needed — WIF handles auth

message = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Summarize this PR."}]
)
print(message.content)

No ANTHROPIC_API_KEY secret in your repo. No rotation to schedule. No leaked credentials in build logs.

Service Accounts: Per-Workload Identity

One of the most operationally valuable additions alongside WIF is service accounts as first-class entities on the Claude Platform.

Previously, most teams shared a single API key across all their automations — one key for the CI pipeline, the internal tool, the customer-facing chatbot, and the batch enrichment job. This creates two problems:

With service accounts, each workload gets its own identity. In practice this means:

• Per-workload rate limits: Your batch job can't starve your customer-facing app.
• Granular permissions: The CI bot gets read access to models; the production app gets full tool use; the analytics job gets a different workspace entirely.
• Meaningful audit logs: Every API call in the Console is attributed to svac_cicd_pipeline or svac_production_app rather than an anonymous key.

This is the same pattern AWS IAM roles, GCP service accounts, and GitHub environment secrets use — now native to the Claude Platform.

WIF with AWS IAM and Google Cloud

The pattern is identical for cloud-hosted workloads, just with different OIDC issuers.

Migrating Existing Workloads

Anthropic kept existing sk-ant-... keys working alongside WIF. Migration is therefore incremental:

The practical priority: any script running in CI/CD should move to WIF now. These are the environments where keys most commonly leak through build logs or accidental commits.

Key Takeaways

• WIF is GA as of June 17, 2026 — it's production-ready and Anthropic-supported.
• Short-lived tokens replace static keys — OIDC tokens expire automatically; there's nothing to rotate or revoke.
• Supported IdPs include: AWS IAM, Google Cloud, GitHub Actions, Kubernetes, SPIFFE, Entra ID, and any OIDC-compliant issuer.
• Service accounts give each workload its own identity — granular permissions, per-workload rate limits, and meaningful audit trails.
• Migration is non-breaking — static keys continue to work; you can move workload by workload.
• Scope your federation rules tightly — always pin to the narrowest repository, branch, and environment combination.

WIF Is a CCA Exam Topic

If you're preparing for the Claude Certified Architect (CCA-F) exam, authentication and security architecture are core competency areas. Understanding when and how to use WIF vs. static keys — including the trade-offs around credential lifecycle, blast radius, and audit trails — is exactly the kind of practical knowledge the exam tests.

The CCA exam specifically covers Claude Platform security patterns: API key management, service accounts, workspace isolation, and how to architect Claude deployments that meet enterprise security requirements.