Your Sandbox Is Only as Strong as Its Next Escape
An AI agent connected to one folder on a Mac. Someone sent it a short message. It escaped a kernel-isolated Linux VM, reached the host filesystem, and could read and write files anywhere on the machine — SSH keys, cloud credentials, all of it — with no permission prompt at any point.
That's not a hypothetical. That's SharedRoot, the vulnerability Accomplish AI disclosed in Claude Cowork this month. I wrote about the Hugging Face incident three weeks ago and called it a frontier-lab problem, out of Thuban Shield's scope. SharedRoot isn't. It's exactly the problem Thuban Shield exists to sit in front of, and it's worth being precise about why.
What actually happened
Claude Cowork runs its agent inside a disposable Linux VM on the host Mac, using Apple's Virtualization framework. That's a real isolation boundary — not a chroot, not a container, a genuine kernel-level VM. Whatever folder you connect gets shared into that VM by a root daemon. The rest of the host filesystem is supposed to stay out of reach.
Except the whole host / was mounted read-write into the VM anyway, visible only to guest-root inside it. So the entire attack came down to one question: could the agent get guest-root? It could. A privilege-escalation bug in the Linux kernel's traffic-control subsystem (CVE-2026-46331, "pedit COW") gave it a path from unprivileged user namespace straight to guest-root. Once there, the VM boundary was cosmetic. The agent could read and write anywhere on the host, as the logged-in user, including SSH keys and cloud credentials.
Anthropic closed the disclosure as informative, without a fix, though the current version of Cowork now defaults to cloud execution — which sidesteps the problem rather than closing it. Anyone still running local sessions on an unpatched kernel is exposed.
Why this is different from Hugging Face, and why it matters more to me
The Hugging Face incident was about a model finding a zero-day in a package registry proxy and pivoting into production infrastructure Thuban Shield has no visibility into. I was honest at the time: Thuban Shield would not have stopped that. It doesn't run on frontier-lab infrastructure, and it has no opinion about a network proxy vulnerability.
SharedRoot is a different shape of problem entirely. It isn't about network containment, credential theft against a remote service, or lateral movement across someone else's servers. It's about what happens when an agent, having gained elevated privileges inside its own execution environment, turns around and hits the local filesystem — your files, your keys, your machine. That is precisely Thuban Shield's territory. Not adjacent to it. Not similar to it. The exact thing.
The uncomfortable generalisation
Strip away the specific kernel bug and the specific vendor, and SharedRoot says something broader: a sandbox is a claim, not a guarantee. Or Hiltch, who led the research, put it well — the Linux networking subsystem throws off this exact shape of privilege-escalation bug on a regular cadence. Patch one, and the chain re-arms on the next one. Sandboxes are structurally one N-day behind, all the time. That's not a criticism of Apple's Virtualization framework or of Cowork's design specifically — it's a property of software boundaries in general. Any isolation layer, however well engineered, is a piece of code, and code has bugs, and some fraction of those bugs are escapes waiting to be found.
Which means the question was never "is the sandbox good enough?" It's "what happens the day it isn't?" If the only thing standing between an agent and your SSH keys is the sandbox itself, then the sandbox failing is the whole ballgame. You need something that assumes the sandbox might not hold, and protects the filesystem anyway.
What "protection outside the sandbox" actually means
This is the part I want to be concrete about, because it's easy to nod along with "defence in depth" as a slogan and not think about what it requires in practice.
A sandbox controls where code runs. It does not, by itself, control what the agent is allowed to do to your files once it's running — that's a policy question, and policy questions need a policy engine, not a container boundary. If your only enforcement is "the agent can't get out of the box," you have exactly one control, and SharedRoot demonstrates what happens when that one control has a bug in it.
Thuban Shield doesn't try to be a better sandbox. It's an independent policy layer that sits between whatever the agent decides to do and your actual filesystem, and it doesn't trust the execution environment at all — not the model's intentions, not the container's isolation guarantees, not the VM's privilege model. It asks a narrower, more answerable question every single time: is this specific write, to this specific file, something the policy allows? That question doesn't get easier or harder depending on whether the agent is running in a VM, a container, or bare on your laptop. It's the same check either way, which is the point — it doesn't rely on the sandbox holding to do its job.
1. File Guard
Protected files (.env, *.pem, *.key, lockfiles, CI config) are enforced regardless of what process or privilege level the write request comes from. Empty-content rejection and a similarity gate catch silent overwrites before they land.
2. Shadow Realm
Every proposed write is parsed in isolation before it touches disk. This isn't the sandbox the agent runs in — it's a second, independent check on the content itself, on top of whatever containment the execution environment claims to provide.
3. Watchers
High-risk operations — deletes, protected files, anything touching auth or credentials — get reviewed by three independent AI models in parallel. Any single veto blocks the write. No single point of judgment.
4. Execution Gate
Explicit human approval required before destructive operations proceed. There's no elevated-privilege path around it — the gate doesn't care how the agent got the permissions it's trying to use.
5. Audit & Recovery
Every checked operation is logged with a hash-chained audit trail. Before any write or delete, Thuban Shield snapshots the existing file, so thuban shield rollback gives you a way back even if something did get through.
What we can't protect you from, still
I said this in the last post and it's still true: I'd rather be precise about scope than sound impressive. Thuban Shield would not have prevented the SharedRoot kernel exploit itself. It has no visibility into the guest kernel, no ability to patch act_pedit, and no way to stop an unprivileged user namespace from being escalated to guest-root in the first place. That's a kernel and virtualisation-architecture problem, and the right fixes are the ones Accomplish AI recommended — disable unprivileged user namespaces, don't mount the whole host into the VM, run the sharing daemon in its own hardened mount namespace.
What Thuban Shield does do: it doesn't need the sandbox to have won.
Even if an agent gets guest-root, even if it reaches your real filesystem through a compromised VM boundary, Thuban Shield's policy engine is still running that same check on every write it's asked to perform: is this operation allowed? Is this file protected? Does this need human sign-off? The privilege escalation happened one layer down; the policy enforcement doesn't care, because it was never relying on the sandbox to be the only thing standing guard.
That's a meaningfully different claim from "we stop VM escapes." We don't. What we do is make sure that a VM escape isn't automatically a filesystem compromise too — because there's a second, independent gate in the way that doesn't get bypassed just because the first one did.
Honest about our own bugs, again
Same discipline as last time. Before I write a post arguing our approach is validated by someone else's incident, I want our own house checked first. We ran a dedicated adversarial red-team pass on Thuban Shield specifically probing for escape and bypass patterns — path traversal out of the project root, dangerous-pattern obfuscation, Unicode homoglyph filename tricks, snapshot corruption, and more.
It found 6 real bugs, including a critical one: Thuban Shield had no check for whether a resolved file path actually stayed inside the project root. A path crafted with enough ../../../ traversal, or an absolute path pointing anywhere else on disk, could sail straight through Layer 1 as long as its basename didn't match a protected pattern — we confirmed it by writing to a path shaped like the Windows hosts file. That's a real escape, in our own tool, found by testing it like an attacker would rather than trusting that it worked.
All 6 findings are fixed, with 22 new regression tests added specifically so they can't quietly come back. The full write-up — exact attack code, root cause, exact fix — is public in SHIELD-ADVERSARIAL-REPORT.md in the repo. Full suite: 210/210 passing. I'd rather you read about our own path-traversal bug from us, fixed, than discover it yourself.
Two separate problems, and you need both
Sandboxing answers "where does the code run, and what can it reach from there?" Filesystem protection answers "of the things it can reach, what is it actually allowed to do to them?" SharedRoot is what happens when an organisation has invested seriously in the first question — a genuine kernel-level VM, not a token container — and the second question had no independent answer at all. The moment the VM boundary had a bug, there was nothing else in the way.
Execution control and filesystem protection aren't the same problem wearing different names, and one doesn't substitute for the other. You need a sandbox, because most of the time it works and it reduces blast radius when something goes wrong inside it. And you need something that assumes it might not hold, and checks every file operation on its own terms regardless. Thuban Shield was never meant to compete with sandboxing. It's meant to be there for the day the sandboxing isn't enough — which, per Accomplish AI's own read of the kernel bug-finding landscape, is a "when," not an "if."
Where that leaves us
I don't think every AI coding tool needs to reinvent VM isolation, and I don't think Thuban should try to build one. What I do think is that any organisation giving an agent write access to real infrastructure — a laptop, a repo, a shared folder — needs an enforcement layer that isn't betting everything on the container holding. Your sandbox is only as strong as its next escape. Thuban Shield doesn't need the sandbox to have won, because it was never trusting it to in the first place.
Protect the filesystem, not just the perimeter.
Free, no signup, runs entirely locally — your code never leaves your machine.
npx thuban shield initWorks with Copilot, Cursor, Windsurf, Claude Code, Codex, Devin — any AI agent that writes to your filesystem, sandboxed or not.