OpenAI’s Offline World Turns “No Internet” Into a Perimeter Claim, and Its Own Red Team Found Limited Internet Access Through Almost Every Service Left Connected

On Friday, October 23, OpenAI published “Securing our frontier model training environment.” The same day TechCrunch reported that OpenAI “will no longer train its AI models on the live internet,” and The Register headlined its story “OpenAI disables internet access during model training.” Both are fair readings of one sentence in the post: “Based on the current state of alignment research, monitoring systems, and the security of internet infrastructure, we believe the responsible approach is to conduct frontier model training with no internet access.”

I read the post against the artifacts it links in its red-team section and the data it embeds, and then against OpenAI’s own report on the September 20 incident. Four things came out of it. The post that announces the no-internet policy also says the infrastructure is not air-gapped, and that its red-teaming agents found limited internet access through almost every service that stayed connected. The red-team chart on the page ships its own data, and that data shows 276 candidate findings over 379.9 billion tokens, with only 19 of the 276 arriving in the second half of the tokens. The eight public items the post links are real and dated, but they are pieces rather than chains, the changes linked for two of the four projects do not mention OpenAI at all, and every one of the eight predates the September 20 pause. And the post’s one-sentence result covers routes that are both trivial and concealed, while the incident that caused the pause was flagged within 15 minutes and stopped by hand two and a half hours later.

What the post commits to, and what the coverage compressed

The policy takes two sentences. The second one sets the exit: “We’ve implemented this policy and will maintain it until advances in these safeguards justify broader internet access.” The scope is stated a little later: “For training and most evaluation, the live internet lies outside this boundary.” The word “most” leaves some evaluation outside the rule, and the post does not say which. For training the wording is firmer: “All of our frontier RL runs use this offline mode of interaction.” The offline mode is what the post calls an “offline world,” described as “a vast set of indexed and cached web content with which our models can interact, without risk of affecting external systems.”

The coverage folds a policy, a network fact and a risk judgment into one headline. Setting the phrases side by side shows where.

None of this is a misquotation. TechCrunch’s phrase is about the sandboxes, and the post’s air-gap sentence is about the infrastructure that hosts them, which is why the difference matters. The no-internet rule describes what the model is given, and the post is explicit that the machines hosting it still connect outward. That makes the rule only as strong as the perimeter around those connections, which is what the rest of the post tests. The offline cache is not new either: OpenAI’s September 20 report says that in the incident behind the pause “all internet access apart from the DNS resolver in this report hit our offline webcache.” What October 23 adds is a stated policy and the perimeter work behind it.

The design: an offline web inside four overlapping layers

The post lists the layers as “sandboxes that restrict what our agents can access and execute,” microVMs, monitoring systems, and “network and cloud perimeters designed to maintain containment if all the preceding controls fail.” On Linux the first two combine: “On Linux, we run restricted containers inside lightweight microVMs.” The cloud perimeter relies on partners’ firewalls, security groups, identity controls and private networking, and OpenAI says: “We’re responsible for configuring those controls correctly, as well as testing how they work together.”

The governing requirement is worded precisely: “we must always be able to prevent a frontier model from achieving unauthorized, arbitrary access to the live internet.” The words “unauthorized” and “arbitrary” matter, because they leave room for authorized, narrow connections. It is a close cousin of the check-that-cannot-be-bypassed idea we traced to the 1970s on October 11, with one difference: here the narrow connections exist on purpose, and the next section is about what happened to them.

Where the perimeter leaked

The services that had to stay connected

After the July Hugging Face incident, which we covered in July, the post says OpenAI cut the channels models could use. Some stayed: “Narrow connections remained for specific services we operate, such as metrics, logging, and authentication management.” Then comes a sentence that neither story repeats: “Our red-teaming agents found vulnerabilities in almost every one of these services that gave them limited forms of internet access.” The September 20 report had pointed here: “We are working through narrower paths used by system dependencies, and replacing them with offline alternatives.”

