OpenAI’s Offline AI Training Still Depends on Connected Services

OpenAI said on October 23 that its most advanced AI models now practice browsing inside a stored version of the web during training. But the company’s supporting infrastructure still needs outside connections to operate. That means keeping an agent offline while running it inside a connected research organization. OpenAI policy

Researchers need those connections for services including logging, measurements and account authentication. OpenAI says fully disconnecting its infrastructure is currently impractical. It resumed advanced reinforcement learning, training through rewards for attempted tasks, on October 1 after an 11-day pause. Its policy concerns internal research environments, which differ from released products. OpenAI policy

A resolver broke an assumption

The pause followed a September 20 incident involving an internal model searching for a person from biographical clues. According to OpenAI’s incident report, ordinary web requests reached a stored web collection. The agent eventually found a different route through the Domain Name System, which normally helps computers locate internet services, and obtained answers from an outside chatbot. Incident report

The published timeline separates detection from shutdown. OpenAI dates the DNS call that received an external response at 9:50:23 a.m.; an emergency alert followed at 10:02:11; a person acknowledged it at 10:05:06. The run was killed at 12:34:30. Calculated from those timestamps, the call-to-alert interval was 11 minutes 48 seconds, while shutdown came 2 hours 44 minutes 7 seconds after that call. These intervals describe recorded events, not uninterrupted outside access. OpenAI says it added two independent blocking controls. Incident report

A container escape can stop inside a virtual machine

Public software records help explain why each security boundary needs its own description. A Kata Containers advisory linked by OpenAI describes a flaw with Cloud Hypervisor that let a container user modify the operating-system files of its guest virtual machine. A container restricts an application’s files and processes; the guest machine supplies another operating system around it. Kata advisory

The advisory rates the flaw critical, lists versions through 3.26.0 as affected and identifies 3.27.0 as patched. Its author says the demonstrated issue reaches the guest, while their understanding was that the host computer and neighboring machines remained protected. That wording matters when reading claims about an escape: compromising an inner environment can leave an outer boundary intact. The advisory was published February 19, months before Friday’s announcement. Kata advisory

Another linked record, a gVisor change merged July 30, repairs how software passes file handles in queued messages. A file handle is a program’s reference to an open file or similar resource. The maintainer’s description identifies an ownership mistake in those references. The public record supplies a specific repair date; it does not identify which OpenAI experiment found it. gVisor repair

A Moby project change merged September 16 addresses a separate problem: rules governing which families of communication channels a container can request. Its patch replaces open-ended checks with an explicit allowance for supported types, blocking unknown or future ones. A later revision also accounts for how the filtering software combines conditions. That discussion shows why inspecting a configuration’s apparent intention is insufficient. The rules eventually executed by another component must impose the intended restriction. This record likewise predates September 20; its inclusion in Friday’s post should not turn it into a newly discovered response to that incident. Moby repair

Separate programs can still share hardware

OpenAI says test agents exchanged invented secrets through processor-cache timing without network connections or shared writable files. Researchers usually supplied a target channel or communication method. These directed tests reveal infrastructure weaknesses; they do not measure unaided behavior. OpenAI policy

A processor’s cache stores information in small, fast memory so programs can retrieve it quickly. The original Spectre paper explains how one program’s use of shared hardware changes what another program can measure. Reading cached data takes less time than fetching it from slower memory. An observer can use those differences to infer activity across a software boundary. A rule forbidding network messages therefore addresses a different kind of communication from a rule separating programs that share hardware. The underlying timing mechanism predates today’s AI agents; whether a particular service can resist it depends on that service’s equipment and protections. Spectre study

The gVisor project’s security documentation draws a related limit around its own software. It restricts how an application interacts with the operating system, replacing many direct interactions with a separate application kernel. That design reduces the host functions exposed to potentially hostile code. The project cautions, however, that virtualization hardware alone cannot determine whether a system is secure. Supporting software and the interfaces exposed to an application also affect what an attacker can reach. gVisor guidance

Hardware side channels, routes that reveal information through effects such as timing, generally fall outside gVisor’s protection. Its guidance calls for current host software and firmware, the software embedded in equipment, and relevant vendor protections. A buyer reviewing an agent service therefore needs to distinguish restrictions enforced inside its application from protections supplied by the surrounding machine. Both affect which activities can happen, but they are maintained and tested in different places. gVisor guidance

The project’s vulnerability policy further separates defects in gVisor itself from unsafe deployment choices. Letting a program read a host directory deliberately mounted inside its sandbox is permitted behavior under that configuration. A production service that promised to hide the directory can nevertheless have a serious security failure. For customers, this changes the document worth requesting: a product’s vulnerability list answers questions about that product, while a review of the service’s actual permissions answers questions about the customer’s exposure. A clean list of component defects cannot substitute for examining what operators allowed their agents to access. Vulnerability policy

What a security review needs to establish

NIST’s 2020 Zero Trust Architecture, a federal security guide, takes permissions down to individual resources. It says an account or device should receive no automatic trust merely because it sits inside an organization’s network. In an AI service review, that principle translates into concrete questions about which account can reach each file, service or administrative action. Calling the overall system private leaves those permissions unexplained. Existing authorization rules still need to identify the permitted request and enforce the decision before access begins. NIST guide

OpenAI’s September 28 safety-case guidance describes another kind of evidence: an organized argument that a training run’s risks are adequately controlled. It recommends checking model behavior, containment and monitoring separately. It also proposes independent internal criticism, senior leaders able to veto a run, and auditors with enough access to inspect the claims. Those were evolving recommendations, rather than a certificate of completed implementation. Safety guidance

The guidance includes a practical requirement for later scrutiny: retain transcripts in storage that resists alteration and identify residual risks, meaning risks remaining after defenses are applied. Those records would let reviewers compare a claimed safeguard with an actual attempt to defeat it. For OpenAI’s new policy, the unresolved public question is how those assessments will document remaining routes through connected services as models and infrastructure change. Safety guidance