OpenAI will require approval for model routers and AI gateways from November 20

OpenAI is adding a prior‑review requirement for services that let third parties directly access its models. In an [October 21 announcement](https://openai.com/index/broad‑access‑through‑consistent‑standards/), the company identified model routers and AI gateways as examples and set November 20, 2026 as the effective date of its updated Usage Policies. The timing matters: this is an announced policy change with a future effective date, rather than evidence that every gateway has already been assessed. The [policy itself](https://openai.com/policies/usage‑policies/) states that operators of a model‑access intermediary platform, or another service enabling third parties to directly access OpenAI models, must obtain OpenAI’s review and approval. Neither document provides a public list of approved gateways, a review turnaround or a detailed application procedure. A named service’s approval status cannot be inferred from its absence from this announcement.

The [updated policy](https://openai.com/policies/usage‑policies/) includes an explicit qualification: the requirement does not apply solely because an application integrates OpenAI models to power its own features or functionality. That gives developers a more useful starting point than assuming every AI‑enabled product is a model reseller. For a product team, the practical question is what the service offers its customers. An application feature and a service offering direct model access are different descriptions of a product. The qualification does not provide a complete test for every mixed business, so teams operating both kinds of service need to resolve that boundary against the actual policy and OpenAI’s review process. Merely renaming a gateway as an app would not answer the underlying question of what users can access.

OpenAI presents the approval requirement as part of a broader effort to align safety rules across its own service, partners hosting its models and reseller partners. It [says partners must maintain safeguards consistent with its own](https://openai.com/index/broad‑access‑through‑consistent‑standards/), investigate potential violations and coordinate enforcement so restrictions remain effective across services. The consequence for buyers is that a different access route should not be assumed to remove the provider’s safety requirements. Model choice, commercial terms and integration design can still differ across services, but this announcement makes consistent safeguards an explicit distribution objective. The policy development follows the expansion of partner access, including [OpenAI models in Google Cloud’s Model Garden](https://opentools.ai/news/openai‑models‑google‑cloud‑model‑garden‑codex‑access).

OpenAI also [describes work with customers on SafetyIDs](https://openai.com/index/broad‑access‑through‑consistent‑standards/). It says customers can provide those identifiers to help distinguish individual end users during an investigation without OpenAI learning their identities, with the aim of reducing disruption to others. That is the company’s description of the system and intended effect; the announcement is not an independent validation of its privacy properties or enforcement results. The company says misuse may involve end users, compromised accounts or leaked API keys. It also says enforcement decisions are based on documented conduct and risk, and restrictions can be revisited when meaningful changes address the concerns. Those statements describe its intended approach, rather than a guarantee about any particular investigation.

Operators offering direct model access have a concrete date around which to organize their policy review. They should establish which part of their service falls within the direct‑access requirement, seek confirmation of the applicable approval path and retain the answer alongside their customer‑facing access arrangements. Customers using an intermediary can ask that provider how it is addressing the change. The next useful evidence will be operational: application instructions, approval‑status communication and explanations for products that combine features with direct access. Until those details are available, the announcement supports a dated compliance question, not a conclusion that any particular vendor is unauthorized. The [effective policy text](https://openai.com/policies/usage‑policies/) is the reference for the requirement and its exception. *Figure by OpenTools Team; no third‑party expressive material used. Original explanatory figure based on the linked OpenAI policy documents.*