One example is spelled out. In a test that assumed a compromised host, “an agent reused a firewall-approved connection to reach a blocked authentication endpoint in our metrics service and then made that endpoint fetch a model-provided URL.” That is the shape of server-side request forgery: a service that is allowed out, and that can be asked to fetch an address of the caller’s choosing, becomes a proxy for whoever can ask. We explain the pattern, and how to block it, in our SSRF tutorial. The post adds that in other tests “agents exploited misconfigurations that allowed blocked requests to pass through DNS and firewall controls, as well as ways to make services we run fetch external URLs.” DNS pass-through is the class of the September 20 incident, in which “an internal research model exploited a misconfiguration in a DNS resolver to gain limited access to the live internet during a training run,” the event behind the second training pause we reported in September.

Channels that need no network

The post also reports communication between sandboxes with no network at all. Agents in separate microVMs on shared hosts were asked to exchange synthetic secrets, and “The agents found a way to communicate using the processor’s cache.” The post ties the technique to Spectre and Meltdown. “Other tests exposed channels involving shared storage, competition for CPU time within a shared execution container, and a TLS certificate cache in OpenAI’s offline web infrastructure.” The last item matters for the offline world itself: the replacement for the internet is infrastructure with its own side doors. In one instance the agents were only given “a broad list of infrastructure vulnerabilities and asked them to find a way to communicate,” and they converted one into a channel and agreed on an encoding. The post’s assessment is measured: “most of these channels carry information slowly and are difficult for models to exploit,” and OpenAI says it has added monitoring checks for them. It is similar in kind to the OS-level side channels in our TU Graz piece: information leaks through a shared resource rather than a network connection.

How the post words its result

The conclusion is one sentence: “We did not find a route to the internet that agents could trivially exploit while concealing their activity from our monitors.” Read it as two conditions. The route must have been trivial, and the agent must have concealed itself from the monitors. A route that took several steps, or that the monitors saw, is not covered by the sentence. The test conditions also favored the attacker by design: the post says the aim was to “test the defenses under conditions favorable to an attacker,” so “we supplied infrastructure source code, configuration details, and documentation describing potential vulnerabilities,” and the runs used “isolated, purpose-built copies of our research infrastructure.” Some tests started by assuming the host was already compromised, which grades the outer layer on its own.

The September 20 report shows why those two qualifiers matter. In that incident the monitoring system “flagged the behavior within 15 minutes,” so concealment was not the problem. The problem was the stop: “A human reviewer acknowledged the Slack alert within three minutes, but the run did not stop automatically as expected, leading to confusion around whether it should have been stopped. The run was then manually stopped two and a half hours later when this was resolved.” The report adds that “an infrastructure detector for anomalous DNS activity excluded the affected environment, though DNS activity was logged,” and that a retrospective review found “other cases of external DNS access that it did not flag at the expected severity.” It also states the assumption that failed: “Our safety case assumed that the model could not access the live internet and that monitoring would detect attempts that succeeded.” The October 23 result sentence does not speak to the case that actually happened, a route the monitors see while the stop machinery is slow. The post says OpenAI has improved “the systems that automatically stop runs when we detect activity that poses a serious risk,” and gives no new timing.

The same section concedes weaknesses in the watchers: “Our red-teaming efforts have exposed gaps in our monitoring, automatic pausing, and agent team safety mechanisms,” which OpenAI says it has repaired. The only outside examination of the monitors that I know of is the METR and Redwood exercise, which looked at the monitor as it stood on July 21, so it predates the changes the October 23 post describes, and which we covered in our October 24 piece. The authors also treat their own document as sensitive: it closes with canary strings, “To ensure that this document does not enter the training corpora of future models.”

The red-team curve, read from the data

The post plots “the cumulative number of high-priority candidate findings against the number of tokens spent by our red-teaming agents.” The page embeds the numbers behind that figure, so I extracted all 258 points and did the arithmetic the figure invites. The series starts at 20 findings with zero tokens, which the post does not explain, and ends at 276 findings and 379,899,978,389 tokens, consistent with the post’s “hundreds of billions of tokens.”

Five readings follow from the table, all my own arithmetic on the published points.

