Workload Identity vs API Keys for LLM API Access: Provider Federation Options, Cost Exposure and Migration

A model provider API key is a bearer credential that spends money and reaches your data for whoever holds it, and most model providers now let workloads authenticate without one. The choice between workload identity and API keys for LLM access looks like the familiar cloud debate, but three things make it different: the attacker's payoff is immediate compute spend that can be resold, the providers differ widely in what federation they offer, and many organisations put an AI gateway in the middle that holds keys on everyone's behalf. This guide covers only those LLM-specific points: which model APIs accept federated workload identity as of November 2026, how cost exposure differs between the two models, how to broker access through a gateway, and how to migrate. It is for platform engineers, AI platform owners and identity architects. General federation mechanics are in Workload Identity Federation vs Static Cloud Keys, and key hygiene and detection for model keys are in the LLMjacking Guide; this page does not repeat them. Providers are listed alphabetically throughout; the order is not a ranking.

Key takeaways

• Federation is now available across the major model APIs: the three hyperscaler platforms authenticate through their cloud IAM, and the Anthropic Claude API and the OpenAI API both document workload identity federation that exchanges an external token for a short-lived provider token.
• Exposure is measured in spend per hour: Sysdig's first LLMjacking research estimated a worst-case cost above $46,000 per day for a single stolen cloud credential, so the lifetime of the credential is a direct cost control.
• Leftover keys silently win: SDKs check for an API key before federation settings in at least one provider's documented precedence, so migration is finished only when the key variable is removed and the key deleted.
• A gateway moves the key, it does not remove it: if the gateway holds provider keys, it becomes the single most valuable credential store in the AI stack; prefer a gateway that itself uses workload identity to reach providers.
• Turn key access off where the platform allows: deny bearer-token calls on Amazon Bedrock, set disableLocalAuth on Azure, and remove keys elsewhere, then verify with an old key that it is refused.

The short answer

Use workload identity wherever the model provider and the workload's runtime support it, which in November 2026 covers most production paths. Keep API keys only for exploration, for tools that accept nothing else, and for the gateway-to-provider hop when no federation exists there, and contain those keys with scope, expiry, spend limits and monitoring. The API Keys vs OAuth Tokens Guide explains the general difference between static and issued credentials; the rest of this page is about how it plays out for model APIs.

Threat model for each option

API keys

• How it works: the provider issues a long-lived secret string tied to a project, workspace or account. The workload sends it as a header on every call. Anyone who copies it can call the API until it is revoked.
• What attackers do with it: Sysdig's May 2024 research found a script that tested stolen credentials against ten AI services, including Anthropic, AWS Bedrock, Azure, GCP Vertex AI, Mistral, OpenAI and OpenRouter, and a reverse proxy that lets an operator resell access while the account owner pays. Keys leak through repositories, notebooks, client applications and malware. The xAI API key leak stayed valid for about two months after a scanner first flagged it in a public repository.
• Blast radius: spend up to the account's quota across every region and model the key can reach, access to stored files, fine-tuned models and conversation state where the API exposes them, and abuse of the account for content the owner is then associated with.
• ATT&CK: T1552.001 Credentials In Files for the leak and T1496.004 Cloud Service Hijacking for the abuse.

Workload identity

• How it works: the workload's own platform (a Kubernetes cluster, a cloud runtime, a CI system or a SPIFFE issuer) gives it a short-lived signed token. The model provider, or the cloud IAM in front of it, verifies the issuer and claims and returns a short-lived access token mapped to a service account or role. Nothing long-lived is stored with the workload.
• What attackers do instead: steal a minted access token from a running workload (T1528 Steal Application Access Token), compromise the upstream identity provider or its signing keys, or exploit a trust rule with a loose subject condition so that their own workload matches it.
• Blast radius: bounded by token lifetime and by the scope the mapping grants. The trust configuration is now the boundary, so changes to it need the same review as a privileged role assignment. Anthropic's documentation describes federation as defence in depth that is only as strong as the upstream identity provider.

Comparison table

Federation options by model provider

Checked against each provider's documentation on 14 November 2026. Features and names change quickly in this market, so confirm against the current documentation before you design around a detail.

