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.
At a glance
What this is: Anthropic’s Claude API now supports native workload identity federation, but the article argues that this only solves one destination while leaving workload access fragmented and manually governed.
Why it matters: IAM, NHI, and platform teams should treat vendor-native federation as a local improvement, not a complete workload identity programme, because governance, attestation, and audit remain cross-vendor problems.
Context
Workload identity federation lets a service authenticate with a short-lived token from an identity provider instead of a static API key. In this article, the governance gap is not the federation mechanism itself, but the fact that one vendor-native integration does not create a coherent workload identity programme across an enterprise.
The practical issue for IAM teams is fragmentation. Every destination can bring its own trust rules, token lifetime, and logging model, which pushes identity design down into individual development teams unless a central platform owns issuance, attestation, and policy.
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. That fragmentation makes access harder to audit and easier to leave in place after a workload changes role or is decommissioned. The result is governance sprawl, where each destination looks controlled on its own but the overall programme is not centrally governable.
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. If the identity provider scopes a service account too broadly or accepts weak trust rules, federation will still mint a valid token for the wrong caller. The control boundary sits with the issuer, not the destination API.
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. If teams still depend on copied secrets for routine execution, federation has not yet changed the governance model in practice.
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.
Technical breakdown
How Claude API federation exchanges identity for a scoped token
Anthropic’s model accepts a JWT from an upstream identity provider, validates it against configured trust rules, and returns a short-lived access token scoped to a service account. That pattern removes the long-lived static key from the authentication path, but it still depends on the quality of the upstream issuer, the claims mapping, and the federation rule. The key architectural point is that federation is an exchange, not a governance plane. It narrows one credential surface without standardising how the rest of the workload estate authenticates.
Practical implication: treat federation as one control in a broader workload identity architecture, not as the architecture itself.
Why upstream IdP trust and workload attestation still matter
The security of federation is bounded by the identity provider that signs the token and by the precision of workload attestation. If the issuer trusts a Kubernetes service account too broadly, or GitHub Actions trust is mis-scoped, Anthropic will still mint a valid token for the wrong workload because it assumes the upstream identity was already proven. Attestation is the cryptographic binding of a token to a specific workload in a specific runtime context, and that binding is often weaker than teams assume when they rely on namespace-level or shared service-account identity.
Practical implication: verify that attestation happens at the right layer before you treat federated tokens as proof of the right workload.
Why per-vendor federation creates policy and audit sprawl
A federated setup for one API does not unify policy across the rest of the workload surface. Each destination can end up with its own trust configuration, claims logic, lifetime settings, and logs, which means policy is scattered and revocation becomes destination-specific. That is the core app-by-app IAM problem: developers solve the same identity plumbing repeatedly, and the IAM team loses a single control point for issuance, visibility, and lifecycle management. The governance issue is structural, not operational noise.
Practical implication: centralise policy and audit for workload access before the number of destinations makes manual federation ungovernable.
Threat narrative
Attacker objective: Obtain valid API access through trusted federation paths while avoiding the visibility and lifecycle controls that a central workload identity programme would provide.
- Entry occurs when a workload uses a short-lived OIDC token from its upstream identity provider instead of a static API key.
- Credential exposure risk shifts upstream, because a mis-scoped issuer or overbroad service account can still produce a valid downstream token for the wrong workload.
- Impact is limited to one destination when the federation is configured correctly, but the broader risk is fragmented trust across many APIs and no unified control plane.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Upstream attestation is the real control boundary: Federation only works when the identity provider can prove that the calling workload is the one the policy intended. If the upstream issuer is too broad, the downstream API merely inherits that weakness with a shorter-lived token. Practitioners should treat attestation as the first governance question, not a backend detail.
Vendor-native federation creates governance debt when teams scale it manually: Developer-owned token exchange logic, claims mapping, and fallback handling turn identity infrastructure into duplicated application code. That pattern weakens consistency and pushes security decisions into places that should not own them. The practitioner conclusion is that central policy enforcement matters more than vendor-by-vendor enablement.
Workload access is now an identity lifecycle problem, not just an authentication problem: The issue is not whether a token is short-lived, but whether access can be governed, reviewed, and revoked across every destination a workload touches. Once workload identity spans AI APIs, internal services, and cloud platforms, lifecycle control becomes the deciding factor in whether the programme is actually manageable.
Behavioral monitoring across non-human identities is the missing governance layer: Per-destination logs tell you what happened at one API, but they do not show what a workload did across its full session and tool chain. That is why cross-destination visibility becomes a named concept in workload IAM. Practitioners need a unified access record, not a set of isolated vendor logs.
From our research library:
- 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.
- Read next: Ultimate Guide to NHIs — What are Non-Human Identities
What this signals
App-by-app workload federation creates policy debt: Short-lived tokens reduce the risk of static secret reuse, but they do not solve the problem of how many places policy now lives. Once every destination has its own trust rules and logging, the IAM team loses the ability to govern workload access as one system.
A central workload identity layer changes the control question from whether one vendor supports federation to whether the organisation can issue, attest, and revoke access consistently across all destinations. That is the governance boundary that separates a local authentication improvement from a scalable identity programme.
For practitioners
- 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.
- Replace per-vendor logging with unified access records Correlate credential issuance, token exchange, and destination access into one record that shows what each workload did across a session, not only what happened inside a single API.
Key takeaways
- Vendor-native workload federation can remove static API keys from a single integration, but it does not by itself create enterprise workload governance.
- The main risk is fragmentation, because trust rules, logging, and revocation can still be split across destinations and development teams.
- A scalable programme needs central attestation, policy enforcement, and unified access records across the full non-human identity surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Federated Claude API access still depends on how workloads are authenticated upstream. |
| NHI-05 — Overprivileged NHI | Broad service-account trust and destination-specific policy can overgrant workload access. | |
| NHI-01 — Improper Offboarding | Per-vendor federation makes it easy to leave access behind when a workload or integration is retired. | |
| Recommendation — Validate federated workload authentication paths against NHI-04 before retiring static keys. Constrain workload entitlements so federated identities cannot inherit excess access. Tie workload offboarding to revocation across every destination the identity can reach. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centers on replacing static keys with managed federated authenticators. |
| Recommendation — Apply IA-5 to govern credential issuance, lifetime, rotation, and revocation for workloads. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Compromised upstream identity can enable valid downstream access and spread across services. |
| Recommendation — Map federated workload abuse to credential access and lateral movement in detection and response. | ||
Key terms
- Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
- Workload Attestation: Workload attestation is the process of proving that a workload is running in an expected, trusted environment before granting access. It helps stop copied credentials from being treated as universally valid and is a core control for reducing impersonation risk.
- Unified Access Record: A consolidated view of what a workload accessed across destinations, time, and policy boundaries. It matters because single-vendor logs only show one part of the session, while governance and incident response need a cross-system record of workload behaviour.
- Identity Provider: An identity provider is the system that authenticates a user or workload and issues the trust signal used by downstream applications. In federated environments, it becomes a high-value control point because compromise, misconfiguration, or over-trust at this layer can affect many services at once.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 4, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org