Claude on Vertex AI authenticates with Google Cloud credentials — the AnthropicVertex client picks up Application Default Credentials, and production workloads normally run as service accounts granted roles/aiplatform.user. That's straightforward when the workload lives on Google Cloud. It gets awkward when it doesn't: a backend on AWS, a CI pipeline in GitHub Actions or GitLab, a job in a non-GKE Kubernetes cluster, or anything behind Okta, Active Directory, or another identity provider.
The historical answer was to export a service account key — a long-lived JSON credential file — and ship it to the external environment. Google's documentation is blunt about why that's a problem: exported keys are a security risk if mismanaged. They don't expire, they leak into repositories and CI variables, and revoking them is a manual scramble. Workload Identity Federation (WIF) exists to eliminate them.
How the exchange works
WIF lets workloads outside Google Cloud — Google's docs list AWS, Azure, GitHub, GitLab, Kubernetes, Okta, Active Directory, and any OIDC or SAML 2.0 provider — obtain short-lived Google Cloud credentials via token exchange with the Security Token Service (STS). The workload proves its identity with a token from its own environment (an OIDC token, which is a signed identity assertion from a standards-compliant identity provider), and Google's STS trades it for a temporary Google credential. No Google secret is ever stored in the external environment; trust is established by configuration, not by a copied key.
The three building blocks
WIF is organized into a small hierarchy:
| Resource | What it represents | Practical guidance |
|---|---|---|
| Workload identity pool | A container for external identities | One pool per external environment (e.g. one for AWS, one for CI) |
| Pool provider | The trust relationship to one IdP | Points at your OIDC/SAML issuer — AWS, GitHub, GitLab, Okta, etc. |
| Attribute mappings & conditions | Which external identities may authenticate, and as what | Map token claims (repo name, role ARN, subject) and restrict tightly |
Access is then granted in one of two documented ways: directly to the external identities (IAM bindings on the federated principals themselves) or through service account impersonation, where federated identities are allowed to act as a designated service account. Either way, the attribute mappings and conditions are your blast-radius control — for a GitHub Actions provider, for instance, conditions on the mapped repository claim ensure that only your deployment repo, not any repository presenting a GitHub token, can authenticate.
Wiring it to Claude specifically
Nothing about the Claude side changes. Whatever principal your federated workload ultimately acts as — the mapped external identity or the impersonated service account — needs the same IAM as any other Vertex AI caller: the aiplatform.endpoints.predict permission, included in roles/aiplatform.user (Vertex AI User). Model enablement in Model Garden remains a separate, one-time admin task requiring roles/consumerprocurement.entitlementManager — see the two-roles article.
Your application code doesn't change either. WIF plugs into Application Default Credentials via a credential configuration file (generated when you set up the provider), so the standard client works as-is once the environment is configured:
from anthropic import AnthropicVertex
# ADC resolves the WIF credential configuration automatically
client = AnthropicVertex(project_id="my-project", region="us-east5")
message = client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello from AWS"}],
)Why security teams prefer this, in audit terms
- Nothing long-lived to leak. Credentials are short-lived tokens minted per exchange; there is no key file to rotate, vault, or accidentally commit.
- Revocation is configuration. Deleting or tightening the pool provider severs access for that whole environment at once.
- Attribution survives. Federated calls appear in Cloud Audit Logs under their mapped identities — pair WIF with DATA_READ audit logging so every Claude prediction is attributable to a specific external workload.
Where to go next
Start with the ADC auth guide if your workloads are still on Google Cloud, and least privilege for scoping what a federated identity may do once inside.