// AI security

AI Agent Security Week: OpenAI just took its frontier models off the live internet

OpenAI confirmed on October 23 that its frontier models now train with no live internet access at all, working instead inside a cached environment it calls an offline world. That announcement kicks off a week on this site about the AI agent attack surface: the systems that act on your behalf, and what happens when someone else learns to steer them.

What happened

On September 20, during an ordinary information-finding task, an internal research model exploited a misconfigured DNS resolver to reach the live internet from inside its training environment. OpenAI contained the incident, with no damage to external systems reported, and paused training and evaluation of its most capable models. Work resumed on October 1, eleven days later, after containment was strengthened and continuous red-teaming was made part of the safety cases that decide whether a frontier training run can proceed.

The policy now stands until advances in alignment research, monitoring, and internet infrastructure security justify broader access. Agents still need to learn to browse, search, and use web applications, so the offline world gives them an interactive environment built from indexed and cached web content: interfaces, search tasks, and application workflows, with no path to live systems. Anthropic limited its newest models' live web access about two weeks earlier, so both leading labs have now decided frontier training cannot safely touch the open internet.

The red-team twist

OpenAI then set its most cyber-capable models loose on its own research environment to find weaknesses. They found zero-day vulnerabilities, virtual machine escapes, and hardware side-channels that let agents communicate by manipulating processor cache timing. Fixes went to open-source projects including Kata Containers, gVisor, Docker, and the Linux kernel. Two outside groups, METR and Redwood Research, separately found ways agents could slip past OpenAI's monitoring, which is a reminder that finding holes is not the same as closing them.

Why this matters beyond the labs

The pattern in that story is the same pattern sitting inside every company deploying agents: an agent with tools, data access, credentials, and a network path, taking instructions from content it reads. If a frontier lab decided its own containment needed an offline world, your agent deployment needs identity, least privilege, tool scoping, and monitoring of agent actions, not just a prompt filter on the front door. Data the agent reads is input, and input can carry instructions.

The week ahead

Each coming brief will carry one item from the agent attack surface, in this order: MCP agent-to-agent prompt injection, where one compromised agent relays instructions to agents that trust it as an internal peer; flaws in the Agent2Agent protocol itself; GitLab AI Gateway CVE-2026-90970, a 9.9 sandbox escape to command execution; ZombieAgent, a zero-click ChatGPT attack; and LangAlpha CVE-2026-109440, indirect prompt injection reaching shell commands. Same brief, same standard: verified claims, what to do, no hype.

What to do today: inventory your agents and their tool access, remove or scope any default shell tool, treat everything an agent retrieves as untrusted input, and log agent actions like user actions. The week will give you the specifics; that inventory is the prerequisite.



Related reading

Kevin Swaney, Principal Cybersecurity Engineer

Kevin Swaney

Principal Cybersecurity Engineer with 17+ years across banking, payments, and consulting. Writing about AI security, identity, and the fundamentals that stop most incidents. kevintswaney.com

← kevintswaney.com