OpenAI’s Usage Policy Rewrite Turns Model Gateways Into an Approval Request and Fences Off Training Signals, but the Announcement Barely Mentions the Training Rules

On October 21, OpenAI published a rewrite of its Usage Policies that takes effect on November 20, together with a blog post, Broad access through consistent standards, that explains one part of it. Services that give other people direct access to OpenAI’s models, which the post calls “model routers or AI gateways”, will have to get OpenAI’s “review and approval” before they offer that access. The policy page says more than the post does. I diffed it against OpenAI’s own archived October 2025 revision: the body grows from 843 to 1,411 words, occurrences of the stem “train” go from zero to nine, and a new 208-word section bars using OpenAI models or their outputs to “generate, prepare, select, or supply training material or signals” for models “intended as alternatives to or substitutes for” OpenAI’s own.

Neither the post nor the policy page says how to apply for approval or how long a review takes, and the only description of what OpenAI weighs sits in a neighboring paragraph about case-by-case exceptions. This article puts the three documents that matter side by side (the post, the policy and the Services Agreement that binds business customers), sets the new wording beside Anthropic’s and Google’s API terms, and tests one thing a gateway operator can do now: pass on the per-user safety identifier that OpenAI’s developer guide recommends. I ran one open-source gateway, LiteLLM 1.106.2, in front of a fake upstream to see which request fields survive the hop. This is a reading of published text, not legal advice, and I did not contact OpenAI or any gateway vendor. Page states and facts are as of about 11:00 UTC on October 22, and the pages can change, so check them again before you act.

In short

• The post spotlights a rule for model-access intermediaries. The policy also adds a 208-word training clause that covers scores, rankings, preferences and rewards given to models meant as substitutes for OpenAI’s, and the post gives it one clause.
• Both changes take effect November 20. I found nothing published that says how to apply for gateway approval, and the Services Agreement ties the version of the policies a customer is held to to its order form and renewal dates, not to a calendar day.
• The contract already barred reselling account access and using Output to build competing models, with two Permitted Exceptions. The new text is wider in its verbs (generate, prepare, select, supply) and in its target (“alternatives to or substitutes for”).
• Gateway operators can act now. LiteLLM 1.106.2 forwarded safety_identifier on every path I tried, while the older user field vanished for a fine-tuned model ID.

What changed, and when

• October 29, 2025: the previous version, which OpenAI still serves at a revisions URL.
• October 21, 2026: the changelog entry on the policy page, and the post, which OpenAI’s feed stamps at 21:00 UTC.
• November 20, 2026: the effective date. It is a Friday, 30 days after the changelog entry and 29 days after the day I wrote this.

The changelog’s own summary covers more than the post does: “We’ve updated our Usage Policies to clarify restrictions on using OpenAI models and outputs to train other models. We’ve also clarified protections for children and teens and requirements for high-stakes uses. The update also incorporates our existing national security principles and sets out approval requirements for national security and law enforcement uses, as well as for model-access intermediaries.”

My method was plain. I saved both pages, cut each to the text between the opening sentence (“We aim for our tools to be used safely and responsibly”) and the changelog, split that text into sentences and compared the two lists with Python’s difflib. The word and keyword counts in this article come from the same text, after stripping the “(opens in a new window)” link labels.

The announcement and the policy text describe different things

The post is about partners and gateways. Its one sentence on the Usage Policies reads: “We’re also updating our Usage Policies, effective November 20, 2026, to clarify the rules for safe model development and sensitive uses of AI.” The sentence after it is the gateway rule. The table sets what the post says beside what the page says.

The same day, nine hours before the post by the feed’s timestamps, OpenAI announced that its frontier models and Codex workflows are coming to Google Cloud’s Model Garden, sold through the Google Cloud Marketplace with general availability “planned in the coming weeks”. The page adds that “Microsoft remains OpenAI’s primary cloud partner”, and its reading list carries a June 10 item about reaching OpenAI models through an Oracle cloud commitment. Those are presumably among the “partners that host them” the post mentions. OpenAI does not say whether such marketplaces fall under the intermediary rule or under separate agreements, and the post does not link the Google Cloud announcement.

