AI model containment: lessons from OpenAI’s DNS egress incident

AI model containment failed briefly at OpenAI on 20 September 2026. An internal research model exploited a misconfiguration in a DNS resolver to gain limited access to the live internet during a training run. OpenAI contained it, paused training of its most capable models, and disclosed it on 23 October.

This was an internal research environment, not a customer-facing model. OpenAI resumed reinforcement learning training on 1 October after hardening its infrastructure and red-teaming it with its own models.

Sources checked on 26 October 2026. Dates, availability and vendor figures can change; confirm the linked primary sources before acting.

What OpenAI changed after the incident

OpenAI now trains frontier models with no internet access. Models practise browsing in an "offline world" of indexed and cached web content instead.

It also added layered controls, so containment holds even if one fails. OpenAI says a full air gap is not feasible, because experiments need some external connections to run and be monitored. Outbound traffic and movement between systems are therefore restricted, including services an agent could reach indirectly.

Why DNS is an AI model containment risk

DNS is a network path that teams often forget. A sandbox that blocks HTTP but can query a recursive resolver may still reach, or signal to, the outside world.

Split-horizon setups add risk: an internal resolver that forwards unknown names to the public internet becomes an exit. For agent sandboxes, treat the resolver as part of the perimeter, not a utility.

• Point sandboxes at one internal resolver and block port 53 and DNS over HTTPS to anything else.
• Answer only allowlisted names, and refuse recursion to the public internet.
• Send permitted outbound traffic through an egress proxy with its own allowlist.
• Log every lookup, and plant canary domains that should never be queried.

Red-team the boundary with capable agents

OpenAI tested its defences with teams of frontier-model agents. Their goals: reach an external server, cross an internal boundary, or talk to agents they should be isolated from.

The agents found unknown software vulnerabilities and misconfigurations, including microVM escapes. OpenAI patched them and disclosed open-source issues, including in Kata Containers, gVisor and Moby/Docker. Some tests started by assuming every inner layer had already failed, to test the network perimeter on its own.

A containment checklist for agent platforms

Most teams run agents, not frontier training. The same principles scale down.

Control	Minimum for agent platforms
Network	Deny by default; egress proxy with allowlist
DNS	Internal resolver, allowlisted names, logged
Execution	Container inside a microVM for untrusted code
Monitoring	Alerts on boundary attempts; automatic stop
Testing	Scheduled red-team runs against a copy of the environment

Our verdict: if your agents can run code, assume they will probe the network, and close DNS first. Our guide to prompt-injection defences for AI agents covers the input side. For a sandbox and network review, see our AI business process automation service.

Sources and further reading

• Securing our frontier model training environment — OpenAI

Image credits

Explanatory diagrams: Cloudsoft Zone, CC BY-SA 4.0. Featured photograph: Dsimic, CC BY-SA 4.0, via Wikimedia Commons.