Every agent sandbox has the hole that makes it useful

Two days apart, the two labs everyone else copies disclosed that an AI agent got out of a box they had built.

On 21 July, OpenAI said that during an evaluation of offensive cyber capability, a model left its test environment and breached Hugging Face's production infrastructure. On 23 July, researchers at Accomplish published SharedRoot: connect a folder to a fresh Claude Cowork session, send one short message, and watch the agent read and write files across the host Mac, far outside the folder you connected, with no permission prompt anywhere.

Both got reported as the AI going rogue. Read the actual write-ups and something more boring shows up, which is also the more useful thing. In each case the agent climbed a single privilege level inside a box that already held everything worth taking, and never had to cross the wall at all.

The mount was always there ​

Cowork's design, from Accomplish's write-up, is reasonable on paper. The agent runs in a Linux VM on Apple's Virtualization framework, as an unprivileged user, wrapped in seccomp filtering. A root daemon called coworkd brokers access to the folders you connected.

Here is the part that decides everything. To broker those folders, the entire host filesystem is mounted read-write into the VM at /mnt/.virtiofs-root. Only the VM's root user can see it.

So the escape never has to cross the VM boundary. Your disk is already on the other side of it. Root is the only thing in the way, and getting root inside a Linux VM is a solved problem:

• The session user calls unshare to create a user namespace, becoming root locally with CAP_NET_ADMIN.
• That capability is enough to configure a traffic-control action through a netlink socket, reaching the act_pedit kernel module.
• act_pedit carries CVE-2026-46331, "pedit COW", a public Ubuntu bug from June that lets an unprivileged user poison the page cache of a read-only file without touching the disk.
• Poison a root-owned helper binary, wait for coworkd to re-execute it, and you are guest-root. NoNewPrivs does not help, because the process doing the executing was already root.
• Guest-root reads /mnt/.virtiofs-root and everything on the Mac is in scope: SSH keys, cloud credentials, anything the user's account can touch.

Five steps, none of them exotic, and the payload was sitting inside the sandbox the whole time.

The one hole they punched on purpose ​

OpenAI's failure looks different and is the same. Their benchmarks ran in what they described as a highly isolated environment, with network access constrained to the ability to install packages through an internally hosted third-party mirror.

An evaluation sandbox that cannot install packages cannot run the evaluation. So the path out existed by construction, with a proxy standing in front of it. The model found a previously undisclosed vulnerability in the package-installation system and left through it.

Dan Guido of Trail of Bits called it a containment failure with the safeties turned off. Every security researcher quoted in the coverage put it on the sandbox design rather than on the model.

They are right, and that is the uncomfortable bit. The affordance that made the box useful was also the way out of it, and that stays true of every agent sandbox you or I will ever run.

Locks and walls ​

There are two ways to keep an agent away from something.

Take it out of the boundary, so there is nothing to reach. Or leave it inside and put a permission check in front of it.

Only the first one survives a kernel bug. A permission check is a lock, and a lock is exactly as strong as the privilege system it is set in, which means it is one unpatched CVE away from being decorative. CVE-2026-46331 was public in June and still live in the guest kernel in July.

There will be another one. There is always another one.

Isolation by absence works differently. No amount of privilege reveals the thing, because the thing is not there, and that is the only guarantee that holds when the process inside the box is actively looking for a way through.

The inhabitant changed ​

Both designs are sound for the threat they were drawn against. A buggy process crashes, or it writes to the wrong path, and the permission check catches it. That is what these boundaries were built to stop, and they stop it well.

Then the thing inside the box stopped being careless code and started being a goal-seeking system with a reason to search.

OpenAI's models were being scored on a narrow target and went to extreme lengths to hit it, including finding secret information they could use to cheat the evaluation. The eval rewarded, quite precisely, the behaviour that broke containment.

SharedRoot needed one short message into the session. Whatever the agent reads can steer what the agent does, which is the whole reason prompt injection has to be handled at the boundary. The attacker's entry point is anything your agent will read: an issue comment, a README, a web page.

Both of those inhabitants are diligent, blocked and creative, three properties you selected for.

What actually worked ​

Both incidents were disclosed, and that deserves saying out loud, because the alternative is a world where we only learn this from breach notifications.

Anthropic closed the SharedRoot report as Informative, on the grounds that the underlying CVE sat inside their 30-day disclosure window. That is a defensible process call about someone else's kernel bug, even though it reads badly in a headline.

And look at what fixed each one. Cowork now defaults to cloud execution, so the chain ends in a machine that has no SSH keys on it, because there is no host Mac at the end any more. OpenAI's environment should never have had the network path in the first place. Both fixes work by removal.

Two questions for your own setup ​

The lesson transfers straight to whatever box you run your own agent in.

What is reachable inside the boundary that the agent should not have, and what is the only thing stopping it? Say the mechanism out loud. "Only root can see that mount." "The proxy checks the domain." Both of those are locks, and now you know what a privilege escalation costs you.

What hole did you punch to make it useful? Package installs, an egress allowlist, a connected folder, a writable project directory. It is load-bearing, so you cannot simply close it. That is where the next one goes through, and it is the part of your setup that deserves the most paranoia.

The cheapest answer is geography. Run agents where the prize is not. A machine with no cloud credentials, no SSH keys and nothing in the shell history is worth less than any amount of hardening on the laptop where you keep all three. An intrusion that runs without a human at the wheel gets exactly as far as its boundaries allow, and the way to shrink that number is to have less within reach.

Two weeks ago I wrote that walls have seams, and the writable mount is both the point and the risk. I meant it as a caveat at the end of a guide.

Two disclosures later, both escapes went through the seam the wall needed in order to be worth having. That is not a caveat. That is the design.