OpenAI now wants to approve the AI gateways that offer its models. Find out if yours counts before November 20
OpenAI's updated Usage Policies require model routers and AI gateways that provide direct access to its models to get its approval. The rule is contractual, and its edges are not yet clear.
Listen to this article · 6 min
AI-generated narration of the full article.
The AI gateway has spent the last year becoming the most useful box in the enterprise AI diagram. It routes requests to the cheapest capable model, enforces budgets, logs every call and lets a platform team switch providers without touching applications. From November 20, for OpenAI’s models, it may also need OpenAI’s permission.
In a post on October 21, OpenAI said it is updating its Usage Policies, effective November 20, 2026, and that the update builds on its safety work “by requiring services that provide direct access to our models such as model routers or AI gateways to get our review and approval before offering that access.”
On the same day, OpenAI and Google Cloud announced that OpenAI’s models are coming to Google Cloud’s Model Garden. The two announcements belong together. OpenAI is widening the number of places its models can be bought and, at the same time, tightening who is allowed to pass them on.
What OpenAI actually said
The post is short, and its key commitments are these:
- The policies apply whether people reach OpenAI’s models directly, through partners that host them, or through resellers.
- Partners that provide access must maintain safeguards consistent with OpenAI’s own, investigate potential violations and act on them, and coordinate enforcement so that a restriction in one place holds in the others.
- Services that provide direct access, “such as model routers or AI gateways,” need OpenAI’s review and approval before offering it.
- OpenAI is working with customers to introduce SafetyIDs, identifiers a customer can pass so OpenAI can tell individual end users apart in an investigation without learning who they are.
This is a provider’s contractual policy, not regulation. It binds those who accept OpenAI’s terms, directly or through a partner. It is also, for now, a description of intent: the post does not publish the approval process, the criteria or any exceptions.
Where the line probably falls, and where it is unclear
Three common setups read very differently against that sentence.
A commercial router or aggregator that sells access to many models, OpenAI’s among them, to anyone with a credit card. This is the most direct reading of “services that provide direct access.” If your teams use one, its approval status is now a dependency of your architecture.
A software product that exposes raw model access to its own customers, for example a platform that lets clients pick “GPT” from a menu and send arbitrary prompts. Whether that is “direct access” or a product built on a model is exactly the kind of question the policy text does not settle.
An internal enterprise gateway that routes your own employees’ and applications’ requests. Most enterprises built one for cost and control, and we have argued the gateway is becoming a policy enforcement point rather than a proxy. Whether OpenAI considers an internal gateway a service “offering that access” is not stated. Do not assume either answer. Ask your account team, and get the answer in writing before November 20.
Why enterprises should care even if they are clearly exempt
Your routing strategy now depends on each provider’s distribution terms. Multi-provider routing assumes you can send any request to any model you are licensed for. If one provider restricts which intermediaries may carry its models, a router that loses approval stops being able to serve that model, and your fallback plan has to cover it.
Approved channels will multiply, and they are not identical. OpenAI models are now reachable directly, through Microsoft, through Oracle commitments, through AWS’s Bedrock Managed Agents in preview and soon through Google Cloud. Each is an approved path with its own controls and timing. An unapproved router is a path that can close. Your model inventory should say which path each workload uses, as we suggested in our note on OpenAI’s arrival on Google Cloud.
Per-user identity at the gateway stops being optional. SafetyIDs exist because a provider investigating misuse through a shared API key sees one customer, not the person who caused the problem. OpenAI’s alternative to that ambiguity is restricting the whole key. A gateway that forwards a stable, pseudonymous user identifier lets an investigation target one user instead of an entire application. It is good practice for your own audit trail anyway; Databricks, for example, lets gateway policies read request context supplied by the caller.
Before November 20
- List every path by which your company reaches OpenAI models: direct API, cloud marketplaces, routers, and SaaS tools that call OpenAI underneath. The last group is usually the longest.
- Ask each router and AI platform vendor whether it has applied for or received OpenAI’s approval, and what happens to your traffic if it has not by November 20.
- Ask OpenAI or your reseller whether your internal gateway is in scope, and record the answer.
- Add a continuity clause to router contracts: notice if the vendor loses access to a provider, and a defined fallback.
- Propagate a pseudonymous end-user identifier through the gateway to every provider that accepts one, so an abuse investigation stops at a user rather than at your application.
None of this is a reason to abandon gateways. It is a reason to treat the gateway as what it has become: a contractual party in your model supply chain, not just a piece of plumbing.