The Word “Isolation” Covers Different Boundaries
sandbox-runtime, or srt, is an npm package that wraps commands and uses operating-system mechanisms to restrict file and network access for those commands and their child processes. It addresses the permissions of tool-using agents when they execute commands. It is not a model, and it does not simply disconnect an entire system from the network. By enforcing what a process may do at runtime, it turns an abstract promise into rules that can be inspected.
Command-level sandboxing and training-environment isolation are not interchangeable. The incident described by OpenAI involved a DNS resolver misconfiguration that allowed limited internet access, which made the outbound path of the infrastructure the relevant boundary. For a command sandbox, teams must inspect what a command can read, write, and connect to. For a training environment, they must also check DNS resolution, routing, and the network configuration around the environment. Calling both “sandboxing” can obscure the specific controls that need review.
Permissions Need Separate Rules for Reads, Writes, and Network Access
srt configures file and network permissions separately, and its rules cover the launched command and all of its child processes. The described defaults allow reads while denying writes and network access. Network requests pass through a host proxy and are filtered against a domain allowlist. This separation is useful in practice: teams can ask independently whether data can be read, files changed, and requests sent outside the machine, rather than treating the label “isolated” as a substitute for reviewing permissions.
Default denial of writes and network access does not automatically address the risk of reads. Since reads are allowed by default, sensitive paths still need to be explicitly denied or a restricted process may reach data that should not be exposed. The opposite problem is an allowlist so narrow that the task stops working. The material specifically advises testing npm install under the allowlist. Acceptance should therefore check not only what the controls block, but also whether expected installation and execution workflows remain usable.
Cross-Platform Support Does Not Mean One Shared Implementation
srt has different deployment paths on different operating systems. On macOS it calls sandbox-exec and Seatbelt; on Linux it uses bubblewrap; the Windows version is still alpha and uses a dedicated account, ACLs, and WFP. The package is version 0.0.81, unpacks to about 11.4 MB, and requires Node.js 22.12 or later. Linux also requires socat and ripgrep, while macOS requires only ripgrep. For deployment teams, these are not incidental details. They help determine whether the runtime environment meets the package’s prerequisites.
Because the platforms rely on different mechanisms, a policy file that works on one system does not establish equivalent behavior elsewhere. Windows being in alpha is especially relevant to readiness decisions. The project as a whole is also described as a beta research preview. Teams adopting it should record the target platform, dependencies, and policy version, then verify that permissions actually take effect in that environment. Cross-platform support should not be mistaken for a guarantee of cross-platform security.
The DNS Misconfiguration Exposed the Risk at Runtime
The timeline disclosed by OpenAI shows why a sound boundary design does not guarantee error-free runtime configuration. On September 20, a DNS resolver misconfiguration gave a training environment limited internet access, and training and evaluation of the most capable models were temporarily paused. By October 1, frontier reinforcement learning and internal reasoning had resumed. The change makes clear that network access is not a static statement in documentation. It depends on runtime resolution and configuration, and even limited unintended access can trigger a pause and investigation.
After the work resumed, frontier RL runs did not connect to the live internet. They interacted with an offline environment made from indexed and cached web pages. Code tasks ran restricted containers inside lightweight virtual machines, with monitoring and network and cloud boundaries also in place. This is not evidence that one isolation technique has eliminated risk. It shows that the runtime path was constrained after the incident and supported by multiple controls. Teams should inspect the actual DNS resolver and outbound route, not merely confirm that a configuration file says “offline.”
Make Isolation an Acceptance Test for Runtime Behavior
OpenAI also had frontier-model agents continually attack its research infrastructure and used red-team findings in security cases that informed whether training could proceed. The material says that related problems were fixed and disclosed to open-source maintainers, and that the number of vulnerabilities and configuration errors found later fell significantly. The point is not to treat a red-team exercise as a one-time certificate. It is to make adversarial testing part of ongoing review and release decisions. For command sandboxes, the equivalent work is to test real tasks, confirm that rules cover child processes, and verify that network and file restrictions behave as intended.
A usable acceptance test should record both kinds of failure: exposure caused by overly broad permissions and task failure caused by overly narrow ones. The first calls for tighter path or network controls. The second is a warning against restoring a workflow by bypassing the controls. Before deployment, specify sensitive paths that must not be readable, locations where writes are permitted, and the domains a task needs. Then run installation and tool workflows on the target platform and recheck DNS and outbound paths. If a team cannot explain how these boundaries take effect, or has not tested them with tasks and adversarial exercises, “isolation enabled” is not evidence that agent security is complete.