SharedRoot: what a Cowork sandbox escape teaches us about AI agent security

Security researchers at Accomplish AI published SharedRoot this week — a demonstrated escape from Claude Cowork's local Linux VM that lets content inside a session reach across into the host macOS filesystem, reading SSH private keys, cloud credentials, and anything else the user's account can access. The disclosure is getting attention on Hacker News today, and it deserves a careful read — not because the CVE is novel, but because the structural argument underneath it applies to every AI agent product that isolates untrusted code in a kernel-level sandbox.

What SharedRoot actually is

Claude Cowork's local mode runs inside a Linux virtual machine on your Mac. The idea is that whatever the AI agent does — reading files, running code, making network requests — stays contained inside that VM. The shared folder between guest and host is the intentional surface; everything else is supposed to be off-limits.

SharedRoot breaks that containment. The attack chains a publicly known Linux kernel vulnerability — CVE-2026-46331, a flaw in the act_pedit traffic control subsystem — with four specific design choices Accomplish AI identified in how Cowork integrates its sandbox with the host filesystem. By loading the act_pedit kernel subsystem into an unprivileged user namespace, an attacker can exploit the CVE to obtain guest root. From guest root, the technique targets a root-owned binary and corrupts its in-memory page cache — without touching the on-disk version — so that when coworkd, the root daemon, eventually re-executes that binary, it inherits the malicious modifications. At that point the guest has host-level reach.

The researchers note this isn't the product of a single, clean kernel bug. The vulnerability stems from four layered design choices about how the sandbox integrates the kernel, user namespaces, and the shared host filesystem. Any one of the four, addressed in isolation, would not close the attack surface by itself. That design-level framing is where the disclosure gets interesting.

Anthropic's response and the current status

Accomplish AI reported the findings to Anthropic. Anthropic closed the report as "informative" — meaning they acknowledged it but did not commit to a direct fix addressing the underlying design. Instead, the latest Cowork release now defaults to cloud execution rather than local VM execution. Because the SharedRoot exploit requires attacker code to run inside the local guest VM, cloud execution sidesteps the local escape path entirely: your session runs in Anthropic's infrastructure, not a VM on your machine.

The practical upshot for users on the latest version: if you have not explicitly switched back to local execution mode, you are running in cloud mode and are not exposed to SharedRoot as described. If you are running an older version of Cowork, or have opted into local mode deliberately, update or switch modes now.

Accomplish AI estimates that approximately 500,000 macOS users were running local Cowork sessions before this became public. The shift to cloud-default is a pragmatic mitigation, but it is worth understanding what it actually means: Anthropic did not fix the underlying design; they changed the product's default posture to route around it.

The structural argument that outlasts this CVE

Or Hiltch, the researcher who led the disclosure, made a point in his announcement that I think deserves more attention than the CVE number itself: "Sandboxes are structurally one N-day behind, all the time."

Here is what that means in practice. A VM-based AI agent sandbox isolates untrusted code inside a guest Linux kernel. That guest kernel has a patch lag — it will always be some number of days behind the latest security releases, because Cowork (or any similar product) needs to validate each kernel update before shipping it. AI-assisted kernel bug-finding is accelerating. Researchers and, increasingly, automated tools can identify exploitable kernel conditions faster than the patch cycle of any embedded guest OS can keep up. The sandbox is never running today's kernel; it is running last week's or last month's. The window of exposure is structural, not incidental.

This is not unique to Cowork. Every AI agent product that runs untrusted code or untrusted content inside a VM — and there are many — faces the same property. The guest kernel they ship will always lag the current patch state. As long as adversaries can find and exploit N-days faster than vendors can ship patched guests, the sandbox boundary is porous by construction.

The implication is not that VM sandboxes are useless — they raise the bar significantly and stop the vast majority of threats. The implication is that treating the sandbox as a trust boundary you can fully rely on is incorrect. Defense in depth has to apply inside the agent's reach, not just at the VM perimeter.

What this means if you build or deploy AI agents

SharedRoot is a Cowork-specific disclosure, but the lessons apply to any production agent deployment that uses a sandboxed execution environment:

• Do not put credentials inside the agent's reach that you do not want the agent to be able to exfiltrate. SSH keys, cloud credentials, and API tokens that live in ~/.ssh or standard config paths are reachable if the sandbox breaks. Treat the agent's execution environment the way you would treat a shared machine: secret-manage aggressively, revoke quickly, and scope permissions to the minimum the task actually requires.
• Audit what is in the shared folder. The intentional shared surface between host and guest is where most users focus, but SharedRoot demonstrates that the unintentional surface (things accessible after a guest-root escape) can be far larger. Know what your agent's worst-case host reach looks like, not just its intended reach.
• Prefer cloud execution for sensitive workloads, with full awareness of what that trades. Cloud execution removes the local escape surface but moves your session data into the vendor's infrastructure. Neither option is obviously correct for all users; the choice depends on your threat model. The important thing is making that choice deliberately rather than by default.
• Watch the kernel version your sandbox ships. For products that let you inspect the guest kernel version, check it against the CVE database periodically. The lag between a public CVE and a patched guest kernel in your AI tool is your exposure window.

The bigger picture

SharedRoot is, in a narrow sense, a story about one CVE in one product. But the disclosure's timing is not accidental: Accomplish AI made the point explicitly that they are finding these vulnerabilities faster because AI-assisted bug-finding tooling has gotten dramatically more capable. The same technology that makes AI agents powerful accelerates the pace at which adversaries — and researchers — can identify kernel-level exploits.

As agent products move from novelty to production infrastructure — processing sensitive documents, running code against real databases, managing cloud resources — the security bar for the sandboxes they rely on needs to move with them. A product that was acceptable for demos in 2025 may be inadequate for the workloads it is handling in 2026. SharedRoot is an early, well-documented illustration of that gap. It will not be the last.