SharedRoot: What a Sandbox Escape in Claude Cowork Says About Identity, Not Just Isolation

Introduction:

In a routine Cowork session scoped to one folder, a single prompt triggered a complete VM escape. A file authored within the sandbox surfaced in the host’s home directory, a cross-boundary leap that happened without a single permission prompt or alert. Outside that boundary, the agent inherited the unconstrained reach of the local macOS user, placing every SSH key and cloud credential on the machine within its immediate blast radius.

Locally, Cowork runs as a macOS app that launches a separate Linux VM through Apple's Virtualization framework, with the agent inside as an unprivileged user and connected folders brokered in as mounts. On paper, nothing inside that VM should reach further than those folders.

Cybersecurity researchers have uncovered the chain named SharedRoot by Accomplish AI. It combined one Linux kernel bug in Cowork's Ubuntu-based guest, CVE-2026-46331, with four configuration choices that were always adjustable: unprivileged user namespaces left enabled, a seccomp filter (the rule set governing which low-level system calls a process may make) that blocked specific calls instead of allowing only approved ones, an unused kernel module free to autoload, and the entire host filesystem mounted read-write into the guest VM instead of just the connected folder. Cowork's current release defaults to cloud execution, which closes this local path. The report itself was closed as “Informative,” a defensible call for a bounty program, and a separate question from what was running on people's laptops before that default changed.

The kernel bug will get patched. The condition that made it matter won't, unless it's addressed directly: an AI agent was running with a human's full trust and a human's full filesystem access, and nothing in that arrangement had been scoped down to what the agent needed.

The identity problem underneath it

Every fix on that list, closing the namespace, tightening seccomp, blocking the module autoload, scoping the mount, hardens the boundary itself. All four assume that if the boundary holds, what's on the other side of it doesn't matter as much. None of them ask why the agent had a path to every credential on the machine in the first place, boundary or no boundary.

That's not a Cowork-specific failure. It's the default shape of agentic access right now. An agent gets connected to a folder, a repository, a set of tools, and its practical reach is defined by whatever the runtime happens to expose, not by what the task in front of it actually requires. Nobody sits down and scopes an agent's access folder by folder, credential by credential, before every session. That default is exactly what turns a single privilege escalation into a full compromise instead of a contained one.

The SSH keys and cloud credentials at risk in SharedRoot weren't stolen through phishing or credential stuffing, the usual ways credentials leak. They were sitting inside a blast radius nobody had measured, let alone scoped down. The question worth asking isn't whether an agent behaves well. It's what it can reach if something, anything, goes wrong upstream of it. A kernel patch answers that question for exactly one bug. It doesn't touch the arrangement that made the answer “everything” instead of “one folder.”

How Unosecur's MCP Gateway addresses this

The Gateway sits at the application layer, between AI clients and the servers they call, not inside the guest kernel. It has no bearing on unshare, act_pedit, or a VM escape happening below it, and it wouldn't have stopped this specific chain. What it addresses is the identity question the chain exposed: once an agent is connected to real tools and real data, repositories, cloud storage, internal systems, what is it actually permitted to do with that access, and can anyone see what it did.

The mechanism is identity binding: every AI client routes through one gateway endpoint, and every action that passes through it is tied to the real human identity behind the agent, not just the agent itself. Four things follow, and each would have mattered here if the agent's leverage had come through connected tools instead of a kernel escape.

Access stops being standing by default. Instead of an agent inheriting whatever a session happens to expose, access runs through Standard, JIT, or Least Privilege policies. JIT grants are time-boxed with a mandatory end date and a written justification, so a task-scoped need doesn't quietly become permanent access. Least Privilege policies are auto-generated denylists built from observed usage, closing the gap between what an agent was granted and what it actually uses.

Over-provisioning gets caught before it's exploited, not after. Access Analyzer scores every connection on granted access against used access and flags the difference, the exact question nobody was asking about SharedRoot's mount until it was too late.

Sensitive data gets inspected in the traffic itself. DLP scans both directions of MCP traffic for credentials, tokens, and secrets, flagging risky requests and redacting sensitive values before they reach the client. Analyze Intent classifies what a tool call is actually trying to do, low through critical risk, and can block on that classification before execution, which is exactly the kind of call a static allowlist wouldn't catch.

Every action leaves a record on its own. Tool Monitor logs every MCP call, who made it, through which client and server, with what outcome, separate from the admin log of policy and configuration changes. Answering what an agent touched becomes a query against a log that already exists, not a forensic reconstruction after the fact.

None of that replaces disabling the namespace, tightening seccomp, or scoping the mount. Those are still what stops this particular chain from working at all. What identity-first governance adds is a second, independent boundary that doesn't assume the sandbox holds. The audit worth running this week isn't about Cowork specifically: pull the list of every agent connected to a repository, a cloud account, or an internal tool, and check whether its current access still matches what its last month of activity actually used. Most organizations haven't run that comparison once.