Writing ·
How to authenticate OpenAI agent workloads without long-lived API keys in 2026
Use OpenAI Workload Identity Federation to exchange an external workload identity for a short-lived access token, with a narrow service-account mapping and explicit permissions.
By Youssef Hemimy · OpenAI · agent security · identity
Authenticate an OpenAI agent workload with a short-lived token instead of leaving a reusable API key in its configuration. OpenAI's Workload Identity Federation exchanges an externally issued identity token for a short-lived OpenAI access token. The useful part is not the exchange alone—it is making the workload identity, service account, and permitted access explicit and reviewable.
- 4
- documented flow parts: provider, mapping, exchange, request
- 1
- service account mapping per permitted workload identity
- 0
- long-lived API keys required by the documented exchange pattern
- 2
- environments to separate: production and non-production
External identity
A workload receives a subject token from its trusted identity environment.
Claim mapping
Issuer and token attributes are checked against the allowed service-account mapping.
Token exchange
The external subject token is exchanged for a short-lived access token.
API request
The workload uses the issued bearer token for the permitted API request.
Boundary rule
The workload presents its existing identity. The mapping decides which workload may mint a token and how narrowly that token is constrained.
Make workload identity the boundary
A static API key answers only one question: who holds this secret? A workload-identity flow can answer a more useful set: which issuer created the identity, which token attributes matched, which service account may be used, and which permissions are narrowed for that workload. OpenAI documents this as a workload identity provider, a service account mapping, a token exchange request, and a bearer-token API request.
The pattern is specific to the product and configuration you are using. OpenAI's guide describes OIDC-compatible JWT subject tokens for its documented setups. It does not mean every identity provider or every OpenAI account automatically has the same option.
Keep the identity decisions separate
| Decision | Question to answer | Where to enforce it |
|---|---|---|
| Trusted issuer | Which identity environment is allowed to present a subject token? | Workload identity provider configuration. |
| Workload mapping | Which token attributes may mint a token for this service account? | Service account mapping. |
| API permissions | What can a token minted from this mapping do? | Mapping-level permissions and downstream API authorization. |
| Operational boundary | Can a non-production workload act as production? | Separate service accounts, mappings, and review paths. |
This is the same AgentOps Hardening instinct we apply to tool calls: make the boundary legible before the work begins. A workflow that can explain its identity, its permitted surface, and its outcome is easier to audit than one built around a secret copied into a runtime.
Use exact mappings before broad convenience
OpenAI's guidance recommends a dedicated service account for each application or workload, separate production and non-production environments, exact claim matching where possible, minimum permissions, and regular removal of unused mappings. Those are not decorative settings: they are how an exchange stays attributable when the agent runtime is no longer a single process on one laptop.
- Define the issuer and audience you expect before accepting a subject token.
- Map only the token attributes that identify the intended workload.
- Give each workload a dedicated service account and narrow permissions.
- Keep production identity paths separate from experimentation.
- Monitor failed exchanges and access patterns alongside agent failures.
Make the exchange part of the operating model
Identity failures are workflow failures. A changed claim, disabled mapping, or unexpected exchange rejection should be observable before an agent retries into confusion. Tie exchange monitoring to the same operational view as agent observability, and keep permissions aligned with the read/write boundaries described in production tool contracts.
Sources
FAQ
What is workload identity federation for OpenAI workloads?
It is OpenAI's documented flow for trusted workloads to exchange externally issued identity tokens for short-lived OpenAI access tokens, instead of storing a long-lived API key in the workload.
Does workload identity federation remove the need for authorization?
No. The mapping is an authorization boundary: it decides which external token attributes can mint a token for a particular service account, and optional permissions can narrow that token further.
What should be separated in a production setup?
Separate service accounts by workload, keep production and non-production environments distinct, match claims as exactly as practical, and monitor unexpected exchange failures or access patterns.
Does every OpenAI deployment use workload identity federation?
No. It is a specific OpenAI feature with documented provider configurations and organization-level setup requirements. Check the current guide before treating it as an available option for a particular account or platform.
Building something that has to hold up?
We do this work for teams — agent reliability hardening, custom MCP servers, and full-stack AI systems built to survive production.