OpenAI AI Gateway Approval: What Changes on November 20

OpenAI announced on October 21 that services providing direct access to its models, including model routers and AI gateways, will need prior review and approval. The updated Usage Policies take effect on November 20, 2026. Applications that simply use OpenAI models to power features are explicitly distinguished from those intermediaries.

That distinction matters more than a broad claim that every AI application now needs permission. The practical question is what a service gives its customers access to, and who remains responsible when that access is misused.

Which services need OpenAI approval?

The updated Usage Policies apply the requirement to platforms and services that let third parties directly access OpenAI models. The same section says integrating a model into an application’s functionality does not, by itself, trigger the requirement.

A router is typically infrastructure that sends requests to a selected model or provider. An application might instead use a model behind a defined feature, such as summarizing a document. Those are useful architectural examples, not a determination of how OpenAI would classify a particular business. Mixed products should seek clarification about their actual offering rather than assume their marketing label settles it.

The policy also clarifies restrictions on using OpenAI outputs to develop substitute models, including preparing training material or supplying training feedback. Research, software development, evaluation and product development remain permitted within the stated boundaries, subject to applicable agreements. That is a separate issue from whether an intermediary needs approval.

Why OpenAI is focusing on the access layer

In its announcement, OpenAI says partners hosting or reselling models must maintain consistent safeguards, investigate potential violations and coordinate enforcement. The objective it describes is preventing restrictions from becoming ineffective when access moves between services.

For an infrastructure provider, this turns abuse handling into part of the product’s operating model. Routing quality, latency and billing still matter, but there also needs to be an answer to who can investigate a suspicious account and where a restriction is enforced.

Consider a multi-tenant gateway. If every customer’s requests look identical upstream, an investigation can become difficult to isolate. If individual users can be distinguished appropriately, the operator has a better basis for identifying affected traffic without unnecessarily disrupting unrelated customers. That is an operational implication, not a guarantee about how any particular enforcement decision will work.

SafetyIDs and the API mechanism already documented

OpenAI says it is working with customers to introduce SafetyIDs: customer-provided identifiers intended to distinguish end users during investigations without revealing their identities to OpenAI.

Separately, the existing safety-classifier documentation describes the safety_identifier parameter in Responses, Chat Completions and Images, and the OpenAI-Safety-Identifier header for Realtime. It recommends stable identifiers and hashing emails or internal user IDs rather than transmitting personal information. The guide currently describes safety identifiers as recommended, not required.

Those details should not be collapsed into a claim that October 21 launched a new mandatory API parameter. The announcement describes a broader customer initiative; the developer guide provides the concrete integration behavior presently documented.

For teams evaluating their implementation, the important engineering question is whether identity survives the request path consistently. An application can generate a useful identifier and still lose it when traffic passes through another layer. Testing that behavior is more informative than assuming the gateway forwards every field unchanged.

What remains unclear

The announcement and policy do not provide a universal approval turnaround time, a public list of approved gateways, or a fixed review price. They also do not announce a blanket shutdown of existing routers on October 21. The effective date is November 20.

A provider’s contractual position and individual approval status cannot be established from this announcement alone. Customers evaluating a gateway can ask the provider how the new requirement applies to its service and how it will handle the transition. This is a product and infrastructure explainer, not legal advice about a specific agreement.

The change adds another consideration to model portability. A common API can make switching providers technically straightforward, while the responsibilities attached to that access remain different. A useful gateway will need to make both the request path and the accountability behind it understandable.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders explain product changes and developer infrastructure clearly, so the right audience understands what actually changed.

Book a 30-minute call.