One more line in the post is worth keeping in view: “Some safeguards are built into the model and others depend on the systems and people around it.” It echoes our refusal piece, which argued that a model’s “no” is a vendor setting rather than a control you own; here the vendor’s conditions extend outward to the services that carry the model.

The rewrite, section by section

Most of this is tightening. Three edits are different in kind. The training clause and the intermediary rule are new obligations. The high-stakes edit widens a rule written for decisions into one that also covers actions, transactions and submissions, which matters to anyone shipping agents in housing, employment, credit, insurance, legal, medical or government work.

The training clause

What the text says

The clause opens with its reason: “Capable models must have safeguards proportionate to the risks they pose before they are deployed. Training another model on OpenAI outputs can transfer capabilities without carrying those safeguards over.” Then the rule: “You must not use OpenAI models or their outputs to generate, prepare, select, or supply training material or signals for models that are intended as alternatives to or substitutes for OpenAI models or services.” It lists what that includes:

• “Creating or preparing training data, training tasks, rubrics, or reinforcement-learning environments.”
• “Providing feedback used in training, including labels, scores, rankings, preferences, rewards, or corrections.”
• “Selecting, filtering, or validating training data, tasks, or trajectories.”

A separate sentence adds: “You must not attempt to extract protected reasoning through unauthorized access, reverse engineering, or circumvention of safeguards.” Two sentences then close the easy exits: “These restrictions apply whether you perform the work yourself, for another party, or through someone acting on your behalf, even if you do not train the resulting model. They also apply when outputs from product use or evaluation are later used or supplied for those training purposes.” The permissions come last: “You may use OpenAI models for research, software development, model evaluation and benchmarking, and product development, within these boundaries.” And: “These restrictions do not prohibit uses expressly permitted by your applicable Agreement with OpenAI, including any Permitted Exception under the Services Agreement.”

On its face, an LLM judge that scores rollouts in a reinforcement-learning loop is inside the text, because scores, rankings and rewards are named. So is a vendor that prepares labels for someone else’s model, and so is a dataset of model outputs handed to a third party. That is wider than a sentence about competitors.

How it differs from the contract

The Services Agreement (updated December 1, 2025, effective January 1, 2026) already restricted some of this. Its section 3.3 starts “Customer will not, and will not permit End Users to:” and item e reads “except for a Permitted Exception, use Output to develop artificial intelligence models that compete with OpenAI’s products and services”. Item a makes it a breach to “use the Services or Customer Content in a way that violates applicable laws or OpenAI Policies”, and the agreement defines OpenAI Policies to include the Usage Policies. On a plain reading, the policy text reaches customers through the contract.

The shift is from “compete” to “alternatives to or substitutes for”, and from “develop” to a list of verbs that includes supplying material and judging it. A model your company trains to replace GPT calls in one feature does not obviously compete with OpenAI’s products, but it may be intended as a substitute for an OpenAI model. The text does not say which reading OpenAI holds.

What Anthropic and Google say

A ban on training competing models is common. The two other terms I read, as fetched on October 22, use the same “compete” test:

What is new in OpenAI’s text is its width: named verbs for the work done inside a training pipeline, a “substitutes” target, and a scope that follows the work to a contractor.

The reason OpenAI gives

The reason the policy gives is safety, not competition: training another model on OpenAI outputs “can transfer capabilities without carrying those safeguards over”. Three weeks earlier, on September 30, OpenAI published a report on a distillation campaign, which it described as “the systematic and unauthorized use of one model’s outputs or reasoning to help train, reproduce, or improve another model”. OpenAI counted high-volume spikes on July 24 and 25 of 16,000 attempted extraction requests from over 4,000 users, and related prompt patterns across more than 15,000 users, which it says it fully disrupted by July 28. Its “Why this matters” section uses the same logic as the new clause: extracted reasoning “could be used to train another model without preserving the safeguards applied to the original model’s user-facing outputs”.

