OpenAI intermediary approval: what does it mean for customers of AI platforms?

On 21 October 2026 OpenAI announced that its Usage Policies will, from 20 November 2026, require prior approval for services that give third parties direct access to OpenAI models. The announcement names model routers and AI gateways as examples. The change affects businesses that buy access to language models through a third-party platform, and providers that offer such access themselves. This article considers which services are caught, the basis on which OpenAI may cut off access, the allocation of risk along the contract chain, and what the customer should require of the platform.

What does OpenAI require of intermediaries from 20 November 2026?

The Usage Policies contain a new provision headed “Providing access to our models”, which requires intermediaries to obtain OpenAI’s prior review and approval. It reads as follows.

«If you operate a model-access intermediary platform or other service that enables third parties to directly access OpenAI models, you must obtain our prior review and approval.»

According to the announcement, partners that provide access to OpenAI models must maintain safeguards comparable to OpenAI’s own, investigate suspected violations and coordinate enforcement with OpenAI. OpenAI has not yet published approval criteria, an application process or processing times, and no list of approved services had been found as at 11 November 2026.

Which services need OpenAI intermediary approval?

The requirement is aimed at services that pass on access to the model itself. Typical examples are routers and gateways that give customers access to models from several providers through a single API. The Usage Policies expressly exclude ordinary applications, since the requirement does not apply solely because an application integrates OpenAI models to power its features or functionality.

The boundary is nonetheless not sharp. A SaaS product that uses a model to summarise documents is an application. If the same provider also offers an open API or a developer feature through which customers choose the model and submit their own prompts, that part of the service may be an intermediary. In our view the test should turn on whether the customer in substance obtains access to the model as such, and not on how the provider markets the service. The role a platform assumes under the AI Act when it resells access is discussed in the article on reselling AI and the provider role.

On what basis can OpenAI suspend access?

The basis lies in the platform’s own agreement with OpenAI. Under section 16.1 of the OpenAI Services Agreement, the Usage Policies are incorporated by reference, and under section 3.3(a) the customer must neither use the services in breach of the policies nor permit its end users to do so. The agreement already prohibits reselling or leasing access to the account (section 3.1) and buying, selling or transferring API keys (section 3.3(g)). The new requirement defines which onward access OpenAI will permit.

In the event of breach, OpenAI may limit or suspend access under section 8.2. OpenAI must use reasonable efforts to give notice first, but may suspend without notice where reasonably necessary. A material breach that is not cured within 30 days of written notice entitles OpenAI to terminate under section 11.2. Breach of section 3.3 is also carved out of the exclusion of indirect loss in section 14.1, so an intermediary operating without approval faces uncapped exposure to OpenAI for that category of loss. For customers in the EEA the contracting party is OpenAI Ireland Ltd, and the agreement is governed by Irish law. Suspension clauses in cloud contracts more generally are discussed in the article on cloud suspension clauses.

The point at which the requirement binds a particular platform is not entirely settled. Under the definition of “OpenAI Policies”, the applicable version is the one in force on the latest of the effective date of the agreement, the most recent order form or renewal. In our view a platform with an older order form may therefore argue that the new policies apply only from its next renewal. The argument offers limited protection, because the Usage Policies also reserve OpenAI’s right to withhold access where it reasonably believes this is necessary to protect the service or others.

How is the risk allocated along the contract chain?

A customer of a router or gateway normally has no contract with OpenAI. Any claim arising from loss of model access must therefore be brought against the platform and decided under the platform agreement. Platform terms often disclaim responsibility for third-party models, but in our view such a disclaimer is unlikely to cover a suspension caused by the platform’s own failure to seek approval, since that matter lies within the platform’s control and is therefore not force majeure either.

Purchasing through an authorised reseller differs from purchasing through an intermediary. The Services Agreement contemplates that a customer may buy through a reseller and still be a party to the agreement with OpenAI, in which case the provisions on notice before suspension apply directly to the customer. The customer should therefore establish which of the two models actually applies.

What does the approval requirement mean for the processor chain?

Where the platform routes personal data to OpenAI on the customer’s behalf, the platform will normally be a processor and OpenAI a sub-processor. Under GDPR Article 28(2) a processor may engage another processor only with the controller’s prior authorisation, and under a general authorisation the controller must be informed of intended changes and given the opportunity to object. Under GDPR Article 28(4) the same data protection obligations must be imposed on the sub-processor, and the platform remains fully liable to the customer for the sub-processor’s performance.

The approval requirement affects the processor chain in two ways. If the platform loses access and redirects traffic to another model provider, that is a change of sub-processor requiring notice and giving the customer a right to object. If the platform instead seeks to maintain access through another channel, such as a cloud provider hosting OpenAI models, that channel must also appear on the list of authorised sub-processors. The general requirements for the agreement are set out in the article on the SaaS data processing agreement.

What should the customer require of the platform provider?

Customers using OpenAI models through a router, gateway or other third-party platform should review the agreement before 20 November 2026. Providers that are themselves intermediaries should expect the same requirements from their own customers. Further articles on supplier contracts are collected on the contracts topic page.

1. Require written confirmation that the platform has applied for or obtained OpenAI’s approval, and of the conditions attached to it.
2. Agree that the platform must notify the customer immediately of any refusal, withdrawal, restriction or notice of suspension from OpenAI.
3. Require the platform to offer a named alternative model, with any switch made under the sub-processor provisions of the data processing agreement.
4. Agree that price and service levels cannot be changed unilaterally on a change of model, and see the article on SaaS price increases for price adjustment terms.
5. Negotiate a right to terminate without charge if access to the agreed model ceases or changes materially, together with assistance on cloud exit.
6. Agree that the platform bears liability for service interruption caused by lack of approval, and that such loss falls outside both the general limitation of liability and the force majeure clause.

Questions and answers

Next legal review: 27 November 2026