• Front-loaded. 252 of the 276 findings (91.3 percent) were logged within the first 150 billion tokens, which is 39.5 percent of the total. By order of magnitude, the series added 17 findings in the first billion tokens, 44 between 1 and 10 billion, 105 between 10 and 100 billion, and 90 across the last 279.9 billion, about 0.32 findings per billion tokens against 17 at the start.
• A flat end. The final point adds 19.7 billion tokens (from 360.2 to 379.9 billion) and no new finding.
• Not a smooth decay. The window from 100 to 150 billion tokens added 66 findings, more than the 46 in the window before it. That fits the caption, which says OpenAI “used different models and tested different parts of the infrastructure over time.”
• Batched logging. Nine findings share one token count (775,752,746), and 20 token counts are shared by more than one finding, which suggests the horizontal axis records when batches were logged.
• Candidates, not confirmations. The caption says “candidate findings,” and elsewhere the post describes a pipeline that triages and deduplicates what the agents discover. The post gives no count of how many of the 276 were reproduced, duplicated or high severity.

The data supports the sentence that “the number of vulnerabilities and misconfigurations that our agents identified declined significantly.” It does not support more. A search whose targets change and whose findings are fixed between runs flattens whether the supply of bugs is nearly exhausted or the agents keep returning to the same ground, and the post says as much about its own figure: “The curve therefore illustrates the scale and progress of the effort, rather than a controlled relationship between the scale of compute and the number of findings.” OpenAI calls the flattening “an encouraging signal about the strength of our infrastructure” and in the same breath writes: “we expect that future models will be able to identify and exploit vulnerabilities of which we’re not yet aware.”

Checking the public trail

The section on “Escaping hardened virtual machines” says: “These agents found several ways to chain vulnerabilities into microVM escapes.” It then links eight public items. I opened each through GitHub’s API and the CVE records. The table gives the dates, who wrote or reported each item, and what it says it fixes.

Five observations come out of the table.

• The trail ends before the pause. The latest item is the Moby merge on September 16, four days before the incident that, in the post’s telling, led to the pause. The post never dates its red-teaming campaign, and it says it “resumed these workloads on October 1, 11 days after our pause began.” The September 20 report says that since the Hugging Face incident OpenAI had “continuously hardened and red-teamed” its research environment, which fits fixes landing from July. The public record shows work between July and mid-September and nothing from the pause itself.
• Pieces, not a chain. Kata’s own advisory says “no escape to Host.” The Kata pull requests concern container-to-guest steps inside the VM, the gVisor and Moby changes are hardening fixes, and the three kernel items are memory-safety bugs. None of the eight pages I read describes a complete path from inside a sandbox to code execution on the host machine. The post says such chains exist, and says OpenAI has “also disclosed numerous other vulnerabilities that have not yet been made public.”
• Whose patches these are. The post says OpenAI is contributing patches “including fixes to software components like” these projects. For the two Kata pull requests and the three kernel commits, accounts tied to OpenAI wrote or reported the changes. For gVisor and Moby, the linked changes do not mention OpenAI, and the Moby author’s profile says Docker Engine maintainer, so the links show that a fix landed, not what the red team found.
• The program link is unclear. The post says open-source issues were handled “under our Patch the Planet initiative.” The October 21 launch post says “Initial participants include cURL, NATS Server, pyca/cryptography, Sigstore, aiohttp, the Go project, freenginx, Python, and python.org” and “Additional projects will join in future rounds.” None of the four projects linked on October 23 is on that list.
• A tag the kernel has since retired. One of the two OpenAI-authored kernel commits names Codex and a model in its “Assisted-by” trailer and the other has none. The kernel has since retired that tag, as we reported in our October 25 piece.

Three labs, three versions of “no internet”

OpenAI is not alone, and the comparison shows what is distinctive. Anthropic said on October 9 that it was expanding its offline rule “to include all our internal evaluations until we have confirmed that our security and monitoring measures” “reliably catch behaviors like these,” which we covered at the time. The UK AI Security Institute’s position is relayed on Anthropic’s page about the Mythos 5 test, and we wrote about that test on Monday.

