The vendor security questionnaire came back with a line nobody had seen before: describe what happens when the code inside your sandbox is actively trying to get out. The platform team had always written "isolated" in that box and moved on. This month that word stopped being enough.
In October, Anthropic and OpenAI each published research in which AI models broke through boundaries that teams treat as walls: a browser's sandbox, a container, a microVM. The lesson for anyone running agent code is that an isolation claim is only as good as its layers, its network exits and its credentials, and Solari documents each of those layers for its sandboxes. This guide walks through what the disclosures showed and how to check each layer before trusting it.
What the October Disclosures Showed
The two reports tested different walls, so it helps to take them in turn. Anthropic's Frontier Red Team described an unreleased model that chained bugs in Chrome's V8 engine, CacheStorage and FedCM into code running outside the browser's sandbox. Anthropic says Google has assigned and patched 62 CVEs from the work, 13 of them sandbox escapes, and that the model also found escapes in popular sandboxing infrastructure.
OpenAI's account of its training environment, published October 23, went after the layer below. Its Linux environments put restricted containers inside microVMs, and red-team agents chained vulnerabilities to run code on the underlying host machines, as GBHackers reported. The fixes touched Kata Containers, gVisor and Docker's syscall filters.
The caveats matter as much as the headlines. OpenAI's agents were handed source code and vulnerability documentation, and the targets were research infrastructure rather than customer products. Even so, both reports point at the same question: what holds when the first wall gives way.
Why a Single Wall Is Not an Isolation Claim
Answering that question starts with counting layers, because a container and a virtual machine fail differently. A container shares the host's kernel and relies on namespaces and cgroups to keep processes apart. A microVM runs its own kernel behind a hypervisor, so a kernel bug inside it does not hand over the host.
The Kata Containers flaw in OpenAI's fix list, CVE-2026-24834, shows the difference in practice. Edera's analysis explains that it let a container process gain root inside the microVM guest, while the hypervisor boundary to the host held. The inner wall failed and the outer one did its job.
So the useful reading of any vendor's "isolated" is a list: which boundaries sit between the agent's code and the host, and what each of them trusts. That list is exactly what the Solari sandbox tiers spell out.
How Solari Layers a Sandbox
Solari answers that list with three named tiers, so the boundary is a choice rather than an assumption. The caller picks it at create time through the isolation option on the sandboxes API, and the figure below sets out the tiers side by side.
The default tier, dedicated, runs as its own microVM on Cloud Hypervisor with a dedicated kernel per session. Hardened is the same machine with all outbound network blocked, which makes it the tier for code nobody has reviewed. The shared tier is cheaper and starts faster, and keeps its sandboxes apart with namespaces and a cgroup rather than a hypervisor.
Across all three tiers, a sandbox never shares a VM with another organization. That leaves the second thing both reports probed: the ways out over the network.
The Network Exits the Red Team Found
OpenAI's agents did not need a kernel bug to reach the internet. GBHackers reports they found routes through permitted services for metrics, logging and authentication, including a firewall-approved connection reused to reach a blocked endpoint. An allowlist built around trusted internal services is only as narrow as those services.
That is the case for blocking egress outright where the job allows it, which is what the hardened tier does. When an agent does need the web, Solari's browsers take a different control: allowedDomains restricts a stealth session to a list of hosts and refuses everything else at the proxy layer. An empty list is rejected with an error rather than read as unrestricted, so a broken config fails closed.
The allowlist works on hostnames: it is set through the HTTP API on the Team and Enterprise plans, and direct-IP connections and DNS lookups sit outside it. OpenAI's other finding, a covert channel built from processor-cache timing between microVMs on a shared host, is a reminder that network rules are not the only exit worth asking a vendor about.
Credentials and Clean State Count Too
The last layer is the one teams forget: who can reach the sandbox from outside. On Solari, a sandbox id and its control and stream URLs are credentials, and whoever holds them can run commands as root in that sandbox until it ends. Keeping them out of logs, tickets and client-side code is part of isolation, not an afterthought.
Clean state closes the loop. A snapshot saves a prepared machine, and revert rewinds the same sandbox to it by booting a fresh VM behind the same id. Between runs of untrusted code, nothing an agent wrote yesterday is still on the machine today.
With the layers laid out, the decision for a given workload gets short.
Choosing the Right Setup
The October reports did not show that sandboxes are useless; they showed that a single boundary is a bet. Put agent-generated code in its own microVM, block outbound traffic unless the task needs it, and allowlist hosts when it does. Treat sandbox ids and URLs as secrets, and reset machines from a snapshot between untrusted runs. How the browser, sandbox and desktop surfaces fit together is covered in the introduction to Solari.
Get Started With Solari
Start by creating a hardened sandbox and running the agent's code there before anything gets network access. Solari sandboxes are ready in 90 ms and are almost 3x cheaper per sandbox hour than E2B, and the Free plan comes with $3 of monthly credits. Create a free Solari account and run that first hardened sandbox today.