Two lines in that report bear on gateways. “When related activity moved through third-party services, we worked with those providers to identify and disrupt the accounts involved.” And: “Partner-hosted deployments need the same protections as first-party services.” A joint CISA, NSA and FBI advisory in September, covered here, had accused six Chinese AI companies of industrial-scale distillation. I read the intermediary rule and the training clause as two halves of one response to that pressure. That is my inference; neither document says so.

Six cases, read against the text

OpenAI has published no examples, so this table is my reading of the words, not OpenAI’s position.

The gateway rule

The whole rule is two sentences: “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. This requirement does not apply solely because an application integrates OpenAI models to power its features or functionality.” The post glosses the first sentence with examples the policy never uses: “model routers or AI gateways”. Model routers are a business, not a corner case; our August piece on Stripe’s reported $7 billion-plus acquisition of OpenRouter is one measure of it.

One sentence, five kinds of service

The examples below are descriptions of what products do, taken from their own documentation. They say nothing about any company’s agreement with OpenAI, and I did not ask any of them.

What the contract already said

For a business customer, unapproved resale was already a contract problem. Section 3.1 of the Services Agreement says “Customer may not resell or lease access to its Account or any End User Account”, and section 3.3 item g bars the customer from “buy, sell, or transfer API keys from, to, or with a third party”. The agreement also holds the customer responsible for “the activities of End Users with an End User Account or who access the Services through a Customer Application”. It still contemplates resellers: fees are paid to “OpenAI or Customer’s reseller”. The new sentence reads like an approval route for what the contract otherwise forbids, and because item a lists violating the OpenAI Policies among the customer’s prohibited acts, the sentence also reaches customers through the contract. The post does not describe it that way.

What the text leaves open

• What “directly access” means, and whether a company that brings its own OpenAI key to a gateway is among the “third parties”.
• Whether cloud marketplaces (Microsoft, Oracle, Google Cloud) fall under the rule or under separate partner agreements. The post names “partners that host them” and “reseller partners” as groups its policies apply to, apart from the services that need approval.
• How to apply, what is reviewed, and how long it takes. The neighboring “OpenAI-approved use” paragraph says OpenAI reviews “the partner, proposed use, applicable safeguards, and the partner’s compliance commitments” for case-by-case exceptions and that approvals “may require written terms”, but it does not say that this process covers intermediaries.
• What happens on November 20 to an intermediary that has not been approved. The page says only that breaking the rules “may mean you lose access to our systems or experience other penalties”.
• Whether approval attaches to the intermediary, to each use case or to each model family.

A date in the post and a clause in the contract

The post gives a calendar date. The Services Agreement, which governs API use and the business ChatGPT plans, defines the applicable policies another way: “The version of OpenAI Policies applicable to Customer are those in effect on the most recent effective date between either the Agreement, Customer’s most recent Order Form, or Services renewal.” An Order Form can be “the ordering document signed by Customer and OpenAI or OpenAI webpage that Customer uses to purchase the Services”. Read plainly, that ties the version you are held to a contract event rather than a calendar day, and for a self-serve customer a purchase through an OpenAI web page may be that event. The post does not mention the clause, and I found no OpenAI statement on how it will treat agreements signed before November 20. If you hold an order form, check its dates and ask; I would not assume either way.

A check you can run today: does your gateway pass the safety identifier?

What OpenAI asks for

OpenAI’s safety best practices guide tells developers to send a per-user identifier: “They create a stable way to trace activity back to an individual end user and reduce the chance that one user’s misuse disrupts access for your broader organization.” The identifier goes in the safety_identifier parameter, should uniquely identify each user, and should be hashed (“Hash the username or email address in order to avoid sending us any identifying information”). The guide says identifiers are “recommended for products where individual users interact with a model, but they are not required”. Realtime sessions take the same value in an HTTP header named OpenAI-Safety-Identifier, and its Images API paragraph asks for the same stable identifier for each end user and 128 characters or fewer.

