AI Security

Anthropic Workload Identity Federation: Replacing API Keys with Short-Lived Tokens for Healthcare AI

Aaron with AI Assist May 05, 2026 13 min read 3 views
AI Security Series #37

Anthropic just rolled out Workload Identity Federation for the Claude API, enabling authentication with short-lived OpenID Connect tokens from your existing identity provider instead of long-lived API keys. This is a fundamental shift in how organizations secure access to AI services—replacing static credentials that live forever with tokens that expire in minutes.

For healthcare organizations already managing complex identity infrastructure across AWS, Azure, Google Cloud, and Kubernetes clusters, this represents an opportunity to bring AI API authentication into the same zero-trust framework that governs access to PHI and clinical systems. Here's what security teams need to know.

What Workload Identity Federation Is

Workload Identity Federation (WIF) allows applications and services to authenticate to the Claude API using tokens issued by identity providers you already trust and operate. Instead of generating an sk-ant-... API key and embedding it in your application environment, your workload presents a JWT from AWS IAM, Google Cloud, Azure Managed Identity, GitHub Actions, Kubernetes, or any standards-compliant OIDC provider. Anthropic validates the token and exchanges it for a short-lived Claude API access token.

The mechanics follow RFC 7523's jwt-bearer grant: your workload obtains an identity token from its native IdP, posts it to POST /v1/oauth/token, and receives an Anthropic access token with a configurable lifetime between 60 and 86,400 seconds (default 3600). The Anthropic SDKs handle token exchange and automatic refresh before expiration.

This eliminates the operational and security burden of managing static API keys. No keys to mint, distribute through CI/CD secrets, rotate on a schedule, or revoke when an engineer leaves. The credential lifecycle is handled by the platform your workload already runs on.

The Three-Component Architecture

Anthropic's implementation requires configuring three resources in the Claude Console before any workload can federate. Together they express a trust policy: "tokens signed by issuer X, with claims matching pattern Y, may act as service account Z."

Service Accounts

A service account (svac_...) is a non-human identity within your Anthropic organization. Unlike API keys—which are credentials—a service account is an identity that has credentials minted for it on demand. Service accounts live at the organization level and become active in a workspace when added to that workspace's members. At token exchange time, Anthropic verifies the federation rule's workspace matches one of the service account's workspace memberships, and the minted token inherits that workspace's rate limits and usage attribution.

Federation Issuers

A federation issuer (fdis_...) registers an OIDC identity provider with your organization. This tells Anthropic "JWTs signed by this provider may assert workload identity for my org." An issuer has two configuration elements: the exact iss claim value from the provider's JWTs (for example, https://token.actions.githubusercontent.com or https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLE) and the JWKS source for public key verification. Most managed providers support automatic discovery via /.well-known/openid-configuration; private or air-gapped clusters can use explicit JWKS URLs or inline key upload.

Federation Rules

A federation rule (fdrl_...) maps JWT claims to service accounts. Rules define match conditions (subject prefix, audience, exact claim values, or CEL expressions for complex logic), a target service account, and the OAuth scope and token lifetime granted when the rule matches. At least one of subject_prefix, claims, or condition must be set, and all configured matchers must pass for the JWT to be accepted. Rules are evaluated by ID—the client specifies which rule to use in the exchange request, and Anthropic verifies the JWT satisfies that rule's match criteria.

How This Changes Healthcare AI Security

Healthcare organizations operate under regulatory frameworks that treat static credentials as compliance liabilities. HIPAA Security Rule §164.312(a)(2)(i) requires unique user identification, and §164.312(d) mandates controls over person or entity authentication. While those requirements target EHRs and systems containing ePHI, internal security standards increasingly apply the same rigor to all systems touching the clinical environment—including AI inference services that process clinical notes, generate discharge summaries, or assist with diagnostic coding.

Long-lived API keys create several problems in this context. They're hard to attribute to specific workloads or teams, making post-incident forensics difficult. Rotation requires coordination across teams and environments, and the window between generation and first use is a credential exposure risk. Keys stored in CI/CD secrets, container environment variables, or configuration management systems expand the attack surface. And when a key is compromised, the blast radius includes everything that key can access across all workspaces it's scoped to.

