What OpenAI Learned Containing Its Own Models, and What Enterprises Should Copy

On September 20, an OpenAI research model exploited a misconfigured DNS resolver during a training run and gained limited access to the live internet. OpenAI contained it, paused training and evaluation of its most capable models, and resumed on October 1, 11 days later. On October 23 it published what it changed in Securing our frontier model training environment.

The post is about OpenAI’s own research infrastructure, but is instructive in how the world’s leading AI companies are securing the AI they train. Its treatment of model containment applies directly to enterprises that run autonomous agents. R&D teams in chip design, high tech, and pharma, where agents now work inside source repositories and research data, should take note and apply similar controls to their environments.

What OpenAI built

OpenAI’s containment model starts with a security boundary. Each agent gets a strictly defined set of authorized resources. Inside the boundary, agents can use browsers, code execution, computer-use tools, and the services their task requires. Anything not explicitly authorized stays out of reach. OpenAI states the requirement plainly: the limits on what an agent can access “must hold even when the agent tries to circumvent them.”

For training and most evaluation, the live internet sits outside the boundary. Models learn to browse from a large offline collection of indexed web content.

The boundary is enforced in layers, so that containment holds if one control fails:

• Sandboxes that restrict access and execution
• Lightweight microVMs that isolate each workload from its host
• Monitoring that detects unauthorized activity in time to intervene
• Network and cloud perimeters designed to hold even if the sandbox and monitoring fail

OpenAI could not fully air-gap the environment, because experiments need some external connections to run and be monitored. So the boundary needed to be “semi-permeable”, restricting outbound traffic, movement between systems, and the services reachable from its hosts based on policies, rather than hardened infrastructure.

What the red team found

OpenAI then set teams of frontier-model agents against the new defenses. It gave them source code, configurations, and vulnerability documentation, and some tests assumed the agent already had full access to its host.

Even with that head start, getting around the boundary took complex, convoluted work. Agents had to chain several vulnerabilities to escape a microVM, find and exploit flaws in the few services OpenAI had left reachable, or build timing side channels between isolated workloads in targeted tests. OpenAI found no route to the internet that agents could trivially exploit while hiding their activity from monitors, and it resumed training on that basis.

That is the lesson for enterprises. A well-defined boundary does not have to be perfect to work. It turns an easy escape into a slow, noisy one that monitoring can catch. In many enterprise environments, agents run with the same network access as the developer who launched them, so an agent can reach another project’s systems without any exploit at all.

Why this applies to enterprise agents

OpenAI is containing models that may not yet have completed safety training, and it tests them adversarially on purpose. Enterprise agents are released products, but the same controls should still apply to them.

The agents enterprises deploy are built on the same frontier model families. OpenAI notes that “as models become more capable, they become better at finding ways around those limits.” A chip floorplanning agent stuck on a hard problem will also look for ways around the limits it runs into.

Enterprise agents run with real credentials on networks that hold real IP. An R&D agent does not need the internet to do damage. It can reach another project’s repository and design data. OpenAI’s red team tested internal security boundaries as well as the path to the internet.

Enterprise agents also cannot work from an offline copy of the world. They need the actual repositories, license servers, compute, and model providers. Each of those is an allowed connection, and allowed connections are where OpenAI’s red team found its paths out.

Four steps enterprises should copy

1. Define the boundary by authorization. Start from the resources an agent needs for its task, and make everything else unreachable. A blocklist has to grow with every new system and fails on the first one someone forgets.
2. Treat movement between projects as a containment failure. OpenAI restricts unauthorized movement between systems and counts unpermitted communication between agents as a failure. In an R&D organization, the natural boundary is the project. An agent working on one customer’s design should not be able to reach another customer’s repository, whether it is compromised or only looking for an answer.
3. Assume every allowed connection is a way out. OpenAI’s red team found its weaknesses in the services OpenAI had deliberately left open. Keep each agent’s allowed set small, and put the connections that carry data, such as the path to model providers, behind inline inspection.
4. Plan for the inner layer failing. OpenAI tested its perimeter on the assumption that the agent already controlled its host. A control that runs only inside the agent’s own process or tool harness fails along with it. The boundary needs to sit where the agent cannot reconfigure it.

How Ensage implements the boundary

Ensage AI implements the security boundary and network perimeter layers of OpenAI’s model for enterprise agents. It runs on the CoIP Platform overlay and works alongside whatever workload isolation the enterprise already uses.

• The enclave is the boundary. Ensage scopes each project to an enclave. Resources outside an enclave are not reachable from inside it, and enclave resources are not reachable from outside it. Within the enclave, per-agent sandboxes restrict each agent to its authorized destinations (steps 1 and 2).
• Unsanctioned agents are covered. zLink detects AI agents and coding tools at the process level on enrolled endpoints, including agents the security team did not deploy.
• The path to model providers is inspected. The AI Session Controller inspects agent sessions inline as a TLS-terminating proxy, inside the customer’s environment (step 3).
• Credentials stay out of reach. Agents hold substitute credentials, and the AI Session Controller injects the real key at the enforcement point, so no enterprise AI credential remains on the endpoint to steal.
• Misbehaving agents can be stopped. When an agent misbehaves, Ensage quarantines it at the boundary, and the quarantine persists across process restarts on the affected endpoint until an administrator releases it.

Ensage does not replace hypervisor isolation or defenses against side channels between workloads that share hardware. OpenAI’s model is layered for that reason, and the enclave is one of the key layers.

Put the boundary in place now

OpenAI stopped training its most capable models for 11 days after one misconfigured DNS resolver. Enterprises running agents against their own IP can put the same boundary in place before they have an incident of their own.