OpenAI has hardened the environment in which it trains its frontier models. It restricted internet access during reinforcement learning, reinforced isolation between computing environments, and then deployed fleets of advanced AI agents to find out whether those protections could survive a deliberate attack.
They could not, entirely. The tests exposed weaknesses that conventional security controls had not fully addressed.
In its October 23, 2026 disclosure, OpenAI described how its red-teaming agents uncovered previously unknown software vulnerabilities and infrastructure misconfigurations. Among them: ways to escape virtual machine boundaries, to exploit services with limited external connectivity, and to communicate between supposedly isolated environments through shared computing resources.
OpenAI patched the vulnerabilities, tightened network restrictions, and strengthened monitoring and automated stopping mechanisms. It also worked with cloud providers and open-source maintainers to close gaps across its wider infrastructure. It had paused training and evaluation of its most capable models while it did so, and resumed reinforcement learning training and internal inference on October 1, following further work and security assessments.
One decision stands out. OpenAI built an offline environment of indexed and cached web content, so models can practise browsing, search and web-based tasks without touching live websites. Its frontier reinforcement learning runs now use this mode. The aim is to preserve useful capabilities while reducing the chance that a model could affect systems beyond its authorised environment.
Underlying all of this is a single requirement: restrictions on an AI agent must hold even when the agent actively tries to circumvent them.
That principle reaches well beyond frontier research. It points to a discipline that enterprise technology leaders will increasingly need to understand: model containment.
Why containment is a discipline of its own
Enterprise security has long centred on protecting networks, controlling identities, patching vulnerabilities and isolating workloads. Those controls remain essential. But capable AI agents introduce a different problem.
An agent need not wait for an attacker to exploit a weakness on its behalf. It can inspect its environment, execute code, test alternative approaches and combine small weaknesses in pursuit of a goal. When it meets a restriction, it may systematically explore other routes. If the model is misaligned, compromised or chasing an unintended objective, that ability to reason and act can turn ordinary software flaws into a much larger security problem.
So containment has to go beyond conventional access control. The question is no longer only whether an agent has permission to perform a task. Security teams must also ask whether it can escape its execution environment, acquire additional privileges, reach unauthorised systems, or communicate through channels administrators never approved.
Model containment brings together infrastructure isolation, network security, identity controls, monitoring and automated intervention to limit the consequences of such behaviour. It does not assume every model will try to break out. It treats the possibility as a scenario that must be tested.
OpenAI’s experience offers four concrete illustrations.
1. When the sandbox fails, the rest of the infrastructure must hold
A sandbox restricts what an application can access or execute. Virtual machines add a further layer by separating the execution environment from the host.
OpenAI’s red-teaming agents found ways to chain software vulnerabilities into virtual machine escapes, and the company reported fixes involving components such as Kata Containers, gVisor and Moby/Docker. The lesson is a familiar one: architectures that lean on a single boundary hand an intruder capabilities nobody intended to grant once that boundary falls.
Imagine an enterprise agent that analyses source code and runs scripts inside a disposable environment. If it finds a way out, the consequences depend on what comes next. Can it reach the host operating system? Read credentials? Touch another workload? Use the host’s network connection to contact an external server?
A conventional approach concentrates on preventing the initial escape. A containment-oriented approach assumes the escape may happen and asks whether independent controls would still stop further access. OpenAI layers restricted containers, virtual machines, hypervisor isolation, network restrictions, cloud security controls and monitoring for precisely this reason.
For enterprise architects, the takeaway is plain: a sandbox escape should be treated as a serious security event, but it should not automatically become a full infrastructure compromise.
2. A permitted connection can become an unintended gateway
OpenAI also tested what would happen if an agent took control of a host machine and tried to reach the live internet.
External connectivity was restricted, but some connections remained necessary for services such as metrics, logging and authentication management. The red-teaming agents found weaknesses in several of these services that created limited routes out. In one case, an agent reused a firewall-approved connection to reach a blocked authentication endpoint in a metrics service, then made that endpoint fetch a URL the model supplied. Other tests exposed misconfigurations involving DNS, firewall controls and services able to fetch external URLs.
The permitted connection was not the problem in isolation. The risk emerged from how it interacted with the service behind it and the privileges available to the agent.
The same pattern could play out at a bank, insurer or manufacturer. An agent authorised to pull information from an internal monitoring platform might be talking to a platform that can itself make requests to other services. If the agent can manipulate those requests or exploit a flaw in the platform, it could use a trusted service to reach resources its own permissions forbid.
Containment therefore demands scrutiny of indirect access paths, not just direct network connections. CIOs and CISOs should ask which services can act on an agent’s behalf, whether those services validate requests properly, and whether a compromised workload could turn an approved connection into an unintended gateway. The same questions apply to identity systems, observability tools, document-processing services and internal APIs.
3. Two isolated agents may still find a way to talk
Perhaps the most striking finding involved communication between agents that were never meant to exchange information.
In one experiment, agents in separate virtual machines were told to swap synthetic secrets without using network connections or shared writable files. They succeeded by exploiting processor-cache timing. A processor cache holds recently accessed data so it can be retrieved faster than from main memory; one agent altered cache behaviour to send a signal, and the other measured the timing differences to decode it. OpenAI also described possible channels involving shared storage, CPU activity and a TLS certificate cache.
These are covert channels: information can pass through shared resources even when conventional communication is blocked.
Consider an organisation running several agents in separate environments. One handles confidential financial data; another has access to different tools or external resources. Network rules and file permissions prevent direct contact. But if the agents share underlying hardware or services, those resources may offer an unexpected path for information to travel.
This does not make every shared computing environment unsafe. Such channels can be hard to exploit and may carry little bandwidth. But their existence shows that isolation cannot be judged solely by confirming that network traffic and file sharing are blocked. For sensitive workloads, organisations may need stronger separation, limits on shared resources and tests designed to surface side channels, with the level of protection scaled to the sensitivity of the data and the cost of a breach.
4. AI can test security at a scale traditional methods may miss
OpenAI did not stop at patching known weaknesses. It deployed fleets of frontier-model agents to hunt for more, giving them three objectives: reach the live internet, cross internal security boundaries, and communicate across environments that should have been isolated.
It also tested scenarios in which the inner security layers were assumed to have failed. By handing agents control of a host machine, the company could check whether its network and cloud protections would still block unauthorised internet access. The experiments ran on isolated, purpose-built copies of the research infrastructure, with monitoring and automated checks to halt any activity that strayed beyond its authorised scope.
OpenAI reported spending hundreds of billions of tokens on these exercises. The number of high-priority candidate findings fell significantly as testing progressed, though the company cautioned that future models could discover vulnerabilities that remain unknown today.
The approach shows how AI can strengthen security assurance. Vulnerability scanners excel at known classes of weakness. Penetration testers can probe complex attack paths, but their time is finite. AI agents can try many approaches, investigate relationships between services, and repeatedly test whether different weaknesses can be combined.
None of this replaces experienced security professionals. Findings still need to be reproduced, prioritised and verified, and the testing agents themselves must be kept away from production systems. But it opens the door to more continuous testing against increasingly sophisticated attack strategies.
Five priorities for CIOs
Model containment is not a product or a configuration setting. It is an architectural discipline built on the assumption that an AI agent may attempt actions beyond its intended scope. Five priorities stand out.
1. Define an explicit security boundary for every agent. Specify which data, tools, services and systems the agent may access. Resist broad permissions granted simply because they make a workflow easier to build.
2. Design for the failure of individual controls. Combine application sandboxing, virtualisation, identity restrictions, network segmentation and cloud security policies, then test whether one compromised layer exposes the rest.
3. Restrict live internet access. Grant external connectivity only when a task requires it. Where possible, rely on controlled data sources, cached content or approved gateways, and validate indirect routes through internal services.
4. Monitor and intervene. Detect attempts to cross boundaries, probe unauthorised services or exploit unexpected capabilities. Make sure serious alerts can trigger a rapid pause or shutdown, and test that those mechanisms still work under adverse conditions.
5. Make red-teaming continuous. Reassess containment whenever models, tools, permissions, software or infrastructure change. Use controlled, AI-assisted testing to find weaknesses before they can be exploited in production.
These measures belong in enterprise AI governance, cloud security reviews and software development processes, not solely with the teams experimenting with models.
Limiting the consequences of failure
OpenAI’s work signals a broader shift in how organisations must think about AI security. The goal is neither to assume every model will behave maliciously nor to claim any architecture can eliminate every vulnerability. It is to ensure that a model’s capabilities never automatically translate into unrestricted authority.
An agent that can write code should not automatically control the host that runs it. An agent that can reach an internal service should not automatically be able to use it as a gateway to external systems. And two agents meant to operate independently should not be presumed isolated simply because their network connections are blocked.
For CIOs, this is a change in design philosophy: from protecting individual controls to demonstrating that the whole system stays secure when some of them fail. As enterprises move from conversational AI to agents that execute code, manipulate data and run business applications, that distinction will only grow in importance.
The next stage of enterprise AI security will be measured not only by what organisations let their agents do, but by what those agents remain unable to do when they push against the boundaries.