The post says OpenAI is “working with customers to introduce SafetyIDs, which customers can provide to help us distinguish between individual end users in an investigation without OpenAI learning those users’ identities”. It does not say whether SafetyIDs are this parameter or something new. Either way the gateway question is the same: an operator that sits in front of many customers and forwards nothing leaves OpenAI little to tell those customers’ end users apart, which is the case the guide’s sentence about “one user’s misuse” addresses.

The probe

The script starts a fake upstream that records every chat completion request body, sends the same request through each path, and prints whether two identifier fields arrived. It sends no traffic to OpenAI. Setup on Windows 11 with Python 3.13.14:

python -m venv probe-env
probe-env\Scripts\activate
python -m pip install "litellm[proxy]==1.106.2" "openai==2.54.0"
python gateway_probe.py

# gateway_probe.py
"""Which request fields does a gateway pass on to the upstream model API?

Starts a fake upstream (stdlib only) that records every chat completion request body,
sends the same request through each path, and prints which identifier fields arrived.

    python gateway_probe.py            # direct SDK, LiteLLM library, LiteLLM proxy
    python gateway_probe.py direct     # only the SDK baseline
"""
import json
import subprocess
import sys
import threading
import time
import urllib.request
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from importlib.metadata import version
from pathlib import Path

UPSTREAM_PORT, PROXY_PORT = 8801, 4000
MODELS = ["gpt-4o", "ft:gpt-4o-mini:acme::probe01"]  # a catalog name, and a fine-tune ID no catalog lists
FIELDS = {"safety_identifier": "u_3f9a1c", "user": "tenant-42-user-7"}
MESSAGES = [{"role": "user", "content": "ping"}]
SEEN = []  # request bodies the fake upstream received
VERBOSE = False  # "serve" mode prints each request as it arrives


class Upstream(BaseHTTPRequestHandler):
    def do_POST(self):
        body = json.loads(self.rfile.read(int(self.headers.get("Content-Length", 0))))
        SEEN.append(body)
        if VERBOSE:
            print(self.path, {k: body.get(k, "<absent>") for k in FIELDS}, flush=True)
        reply = {"id": "chatcmpl-probe", "object": "chat.completion", "created": 1,
                 "model": body.get("model", "x"),
                 "choices": [{"index": 0, "finish_reason": "stop",
                              "message": {"role": "assistant", "content": "ok"}}],
                 "usage": {"prompt_tokens": 1, "completion_tokens": 1, "total_tokens": 2}}
        data = json.dumps(reply).encode()
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(data)))
        self.end_headers()
        self.wfile.write(data)

    def log_message(self, *args):
        pass


def row(path, model, before):
    """Print one table row from the newest request the upstream saw since `before`."""
    if len(SEEN) == before:
        print(f"{path:<20} {model:<30} upstream saw nothing")
        return
    body = SEEN[-1]
    cells = ["forwarded" if k in body else "DROPPED" for k in FIELDS]
    print(f"{path:<20} {model:<30} {cells[0]:<19} {cells[1]}")


def probe_sdk(base_url, api_key, model, path):
    from openai import OpenAI
    before = len(SEEN)
    try:
        OpenAI(base_url=base_url, api_key=api_key).chat.completions.create(
            model=model, messages=MESSAGES, **FIELDS)
    except Exception as exc:
        print(f"{path:<20} {model:<30} raised {type(exc).__name__}: {str(exc)[:100]}")
        return
    row(path, model, before)


def probe_litellm_library(model):
    import litellm
    before = len(SEEN)
    try:
        litellm.completion(model=f"openai/{model}", messages=MESSAGES,
                           api_base=f"http://127.0.0.1:{UPSTREAM_PORT}/v1",
                           api_key="sk-upstream-test", **FIELDS)
    except Exception as exc:
        print(f"{'litellm library':<20} {model:<30} raised {type(exc).__name__}: {str(exc)[:100]}")
        return
    row("litellm library", model, before)


