Anthropic Workload Identity Federation with Riptides

Anthropic recently added workload identity federation support for Claude, and our reaction was:

This is exactly the direction the industry should be moving toward.

Because the alternative was getting increasingly awkward.

Modern AI workloads need access to everything. Claude APIs, MCP servers, GitHub, Slack, cloud providers, internal services, databases, customer systems. Once you start wiring agents and tools together, credentials begin spreading through runtime environments surprisingly fast.

Most systems still handle this the old way: generate another API key, push it into a secret store, inject it into a container, and hope it does not accidentally leak somewhere along the way.

This works until you start dealing with highly dynamic workloads, transient agents, orchestration systems, MCP servers, or tool chains where credentials move constantly between components. At that point, operational overhead alone becomes painful, let alone the security implications.

This is why Anthropic’s workload identity federation support is genuinely useful.

You can read the documentation here:

https://platform.claude.com/docs/en/manage-claude/workload-identity-federation

Instead of distributing permanent Anthropic credentials into workloads, Claude can now trust workload identities coming from systems the workload already runs under.

That model maps directly onto how Riptides already works.

A workload running under Riptides can securely communicate with Claude without developers manually managing Anthropic API keys at all. The workload itself does not need to implement token refresh logic, credential rotation, revocation handling, or federation flows. Riptides handles the entire lifecycle transparently underneath using runtime workload identity.

The actual configuration is intentionally very small.

First, you define the Anthropic federation configuration itself as a CredentialSource:

apiVersion: core.riptides.io/v1alpha1
kind: CredentialSource
metadata:
  name: anthropic-wif
  namespace: riptides-system
spec:
  anthropic:
    organizationId: 6bf...........................b3b9
    workspaceId: default
    serviceAccountId: svac_012Vh.........QsxofNQzN3
    federationRuleId: fdrl_01X3a.........5iLuiRdjvs

Then you bind it to workloads using a CredentialBinding:

apiVersion: core.riptides.io/v1alpha1
kind: CredentialBinding
metadata:
  name: anthropic-wif
  namespace: riptides-system
spec:
  credentialSource: anthropic-wif
  propagation:
    injection:
      selectors:
      - svc:name: anthropic-api
  workloadID: riptides-demo/app/foo

That is it.

The workload simply talks to Claude normally. Riptides intercepts the connection, handles workload identity federation with Anthropic, injects short-lived credentials transparently, and continuously manages the credential lifecycle underneath.

Rotation, expiration, and revocation are all handled automatically.

More importantly, the application itself never needs to permanently hold reusable Anthropic credentials in process space.

That becomes increasingly important once you start dealing with real-world AI infrastructure instead of isolated demos. Agents, MCP servers, orchestration systems, and temporary workloads create environments where distributing static credentials everywhere becomes both operationally difficult and fragile from a security perspective.

The healthier model is letting workloads authenticate using runtime identity while the infrastructure handles the federation and credential lifecycle automatically.

That is exactly what Riptides was already built around, which is why Anthropic’s federation model fits into the platform naturally.

---

If you enjoyed this post, follow us on LinkedIn and X for more updates. If you'd like to see Riptides in action, get in touch with us for a demo.