OpenAI sets approval requirements for direct model access services
OpenAI announced an approval requirement on October 21, 2026 for services offering direct access to its models. The company names model routers and AI gateways as examples. It gives the updated Usage Policies an effective date of November 20, 2026.
The published policy requires an intermediary or other service enabling third parties to access OpenAI models directly to obtain prior review and approval. An application does not trigger that requirement solely by using OpenAI models to power its own features.
The distinction turns on direct access
For developers, the practical distinction is what the service offers its users. Incorporating a model into an application’s functionality is different from providing direct access to the model itself.
The linked previous policy has no corresponding intermediary access clause. The new page does not supply an application process, approval timetable or public provider roster.
Existing agreements still matter
OpenAI’s Services Agreement already permits developers to build customer applications with its API while separately restricting account resale and transfers of API keys. It ties the applicable policy version to specified agreement, order and renewal dates, with a separate rule for newly adopted services.
Those provisions matter when interpreting the announcement. The published November 20 policy date alone does not establish the deadline for every existing customer. This article does not determine any individual provider’s contractual obligations.
Safeguards follow the access route
OpenAI says partners supplying its models must maintain comparable safeguards, investigate suspected violations and coordinate enforcement across services. Its stated approach covers hosting and reseller partners as well as direct access. These are the company’s descriptions of its standards and enforcement arrangements.
The announcement also describes work with customers on SafetyIDs. OpenAI says these identifiers help distinguish individual users during investigations without revealing their identities to the company.
Safety identifiers remain optional
Existing developer documentation recommends safety identifiers but says they are optional. It lists support in Responses, Chat Completions and Images, with an equivalent header for Realtime. Developers are advised to use stable identifiers and hash email addresses or internal user IDs rather than transmit personal information.
The documentation also says identifiers do not automatically carry across APIs or sessions. Applications must pass the stable value for each relevant request or session. These instructions describe existing implementation guidance, rather than establish an October 21 technical launch.
Investigation tools provide separate context
The safety enforcement guide describes organization level webhooks for warnings and deactivation notices. Each notification includes a case identifier that applications can use to retrieve available details for their investigation or support workflow. Reading a case does not reverse enforcement. These notices are separate from project level misalignment alerts, and the guide does not establish when these interfaces first became available.
Related coverage explains OpenAI’s separate API service tier restrictions, which concern processing modes available to a project.
Photo by User_Pascal via Unsplash. Used under the Unsplash License.