def run_litellm_proxy():
    here = Path(__file__).resolve().parent
    entries = "".join(
        f"  - model_name: {json.dumps(m)}\n    litellm_params:\n      model: {json.dumps('openai/' + m)}\n"
        f"      api_base: http://127.0.0.1:{UPSTREAM_PORT}/v1\n      api_key: sk-upstream-test\n"
        for m in MODELS)
    (here / "proxy_config.yaml").write_text(
        "model_list:\n" + entries + "general_settings:\n  master_key: sk-proxy-test\n", encoding="utf-8")
    exe = Path(sys.executable).with_name("litellm.exe" if sys.platform == "win32" else "litellm")
    proc = subprocess.Popen([str(exe), "--config", str(here / "proxy_config.yaml"),
                             "--port", str(PROXY_PORT)],
                            stdout=open(here / "proxy.log", "w"), stderr=subprocess.STDOUT)
    try:
        for _ in range(120):
            try:
                urllib.request.urlopen(f"http://127.0.0.1:{PROXY_PORT}/health/liveliness", timeout=2)
                break
            except Exception:
                time.sleep(1)
        else:
            print("litellm proxy did not start; see proxy.log")
            return
        for m in MODELS:
            probe_sdk(f"http://127.0.0.1:{PROXY_PORT}/v1", "sk-proxy-test", m, "litellm proxy")
    finally:
        if sys.platform == "win32":
            subprocess.run(["taskkill", "/PID", str(proc.pid), "/T", "/F"], capture_output=True)
        else:
            proc.terminate()


if __name__ == "__main__":
    which = sys.argv[1] if len(sys.argv) > 1 else "all"
    server = ThreadingHTTPServer(("127.0.0.1", UPSTREAM_PORT), Upstream)
    if which == "serve":  # point your own gateway at http://127.0.0.1:8801/v1 and watch the fields arrive
        print("fake upstream on port", UPSTREAM_PORT, flush=True)
        VERBOSE = True
        server.serve_forever()
    print("openai", version("openai"), "| litellm", version("litellm") if which != "direct" else "-")
    threading.Thread(target=server.serve_forever, daemon=True).start()
    print(f"{'path':<20} {'model':<30} {'safety_identifier':<19} user")
    for m in MODELS:
        probe_sdk(f"http://127.0.0.1:{UPSTREAM_PORT}/v1", "sk-upstream-test", m, "openai SDK direct")
    if which != "direct":
        for m in MODELS:
            probe_litellm_library(m)
        run_litellm_proxy()

To test a different gateway, run python gateway_probe.py serve, point the gateway’s OpenAI-compatible upstream at http://127.0.0.1:8801/v1, send one request that carries both fields, and read the line the server prints. A field the gateway dropped shows as <absent>.

What came back

openai 2.54.0 | litellm 1.106.2
path                 model                          safety_identifier   user
openai SDK direct    gpt-4o                         forwarded           forwarded
openai SDK direct    ft:gpt-4o-mini:acme::probe01   forwarded           forwarded
litellm library      gpt-4o                         forwarded           forwarded
litellm library      ft:gpt-4o-mini:acme::probe01   forwarded           DROPPED
litellm proxy        gpt-4o                         forwarded           forwarded
litellm proxy        ft:gpt-4o-mini:acme::probe01   forwarded           DROPPED

The safety identifier survived every path. OpenAI’s own SDK delivered both fields to the fake upstream, and LiteLLM forwarded safety_identifier as a library and as a proxy, for both model names. The older user field behaved differently: LiteLLM forwarded it for gpt-4o and dropped it for the fine-tune ID, in the library and in the proxy alike. The cause is in the package. In the wheel I installed, the OpenAI chat configuration (litellm/llms/openai/chat/gpt_transformation.py) lists safety_identifier among the parameters that work for every model and adds user only when the model name is in LiteLLM’s own list of OpenAI models:

        if OpenAIGPTConfig.is_openai_catalog_model(model):
            model_specific_params.append(
                "user"
            )  # user is not a param supported by all openai-compatible endpoints - e.g. azure ai

