How do you use short-lived credentials with AI APIs? Let the workload prove who it is with an identity it already has, and exchange that for a provider token that expires in minutes or hours. On AWS that is an IAM role (or a short-term Bedrock API key derived from one); on Google Cloud a service account, with Workload Identity Federation for workloads outside Google; on Azure an Entra ID managed identity, with key access disabled on the resource. OpenAI and Anthropic now both offer Workload Identity Federation, which trades a token from AWS, Google Cloud, Azure, Kubernetes, GitHub Actions or another OIDC issuer for a short-lived API token. Where a static key remains, give it an expiry, a narrow scope, a rotation with overlap and a provider-side spend limit.
The reason is simple: a static key works for anyone who copies it, from anywhere, until someone notices. A token that expires in an hour limits a leak to that hour, and one derived from workload identity cannot be pasted into a .env file in the first place.
What each provider offers
| Provider | Identity-based access | Short-lived token | Static key controls |
|---|---|---|---|
| AWS Bedrock | IAM roles for workloads1 | Short-term Bedrock API key, up to 12 hours2 | Long-term key with a set expiry; IAM can cap it at 90 days2 |
| Google Vertex AI | Service accounts; Workload Identity Federation for outside workloads3 | Federated access tokens3 | Service account keys (Google calls them a security risk)3 |
| Gemini API | Auth keys bound to a service account4 | — | API restrictions; unrestricted keys rejected4 |
| Azure OpenAI | Entra ID, managed identities, RBAC roles5 | Entra access tokens5 | Key access can be disabled6 |
| OpenAI | Workload Identity Federation7 | Exchanged access token7 | Expiry dates, maximum lifetime, creation controls8 |
| Anthropic | Workload Identity Federation9 | 60–86,400 s access token9 | Workspace keys; rotate on a schedule10 |
AWS Bedrock: roles first, short-term keys second
AWS's IAM best practices say to "require workloads to use temporary credentials with IAM roles to access AWS"; on EC2, Lambda and other AWS compute, SDKs pick up role credentials automatically, and workloads elsewhere can obtain them through IAM Roles Anywhere, AssumeRoleWithWebIdentity with a JWT from your identity provider, or AssumeRoleWithSAML1. A Bedrock call signed with role credentials needs no API key at all.
For tools that only take a bearer token, Bedrock API keys come in two kinds. A short-term key lasts up to 12 hours or the session, whichever is shorter, inherits the permissions of the IAM principal that generated it, and is AWS's recommendation for production; a long-term key creates an IAM user and is "for exploration only"2. AWS's token generators return a cached short-term key and refresh it, so long-running applications call them before each request2.
IAM controls both kinds. bedrock:CallWithBearerToken with the bedrock:bearerTokenType condition (SHORT_TERM or LONG_TERM) allows or denies API key use per identity, and iam:ServiceSpecificCredentialAgeDays caps a long-term key's lifetime, for example at 90 days2. A compromised short-term key is invalidated by invalidating the session that generated it or by denying CallWithBearerToken2. One audit detail: API calls are logged in CloudTrail, the keys themselves are not2.
Google Cloud: service accounts and federation
On Google Cloud, Vertex AI calls from Google compute use the attached service account. Workloads elsewhere use Workload Identity Federation, which Google positions as the replacement for service account keys: those keys "are powerful credentials, and can present a security risk if they are not managed correctly", and federation "eliminates the maintenance and security burden" of them3. It accepts AWS, Microsoft Entra ID, GitHub, GitLab, Kubernetes, Okta and any OIDC or SAML 2.0 identity provider, and returns short-lived access tokens; Google recommends granting the external identity direct resource access where the API supports it, with service account impersonation as the alternative3.
The Gemini API on Google AI Studio has moved the same way. Since 2026-05-28, new keys created in AI Studio are auth keys bound to a service account, so requests run under that account's identity and are restricted to the Gemini API by default; the API rejects unrestricted standard keys4. They are still keys a person can copy, so treat them as static credentials with the controls below.
Azure OpenAI: Entra ID, then turn keys off
Microsoft's keyless guide makes the case directly: "Anyone who gains access to the key is able to authenticate to the service", while keyless authentication leaves no key or connection string to store5. Assign the Cognitive Services OpenAI User role for chat completions to a user-assigned managed identity in Azure, or to your own identity for local development, and use DefaultAzureCredential with the https://cognitiveservices.azure.com/.default scope, which runs the same code locally and in Azure5.
az role assignment create \
--role "Cognitive Services OpenAI User" \
--assignee "<identity-id>" \
--scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>"Then remove the fallback. Setting disableLocalAuth to true on the resource, or applying the Azure Policy that requires key access disabled, enforces Entra ID authentication6. Microsoft warns that the change is not immediate: the shared gateway "can continue to accept previously valid keys until its cached configuration refreshes", typically minutes but up to several hours, so verify that a request with the old key returns 401 before you consider keys off6.
OpenAI: federation, expiring keys and creation controls
OpenAI launched Workload Identity Federation on 2026-05-26 and made its mTLS and X.509 variant generally available on 2026-08-298. A trusted workload presents a short-lived external token and receives a short-lived OpenAI access token; the documented sources include Kubernetes, AWS, Microsoft Azure, Google Cloud, Oracle Cloud Infrastructure, GitHub Actions, SPIFFE and X.509 certificates7. Each mapping targets a service account in a project, token exchange never creates a principal or project, and no refresh token is returned: the workload repeats the exchange with a fresh external token7. It is configured under Organization Settings, Security, Workload Identity Provider7.
For keys that remain, two September changes help. Since 2026-09-10 you can set an expiration date when creating a project API key, and admins can cap key lifetime at the organization or project level so new keys must expire within it; since 2026-09-15 admins can restrict key creation to service-account keys or user-owned project keys, or turn it off, with organization restrictions taking precedence and existing keys unaffected8. Set a maximum lifetime now, then work through the keys created before it.
Anthropic: federation with explicit rules
Anthropic's Workload Identity Federation exchanges a JWT from AWS IAM, Google Cloud, GitHub Actions, Kubernetes, SPIFFE, Microsoft Entra ID, Okta or another OIDC issuer for a short-lived sk-ant-oat01-… token bound to a service account, via POST /v1/oauth/token with the RFC 7523 jwt-bearer grant; the SDKs perform the exchange and refresh it before expiry9. Three resources define who may act as whom: a federation issuer (which identity provider), a service account (svac_…), and a federation rule that matches the token's subject, audience or claims and sets the scope and lifetime9. A rule's token_lifetime_seconds ranges from 60 to 86,400 with a default of 3,600, the Console wizard pre-fills 600, and the minted token never outlives twice the remaining life of the identity token presented9.
Anthropic is candid that federation "is only as strong as the upstream identity provider that signs the JWT", and recommends pairing it with that provider's workload binding, conditional access and audit logging9. Two migration traps from its documentation:
- A leftover key wins.
ANTHROPIC_API_KEYsits above the federation variables in every SDK's credential order, so it "silently shadows federation"; unset it in CI secrets, container environments and shell profiles, confirm withant auth status, then delete the key9. - Identity tokens are single-use by default. A token carrying a
jticlaim cannot be exchanged twice; retry loops and restarted processes that re-present a cached token fail withjti_reused9.
When a static key is unavoidable
Some callers cannot federate: a laptop without a workload identity, a third-party tool that only accepts a key, a SaaS platform calling your provider from outside your cloud. Bound those keys on four axes.
| Axis | What to do | Provider controls |
|---|---|---|
| Lifetime | Every key has an expiry; nothing is "never" | OpenAI expiry and maximum lifetime8; Bedrock credential age2 |
| Scope | One project, workspace or IAM policy per consumer; inference only, never admin | OpenAI projects, Anthropic workspaces, IAM policies |
| Rotation | New key first, deploy, verify, then revoke the old one | Google documents this order for Gemini keys4; Anthropic suggests a schedule such as every 90 days10 |
| Spend | A provider-side limit on the project or workspace | Anthropic recommends spend limits and regular review of usage10 |
Keep a written inventory of each static key: who holds it, what it can reach, when it expires. An AI credential inventory covers the format, and least privilege for provider admin keys covers the keys you should never hand out.
How INFRO handles provider credentials and its own keys
INFRO sits between your applications and the provider accounts you own, and today it is one of the callers that holds a static provider credential: you connect an API key per provider (for AWS Bedrock, a long-term Bedrock API key; for Vertex AI, a service-account key from which INFRO signs short-lived access tokens), which INFRO seals with AES-256-GCM, never shows again and uses only for requests routed through it. It does not yet federate into your cloud or provider identity. So bound the credential you give it with the table above: a dedicated project or workspace key, inference permissions only, an expiry, a provider-side spend limit. You can hold several keys per provider in INFRO and replace one through the console or the management API on the next request, which makes rotation with overlap straightforward; replacing a key in INFRO does not revoke the old one at the provider, so revoke it there.
INFRO's own credentials are built to be bounded. Gateway keys carry an expiry, belong to one environment, can be limited to chosen providers and IP ranges (403 ip_not_allowed before any provider call), and rotate with an overlap of none, 1 hour, 24 hours or 7 days, logged in the audit log; management tokens always expire, at most 365 days after creation. See Authentication.
The limit to keep in view: INFRO's budgets and allowlists govern traffic that goes through INFRO. A provider key stolen from anywhere, INFRO included, works directly against the provider until it expires or is revoked. That is the strongest argument for short-lived credentials wherever your own workloads call providers, and for expiry and provider-side limits on every static key that remains.
Summary
Static AI keys are now a choice, not a requirement, for most workloads. Use IAM roles and short-term keys on Bedrock, service accounts and federation on Google Cloud, managed identities with key access disabled on Azure, and Workload Identity Federation on OpenAI and Anthropic. For the keys you cannot remove, set an expiry, narrow the scope, rotate with overlap, cap spend at the provider and write down who holds each one.