From Model API Keys to Workload Identity

Most AI applications still call their model provider with a long-lived API key copied into an environment variable, a CI secret or an agent configuration file, and that key works for anyone who finds it. The major model platforms now let workloads authenticate with identities they already have, such as a cloud role, a Kubernetes service account token, a GitHub Actions OIDC token or a SPIFFE identity, and exchange them for short-lived access. This guide explains how that works for each platform, how to migrate running applications and agents without downtime, and how to retire the keys for good. It is written for platform, AI engineering and identity teams. If a key has already leaked, start with the AI model provider API keys leak response guide; this page is about making the next leak impossible. Platforms are listed alphabetically; order is not a ranking.

Key takeaways

Every major platform now has a keyless path. Amazon Bedrock, Anthropic, Google Vertex AI, Microsoft Foundry (Azure OpenAI) and OpenAI each document a way for workloads to authenticate with a federated or platform-issued identity instead of a stored key.
Short-lived tokens change the economics of a leak. Federated tokens on these platforms last minutes to hours and cannot outlive the identity they came from, so a copied token is worth far less than a copied key.
Attribution improves as a side effect. A key names a project; a workload identity names the workload. Google's documentation, for example, notes that a standard API key logs every request under one bound service account, while Application Default Credentials give per-caller audit attribution.
Leftover keys silently win. SDKs often prefer an API key environment variable over federation, so migration is not finished until the key variable is removed everywhere and the key is deleted.
Federation moves trust upstream. The model platform now trusts your identity provider; tight claim matching on issuer, audience and subject matters as much as the key retirement itself.

Why static model keys are the wrong credential

Model API keys combine three risky properties: they are bearer secrets, they rarely expire, and they convert directly into spend and data access. The LLMjacking campaigns showed the pattern at scale: attackers harvested cloud credentials and AI service keys from compromised servers and public code, tested them, pooled working keys behind reverse proxies and resold model access while victims paid the bills. In ATT&CK terms the harvesting is T1552.001 Credentials In Files and the abuse is T1496.004 Cloud Service Hijacking.

Property	Static model API key	Workload identity with token exchange
Where it lives	Env files, CI secrets, notebooks, agent and IDE configs	Nowhere at rest in the app; the platform issues an identity token at runtime
Lifetime	Until someone deletes it, or a long expiry	Minutes to an hour or so, bounded by the upstream token
Usable from	Anywhere	Only by a workload that can obtain a matching identity token
Who it names in logs	A project, workspace or key	A specific workload, service account or role
Rotation	Manual: create, deploy, delete	Automatic: SDKs refresh before expiry
Main residual risk	Leak equals access	Over-broad trust rules and compromise of the workload itself

NIST SP 800-53 Rev. 5 control IA-5(7) asks organisations to ensure unencrypted static authenticators are not embedded in applications or other static storage. A model key in a container image or repository is exactly that. See the LLMjacking Guide for the threat in detail.

The three keyless patterns

Native cloud identity: when the model runs inside your cloud (Amazon Bedrock, Google Vertex AI, Microsoft Foundry), the workload uses its cloud role, service account or managed identity directly. No exchange with a third party is needed.
Federation to a direct API provider: when you call a provider's own API (Anthropic, OpenAI), the workload presents a signed JWT from your identity provider, the provider validates it against trust rules you configured, and returns a short-lived access token bound to a service account in your organisation.
Gateway brokering: for providers that offer only keys, or to centralise policy, an AI gateway holds the provider credential once and authenticates your workloads by their identity. The key still exists, but in one hardened place instead of dozens. See the AI Gateway and LLM Gateway Guide and Securing the AI gateway itself.

Underneath, all three rely on the same building blocks covered in the Workload Identity Federation Guide: a trusted issuer, a signed token with iss, aud and sub claims, and a rule that maps those claims to a principal with defined permissions.

Platform by platform

Each subsection describes what the platform's own documentation sets out, checked on 15 November 2026. Settings change: confirm against the current documentation before rollout.

Amazon Bedrock

Bedrock calls are normally signed with AWS credentials from an IAM role, so a workload on EC2, ECS, Lambda or EKS uses its role's temporary credentials. Bedrock also offers API keys in two forms. Short-term keys last up to 12 hours (or the session duration if shorter), inherit the permissions of the IAM principal that generated them, and are the type AWS recommends for production. Long-term keys are tied to an IAM user through a service-specific credential and are documented for exploration only.

Restrict long-term keys: control iam:CreateServiceSpecificCredential and cap lifetime with the iam:ServiceSpecificCredentialAgeDays condition key.
Block key use entirely: deny bedrock:CallWithBearerToken (and bedrock-mantle:CallWithBearerToken), or target one type with the bedrock:bearerTokenType condition (SHORT_TERM or LONG_TERM).
Find leftovers: look for the AWS_BEARER_TOKEN_BEDROCK environment variable in code and pipelines.

See the Amazon Bedrock Security Guide.

Anthropic

