Taken together, the stories show that the layer builders added for resilience now depends on a vendor's permission, while the layer around it is becoming portable.
Summary
OpenAI's updated Usage Policies take effect on November 20, 2026. From then on, operators of model routers, AI gateways and other services that give third parties direct access to OpenAI models need prior review and approval. Apps that use OpenAI models only to power their own features are not covered. Around the same time, Codex CLI 0.164.0 added enterprise MCP sign-in, Atlassian connected ChatGPT and Codex to its platform through MCP, and Anthropic donated the Agent Skills standard to the Agentic AI Foundation (AAIF), a Linux Foundation project that OpenAI co-founded.
What happened
The new clause covers 'a model router, AI gateway, or another service that provides direct model access to third parties'. It separates these services from an application that uses OpenAI models to power its own product features. The same update also changes the wording on using outputs to train substitute models, protections for minors, high-stakes uses, and approval for national-security and law-enforcement uses. The published material does not give approval criteria, a review timeline, enforcement mechanics, a list of affected or approved operators, or commercial terms for gateway operators. The current policy stays in force until the effective date.
The related stories are about the tooling around models, not access to them. Codex CLI 0.164.0 adds reusable /presets, inline /model and /permissions arguments, and authentication for enterprise MCP connections, including OAuth clients that require secrets. Atlassian says it is adding OpenAI frontier models to Rovo and lets teams connect ChatGPT and Codex to its permission-aware Teamwork Graph through the Atlassian plugin and MCP. According to Simon Willison's report, Anthropic is donating the Agent Skills specification to AAIF. The specification defines a SKILL.md file with YAML frontmatter, plus optional scripts and assets, loaded in stages. AAIF was co-founded by Anthropic, Block and OpenAI, and Anthropic had earlier donated MCP to the same foundation.
What the archive adds
Our archive shows how normal the intermediary layer has become. Cloudflare's blog announced 'Cloudflare's Auto Router in public beta, available through AI Gateway'. It framed the product around companies wanting to 'manage and oversee token spend', and said 'the best savings are the ones users never notice.' A gateway that chooses the model on the customer's behalf is the kind of service the new clause names. Whether a particular feature counts as 'direct model access to third parties' depends on criteria OpenAI has not published.
OpenAI has given two related reasons elsewhere. In 'Broad access through consistent standards' (d1), it says safeguards should stay consistent across direct, hosted-partner, reseller and intermediary access as model capabilities grow, and that partners must keep their safeguards aligned. In a separate post (d2), it says it detected and disrupted what it calls a coordinated adversarial distillation campaign: scaled, unauthorized use of model outputs or reasoning to train, reproduce or improve another model. The policy text itself does not link the intermediary clause to that campaign. Connecting the two is our inference.
Trend signal
Two layers are moving in opposite directions. Above the model, the connection formats are becoming shared and neutrally governed: MCP for tools and context, Agent Skills for packaged procedures, both now under AAIF. Anthropic made both donations, and OpenAI is a co-founder of the foundation that holds them. Codex's enterprise MCP sign-in and Atlassian's MCP integration show OpenAI's products using these formats. At the level of raw model access, OpenAI is moving the other way. Anyone who passes access on to third parties now has to be a party OpenAI has reviewed.
Our read is that these two moves do not conflict. Shared tooling formats make a model more useful inside other companies' products and cost the model vendor little. Pass-through access is where, by OpenAI's own account (d1, d2), safeguards are hardest to keep consistent and distillation-style use is hardest to attribute. The layer a builder controls and can carry to another vendor is growing. The layer a builder only rents is shrinking.
Why now
Stated by OpenAI: (1) Consistent safeguards across channels. OpenAI says direct, hosted-partner, reseller and intermediary access should all follow the same safeguards as capabilities grow, and that partners must keep their safeguards aligned (d1). (2) Distillation. OpenAI reports detecting and disrupting a coordinated adversarial distillation campaign (d2), and the same policy update tightens wording on using outputs to train substitute models. Stated in the policy itself: (3) Tighter rules for minors, high-stakes uses and national-security approvals, all in the same update. Our inference: (4) All three are harder to enforce when a router sits between OpenAI and the end user and hides who that user is. An approval gate at the intermediary is the cheapest way for OpenAI to get that visibility back. (5) Gateways that choose models for customers, such as Cloudflare's Auto Router in AI Gateway (archive), make the intermediary layer large enough to be worth regulating. The policy does not say this was a reason.
Connections to other events
The platform risk is in where the clause draws its line. Below is our reading of how the wording 'direct model access to third parties' maps onto common architectures. It is an interpretation, not OpenAI guidance.
1) A public router or gateway product (customers send prompts and choose models through you). This is the core case and very likely needs approval. 2) A BYOK gateway (customers bring their own OpenAI key, and you proxy, log, cache or route the calls). This is ambiguous. The customer has their own relationship with OpenAI, but your service still provides the access path. Our guess is that it is in scope until OpenAI says otherwise. 3) A SaaS feature with an open-ended prompt box or a 'raw completion' API endpoint. The closer the feature is to a thin wrapper that passes user prompts through, the more it looks like direct access rather than 'powering its own product features'. A summarizer with a fixed system prompt looks like an app. A generic chat endpoint resold to other developers looks like an intermediary. 4) An internal enterprise gateway. If only employees use it, it plausibly counts as the company's own use. If it also serves contractors, subsidiaries or customer-facing agents, the 'third parties' wording starts to apply.
The non-obvious result is that the cost-routing and fallback layers teams built for resilience can become the parts of the stack that need a vendor's permission. The parts that stay portable are the MCP servers and SKILL.md packages, which now sit under a foundation no single vendor controls. Atlassian's setup shows the pattern that is safe under the current text: models power Atlassian's own features, and outside agents reach Atlassian context through MCP. Neither involves reselling access to the model.
Why it matters
If your product looks like case 1, or plausibly case 2 or 3, treat November 20 as a compliance date. Contact OpenAI through your account channel, ask whether your service falls under the intermediary clause, and keep a written record of the question, the answer and your architecture. If you have no answer by the effective date, that is a business risk you should be able to explain to customers.
Platform teams running internal gateways should list who actually reaches OpenAI models through them. Where the list includes outside parties, decide whether to restrict those paths or raise them with OpenAI.
Buyers who reach OpenAI models through a third-party gateway should ask that vendor in writing two things: whether it has sought review under the new policy, and what happens to their traffic if approval is refused or delayed.
In design terms, keep your ability to switch providers in the layers you own: tools exposed through MCP, procedures written as Agent Skills, and your own evaluation sets. Then changing models means signing a direct contract with another provider, not running a pass-through service that someone else has to approve.
What happens next
- OpenAI publishes written approval criteria or an application page for model-access intermediaries. Rationale for 0.4: operators need guidance before the effective date, but OpenAI often handles partner programs privately, so this is slightly less likely than not. (3 months, 40%). Watch for: An OpenAI help-center or policy page that sets out intermediary review requirements or an application process.
- At least one model router or gateway provider publicly restricts OpenAI model access for some customers and cites the new intermediary policy as the reason. Rationale for 0.3: quiet bulk approval of the large gateways is the more likely path, so a public restriction requires either strict enforcement or a smaller provider being refused. (6 months, 30%). Watch for: A changelog, status page or blog post from a gateway provider naming OpenAI's Usage Policies as the reason for limiting OpenAI models.
- Anthropic or Google adds a clause to its terms that explicitly requires approval or registration for third-party model routers or gateways. Rationale for 0.25: the distillation concern is shared across labs, but rivals may prefer to win over gateway traffic rather than gate it, so copying the clause is far from certain. (12 months, 25%). Watch for: Updated commercial terms or usage policies from either company that name routers, gateways or intermediaries.
Limits and uncertainty
The policy text does not define approval criteria, review timelines, enforcement, or which operators are affected. OpenAI could approve the established gateways quickly and quietly, which would leave the practical impact small. It could also treat BYOK proxies and employee-only gateways as plainly out of scope, in which case our cases 2 and 4 overstate the risk. We do not know how hosted-partner channels relate to this clause. d1 mentions hosted partners and resellers but does not say they need the same approval. The link to distillation is our inference from d2, not something the policy states. Finally, AAIF governance reduces lock-in at the tooling layer only if competing products actually implement MCP and Agent Skills, and the evidence does not show which ones will.
Skill to build now
Build the habit of auditing request paths for vendor policy exposure. First exercise this week: export a day of gateway or proxy logs and group OpenAI-bound requests by who wrote the prompt. The categories are your own fixed product logic, an employee, a contractor or partner, an end customer, or a customer's own API key. Label each group with one of the four cases (public router, BYOK proxy, open-ended SaaS endpoint, internal gateway). Then send one written question to OpenAI about any ambiguous group. If you buy through a gateway, send one written question to that vendor about its approval status. Keep the answers with your architecture docs.
Reader takeaway
Before November 20, draw every path by which a request reaches an OpenAI model in your system. Classify each path using the four cases above: public router, BYOK proxy, open-ended SaaS endpoint, or internal gateway. For any path where someone other than your own product logic writes the prompt, contact OpenAI to clarify its status and document the answer. If you buy access through a gateway, ask the vendor for its approval status in writing.
Open question
Does a BYOK gateway, where the customer already has its own direct OpenAI account and key, 'provide direct model access to third parties'? Or does the customer's own contract with OpenAI take it out of scope? The answer decides whether this rule hits a handful of router startups or a large share of LLM observability and proxy tooling.