OpenAI Workload Identity Federation: Aembit Brings Secretless Access to the OpenAI API

Aembit already covers a lot of ground when it comes to securing AI workload access. For OpenAI’s ChatGPT, workloads can authenticate to the ChatGPT API using static API key injection, with the Aembit proxy handling direct access transparently. Today, we’re extending that coverage with the introduction of the OpenAI Workload Identity Federation Credential Provider, available in Cloud v1.33, bringing keyless authentication to ChatGPT the same way we recently did for Claude. This is also the latest expansion of Aembit’s WIF Credential Provider ecosystem, which now spans AWS STS, Azure Entra, GCP, Anthropic Claude, and OpenAI ChatGPT under a single, consistent, secretless access model.

What Is OpenAI Workload Identity Federation?

OpenAI Workload Identity Federation is an authentication method that lets a workload obtain a short-lived, scoped OpenAI API access token by presenting a federated identity assertion instead of a static API key. A trusted identity provider, in this case Aembit, vouches for the workload’s identity; OpenAI verifies that assertion and issues a token that expires. No long-lived sk-proj-... key ever has to be generated, stored, or rotated by hand.

The Industry Is Moving Away from Static API Keys

It is not a coincidence that both Anthropic and OpenAI have introduced WIF support for their APIs around the same time. The pattern of long-lived, static API keys, whether it is sk-ant-... for Claude or sk-proj-... for OpenAI, has become a recognized liability at scale:

• They get embedded in configs, checked into repositories, passed through CI/CD pipelines, and shared across teams.
• When they leak, and they do leak, the exposure is immediate and often broad.
• There is no built-in expiry, no binding to a specific workload identity, and no easy way to audit which key touched what.

The shift to WIF addresses this directly. Instead of issuing a static secret, the API provider trusts a configured identity provider to vouch for a workload. The workload presents a short-lived OIDC token from that IdP, exchanges it for a scoped, time-limited access token, and makes its API call. The token expires. Nothing long-lived sits in the environment. It is the same model that cloud providers have been pushing for IAM access for years, and AI API providers are now adopting it for the same reasons: static credentials do not scale safely.

How the OpenAI WIF Credential Provider Works

The setup involves two sides:

1. On the OpenAI Platform: configure a Service Account, a Workload Identity Provider pointing to Aembit’s OIDC issuer, and a Service Account Mapping that ties incoming token claims to the right service account.
2. On the Aembit side: create an OpenAI WIF Credential Provider with the corresponding service account details.

From there, Aembit’s EdgeController handles everything at runtime. When a workload calls the OpenAI API, the EdgeController intercepts the request, presents an Aembit-issued federation token to OpenAI’s token endpoint, receives a short-lived OpenAI access token in return, and injects it into the outbound request. The workload does not need to know any of this is happening: no code changes, no SDK modifications, no credential management logic in the application.

The result: your workloads authenticate to OpenAI with ephemeral, identity-bound tokens instead of secrets that have to be stored, rotated, and audited manually.

Consistent WIF Across Your AI Stack

For teams already using Aembit’s WIF pattern for AWS, GCP, or Azure, OpenAI follows the same playbook. Create the Credential Provider, wire it into an Access Policy, and the EdgeController handles the rest. The same is true for Claude WIF support, announced separately. If your environment includes workloads calling both Claude and OpenAI, you can govern access to both through Aembit’s unified policy model, with no static keys in either path.

This consistency matters. Security teams get a single place to enforce access policy, audit token usage, and revoke access. Platform teams do not need to implement custom federation logic per AI provider. Developers write application code without credential management concerns.

Getting Started

The OpenAI WIF Credential Provider is available now in Aembit Cloud v1.33 and above. To configure it, set up the Workload Identity Provider and Service Account Mapping in the OpenAI Platform console first, then create the corresponding Credential Provider in Aembit and attach it to an Access Policy. Full configuration steps are in the Aembit docs, and OpenAI’s federation setup guide is available at developers.openai.com.

If you are currently managing OpenAI API keys across services or CI/CD pipelines and want to move to a secretless model, this is a good place to start. Questions or feedback? Reach out to us directly or drop a note in our community.