.jpg?w=1024)
An AI assistant at work may look like a direct connection to GPT, but another company could be handling the requests behind the screen. Employees see the answers, rarely the service providing access to the model.
Starting Nov. 20, OpenAI will require AI model routers and gateways that give third parties direct access to its models to obtain prior approval. The change introduces new oversight for services connecting businesses to AI technology through an intermediary.
For businesses using these intermediaries, the change raises two questions: whether their provider is authorized to offer OpenAI models, and how securely it handles company data and credentials.
OpenAI wants consistent safeguards across model providers
In its Oct. 21 announcement, OpenAI outlined how safety protections should apply when customers access its models directly or through hosting partners and resellers. Participating services are expected to maintain comparable standards so users cannot simply switch providers to evade restrictions.
The approach includes several measures at different stages of model access:
- Before deployment. Models undergo risk assessments and testing against attempts to bypass safeguards. Trusted-access programs also establish eligibility conditions for some advanced capabilities.
- During use. Monitoring identifies potential misuse, with partners expected to investigate suspicious activity and take action when violations occur.
- After enforcement. Restrictions can be reconsidered when customers address the underlying problems. SafetyIDs, currently under development, could also help distinguish individual end users during investigations without revealing their identities to the model developer.
Privacy is another consideration. OpenAI cited Private Safety Processing as a way to detect potential misuse across related interactions without exposing the underlying customer content to OpenAI personnel. A Sept. 22 update said access was rolling out to API customers in phases.
Approval rules distinguish gateways from ordinary AI apps
The revised Usage Policies apply to platforms that give third parties direct access to OpenAI models. AI gateways can relay requests through a common connection, allowing businesses to work with different AI systems without managing every model integration separately. Services offering that intermediary access must obtain prior approval.
Applications that incorporate GPT into their own products are treated differently. A customer-support assistant or document-generation tool, for example, does not need approval solely for using the technology. Existing contractual permissions remain applicable, and previous policies stay in effect until Nov. 20.
The announcement does not include an approved-gateway list or explain how existing intermediaries should apply for review before Nov. 20.
What eWeek found: Gateway attacks expose risks approval may not prevent
To examine how OpenAI's planned oversight could help when an AI intermediary is compromised, eWeek investigated a recent real-world example involving LiteLLM, reviewing its March security disclosure, subsequent security improvements, and Oct. 21 incident report. The investigation found a recurring security exposure involving the software customers trust to connect them to AI models.
Incident detail | Mar. 24 compromise | Oct. 21 compromise |
| Attack path | Suspected compromise involving the Trivy security scanner | Stolen developer GitHub tokens used to manipulate release workflows |
| Affected Python packages | Versions 1.82.7 and 1.82.8 | Version 1.107.0 |
| Official Docker images | Not affected | Compromised, including latest and main-stable tags |
| Release protections | Before the redesigned security pipeline | After isolated checks, trusted publishing, and image signing were introduced |
Malware distributed during the October incident could steal credentials and enable remote code execution. Particularly concerning, LiteLLM's legitimate GitHub source tag contained no malicious files because attackers built the infected releases from a separate repository they controlled. Affected customers were instructed to treat accessible secrets as compromised, although the project's private enterprise release was unaffected.
OpenAI's plan could help if stolen provider credentials were subsequently used for suspicious model requests. Coordination with approved intermediaries could support investigations and enforcement across participating services, while SafetyIDs could help distinguish legitimate users when those identifiers accompany requests. Neither measure, however, would independently verify the integrity of downloaded gateway software. The distinction also matters in OpenAI’s disclosures of AI behavior that crossed intended boundaries: information that helps investigate a problem does not itself prevent that problem.
LiteLLM's incidents have no established connection to the approval decision, but they show why authorization alone cannot guarantee gateway security.
Before Nov. 20, businesses should ask their gateway providers whether the approval requirement applies to their service, what authorization they hold, and whether the review could affect continued access to OpenAI models. The announcement leaves those provider-specific questions unanswered.
Security teams should also establish which credentials their gateways can reach, who can authorize software releases, and how they would revoke access and restore a trusted deployment after a compromise. Findings from cloud and identity security assessments reinforce why excessive permissions and exposed credentials deserve scrutiny alongside the initial intrusion.
For procurement teams, the practical consequence is a broader vendor review: choosing an AI model also means assessing the intermediary delivering it. Provider authorization, software-release controls, and incident response should each have evidence behind them.
More news: Nvidia is bringing AI-powered monitoring to GPU clusters, with Minerva designed to catch infrastructure problems before they interrupt workloads.