# Short-lived credentials for AI APIs: replacing static keys

URL: https://infro.io/blog/short-lived-credentials-ai-apis
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-21
Last modified: 2026-10-21
Last reviewed: 2026-10-21 (next review due 2026-11-20)
Topic: Security and governance
Format: Guide

> You can replace most static AI API keys with short-lived credentials: IAM roles and short-term Bedrock API keys on AWS, service accounts and Workload Identity Federation on Google Cloud, Entra ID and managed identities for Azure OpenAI with key access disabled, and Workload Identity Federation on both OpenAI and Anthropic, which exchange your identity provider's token for one that expires in an hour or less. Where a static key is unavoidable, give it an expiry, the narrowest scope, a rotation with overlap and a spend limit at the provider.

Key takeaways:
- AWS, Google Cloud and Azure all let workloads call their AI services with identity: IAM roles, service accounts with Workload Identity Federation, and Entra ID managed identities.
- OpenAI and Anthropic now both offer Workload Identity Federation: a workload exchanges its identity provider's token for a provider token that lasts an hour or less.
- Azure lets you disable key-based access entirely with disableLocalAuth, but the change can take up to several hours to reach the gateway that enforces it.
- On Anthropic's SDKs a leftover ANTHROPIC_API_KEY silently wins over federation; unset it before you delete the key.
- Static keys you cannot avoid need an expiry, the narrowest project or workspace scope, rotation with an overlap window and a provider-side spend limit.

**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 workloads[1] | Short-term Bedrock API key, up to 12 hours[2] | Long-term key with a set expiry; IAM can cap it at 90 days[2] |
| Google Vertex AI | Service accounts; Workload Identity Federation for outside workloads[3] | Federated access tokens[3] | Service account keys (Google calls them a security risk)[3] |
| Gemini API | Auth keys bound to a service account[4] | — | API restrictions; unrestricted keys rejected[4] |
| Azure OpenAI | Entra ID, managed identities, RBAC roles[5] | Entra access tokens[5] | Key access can be disabled[6] |
| OpenAI | Workload Identity Federation[7] | Exchanged access token[7] | Expiry dates, maximum lifetime, creation controls[8] |
| Anthropic | Workload Identity Federation[9] | 60–86,400 s access token[9] | Workspace keys; rotate on a schedule[10] |

## 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 `AssumeRoleWithSAML`[1]. 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 request[2].

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 days[2]. A compromised short-term key is invalidated by invalidating the session that generated it or by denying `CallWithBearerToken`[2]. One audit detail: API calls are logged in CloudTrail, the keys themselves are not[2].

## 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 them[3]. 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 alternative[3].

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 keys[4]. 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 store[5]. 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 Azure[5].

```bash
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 authentication[6]. 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 off[6].

## 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-29[8]. 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 certificates[7]. 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 token[7]. It is configured under Organization Settings, Security, Workload Identity Provider[7].

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 unaffected[8]. 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 expiry[9]. 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 lifetime[9]. 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 presented[9].

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 logging[9]. Two migration traps from its documentation:

- **A leftover key wins.** `ANTHROPIC_API_KEY` sits 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 with `ant auth status`, then delete the key[9].
- **Identity tokens are single-use by default.** A token carrying a `jti` claim cannot be exchanged twice; retry loops and restarted processes that re-present a cached token fail with `jti_reused`[9].

## 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 lifetime[8]; Bedrock credential age[2] |
| 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 keys[4]; Anthropic suggests a schedule such as every 90 days[10] |
| Spend | A provider-side limit on the project or workspace | Anthropic recommends spend limits and regular review of usage[10] |

Keep a written inventory of each static key: who holds it, what it can reach, when it expires. [An AI credential inventory](https://infro.io/blog/ai-credential-inventory) covers the format, and [least privilege for provider admin keys](https://infro.io/blog/provider-admin-key-least-privilege) covers the keys you should never hand out.

> **Example: Moving one service off a static key**
> A team runs a summarization service on Kubernetes that calls Claude with an `ANTHROPIC_API_KEY` from a secret. It registers the cluster as a federation issuer, creates a service account in the service's workspace, and writes a rule matching `system:serviceaccount:prod:summarizer` with a 600-second lifetime. It deploys the federation variables alongside the old key, runs `ant auth status` to confirm the key still wins, removes the key from the secret, confirms federation is now selected, and deletes the key in the Console. A copy of the old secret is now worthless, and a stolen pod token buys at most ten minutes.

## 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](https://infro.io/docs/manage/tokens) 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](https://infro.io/docs/org/audit-log); management tokens always expire, at most 365 days after creation. See [Authentication](https://infro.io/docs/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.

## Questions

### Can I call Claude or GPT models without an API key?

Yes, from a workload with an identity. Anthropic and OpenAI both offer Workload Identity Federation: your workload presents a token from AWS, Google Cloud, Azure, Kubernetes, GitHub Actions or another OIDC issuer, and receives a short-lived provider token. The same models on Bedrock, Vertex AI or Azure are reachable with that cloud's own identity.

### How long do federated AI provider tokens last?

Anthropic's federation rules set 60 to 86,400 seconds, default 3,600, and never longer than about twice the remaining life of the identity token presented. OpenAI's access tokens are capped by the upstream token's remaining lifetime and the rule's lifetime; neither returns a refresh token, so the SDK re-exchanges.

### Can I turn off API keys for Azure OpenAI?

Yes. Set disableLocalAuth to true on the resource, or apply the Azure Policy that requires key access disabled. Microsoft warns the gateway may keep accepting old keys for a few minutes to several hours, so confirm with a request using the old key that returns 401.

### Do OpenAI API keys expire?

They can. Since 2026-09-10 you can set an expiration date when creating a project API key, and admins can set a maximum key lifetime at the organization or project level. Since 2026-09-15 admins can also restrict who may create keys. Existing keys are not changed by these settings.

## Sources

1. Security best practices in IAM — AWS. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html (accessed 2026-10-21)
2. API keys (Amazon Bedrock) — AWS. https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html (accessed 2026-10-21)
3. Workload Identity Federation — Google Cloud. https://docs.cloud.google.com/iam/docs/workload-identity-federation (accessed 2026-10-21)
4. Using Gemini API keys — Google AI for Developers. https://ai.google.dev/gemini-api/docs/api-key (accessed 2026-10-21)
5. Use keyless connections with Azure OpenAI — Microsoft Learn. https://learn.microsoft.com/azure/developer/ai/keyless-connections (accessed 2026-10-21)
6. Disable local authentication in Foundry Tools — Microsoft Learn. https://learn.microsoft.com/azure/ai-services/disable-local-auth (accessed 2026-10-21)
7. Workload identity federation — OpenAI. https://developers.openai.com/api/docs/guides/workload-identity-federation (accessed 2026-10-21)
8. Changelog — OpenAI. https://developers.openai.com/api/docs/changelog (accessed 2026-10-21)
9. Workload Identity Federation — Anthropic. https://platform.claude.com/docs/en/manage-claude/workload-identity-federation (accessed 2026-10-21)
10. API key best practices: keeping your keys safe and secure — Anthropic. https://support.claude.com/en/articles/9767949-api-key-best-practices-keeping-your-keys-safe-and-secure (accessed 2026-10-21)