Availability: Amazon Bedrock: short-term API keys are usable only in the Region where they were generated. Anthropic: federation set-up needs the admin, owner or primary owner role, and issuer and JWKS URLs must be public HTTPS on port 443 unless the JWKS is supplied inline. Google Cloud: express mode keys are for @gmail.com accounts and do not produce customer-accessible DATA_READ audit logs, so use Application Default Credentials when per-caller attribution matters. Microsoft: Entra tokens are accepted on the resource's custom subdomain, not the regional endpoint. OpenAI: for issuers not on the documented list, the documentation asks customers to contact support; Codex federation is documented as beta and enabled per workspace.

Trust rule details that matter

• Anthropic Claude API: a rule must set at least one matcher (subject_prefix, audience, claims or a CEL condition) and all configured matchers must pass. Tokens carrying a jti claim are single-use by default; turning check_jti off affects every rule on that issuer. Minted token lifetime is the lesser of the rule setting and twice the remaining lifetime of the presented JWT.
• OpenAI API: mapping keys can match raw claims such as sub, aud and iss or derived attributes built with CEL, with exact values or one trailing wildcard on a non-empty prefix. A token is issued only if exactly one enabled mapping matches, and permissions are never combined across mappings. No refresh token is issued; the workload repeats the exchange.
• Cloud IAM paths (Amazon Bedrock, Google Cloud, Microsoft Azure): the trust conditions live in the cloud's own federation configuration, covered per platform in the Workload Identity Federation Guide, with GitHub specifics in the GitHub Actions OIDC Federation Hardening Guide.

Cost exposure: why lifetime is a financial control

For most stolen credentials the damage is data access. For model credentials it is also direct spend, and it starts within minutes. Sysdig's LLMjacking research observed attackers first checking access with a deliberately invalid model invocation and checking whether invocation logging was enabled before using the account, then estimated the worst case for one compromised cloud account at over $46,000 per day across four regions. Three properties of the credential decide how much of that a leak can cost:

• Lifetime: a key that stays valid for weeks after a leak, as in the xAI case, multiplies daily exposure by weeks. A federated token that expires in an hour caps exposure at an hour unless the attacker can mint new ones.
• Reach: a key scoped to one project, workspace or model deployment with a per-project spend limit caps exposure regardless of lifetime. Set provider-side spend limits or budgets as a backstop for both options.
• Attribution: per-workload service accounts let you see which service is spending; a shared key hides it, which slows detection.

The spend-based detection signals themselves (new models, new regions, disabled invocation logging, sudden token volume) are covered in the LLMjacking Guide, and response steps in the LLMjacking Response Playbook.

Gateway brokering

Many organisations route model traffic through an AI gateway for routing, logging, guardrails and cost allocation. The gateway changes the credential question into two hops, and each hop needs its own answer.

A gateway that holds every provider key fails badly: one compromise exposes all providers at once. Where a provider hop still needs a key, store it in a secrets manager the gateway reads at start-up with its own identity, scope it to the gateway's project, give it a spend limit and alert on use from any other source address. Gateway design is covered in the AI Gateway and LLM Gateway Guide.

Decision criteria

Small and large organisations: a small team on one cloud gets most of the benefit by using that cloud's IAM path for its hosted models and deleting provider keys. A large organisation with several providers usually needs a gateway plus federation at both hops, an inventory of every remaining key with a named owner, and policy-as-code for the trust rules.

Migration from keys to workload identity

1. Inventory keys: list every provider key per project or workspace, its last use, the services injecting it and its owner. Secret scanning across repositories and CI finds the copies; see the Git Secret Scanning Guide.
2. Create one service account per workload: do not map all workloads to a single federated identity, or attribution is lost again.
3. Write narrow trust rules: match issuer, audience and the exact subject (Kubernetes namespace and service account, repository and branch, SPIFFE ID). Avoid wildcards except a deliberate trailing prefix.
4. Run federation alongside the key in a pilot: confirm which credential the SDK is actually using. For the Claude API the documented command is ant auth status; for other providers check request logs for the service account or role rather than the key.
5. Remove the key from the workload: unset the environment variable in CI secrets, container specs and shell profiles, then confirm federation is in use.
6. Delete or disable keys at the provider: delete the key, or for platforms with a switch, deny bearer-token calls (Amazon Bedrock) or set disableLocalAuth (Azure). Microsoft notes the gateway can keep accepting old keys for a few minutes up to several hours, so test with the old key and wait for the 401 before declaring the step done.
7. Rollback: keep a replacement key creatable by an approved role, not stored, during the pilot. Re-enabling local authentication on Azure also propagates with a delay, so plan rollback windows accordingly.