Anthropic's Workload Identity Federation lets workloads call the Claude API with short-lived OIDC-derived tokens instead of sk-ant- API keys. You configure three resources: a service account (svac_), a federation issuer (fdis_) with its JWKS source, and a federation rule (fdrl_) that matches on subject prefix, audience, exact claims or a CEL condition and grants an OAuth scope (default workspace:developer). The SDK exchanges the JWT at POST /v1/oauth/token using the RFC 7523 jwt-bearer grant. Documented identity providers include AWS, GitHub Actions, Google Cloud, Kubernetes, Microsoft Entra ID, Okta and SPIFFE.

Lifetime: token_lifetime_seconds ranges from 60 to 86,400 (API default 3,600), and the issued token is capped at twice the remaining life of the presented JWT, subject to a 60 second minimum.
Replay protection: JWTs carrying a jti are single-use by default; reuse fails as jti_reused. Keep that check on.
Precedence: ANTHROPIC_API_KEY sits above the federation settings in the SDK's credential order, so unset it everywhere and confirm with ant auth status before deleting the key.

See the Anthropic API Keys Security Guide.

Google Vertex AI

Google's documentation says to use an API key for testing and Application Default Credentials (ADC) for production. With ADC the workload authenticates as its attached service account, or through Workload Identity Federation when it runs outside Google Cloud. The audit benefit is explicit: standard API keys log every request under one bound service account, so callers cannot be told apart in Data Access audit logs, whereas ADC gives per-caller attribution. Express mode API keys, intended for quick starts, do not generate customer-accessible Data Access audit logs.

Restrict remaining keys: apply API key restrictions to limit what each key can call.
Keep keys out of clients: Google advises against calling the API directly from web and mobile apps where keys are exposed.
From GKE: follow How to move GKE workloads from keys to Workload Identity Federation.

See the Google Vertex AI Security Guide.

Microsoft Foundry (Azure OpenAI)

Azure OpenAI supports Microsoft Entra ID authentication with user or managed identities. Assign the Cognitive Services OpenAI User role for inference (the role Microsoft recommends for managed identities); Cognitive Services Contributor is needed only for control plane calls. Data plane tokens use the scope https://ai.azure.com/.default, and the resource needs a custom subdomain endpoint for Entra ID authentication. For user-assigned identities set AZURE_CLIENT_ID so the credential chain picks the right one.

Turn off keys: set disableLocalAuth to true, and enforce it with the built-in policy "Azure AI Services resources should have key access disabled (disable local authentication)".
Allow for propagation: Microsoft notes the change can take from minutes to several hours to reach the gateway; verify with an old key and expect HTTP 401.
Role timing: new role assignments can take up to five minutes to apply, so a 403 straight after assignment is usually a wait, not a fault.

See the Azure OpenAI and Azure AI Foundry Security Guide.

OpenAI

OpenAI's workload identity federation lets a workload exchange an identity it already has for a short-lived OpenAI access token. For the API you configure a Workload Identity Provider (issuer URL, audience, key source) and a service account mapping that ties matching claims to a project and service account, with optional permissions. Documented providers include AWS, GitHub Actions, Google Cloud, Kubernetes, Microsoft Azure, Oracle Cloud Infrastructure, SPIFFE and X.509 certificates. The exchange uses the RFC 8693 token exchange grant at https://auth.openai.com/oauth/token, with a separate mutual TLS endpoint for certificates.

Lifetime: access tokens expire after at most one hour and never outlive the external subject token; there is no refresh token, so the SDK re-exchanges.
Matching: mappings can use raw claims such as iss, aud and sub or CEL-derived attributes; all must match and only one enabled mapping can match. A trailing wildcard is allowed, so keep it narrow.
Permissions: a scope sent in the request grants nothing; access comes from the mapping, so review mappings as you would role assignments.

See the OpenAI API Keys Security Guide.

Designing trust rules that hold

Removing the key moves the security boundary to your trust configuration. A loose rule can let any workload in a cluster or any repository in a GitHub organisation obtain model access.

Source of identity	Claims to pin	Common mistake
GitHub Actions OIDC	`iss`, `aud`, `sub` including repository and ref or environment	Wildcard on the whole organisation, so any repository can call the model
Kubernetes projected service account token	Cluster issuer, audience, `system:serviceaccount:<namespace>:<name>`	Matching the namespace prefix only, or sharing one service account across apps
Cloud instance or managed identity	Specific role, managed identity or service account	Reusing a broad compute role that many unrelated workloads share
SPIFFE JWT-SVID	Trust domain and full SPIFFE ID path	Trusting the whole trust domain

One principal per application and environment: separate service accounts or mappings for production, staging and CI, each in its own project or workspace where the platform supports it.
Audience discipline: mint identity tokens with a dedicated audience for the model platform, never a generic one reused across services.
Change control: manage issuers, rules and mappings as code with review, and alert on changes. See the Workload Identity Federation Trust Review Checklist.

Agents and developer tools

