OpenAI said on October 21, 2026 that it is aligning safety rules across every service that offers its models, and that its updated Usage Policies, effective November 20, 2026, will require services that give direct access to its models, "such as model routers or AI gateways," to get OpenAI's review and approval first. The company framed it in a post titled Broad access through consistent standards, tied to its newest models such as GPT-6 Astra.
If you ship through an LLM gateway, a router, or a reseller, this is the policy change to read this week. Related reading: our look at OpenAI models arriving on Google Cloud's Model Garden marketplace, and at the risks of API relays.
TL;DR
| Question | Answer from OpenAI's post |
|---|---|
| What is new? | Updated Usage Policies clarifying safe model development and sensitive uses |
| Effective date | November 20, 2026 |
| Who needs approval? | Services providing direct access to OpenAI models, such as model routers and AI gateways |
| What must partners do? | Maintain safeguards consistent with OpenAI's, investigate potential violations, act on concerns, coordinate enforcement |
| Where does it apply? | Direct from OpenAI, partners that host models, and reseller partners |
| New tool | SafetyIDs, so OpenAI can separate end users in an investigation without learning identities |
| Also mentioned | Trusted access programs and Private Safety Processing |
What OpenAI says changed
The post opens with a statement of intent: over the past few months OpenAI has worked with customers and partners to align safety policies across services that provide its models, and it is now updating its Usage Policies to make the requirements clearer for developers.
Three ideas carry the post.
- Responsibility starts with the lab. OpenAI says it evaluates capabilities and risks before deployment, trains models to follow safety requirements, and tests whether safeguards hold up against deliberate bypass attempts. After release it monitors for abuse. For cyber misuse it trains models to refuse harmful requests and uses systems that look for suspicious patterns across interactions. Trusted access programs add a further layer with eligibility conditions for the most powerful capabilities.
- Safeguards must travel with the model. Some safeguards are built into the model; others depend on the surrounding systems and people. OpenAI says both must work whether people use its models directly or through a partner.
- Partners carry obligations. The policies apply to direct access, to partners that host the models, and to reseller partners. They require those partners to maintain consistent safeguards, investigate potential violations, take action, and coordinate on enforcement so restrictions stay effective across services.
The router and gateway rule
The sentence that matters most for builders is short: the updated policies require services that provide direct access to OpenAI models, such as model routers or AI gateways, to get OpenAI's review and approval before offering that access.
That is a notable shift from an open-API model. Routers and gateways sit between developers and model providers, switch models by price or task, and often pool keys. They are popular for cost control and failover, as in our coverage of model routing at Grok Bot. From a lab's point of view they also create blind spots: the lab sees the gateway's traffic, not the end user's.
Rail switch sending traffic to one of three destinations, illustrating an AI gateway and model router under OpenAI usage policies
OpenAI's post does not name which gateways are affected today, define "direct access," or say how long approval takes. Those details matter for any team whose product is a router, a multi-model proxy or an enterprise AI gateway. We are not going to guess; read the policy text when it publishes and ask your vendor.
SafetyIDs: tracing misuse without identifying users
OpenAI says it is working with customers to introduce SafetyIDs. Customers can pass an identifier so OpenAI can tell individual end users apart during an investigation, without OpenAI learning who those users are.
The practical effect is precision. Today, if one user of a customer's app abuses a model, a lab's only lever may be the whole API key. A SafetyID lets the lab act against one pseudonymous user. OpenAI says this reduces disruption to others and lets it "respond to potential misuse more precisely."
The post also acknowledges the common ways customers get hit: misuse by their end users, compromised accounts, and leaked API keys. It says OpenAI works with customers to understand and fix those problems. If you have not rotated keys recently, the post's mention is a reminder.
Enforcement language
OpenAI commits to basing enforcement decisions on documented conduct and risk, applying rules consistently, and responding proportionately. When it restricts access, it says it will revisit the restriction if meaningful changes in conduct, commitments or safeguards address the concerns. That is a procedural promise, not a contractual one, and the post offers no appeals timeline.
How this fits OpenAI's wider safety and cyber push
The same day OpenAI published two other items: a blueprint for empowering cyber defenders and a Patch the Planet post, which we covered in Brockman on PHP2Shell and remote patching. OpenAI also described a defense factory for cyber agents last month. The pattern is a lab that increasingly argues capable models need controlled distribution, including through Trusted Access for Cyber, and now through partner rules.
The companion blueprint: three proposals for governments and industry
The cyber-defenders post, titled "Democratic governance of frontier AI, part II," says we are in a "defender's window": a limited opportunity to put advanced AI into defenders' hands before advanced offensive cyber capabilities become widely available. It builds on OpenAI's earlier cybersecurity action plan and frontier safety blueprint, and cites its own experience with misalignment and security incidents involving its models as the reason for stronger safeguards across the industry. The blueprint makes proposals in three areas.
| Area | What OpenAI proposes |
|---|---|
| Safety and security for advanced AI | Clearer responsibilities for securing frontier models and agents, detecting dangerous behavior, and keeping reliable shutdown controls for operations under each organization's control |
| Modernizing cybersecurity | Advanced tools, training and technical support for defenders; fixing longstanding weaknesses; investing in essential services and replacing outdated systems |
| Resilient public institutions | Stronger government evaluations and independent technical assessments, consistent incident reporting requirements, better coordinated response and recovery |
Read next to the partner rules, the message is consistent: labs want distribution controls and incident reporting to be normal, and they want governments to require them. OpenAI urges policymakers to act now and tighten requirements as the technology evolves.
There is a competitive reading too. Requiring approval for routers gives OpenAI leverage over intermediaries that blend its models with rivals'. OpenAI frames the change as safety and consistency, and the post says clear rules should help developers "build, compete, and choose the services that work best for them." Which reading proves right will depend on how approvals are granted. That is an opinion, not something the post states.
What developers and gateway operators should do
| If you are... | Do this before November 20 |
|---|---|
| A gateway or router vendor | Contact OpenAI about review and approval; document your abuse detection, logging and enforcement process |
| A company using a third-party gateway | Ask the vendor in writing whether it is approved or in review, and what the fallback is |
| A direct API user | Read the updated Usage Policies, rotate and scope keys, and watch for compromised accounts |
| An app with many end users | Plan to pass a per-user identifier once SafetyIDs are available |
| A reseller or marketplace partner | Confirm your contract reflects safeguards consistent with OpenAI's and a plan to coordinate on enforcement |
| A security team | Treat gateways as a supply chain dependency and monitor for API-key leaks |
For agent builders, the same logic of per-user attribution and strict logging is what an agent security layer needs; AgentBeam, the agent security platform from the explainx.ai team, focuses on stopping AI agents before they take dangerous actions.
Why this matters beyond OpenAI
Every frontier lab faces the same intermediary problem. Models now reach users through clouds, marketplaces, gateways, resold keys and open-source proxies, and a safeguard that exists in the first-party app can vanish one hop later. OpenAI's answer is contractual: make each hop responsible and require pre-approval for the hop that is most likely to blend providers. Expect other labs to publish similar partner rules, and expect gateway vendors to start advertising "approved by" status the way payment processors advertise compliance.
For buyers, the decision rule is simple. Treat a gateway's policy status as a procurement question, the same as uptime and data retention. A gateway that loses approval is an outage risk, not only a legal one, because your product depends on the route to the model.
Open questions
- Which routers and gateways are approved, and how can a developer check?
- What is the review timeline and what criteria apply?
- How will "direct access" be defined for open-source gateways that users self-host?
- How will SafetyIDs be implemented and what data is exposed to OpenAI?
- Does the rule apply equally to Azure and other cloud hosts, which fall under the partner section instead?
We will update this post if OpenAI publishes the policy text or an approved-partner list.
Related reading
- OpenAI models on Google Cloud Model Garden
- FolkBench: API relay benchmark and risks
- Grok Bot model routing
- OpenAI defense factory: cyber agents
- Brockman on PHP2Shell and Patch the Planet
- OpenAI Dev Day 2026
- Official: OpenAI: Broad access through consistent standards · OpenAI: Empowering cyber defenders
Details are from OpenAI's post dated October 21, 2026; the policy text itself may differ in places.