OpenAI mTLS and X.509 Workload Identity Are Now GA: What Every Gateway Operator Must Audit

On August 29, OpenAI made mutual TLS (mTLS) and X.509 workload identity federation generally available for all API organizations. The feature is opt-in and not activated by default — but once any organization administrator enables it, every proxy or gateway forwarding that organization's API traffic becomes a required certificate holder. The failure mode is a TLS handshake rejection, not a 401 error, and it happens before the normal bearer-credential check runs.

What went GA on August 29

OpenAI shipped two related security features:

Mutual TLS adds client certificate verification to API requests. After a trust anchor is uploaded and activated — at the project level or organization-wide — every request in that scope must arrive at the mTLS API host presenting an accepted client certificate. OpenAI verifies the certificate against active trust anchors before the normal API key or workload identity token check.

X.509 workload identity federation uses those same mTLS trust anchors for token exchange. A workload presents its certificate to receive a short-lived bearer token. Subsequent requests send both the bearer token and the client certificate on the mTLS host. This eliminates static API keys from the workload entirely.

Both features are managed through new RBAC permissions (api.mtls.read, api.mtls.write) and a certificate management endpoint family:

• POST /v1/organization/certificates — upload a trust anchor
• GET /v1/organization/certificates — list all org certificates
• GET | POST | DELETE /v1/organization/certificates/{certificate_id} — retrieve, update, or delete a specific certificate

Five operator consequences worth understanding before you enable this

1. The API host changes. mTLS enforcement runs on a separate mTLS API host; connections to standard api.openai.com are not subject to the certificate check. Any gateway that needs to present a client certificate must be configured to connect to the mTLS host — otherwise the enforcement is bypassed, not enforced.

2. The gateway must hold a private key. The workload that presents the TLS client certificate must have secure access to its private key. A gateway terminating TLS and forwarding HTTP internally needs to manage this key itself. A transparent TCP proxy that does not terminate TLS can pass the certificate through only if it is specifically configured to do so.

3. CEL filters create per-workload access scopes. Each trust anchor can carry a CEL filter constraining which verified client certificates it accepts — expressions against api.mtls.subject_dn (subject distinguished name) and api.mtls.san (subject alternative name). This lets operators lock different gateway nodes to different organizational units or hostname patterns within the same organization, without needing separate API keys.

4. There is no revocation checking. OpenAI does not perform AIA, CRL, or OCSP checks. The only path to invalidate a compromised certificate is to deactivate it in the console or via DELETE /v1/organization/certificates/{certificate_id}, then rotate to a new trust anchor and redeploy the gateway. This is entirely manual and must be coordinated across every gateway instance holding the old private key.

5. Multi-project gateways must match certs to projects. OpenAI checks project-level certificates before organization-level certificates. A gateway routing traffic for multiple projects under one organization either presents the correct per-project certificate on separate TLS connections, or falls through to an organization-level certificate. The routing logic must account for which certificate scope a given request falls into.

How this compares to Anthropic and Google's auth models

The contrast across providers is useful context for gateway operators who route to multiple backends.

Anthropic uses OIDC-based Workload Identity Federation: no client certificate required, short-lived tokens exchanged directly from a cloud identity provider (AWS, GCP, Azure). The gateway never holds a private key — it holds a cloud IAM identity that can be federated.

Google Vertex AI and Amazon Bedrock use cloud-native Managed Identity or service account JSON. Same pattern: identity lives in the cloud IAM plane, not in a locally managed certificate.

OpenAI mTLS is the most demanding from an infrastructure standpoint — it requires a certificate authority, key distribution to every gateway node, and a manual rotation process without revocation support. But it is the most portable to environments with existing PKI infrastructure: corporate certificate authorities, HashiCorp Vault PKI, AWS Private CA, or GCP Certificate Authority Service. Teams that already operate a PKI and have strong air-gapped or on-premises workloads get real value here.

The keyless path for gateways

X.509 workload identity federation changes the calculus for gateway operators willing to accept the PKI requirement. A gateway presents its certificate to an OpenAI token exchange endpoint, receives a short-lived bearer token, and uses that token for API calls — no static OpenAI API key stored anywhere. Key rotation becomes certificate rotation, which most mature infrastructure environments already handle with existing tooling.

This is the most meaningful architectural shift in the GA release. The mTLS-only path adds a second factor to an existing API key. X.509 workload identity removes the API key entirely.

What to audit in your routing setup now

mTLS is off by default. No action is required unless you intend to enable it or your organization administrator enables it without coordinating with gateway teams. But the feature creates a new category of silent misconfiguration:

A gateway configured with a hardcoded base_url pointing to standard api.openai.com will not present a client certificate and will not be checked for one — it bypasses enforcement entirely. This is both the failure mode (gateway does not benefit from mTLS) and the unintentional escape hatch (gateway does not break when org-wide mTLS is enabled). Whether that trade-off is acceptable depends on your threat model.

For teams planning to adopt mTLS, the recommended sequence: provision a certificate authority, generate per-gateway client certificates, upload the trust anchor via POST /v1/organization/certificates, activate for a non-critical project first, test by sending requests through the mTLS API host, then expand to production after validation.

Add mTLS host configuration and client certificate fields to your provider credential schema now, before any organization administrator activates the feature and creates an unexpected hard failure. TheRouter's provider configuration docs cover the fields available for custom provider TLS settings.