Worked scenario

A company runs a support agent on Kubernetes that calls the Claude API directly and models on Amazon Bedrock through a gateway. Today a Claude API key sits in a Kubernetes secret and a long-term Bedrock API key sits in the gateway's environment. After migration, the agent's projected service account token is federated to a Claude API service account through a rule matching subject_prefix system:serviceaccount:support:agent and the expected audience, with a 600-second token lifetime. The gateway runs under an IAM role that can invoke only the approved Bedrock models, and an IAM policy denies bedrock:CallWithBearerToken for the account so no new keys can be used. A leaked token from the agent's pod is now useful for minutes, and there is no stored key for an infostealer or a repository commit to expose. The residual risks are a compromise of the cluster's service account issuer and changes to the trust rule, both of which are logged and alerted.

Detection and measurement

• Key count trend: number of live provider keys per provider, with owner and last use; the target is a falling line and zero unowned keys.
• Federated share: percentage of model API calls authenticated by workload identity rather than keys, per provider.
• Trust rule changes: every create, update or delete of a federation issuer, rule or mapping raises an alert and links to a change ticket.
• Exchange failures: spikes in rejected token exchanges (for example the Claude API authentication history reasons such as jti_reused) can mean misconfiguration or token replay attempts.
• Key use after disablement: any successful call with a key on a resource where keys should be disabled.
• Spend per service account: unexpected spend by identity, model or region, compared with a baseline.

Common failure patterns

• Leftover key variables: federation configured but an API key still injected, so the SDK uses the key and nobody notices; the Anthropic documentation calls out this precedence explicitly.
• Broad subject conditions: trust rules that match any branch, any namespace or a wildcard repository, so another workload or a fork can mint tokens.
• Gateway as key vault: every provider key in one gateway configuration, with a default admin key or an internet-facing admin interface.
• Disablement assumed instant: declaring key access off on Azure without testing an old key, while the gateway cache still accepts it.
• Long-term keys used in production: Bedrock long-term keys and Google Cloud API keys carried from exploration into production instead of the IAM or Application Default Credentials paths each provider documents for production.
• One identity for everything: all workloads mapped to one service account, which repeats the shared-key attribution problem with a shorter lifetime.

Framework mapping

Practitioner checklist

• Inventory every model provider key with owner, scope, last use and the services that inject it.
• Use the provider's documented keyless path for every production workload where one exists.
• Create one service account or role per workload and write trust rules on exact issuer, audience and subject.
• Remove API key variables from workloads before declaring migration complete, and confirm which credential the SDK uses.
• Disable or deny key-based access where the platform supports it, and verify with an old key.
• Make the AI gateway reach providers with its own workload identity, and keep its admin interface private.
• Set provider-side spend limits or budgets per project or workspace for both keys and federated identities.
• Alert on trust rule changes, key use on key-disabled resources and spend anomalies per identity.

Standards and references

• Anthropic: Workload Identity Federation
• AWS: Amazon Bedrock API keys
• Google Cloud: Get a Google Cloud API key
• Microsoft Learn: Configure Azure OpenAI with Microsoft Entra ID authentication
• Microsoft Learn: Disable local authentication in Foundry Tools
• OpenAI: Workload identity federation
• Sysdig: LLMjacking, Stolen Cloud Credentials Used in New AI Attack
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: LLMjacking Guide · Workload Identity Federation vs Static Cloud Keys · API Keys vs OAuth Tokens Guide · AI Infrastructure Workload Identity Guide · AI Gateway and LLM Gateway Guide