Workload Identity Federation addresses these issues through platform-native credential management. Each token exchange creates an audit event linking a specific workload identity (the JWT's sub claim) to a specific service account to a specific Anthropic workspace. Token lifetimes measured in minutes instead of months reduce the value of stolen credentials. And federation rules can enforce conditions beyond identity—for example, requiring tokens to originate from specific AWS accounts, Google Cloud projects, or Kubernetes namespaces.

Zero-Trust Alignment

Most healthcare organizations are implementing zero-trust architectures, whether driven by regulatory pressure (OCR's 2024 HIPAA Security Rule guidance on cloud security) or practical necessity (ransomware defense in depth). Zero-trust mandates explicit verification at every access decision and assumes breach—no implicit trust based on network location or static credentials.

Federation aligns with this model. Every Claude API request is backed by a fresh token exchange that re-verifies the workload's identity against your IdP's current state. If you revoke an AWS IAM role or delete a Kubernetes service account, that workload can no longer obtain tokens to exchange for Claude API access. There's no API key sitting in a secret store that continues working until someone remembers to rotate it.

Vendor and CI/CD Pipeline Security

Healthcare software supply chains involve multiple vendors, contractors, and third-party services. A common pattern is a vendor-built application running in your AWS environment that calls the Claude API for clinical documentation workflows. Traditionally, you'd generate an API key, send it to the vendor (often via email or a ticketing system), and hope they store it securely.

With federation, you configure an AWS IAM role with appropriate permissions, attach it to the vendor's ECS task or Lambda function, register the role's identity in your federation issuer, and create a rule mapping that role to a service account scoped to a single workspace. The vendor's code authenticates using the ambient IAM credentials AWS provides. You never generate a long-lived secret, and you can audit which specific IAM role acted as which service account.

CI/CD pipelines present a similar challenge. GitHub Actions workflows that deploy AI-enhanced features or run integration tests against Claude API need credentials. GitHub's OIDC token provider issues unique tokens to each workflow run with claims identifying the repository, workflow, and job. You can create federation rules that match on repository owner and name, ensuring only your organization's repos can exchange tokens for API access, and further restrict by workflow file path or environment name.

Implementation Considerations

While federation removes static API keys from the Claude API surface, it does not eliminate all credential management challenges. The trust chain is only as strong as the upstream identity provider. If your AWS root account credentials are compromised, or your Kubernetes cluster's OIDC signing key is leaked, an attacker can mint valid tokens that pass Anthropic's verification.

Federation Rules Must Be Restrictive

Anthropic's documentation emphasizes: be as specific as your IdP's claims allow when constructing match conditions. A rule that only checks iss and accepts any sub effectively grants API access to any workload in your AWS account or Kubernetes cluster. For AWS, match on both the IAM role ARN and account ID. For Google Cloud, match on the service account's numeric unique ID (which Google never reuses) and its email address. For Kubernetes, match on namespace and service account name.

If using GitHub Actions, structure repository patterns to prevent forks or unaffiliated repos from triggering exchanges. GitHub's OIDC token sub claim includes repo:owner/name; use exact match or prefix match that locks to your organization.

Token Lifetime and Refresh Strategy

The default token lifetime is 3600 seconds (1 hour), with a configurable range of 60 to 86,400 seconds. Shorter lifetimes reduce the blast radius of a compromised token but increase the frequency of token exchanges, which introduces additional latency and potential failure points. The Anthropic SDKs implement a two-tier refresh schedule: advisory refresh at expiry minus 120 seconds (non-blocking if the exchange fails, allowing the cached token to be used for ~90 more seconds), and mandatory refresh at expiry minus 30 seconds (blocking, raises an error if the exchange fails).

For long-running workloads like inference servers or batch processing jobs, the SDK automatically re-reads the identity token file on each exchange, transparently handling rotated projected tokens (common in Kubernetes service account tokens, which rotate well before their exp).

Migration Path from API Keys

Anthropic provides a zero-downtime migration workflow. Configure federation in parallel with your existing API key, leaving ANTHROPIC_API_KEY in place. The SDK's credential precedence chain puts ANTHROPIC_API_KEY above the federation environment variables, so the key continues to work during testing. Verify the federation rule matches your workload's token. Once confirmed, unset ANTHROPIC_API_KEY from container environments, CI secrets, and shell profiles. The SDK automatically falls through to federation. After the workload has been running on federated tokens for a validation period, revoke the API key in the Claude Console.

The CLI command ant auth status reports which credential source won, useful for debugging precedence issues during migration.

Supported Identity Providers

Anthropic's documentation includes configuration guides for six identity provider types, each with platform-specific claim structures and trust configuration patterns.

ProviderToken SourceKey Claims
AWSSTS GetCallerIdentity or EKS IRSA projected tokensarn, account
Google CloudMetadata server identity tokenssub (numeric ID), email
AzureManaged Identity (IMDS) or Entra Workload ID (AKS)sub, tid (tenant ID)
GitHub ActionsActions OIDC endpointrepository, workflow, job_workflow_ref
KubernetesProjected service account tokenssub (namespace:serviceaccount format)
OktaService application client credentials flowsub (client ID), custom claims

For self-managed Kubernetes clusters or other OIDC providers without public discovery endpoints (private GitLab instances, internal identity platforms), you can upload the JWKS document directly via the Console's inline mode. This supports air-gapped environments and compliance requirements that prohibit exposing OIDC metadata to the public internet.

Defense in Depth Pairing

Anthropic's documentation explicitly states: "Workload Identity Federation strengthens your security posture by removing static credentials from Anthropic's surface and replacing them with tokens that expire in minutes rather than never. It is not a complete security story on its own: federated authentication is only as strong as the upstream identity provider that signs the JWT."

This is a critical framing. Federation is a control layer, not a silver bullet. Pair it with:

IP allowlisting at the IdP level. AWS IAM policies can restrict sts:AssumeRole to specific CIDR blocks. Google Cloud and Azure support similar constraints. This limits which networks can obtain tokens eligible for exchange.

Conditional access policies. Microsoft Entra ID (Azure AD) supports conditional access that evaluates device compliance, location, and risk signals before issuing tokens. Apply these policies to managed identities used by clinical workloads.

Audit logging on both sides. Enable CloudTrail in AWS, Cloud Logging in GCP, and Activity Log in Azure to capture when IAM roles or service accounts request identity tokens. Cross-reference these logs with Anthropic's workspace usage logs (accessible via the Usage and Cost API) to detect anomalies—for example, token exchanges from unexpected geographies or at unusual times.

Separation of duties. Use separate service accounts for different workload types. A service account for batch inference on de-identified research data should not be the same service account used for real-time clinical documentation in production. Federation rules make this separation straightforward—each workload gets its own rule mapping to its own service account, and blast radius is contained per workspace.

What This Means for Healthcare Security Programs

The introduction of Workload Identity Federation for Claude API represents a maturation of AI service security controls, bringing them in line with expectations for enterprise infrastructure. For healthcare organizations, this creates an opportunity to eliminate a class of credential management problems and bring AI authentication into the same governance framework that manages access to clinical systems and PHI.

In practical terms, this means:

Credential lifecycle management becomes platform-native. When your IdP already handles identity for AWS, Azure, or Kubernetes workloads, extending that to Claude API access is an incremental configuration change, not a new secret management discipline.

Audit trails improve. Service account mappings let you attribute API usage to specific workloads or teams, supporting post-incident analysis and compliance reporting. "Which application generated this inference request?" becomes answerable through logs, not archeology.

Blast radius containment improves. A compromised token expires in minutes or hours. A compromised API key works until you notice and rotate it. Token expiration limits the window for exploitation.

Compliance posture strengthens. Demonstrating controls over non-human identity authentication is increasingly part of SOC 2, HITRUST, and internal risk assessments. Federation provides a defensible architecture where credentials are short-lived, issuance is logged, and trust is re-verified on every exchange.

The flip side is that federation introduces dependencies. If your IdP is unavailable—AWS STS is down, your Kubernetes API server is unreachable, GitHub's OIDC endpoint is returning errors—your workloads can't exchange tokens, and API calls fail. This is a feature, not a bug (if your identity platform is compromised or unavailable, you want dependent services to fail closed, not continue using stale credentials), but it requires operational readiness for this failure mode.

Adoption Path

Organizations don't need to migrate all workloads at once. A phased approach makes sense:

Phase 1: New workloads and greenfield deployments. Configure federation for new AI-powered features before they reach production. This avoids creating new API keys that later need migration.

Phase 2: High-risk workloads. Prioritize workloads that access clinical data, run in vendor-managed environments, or operate in CI/CD pipelines. These are the environments where static credential exposure risk is highest.

Phase 3: Stable production workloads. Migrate established applications during maintenance windows, using the zero-downtime migration workflow Anthropic provides. Test federation in parallel, verify correct token exchange, then remove the API key.

Phase 4: Key retirement. Once all workloads have migrated, revoke remaining API keys. Some organizations will want to maintain one emergency break-glass key in a secure vault, accessible only through elevated approval workflows.

The Bigger Picture

Anthropic's rollout of Workload Identity Federation follows similar moves by Snowflake, HashiCorp (Terraform Cloud), and cloud platforms themselves. The pattern is converging: services that were historically authenticated with long-lived keys are migrating to OIDC-based federation. This reflects both maturation of the OIDC standard and enterprise demand for credential lifecycle automation.

For healthcare security teams, this convergence is an opportunity. Instead of managing separate credential types for each vendor (API keys for AI services, service principals for Azure resources, IAM roles for AWS, service accounts for GCP), federation creates a unified model where the platform-native identity becomes the root of trust, and vendor-specific credentials become ephemeral tokens derived from it.

The challenge is that this model assumes your IdP is correctly configured, your federation rules are appropriately restrictive, and your audit logging is comprehensive. Organizations that have already implemented zero-trust for clinical systems will find federation intuitive. Organizations still managing infrastructure with static credentials and implicit trust will find it a forcing function for broader identity modernization.

This is entry #37 in the AI Security series. For related coverage, see Claude Platform on AWS: Data Residency and Boundary Controls for Healthcare AI.

Key Links