Topic starter
04/06/2026 2:58 pm
TL;DR: Anthropic’s native workload identity federation for the Claude API removes static keys in one destination, but it still leaves workload access fragmented, per-vendor, and dependent on upstream identity provider trust, according to Aembit. The bigger issue is governance, not token format: one secure integration does not equal a scalable workload identity programme.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “Anthropic Workload Identity Federation: What It Gets Right – and What It Still Doesn’t Solve”.
Key questions
Q: What breaks when workload identity is managed app by app?
A: Teams get isolated federation rules, duplicated token exchange logic, and inconsistent revocation paths.
Q: Why do upstream identity provider settings matter so much for federated API access?
A: Because the downstream API trusts the upstream issuer to have already proved the workload’s identity.
Q: How do you know if workload identity federation is actually reducing risk?
A: You should see fewer long-lived credentials stored in containers, secrets managers, and pipeline variables, plus a smaller set of systems able to mint or reuse Anthropic access.
Practitioner guidance
- Centralise workload identity issuance Move token exchange and credential issuance out of individual application code so developers request access through one governed layer instead of repeating vendor-specific federation logic.
- Validate upstream attestation scope Review the identity provider claims, service-account scope, and trust rules that mint downstream tokens so the wrong workload cannot inherit valid access through a broad issuer policy.
- Inventory every destination a workload can reach Map AI APIs, internal services, data platforms, and automation targets together so revocation and policy changes can be applied across the full access surface rather than one vendor at a time.
Bottom line: Vendor-native workload federation can remove static API keys from a single integration, but it does not by itself create enterprise workload governance.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
04/06/2026 3:09 pm
App-by-app federation is not a workload identity strategy: It is a point control that reduces one credential risk while leaving the rest of the workload estate unmanaged. Every destination-specific trust rule adds another place where policy can drift, logging can fragment, and revocation can become inconsistent. The implication is that workload identity must be governed as a programme, not as a series of isolated integrations.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: When should organisations move from vendor federation to central workload IAM?
A: They should move as soon as workloads call more than one external service or internal system and the number of trust relationships becomes hard to keep consistent. At that point, vendor-native federation solves local authentication but not enterprise policy, audit, or lifecycle management across the full workload estate.
👉 Read our full editorial: Anthropic workload identity federation exposes the limits of appbyapp IAM