Agents add two twists. First, an agent runtime often holds credentials its tools can read; a short-lived token limits the damage if a prompt injection exfiltrates it, but the runtime should still read the identity token from a file or metadata endpoint the agent's tools cannot reach. See AI Agent Runtime Credential Theft via Instance Metadata. Second, developers' local agents, IDE assistants and MCP servers are where keys sprawl most. Federation from a laptop is harder, so route local tools through a gateway or a secrets broker and keep personal keys out of plain-text configs; see How to give MCP servers and local agents secrets without plain-text config files. Where several agents share an application, give each its own service account or mapping so that platform logs attribute calls to the right agent; the AI Agent Attribution and Non-Repudiation guide builds on that.

How to implement

Inventory keys and callers: list every model key across providers, the application or person using it, where it is stored, and its last use. Secret scanning results and provider usage dashboards are the quickest starting point. See How to audit OpenAI and Anthropic organisation API keys.
Classify by runtime: cloud workloads (native identity or federation), CI pipelines (OIDC federation), Kubernetes (projected tokens), developer machines (gateway or broker), and third-party tools that can only take a key (gateway).
Configure federation in parallel: create the role, service account or mapping and the trust rule while the key remains in place. Use the platform's test or verify step where offered.
Pilot one workload per pattern: confirm calls succeed with the federated credential and that platform logs now show the workload identity.
Remove the key variable: unset the key from CI secrets, container environments, Helm values and shell profiles; confirm the SDK is using federation, since a leftover variable can take precedence.
Revoke the key: delete or deactivate it after a quiet period with no usage. Keep a documented rollback for the first days: re-issue a new, short-expiry key stored in a vault, never the old one.
Enforce: turn off key authentication where the platform allows (for example Bedrock bearer token denies or Foundry disableLocalAuth), and restrict who can create new keys.

Decision guidance

Situation	Recommended path	Trade-off
Model hosted in the same cloud as the app	Native role, service account or managed identity	Simplest; ties model access to cloud IAM design quality
App in one cloud, model provider's own API	Provider federation using the cloud's identity token	No secret to store; trust rules need careful claim pinning
CI evaluation and test jobs	OIDC federation from the CI platform	Rules must pin repository and branch or environment
Many providers, some key-only	AI gateway with workload authentication in front	Gateway becomes a high-value target that needs its own hardening
Small team, one app	Start with the platform's federation wizard or managed identity	Little overhead; do it before the key count grows

Detection and measurement

Key usage after migration: any request authenticated with a key for a workload marked as migrated.
New key creation: alerts on key creation events outside an approved exception process.
Federation failures and anomalies: rejected exchanges, replayed JWTs, unexpected issuers or subjects, and rule or mapping changes.
Spend by principal: usage now attributable per workload makes sudden model or volume changes easier to spot.

Metric	Target direction
Production model traffic using workload identity rather than keys	Towards 100%
Active long-lived model keys, by provider	Falling; each remaining key has an owner and exception expiry
Model keys found by secret scanning per month	Falling to near zero
Trust rules with wildcard subjects	Zero, or each justified
Median issued token lifetime	One hour or less

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev. 5	IA-5(7), IA-5(13), IA-9	No embedded static authenticators; expiry of cached authenticators; service authentication
NIST SP 800-53 Rev. 5	AC-6, AU-3	Least privilege for service accounts; audit records that name the caller
NIST CSF 2.0	PR.AA-01, PR.AA-03, PR.AA-04	Managed credentials, authentication, protected identity assertions
ISO/IEC 27001:2022 Annex A	5.17, 8.5	Authentication information, secure authentication
CIS Controls v8.1	5.5	Inventory of service accounts
MITRE ATT&CK v20	T1552.001, T1496.004, T1078.004	Key harvesting, model abuse, misuse of cloud identities

Common failure patterns

Half-migrated workloads: federation is configured but the key variable is still set, so the SDK keeps using the key and nobody notices.
Organisation-wide wildcards: a CI trust rule matching every repository, turning any compromised repository into model access.
Shared compute roles: granting model invocation to a broad instance role that dozens of services share, which loses attribution and widens blast radius.
Keys kept "just in case": old keys left active after migration, which is exactly what credential harvesters find, as the LLMjacking campaigns showed.
Gateway as a new key store: moving every provider key into a gateway without hardening the gateway's own admin access and master credentials.

Practitioner checklist

Inventory every model provider key with owner, location and last use.
Move cloud-hosted model calls to roles, service accounts or managed identities.
Configure provider federation for direct API calls, pinning issuer, audience and full subject.
Use separate principals per application and environment, in separate projects or workspaces where available.
Remove key environment variables everywhere and confirm the SDK is using federation before deleting keys.
Turn off key authentication or deny key use where the platform supports it, and restrict key creation.
Keep JWT replay checks enabled and token lifetimes at one hour or less unless justified.
Manage trust rules as code, review them quarterly and alert on changes.
Route key-only providers and developer tools through a hardened gateway or broker.

From Model API Keys to Workload Identity: Removing Static Credentials from AI Apps