OpenAI Has Machine Identity Now. Which Jobs Should Lose API Keys?

By Greg Nowak. Last updated 2026-09-03.

OpenAI authentication is no longer just a matter of finding a safer place to store an API key. On August 29, 2026, OpenAI made mutual TLS and X.509 workload identity federation generally available. For businesses with well-managed machine identities, that creates a credible path away from long-lived API keys.

It does not mean every key should disappear next week. A rushed migration can introduce certificate failures, faulty identity mappings, permissions that are still too broad, and jobs that stop working when a token expires. Start by listing every system that calls OpenAI, then make an authentication decision for each caller.

mTLS and keyless access do different jobs

The distinction matters. According to the OpenAI mutual TLS guide, mTLS adds client-certificate verification to an API request. Once a trusted certificate is active for an organization or project, affected requests must present an accepted client certificate as well as their normal bearer credential. The API key, service-account credential, or workload identity token still exists.

X.509 workload identity federation goes a step further. The workload presents a verified client certificate and receives a short-lived OpenAI access token. It then calls the API with that token and an accepted client certificate. This removes the API key, although the private key associated with the certificate remains sensitive and must be protected.

So the useful question is not simply, “Can we switch on mTLS?” For each workload, decide whether you need an extra certificate check, whether the job can exchange its certificate identity for short-lived tokens, and whether your team can run the certificate lifecycle without turning authentication into a reliability problem.

What you have	Likely direction	Readiness check
A stable machine identity and a long-lived API key you want to remove	X.509 workload identity federation	The job can protect its private key, present a valid certificate, renew short-lived tokens, and map to a dedicated service account.
A bearer credential that should remain, with a need for an extra certificate check	mTLS with the existing credential	Every affected caller can use the correct mTLS endpoint and present a complete, trusted certificate chain.
Unreliable certificate issuance, renewal, or recovery	Keep conventional credentials for now	Centralize storage, restrict access, rotate credentials, monitor usage, and document revocation while fixing the operational gaps.
One shared key used by unrelated jobs	Separate identities before migrating	Give each caller a named owner, defined permissions, and an authentication path that can be tested independently.

A working decision matrix for OpenAI API callers. Where a job runs matters less than whether its identity and credential lifecycle are dependable.

Which jobs should lose their API keys first?

Look first at unattended, production-relevant workloads with a stable identity and a clear owner. A scheduled job, pipeline, cluster workload, or internal automation may fit. Its hosting label alone tells you very little. Four practical tests are more useful.

1. Can you identify the caller precisely?

OpenAI’s X.509 flow derives identity attributes from the verified certificate, including a required, non-empty openai.subject. A service-account mapping then authorizes that identity to use one OpenAI service account within a project. The mapping needs to describe the real workload, not a vague label covering several unrelated automations.

That aligns with Google Cloud’s federation guidance. Ambiguous or mutable identity mappings create spoofing risk, while dedicated service accounts reduce the chance of excessive access. Use stable identity attributes, limit who can edit mappings, and avoid authorizing a wider group of identities than the job requires.

2. Can its permissions be narrowed?

When administrators create an OpenAI service-account mapping, OpenAI tells them to grant only the API permissions that workload needs. This is a good reason to separate a reporting job from a customer-facing workflow. They may call the same API, but they do not necessarily need the same models, capabilities, or project access.

A shared credential blurs those boundaries and makes activity harder to attribute. Google’s guidance makes a related point: limit both the external identities allowed to impersonate a service account and the resources that account can reach. Machine identity earns its keep when it produces smaller permission boundaries that people can actually understand.

3. Can the workload handle certificates safely?

X.509 federation removes the long-lived API key; it does not remove credential operations. The workload still needs a client certificate, its private key, any required intermediate certificates, and a chain to an active trusted root. OpenAI says private keys should remain outside source control, access should be limited to the workload, and private keys, certificates, and returned tokens should not appear in logs.

The certificate chain can also make or break the deployment. OpenAI requires a valid client certificate suitable for TLS client authentication. The client must present any intermediates needed to reach the active trust anchor during the handshake. Missing or malformed material can stop the connection before OpenAI considers the API request.

4. Will renewal and recovery work unattended?

An X.509 workload identity token lasts no more than one hour and cannot outlive the verified certificate. There is no refresh token, so the workload must repeat the certificate exchange. OpenAI SDKs can renew short-lived access tokens automatically, but the surrounding system still needs sensible timeouts, retries, alerts, and an owner who can distinguish a certificate problem from a mapping or permission failure.

This makes an unmonitored, fragile job a poor first candidate, however undesirable its current key may be. The replacement is stronger only if renewal and recovery work reliably.

Roll out by workload, not across the whole organization

The general-availability announcement says certificates and X.509 identity providers can be configured in the Platform console under organizational roles and permissions. There is a useful operational detail in OpenAI’s implementation guidance: uploading a certificate does not enforce mTLS. Activation is the step that changes request behaviour, which gives teams room to prepare and test before enforcement.

Inventory every caller. Record the repository or deployment location, OpenAI project, credential type, service owner, required permissions, and failure contact. Check shared keys, environment variables, CI/CD secrets, configuration files, and private keys.
Choose the target authentication. Use X.509 federation when API-key removal is the goal and certificate operations are ready. Use mTLS when the bearer credential should remain but a certificate check adds value. If a job must keep conventional credentials, record that as a temporary decision with an owner.
Prepare narrow identities. Create mappings for specific workloads, base them on stable certificate attributes, restrict administrative access to those mappings, and grant only the API permissions each job needs.
Start with a non-critical project. OpenAI recommends activating certificate trust there first and sending representative requests from every expected workload. Test normal calls and token renewal, but also rejected or expired certificates, missing chains, an unavailable token exchange, and alert delivery.
Rotate with an overlap period. OpenAI recommends activating a new trust anchor before deactivating the old one. Move and test the workloads, then remove the old certificate. Revoke the former API keys only when the new path is stable and the evidence shows that no legitimate caller still uses them.

The work does not end when the API key is gone. The OWASP Secrets Management Cheat Sheet recommends short lifetimes, automatic rotation, least-privilege visibility, revocability, protection against logging, monitoring, and documented incident response. Certificate private keys and short-lived bearer tokens need those controls too.

A sensible target is one accountable identity for each meaningful workload, with only the permissions it needs and a tested way to rotate or revoke its credentials. Begin with stable, well-owned automations. Add mTLS where an extra certificate gate is useful, and retain conventional credentials where their risks are understood and actively managed. That removes API keys where the replacement is genuinely stronger without making an authentication upgrade the cause of an outage.

Related on GrN.dk

Need help with this kind of work?

Plan your OpenAI authentication review Get in touch with Greg.

Sources

Last modified

2026-09-03