Workload identity federation is the pattern of authenticating a workload by who it is rather than what secret it holds. A CI job on GitHub Actions or GitLab CI, or a workload under any OIDC-compliant identity provider (IdP), already receives a signed identity token from its platform. Federation lets AWS IAM trust that token: the workload exchanges it for short-lived AWS credentials, assumes a role you control, and calls Claude Platform on AWS over SigV4. No AWS access key is ever created, stored in CI secrets, rotated, or leaked.
Why this fits Claude Platform on AWS so well
Because the platform authenticates with standard AWS SigV4, anything that can produce AWS credentials can call it — and web identity federation is a first-class citizen of the AWS default credential provider chain that the AnthropicAWS client reads. Per the official docs, the chain includes web identity via AWS_WEB_IDENTITY_TOKEN_FILE plus AWS_ROLE_ARN, the exact mechanism used by GitHub Actions federation and Kubernetes IRSA. When those variables (or the equivalent set delivered by your CI's AWS integration) are present, the SDK exchanges the identity token for role credentials and signs requests automatically.
The flow, end to end:
| Step | What happens | Secret stored? |
|---|---|---|
| 1 | CI platform / IdP issues the job a signed OIDC token | No — minted per run |
| 2 | AWS IAM validates the token against the trusted identity provider you registered | No — trust is configuration |
| 3 | The job assumes an IAM role scoped to your workspace ARN, receiving temporary credentials | No — short-lived STS session |
| 4 | AnthropicAWS() picks the credentials from the chain and SigV4-signs each request | No |
Setting up the IdP trust and the role's trust policy (including condition keys that pin which repository or pipeline may assume the role) is standard AWS IAM configuration — follow the official AWS documentation for your CI platform. On the Claude side, nothing special is needed: once credentials are in the chain, the application code is identical to any other deployment.
# Inside the CI job, after the AWS credentials step:
from anthropic import AnthropicAWS
client = AnthropicAWS() # web identity creds via the chain
resp = client.messages.create(
model="claude-haiku-4-5",
max_tokens=512,
messages=[{"role": "user", "content": "Summarize this diff: ..."}],
)Scope the assumed role tightly: for a CI job that runs evaluation prompts, an Allow on CreateInference, CountTokens, GetModel, and ListModels against the single workspace ARN is enough (see the policy templates). Remember the two required config values still apply — AWS_REGION and ANTHROPIC_AWS_WORKSPACE_ID — set them as plain CI variables; neither is a secret.
Three "federations" not to confuse
The word appears in three distinct places around this platform, and mixing them up burns hours:
1. Inbound federation to AWS (this article). Your IdP or CI platform federates into AWS IAM so a workload can assume a role.
2. Outbound web identity federation (account prerequisite). A one-time, per-account setting — aws iam enable-outbound-web-identity-federation — that lets the Claude Platform gateway call sts:GetWebIdentityToken server-side and forward a JWT to Anthropic. If it's disabled, every request fails with "Outbound web identity federation is disabled for your account," the platform's most common setup error. Verify with aws iam get-outbound-web-identity-federation-info.
3. First-party Anthropic WIF. The first-party Claude API has its own workload identity federation: exchanging an IdP JWT at POST /v1/oauth/token for a short-lived sk-ant-oat01-... bearer token, configured with variables like ANTHROPIC_WORKSPACE_ID. That mechanism targets the first-party API, not Claude Platform on AWS — note the env var differs from P-AWS's ANTHROPIC_AWS_WORKSPACE_ID, and OAuth authentication is not supported on Claude Platform on AWS at all. If you're federating to this platform, the path is always through AWS IAM and SigV4.
Where to go next
The same web-identity mechanism inside Kubernetes is covered in the IRSA guide; the chain that makes pickup automatic is in the credential chain. For CI pipelines end to end, see CI/CD integration.