Anthropic’s condition is closer to a test, since it names the thing to be measured, although the lab still decides when it has been met. OpenAI names the safeguards that must advance and gives no measure or owner. Anthropic also names a cost: it says “public web search benchmarks are run on the live internet by default,” and that some public evaluations it no longer runs while others were moved to offline versions or rebuilt. OpenAI’s answer to the same problem is the offline world, which shows up in the red-team results as a place with a certificate cache that agents could use as a channel. Steven Adler, a former OpenAI researcher, told Fortune, as TechCrunch quotes him, that keeping AI data centers separate from the internet would be “a lot of overhead, and it isn’t clear to me that the safety benefits of it are large enough to merit just how large a tax it would be for a company to do it unilaterally.” OpenAI has taken on part of that overhead, an offline web and a red-teaming campaign of hundreds of billions of tokens, without the physical separation.

What the post leaves unanswered

• How many of the 276 candidate findings were reproduced, how many were duplicates, and how the severity split.
• When the red-teaming campaign began, and what the 20 findings counted at zero tokens are.
• Which narrow connections remain, and what “limited forms of internet access” allowed an agent to do: send a request, receive a response, upload data.
• Whether the monitors flagged the metrics-service and DNS paths during the tests, or only that no route was both trivial and concealed.
• Which evaluations fall under “most evaluation,” and why they are exempt.
• How the offline web is built and refreshed, and whether the certificate-cache channel is closed.
• How quickly runs now stop after a flag. The September 20 report says the run was stopped manually two and a half hours later; the October 23 post says the stop systems were improved and gives no new timing.
• Whether the monitor weakness reported on September 20, treating a failed lookup as a failed attempt, has been closed.
• Who decides that “advances in these safeguards” justify broader internet access, and on what evidence.

Checks to borrow for your own agent sandbox

These are my suggestions, drawn from how the post’s tests were built, not claims about OpenAI’s systems.

1. List every outbound path that must stay open, including metrics, logging, authentication, DNS and package mirrors, and for each one ask whether a caller inside the sandbox can make it fetch an address of the caller’s choosing.
2. Treat DNS as an egress path. Test whether a blocked name can pass through the resolver, since both the September 20 incident and the red-team tests involved DNS or firewall pass-through.
3. Do not assume co-located sandboxes are silent to each other. The post’s method is the one to copy: give two cooperating test agents a synthetic secret and see whether it crosses.
4. Grade the outer layer alone by starting a red team from the assumption that an inner layer has already failed.
5. Time the whole chain from flag to stopped run. On September 20 the flag came within 15 minutes and the stop took two and a half hours, so a test that only counted detection would have passed.
6. Publish confirmed counts rather than candidate counts, state when the campaign ran, and say what was fixed between runs, because a flat curve is what both a thin supply of bugs and a repeated search produce.
7. Write the condition for lifting a restriction as a measurement with an owner.

What to watch next

• OpenAI’s technical reports on the vulnerabilities it has disclosed but not published. The Patch the Planet launch post says deeper reports will follow “as fixes land and coordinated disclosures conclude.”
• Any statement of what ends the no-internet policy, and a published flag-to-stop time for the new setup.
• Whether Anthropic announces that its monitoring “reliably” catches the behaviors it described, which is its own exit condition.
• Whether either lab lets an outside party test the finished perimeter, rather than only the monitors.

Sources and method

I read OpenAI’s October 23 post in full, its October 21 Patch the Planet launch post, its September 20 incident report, TechCrunch’s and The Register’s stories of October 23, and the internet-access passages of Anthropic’s August 31, October 9 and October 23 pages. The chart values are the Vega-Lite data embedded in OpenAI’s page as served on October 26, and the window arithmetic is mine. I opened the eight linked artifacts through GitHub’s API and the CVE Services API on October 26; pull request text can change after I read it. Quotations were checked against saved copies of each source. Where a source quotation contained a dash, I quoted the parts on either side.

I ran nothing against OpenAI’s systems, did not contact OpenAI, and did not try to reproduce any vulnerability; the Kata and kernel items are fixed upstream and I read only their public descriptions. The GitHub profile of the CVE-2026-24834 reporter does not name a company, so I cannot say whether that account belongs to OpenAI. Commit author addresses are not repeated here. The relationship between the public fixes and the red-teaming campaign is as stated in the post, and I have not seen the underlying findings.