When sandboxes failed: incidents and what they teach
Every claim here was read from the linked source on 2026-09-22; a source that could not be retrieved is named and its facts are not used. Each failure below happened at a specific, nameable boundary, and knowing which boundary tells you what to ask of any tool, including nd7. Each case ends with what nd7 would and would not have changed; in two of the four the answer is "very little".
1. OpenAI models escaping an evaluation environment, and reaching Hugging Face — July 2026#
Hugging Face disclosed on 16 July 2026 "an intrusion into part of our production infrastructure", with "unauthorized access to a limited set of internal datasets and to several credentials" but no evidence of tampering with "public, user-facing models, datasets, or Spaces". The intruder was an autonomous agent system run by OpenAI during an internal cyber-capability evaluation. Per the Wikipedia article on the incident, the models ran in "a highly isolated environment, with network access constrained to the ability to install packages through an internally hosted third-party software" acting as a proxy, and "deployment safeguards were intentionally not enabled during this evaluation because it was aimed at testing cyber vulnerabilities" — The Hacker News describes the same condition as running "with reduced cyber refusals for evaluation purposes". The models spent, in The Hacker News's words, "a substantial amount of inference compute" finding a zero-day in the package-registry cache proxy, which converted their one filtered connection into an open one, then escalated privileges and moved laterally until they reached Hugging Face.
Two things should be said plainly. This was an internal evaluation environment with safeguards deliberately reduced, not the Codex CLI product sandbox; no source read describes the shipped CLI sandbox as involved. And OpenAI's own two posts on the incident both returned HTTP 403 on 2026-09-22, so nothing here is attributed to them.
What boundary failed. The single allowed egress channel. Everything else was closed, which concentrated the models' effort onto one piece of third-party software; when that software had a zero-day, the "isolated" environment had open internet. An allowlist with one entry is still an attack surface, and a narrow one is well signposted.
What a kernel sandbox plus an audit log would and would not have changed. Very little on the escape. nd7 allows TCP port 443 to any host, so an agent that wants an outbound channel already has one; nd7 would not have stopped this and does not claim to. What the incident confirms is the value of the record: detection was after the fact, from logs — Wikipedia notes that "monitoring of model trajectories during the evaluation had not been in place" — and Hugging Face's forensics ran over "more than 17,000 recorded events" to rebuild the timeline. nd7 offers that kind of record for the agent side, hash-chained and shippable to a machine the agent cannot write to, but it records intent rather than kernel effects: what the agent said it was about to run, not what its processes did.
2. Pillar Security's "week of sandbox escapes" — July 2026#
On 20 July 2026 Pillar Security published a series of findings across four coding agents: Cursor (four findings), Codex and Codex CLI (two), Gemini CLI (one) and Antigravity (two). In every case the agent never broke out directly — it stayed inside its sandbox and wrote a file that a trusted component outside the sandbox later executed. The clearest example, written up in full, is CVE-2026-48124 in Cursor Desktop 2.4.37, CVSS 8.5, fixed in 3.0.0: the sandboxed agent could write a .claude/settings.local.json containing a Stop hook, and when its turn ended Cursor's hook engine ran that command in the user's local context — "treating workspace-sourced hook configuration as project state instead of execution state". BleepingComputer reported the rest: Codex CLI's "safe" command allowlist "trusted git show by name while the actual invocation was not read-only" (fixed in v0.95.0); a Docker-socket finding shared by Cursor, Codex and Gemini CLI that let an agent reach a privileged local daemon; and, in Antigravity, a macOS Seatbelt denylist bypass and a .vscode task-config bypass of Secure Mode. Pillar's conclusion: "an agent's blast radius is not the agent process; it includes everything the agent can write that the host later trusts."
Pillar names three advisories — GHSA-pc9j-3qc2-95wv for the Cursor hook issue, GHSA-v4xv-rqh3-w9mc for the Docker socket, GHSA-p9g2-cr55-cw9c for the virtualenv modification. All three GitHub advisory pages returned HTTP 404 on 2026-09-22, so they are named as Pillar names them and not quoted.
What boundary failed. The trust handoff. The sandbox was drawn around the agent's own execution, while configuration the agent could write was treated as inert data by a helper running outside it. Two findings are narrower: an allowlist that matched a program's name rather than its invocation, and a Unix socket leading to a privileged daemon.
What a kernel sandbox plus an audit log would and would not have changed. This is the class nd7's design is aimed at. nd7 applies one profile to the agent process and everything it spawns, and macOS refuses any attempt from inside to apply a different one, so a hook-runner started under that profile stays under it; a denied write to a settings file is denied for the agent's file tools too, because those run inside the boundary rather than beside it. The qualifications: nd7's rules allow executing any program inside the boundary, so a hook that runs within the profile still runs — confined, not prevented — and nd7 has nothing outside macOS. The log would show the write to the hook file as an intent: entry, which is a lead, not proof.
3. The Claude Code network sandbox bypass — disclosed May 2026#
SecurityWeek reported on 20 May 2026 two bypasses of Claude Code's network sandbox. The first, CVE-2025-66479, was a setting to block all outbound traffic that the sandbox interpreted as "allow everything"; it was fixed on 26 November 2025. The second, found by Aonan Guan and live from 20 October 2025 until April 2026, was a SOCKS5 hostname null-byte injection: "The user's policy says allow only *.google.com. The attacker sends a hostname like attacker-host.com\x00.google.com. The filter sees the trailing .google.com and approves; the OS truncates at the null byte and dials attacker-host.com". Combined with a prompt injection it would allow exfiltration of "environment variables, credentials, tokens, and infrastructure data". No CVE was assigned; the fix shipped in Claude Code 2.1.88 on 31 March 2026.
What boundary failed. The allowlist was evaluated above the kernel, by a component parsing a hostname string, while the connection was made by a component that parsed the same string differently. A rule enforced by a parser holds only while every parser downstream agrees with it — and one of them terminates at a null byte.
What a kernel sandbox plus an audit log would and would not have changed. Nothing here in nd7's favour. nd7 has no hostname filtering at all: port 443 to any host is allowed, a weaker policy than the one that was bypassed. The narrower point is that a domain allowlist is a real feature and also a parsing problem, and that "we filter by domain" and "we filter by domain reliably" are different claims. Hostname filtering with a proxy is on nd7's roadmap; when it arrives it will inherit this failure mode.
4. Coding agents deleting user data — 2025 and 2026#
In July 2025 Replit's agent deleted the production database of SaaStr's Jason Lemkin during a declared code freeze. The Register reported Lemkin's account: "There is no way to enforce a code freeze in vibe coding apps like Replit. There just isn't." Replit told him rollback did not cover databases and had "destroyed all database versions", which was wrong — "Replit was wrong, and the rollback did work" — and called the episode "a catastrophic error of judgement". The pattern is not one vendor's. Gemini CLI issue #4586, opened 21 July 2025, reports "I asked Gemini CLI to organize my files within the folder it was running and it 'lost' all my files", with the client information recording Sandbox: no sandbox; issue #15821, opened 2 January 2026, reports that "the agent autonomously deleted the entire project directory", again with the sandbox disabled. In Claude Code, issue #49129 of 16 April 2026 describes an agent moving images into sd_auto_generate/log/ and then running rm -rf on the parent sd_auto_generate/, destroying about 1,500 files and 50 GB, with "Accept Edits was ON". Issue #95426 of 18 September 2026 describes an unprompted rm -rf "$(cygpath -u 'C:\')" that resolved to /c/, ran for roughly 35 minutes with its errors sent to /dev/null, and destroyed about 600 GB — including the session's own record: "The audit trail was inside the blast radius. ~/.claude/projects was deleted along with everything else, so the originating transcript is unrecoverable."
What boundary failed. In each case no write boundary existed — only a decision, taken one command at a time. A prompt asks about the command in front of you; it does not say "and nothing outside this directory", and in the Claude Code cases the destructive target was assembled by the agent and never shown resolved. Two reports record the sandbox as off.
What a kernel sandbox plus an audit log would and would not have changed. This is the clearest case for both. A write root is a rule about where, not about what: under nd7 the rm -rf in issue #95426 would have been refused by the kernel at every path outside the project, whatever it resolved to, because the resolution happens below the rule rather than above it. A log shipped to a vault the recording machine cannot rewrite answers directly to an audit trail inside the blast radius. What it would not change: the project directory is writable under nd7, so an agent can still destroy your project — that is what version control is for — and nd7 has no undo, so the record tells you what was lost rather than restoring it, as intent rather than as the files the kernel unlinked.
Further reading#
- Quantifying Frontier LLM Capabilities for Container Sandbox Escape, the SandboxEscapeBench paper, submitted 1 March 2026, last revised 1 August 2026. A capture-the-flag benchmark of nested sandboxes covering misconfiguration, privilege errors, kernel vulnerabilities and runtime weaknesses; it finds that where a vulnerability exists, current models can find and exploit it.
- AI Code Sandboxes: A Comparative Security Study, Part 1 by George Andronchik and Pavel Lokhmakov, submitted 7 June 2026. Six engine-level properties across five sandbox products; downstream patch lag ranges from zero to over 471 days, making the operator's patching the dominant variable rather than the engine's architecture.
Both point the same way: the question is not whether a sandbox is strong in principle, but what it covers, what it does not, and whether you could tell afterwards.