Workload Identity Federation (WIF) is now generally available on the Claude Platform. If your engineering team calls the Claude API from AWS Lambda functions, GKE pods, or Azure container workloads: this changes how you should be authenticating — and it removes one of the most common enterprise security blockers to Claude adoption.
The Problem With Shared API Keys
The standard approach to Claude API access is a shared API key: generate one, store it in an environment variable or secrets manager, and inject it into your application. Simple to set up. A liability in production.
Shared long-lived credentials have four failure modes that compound each other:
Leak risk. A leaked key gives an attacker persistent access until you rotate. Rotation is disruptive enough that teams defer it, often for months.
No workload identity. A shared key doesn't tell you which workload made which API call. Audit trails are blurry at best.
No automatic expiry. An API key left in a decommissioned environment variable doesn't expire. It sits there waiting to be found.
Broad blast radius. One compromised key can expose your entire Claude usage , affecting every workload sharing it.
For organisations calling Claude at scale in production, particularly in regulated sectors, this is not an acceptable posture. WIF is the architectural answer.
How Workload Identity Federation Works
Instead of authenticating with a static API key, your cloud workload presents its own identity token , issued by your cloud provider's IAM system to that specific workload. The Claude Platform validates the token through your identity provider. If valid, access is granted. No shared secret is passed. No credential is stored in your application code or config.
The flow is straightforward:
Your workload requests a short-lived token from your cloud IdP (AWS STS, Google STS, or Azure AD)
Your workload presents that token to the Claude Platform
Claude Platform validates the token directly with your IdP via OIDC
Access is granted for the duration of the token, typically one hour
Token expires automatically ; no rotation required, no manual cleanup
If your team already uses WIF for other cloud services (S3 bucket access, GCS reads, Azure Key Vault) the pattern is identical. You are adding the Claude Platform as an additional trusted relying party in your existing OIDC configuration.
What This Enables in Practice
No secrets to store or rotate. Your CI/CD pipeline, Lambda functions, Kubernetes pods ; none of them need to hold Claude API keys. The cloud IAM system handles credential issuance and the short-lived nature handles rotation automatically. That eliminates an entire category of secrets management overhead.
Per-workload identity and access control. Each workload carries its own identity. You can grant different Claude Platform permissions to different workloads, audit access at the workload level, and revoke a specific workload's access without touching anything else.
Automatic credential expiry. Tokens are short-lived by design. There is no scenario where an old credential sitting in a forgotten environment gives an attacker persistent Claude API access.
The Australian Compliance Angle
In regulated Australian environments (financial services under APRA CPS 234, health data under the Privacy Act 1988, government workloads under ISM controls) zero-trust architecture has moved from best practice to procurement requirement. Zero-trust means every access request is verified, credentials are short-lived, and there is a clear audit trail tied to workload identity. WIF on the Claude Platform satisfies all three criteria.
For organisations targeting Essential Eight Maturity Level 2 or 3, the shift from shared long-lived keys to federated workload identity is exactly the kind of credential hygiene that auditors are looking for. A $50,000 security audit that flags shared API keys is a solvable problem. WIF removes the finding before the auditor writes it up.
Sydney-based financial services firms that have been cautious about Claude API adoption due to credential governance concerns now have a viable answer. WIF brings Claude's authentication model in line with what enterprises already require of their cloud-native tooling.
Getting Set Up
WIF is available now on the Claude Platform. Setup has three parts:
Configure your cloud IdP. Your AWS, GCP, or Azure environment needs to be configured to issue identity tokens for your Claude-calling workloads. If you already issue tokens for other services, this is an incremental change.
Configure the Claude Platform trust relationship. Add your IdP as a trusted OIDC provider in your Claude Platform settings. This tells the platform which tokens to accept and from which identity providers.
Update your workloads. Replace the static API key injection with token request logic. For most cloud-native runtimes, this is handled by the platform SDK — your workload requests a token from the metadata service, then presents it to Claude.
For teams already using WIF across their cloud estate, this is a familiar pattern. The main work is the one-time OIDC configuration on the Claude Platform side and updating the authentication call in your Claude-calling code.
Who Should Prioritise This
Not every team needs to switch immediately. If you are running Claude in a proof-of-concept or development environment, shared API keys are fine. But if any of the following apply, WIF should move up your backlog:
You are running Claude API calls in production from cloud-hosted workloads (Lambda, Cloud Run, AKS, EKS)
Your organisation is subject to APRA CPS 234, the Privacy Act, or sector-specific security controls
You are targeting Essential Eight Maturity Level 2 or above
You have a security or compliance team that reviews third-party API credential practices
You want per-workload audit trails for Claude API calls
The Broader Picture
WIF is part of a broader shift in how the Claude Platform is maturing for enterprise use. Centralised MCP authentication, audit logging, and now federated workload identity are all signals that Anthropic is building toward the security and governance requirements that large Australian enterprises actually have, not just the requirements that are convenient to satisfy.
For Australian technology teams evaluating Claude for production workloads, the authentication story is now significantly stronger. The credential management objection that used to come up in security reviews has a direct answer.
If you are planning a Claude Platform deployment and want to design the authentication architecture correctly from the start, get in touch with the Automata AI team. We help Australian engineering teams implement Claude securely in regulated and enterprise environments.