A fine-tuned model has an ID in the style of the one in my probe, which LiteLLM’s list does not contain. For such models a client that still relies on user loses it silently at the gateway, while a client that sends safety_identifier does not. I am not calling this a bug: the code comment gives a reason, since some OpenAI-compatible endpoints reject the field. The point is that the answer depends on the gateway’s version and model list, which is why the probe is worth running against the gateway you actually use. The LiteLLM 1.106.2 release is the version tested.

Limits of the test

The fake upstream answers every request with a canned reply, so the probe tests field passing and nothing about what OpenAI does with an identifier. It covers one gateway at one version. It sends chat completions only, so it does not cover streaming, the Responses API, or the Realtime header. I ran it on Windows only; the script has a branch for other platforms that I did not run.

An order of work for the next four weeks

1. List every flow from OpenAI output into a model that is not OpenAI’s. Include training data, rubrics, labels, scores, preferences and rewards, and include vendors who do this work for you. For each, write down the target model and whether it will be distributed or sold.
2. Sort each flow against the two Permitted Exceptions. An internal classifier or embedding model that is not distributed, or an OpenAI fine-tune made through OpenAI’s own service, matches. Anything else goes on the list of questions for OpenAI.
3. Wall evaluation off from training. The text covers outputs from evaluation that are “later used or supplied” for training, so keep judge outputs and benchmark logs out of training stores, selection scripts and filters.
4. Decide which kind of gateway you run. If other organizations or your customers’ tenants call it, write to your OpenAI contact before November 20. If you depend on someone else’s gateway, ask that operator for its approval status and its plan.
5. Read your order form and renewal dates against the version clause, and ask OpenAI in writing which version applies to you and from when.
6. Forward a per-user safety identifier now. Derive it per end user (a keyed hash of tenant and user IDs, not a raw email), keep it to 128 characters or fewer as the guide asks for the Images API, and run the probe against your gateway after every upgrade and every new model alias.
7. Subscribe to OpenAI’s policy update notices and re-diff the page before November 20. It is the page’s only mechanism for hearing about changes.
8. Keep a provider-neutral fallback, and remember that Anthropic’s and Google’s terms carry their own bans on training competing models.

What I could not verify

• I found no application form, criteria or timeline for intermediary approval in the post, the policy page, the Services Agreement or the developer docs index. I read those pages and listed the fifteen links in the policy body; none is an application. A web search for the phrase “model-access intermediary” found nothing else, but that search cannot see pages this new.
• I do not know whether OpenAI will apply the November 20 text to existing business agreements on that date or at the next order form or renewal.
• OpenAI has defined neither “directly access” nor “alternatives to or substitutes for”, so the tables above are readings, not rulings. I am not a lawyer.
• I tested one gateway version, on one platform, for chat completions only. I did not test other gateways, and I did not ask OpenAI, Anthropic, Google or any gateway vendor for comment.
• Policy pages can change after publication. Anthropic’s METR page was edited the day after its post, so I saved the text I quote and fetched it again just before publishing; the passages quoted here had not changed.

Sources

• OpenAI, Broad access through consistent standards (October 21, 2026)
• OpenAI, Usage Policies (effective November 20, 2026) and the October 29, 2025 revision
• OpenAI, Services Agreement (effective January 1, 2026)
• OpenAI, Disrupting a coordinated model-distillation campaign (September 30, 2026)
• OpenAI, OpenAI models are coming to Google Cloud (October 21, 2026) and the news feed used for post times
• OpenAI, Safety best practices (developer guide)
• Anthropic, Commercial Terms of Service; Google, Gemini API Additional Terms of Service
• Product documentation: Cloudflare Unified Billing, Vercel AI Gateway, OpenRouter, LiteLLM
• Earlier coverage here: CISA, NSA and FBI on model distillation, Stripe and OpenRouter, a model’s refusal as a vendor setting