OpenAI logo for the model access policy update effective 20 November 2026
AI

OpenAI sets approval rules for model routers and gateways

October 22, 2026 6 min read

Image credits: OpenAI

Under updated usage policies that take effect on 20 November 2026, third-party services supplying direct access to OpenAI models, such as model routers and AI gateways, need prior approval. OpenAI’s announcement came on 21 October, so the rule is announced but not yet in force.

Ordinary apps built on OpenAI are not the target. A business that uses OpenAI models to summarize documents or draft support replies inside its own product does not need approval for that alone. The rule arrives as OpenAI widens distribution, including access through Google Cloud’s Model Garden and Marketplace, where general availability is planned in the coming weeks.

Paying business customers should not read 20 November as a universal deadline. OpenAI’s business contract decides which policy version applies to each customer, and signed orders can follow different timing.

What changes on 20 November

Picture the access chain. OpenAI builds the models. An intermediary passes access along, and its customers, often software developers, send requests through it instead of going directly to OpenAI. A model router decides which AI model answers each request, and a gateway gives customers one entry point to several models. OpenAI names both but does not set out a technical test for what counts as one.

The announcement says partners must “maintain safeguards consistent with our own, investigate potential violations, and take appropriate action when concerns are identified.” OpenAI adds that it revisits restrictions after meaningful changes and is working on SafetyIDs, which it describes as privacy-preserving, for use in investigations.

Other changes cover protections for minors, licensed advice, and approval for national security, intelligence and law enforcement uses. They also restrict unauthorized extraction of a model’s protected internal reasoning. Human review was already required for high-stakes decisions; the new text explicitly includes consequential actions, transactions and submissions.

Rival AI developer Anthropic announced its own usage policy update on 8 October, effective 12 November. It covers deceptive campaigns, oversight of high-risk uses and autonomous hardware, so it offers no direct parallel to OpenAI’s intermediary rule.

Which services need OpenAI approval

Services that give other people direct access to OpenAI models need approval, while apps that use those models inside their own features do not on that basis. The exemption reads: “This requirement does not apply solely because an application integrates OpenAI models to power its features or functionality.”

Two examples show the line. One company resells a model endpoint, a web address that developers’ code calls to get answers from an OpenAI model. That is supplying model access. Another runs a help-desk tool that drafts support replies with an OpenAI model in the background. That is a feature integration. The word “solely” limits the exemption to the integration itself, not to everything else a product does.

Partner status elsewhere does not settle the question. OpenAI’s announced Google Cloud distribution makes Google Cloud a channel for its models, but it says nothing about whether an unrelated gateway is approved. OpenAI already limits access in other ways, such as its trusted access controls around a cybersecurity model. Still, this rule is broader and reaches every service that passes model access on.

Do ordinary apps and ChatGPT users need to do anything?

No, not because of the approval rule. An app using OpenAI models to power its features is outside that rule on that basis. A person using ChatGPT, OpenAI’s chatbot, deals with OpenAI directly.

Customers of routers and gateways are the ones with real homework. The rule binds their provider directly and reaches them through the access they buy. An IT or procurement team sending work through a gateway should ask the provider for written confirmation that its approval covers the exact service and model route in use. Because the requirement falls on the provider, this is due diligence rather than a new duty for the customer.

Anyone with questions can contact OpenAI support, though that is a contact route, not an approval portal. Teams that lean heavily on one gateway should also plan how they would reach the same models another way if their provider’s standing changed.

What OpenAI outputs can still be used for

Research, development, evaluation, and benchmarking remain allowed under the updated policies, within limits. The restriction covers models and outputs used to prepare training material or signals for models intended as alternatives to OpenAI’s models or services.

Those limits reach well beyond the training run. They cover preparing training data, producing rewards (scores used to steer another model’s learning), filtering data, doing this work for someone else and later reusing evaluation outputs for training. A team can benchmark OpenAI models, but feeding the saved answers into its own substitute model afterward falls inside the restriction.

Much of this is familiar to business customers. OpenAI’s earlier business terms from May 2025 already restricted account resale and API key transfers. API keys are secret software credentials. Competing-model development using outputs was also restricted, with exceptions. What October adds is explicit intermediary approval and detailed training boundaries in the usage policies, sections the previous usage policies from 29 October 2025 lacked.

Both of the old exceptions survive in OpenAI’s current business agreement, and the updated policies recognize contractual exceptions. Here is where common uses of outputs stand, assuming the relevant contract exception applies and all other usage rules are followed.

Allowed:

  • Evaluation and benchmarking, within the training limits above.
  • An internal model primarily intended to categorize, classify or organize data, including embeddings (numerical representations of data), if it is “not distributed or made commercially available to third parties”.
  • Customizing a model through OpenAI’s own fine-tuning or other listed services.

Not allowed:

  • Sharing or selling that kind of internal model to other companies, because it no longer meets that condition.
  • Training a substitute model, including data preparation, rewards, and filtering.

The classifier exception deserves the closest look from product teams. The same model changes status once it is shared with or sold to outsiders.

Why existing contracts may follow different rules

For business customers on OpenAI’s Services Agreement, 20 November may not be the date that matters. The agreement, effective 1 January 2026, ties the applicable policy version to the latest effective date of the agreement, an order form, or a renewal. Using new services added to the Service-Specific Terms after that effective date can trigger a newer policy version.

Signed orders get separate treatment. The agreement singles out “Order Forms signed by Customer and OpenAI (as opposed to an automated ordering page)”. Orders signed before a customer was notified of an update are excepted from it, subject to qualifications for legal compliance and services launched later. When documents conflict, the order form ranks first, then service-specific terms, the agreement, and finally the policies. Professionals will find most of this in sections 16.13 and 17.

Timing has one more wrinkle. Section 16.13(a) provides at least 30 days’ notice for updates that OpenAI judges materially affect customer rights or obligations, except where legal compliance requires otherwise. The publication interval does not establish a customer’s notification date.

Checking this takes a short stack of documents: the signed order form and its date, the latest renewal, a list of OpenAI services started since, and any service-specific terms. Check the applicable notification date and the order form’s update terms. Website posting can provide notice under section 16.13(a). Gateway customers should add the provider’s written evidence of approval.

The announcement and policy do not specify an application process, review time, fee, or approval roster. The unresolved question is how customers can independently verify a provider’s authorization.

Sufyan’s view: If your business reaches OpenAI models through a router or gateway, get written proof of your provider’s approval before expanding that route. The policy date is fixed, but your provider’s approval and your own contract timing are separate questions.