OpenAI Now Requires Prior Approval to Resell Direct Model Access. It Published No Form, No Criteria, and No Grandfathering.
OpenAI's Usage Policies update, dated October 21 in the changelog and effective November 20, 2026, requires prior review and approval for anyone operating a model-access intermediary platform that lets third parties directly access OpenAI models, and expands its anti-distillation rules to cover training data, rubrics, RL environments, labels, rankings, and evaluation outputs later used for training, even if you never train a model yourself. Integrating OpenAI into your own app's features is explicitly not enough to trigger the intermediary rule. There is no published application process, timeline, or grandfathering for existing routers and gateways. We read the policy page and OpenAI's companion post.
By T.W. Ghost
OpenAI updated its Usage Policies with a changelog entry dated October 21, 2026, effective November 20, 2026, and two of the changes land on exactly the readers of this site: people who route OpenAI models through gateways, and people who build with OpenAI's outputs.
The first change is a gate. Operating "a model-access intermediary platform or other service that enables third parties to directly access OpenAI models" now requires OpenAI's prior review and approval. The policy adds, in its own words, that the requirement "does not apply solely because an application integrates OpenAI models to power its features." The second change is a wider fence around training. The anti-distillation section now covers creating training data, rubrics, reinforcement-learning environments, labels, rankings, rewards, and filtering, applies "even if you do not train" the resulting model, and covers evaluation outputs that are later used for training.
What the policy page does not contain is a form, a set of criteria, a timeline, or any grandfathering language for the routers and gateways that exist today. We read the policy page, its changelog, and OpenAI's companion post on broad access and consistent standards. Here is what held up.
What Changed, and When
| OpenAI Usage Policies update | |
|---|---|
| Changelog date | October 21, 2026 |
| Effective | November 20, 2026 |
| Intermediary rule | Prior review and approval required to operate a model-access intermediary platform or service that enables third parties to directly access OpenAI models |
| Explicit carve-out | Does not apply "solely because an application integrates OpenAI models to power its features" |
| Anti-distillation | Covers training material, rubrics, RL environments, labels, rankings, rewards, filtering; applies even if you do not train; covers eval outputs later used for training |
| Other items in the same changelog | National security and law enforcement approval; child and teen provisions; high-stakes use |
| Application process, criteria, SLA, grandfathering | None published |
| Companion post | "Broad access through consistent standards," describing SafetyIDs and partner safeguards |
The line is direct access versus feature integration. A product that calls OpenAI to power its own features is on the safe side by the policy's own sentence. A router, gateway, or proxy that lets its customers call OpenAI models directly is the thing being gated. OpenRouter, Vercel's AI Gateway, LiteLLM-style proxies: that is the category, and none of them has a published path to approval as of today.
Evaluation outputs are training data now, if you train on them later. The expanded section is written to close the gap where a team evaluates OpenAI models, keeps the outputs, and uses them to build a rubric or reward model. The policy says that counts even if a different team, or a different company, does the training.
Cloud partners are not addressed. Whether Azure, or the Google Cloud Vertex preview that launched the same day, counts as an approved intermediary is not spelled out on the policy page. We do not guess, and neither should your compliance team.
Verified vs Unconfirmed: The Scorecard
| Claim | Verdict |
|---|---|
| Changelog dated Oct 21; effective Nov 20, 2026 | Verified (OpenAI Usage Policies page) |
| Prior review and approval required for model-access intermediaries; feature integration exempt | Verified (policy wording, quoted) |
| Anti-distillation covers rubrics, RL environments, labels, rankings, rewards; applies even without training; eval outputs later used for training | Verified (policy wording) |
| Companion blog on SafetyIDs and partner safeguards exists | Verified |
| Application form, criteria, SLA, or grandfathering | Verified absent from the policy page |
| Public response from OpenRouter or Vercel | Unverified (none found) |
| Azure and Google Cloud count as approved intermediaries | Unverified (not addressed) |
Who This Is For
If you run a router, gateway, or proxy that gives customers direct OpenAI model access: escalate to legal before November 20. There is no door to knock on yet, which is itself the finding, and the policy takes effect whether or not one appears.
If you build evaluation pipelines: inventory where OpenAI outputs end up. If any of them feed a rubric, a reward model, or a training set, anywhere, the new section reaches them.
If you only call the API from your own product: the policy says you are fine, in a sentence you can quote.
The frontier is elsewhere: this is a policy story, not a model story, and the models it covers are the same ones on our Index this week. Our model comparison has the current standings side by side, and the week's other OpenAI distribution news, the Google Cloud preview, is where the intermediary question will first get tested.
Sources
- OpenAI: Usage Policies
- OpenAI: broad access through consistent standards
- DigIntoAI: OpenAI usage policy for routers and gateways
*Not sure whether your stack is a feature integration or an intermediary under the new wording? Take the free 2-minute quiz and get matched. Then read about a gateway product that sells OpenAI's rivals by the token, and what its terms let the operator change: Vercel's Token Pass.*