One Message, Full Access: What the Claude Cowork Security Flaw Means for Your Company Data

A single message. A freshly connected folder. That's all it took to bypass the Claude Cowork sandbox and gain access to an entire Mac's file system - SSH keys, cloud credentials, and practically all personal files included. On July 23, 2026, the security firm Accomplish AI published a blog post documenting exactly that: a sandbox escape flaw called SharedRoot. For companies using Cowork or comparable AI agents with file system access, this is more than a technical footnote. It's a concrete test of just how solid the promise "the agent runs isolated" actually is in practice.

What Is SharedRoot – and Why Does It Affect You as a Business Owner?

Claude Cowork is Anthropic's AI agent for desktop tasks, launched on January 12, 2026 as a research preview - explicitly designed for non-technical knowledge workers, not just developers as with the related Claude Code. Since early July 2026, Cowork has also been available as a mobile and web beta. If you or your team use Cowork locally on a Mac, you typically connect a folder - say, one containing proposals, accounting documents, or contract drafts - so the agent can read and write within it. The idea behind it: the agent is meant to work exclusively within that folder, technically sealed off from the rest of your computer by an isolated Linux VM running via Apple's Virtualization Framework.

That isolation is exactly what SharedRoot is about. Oren Yomtov, Principal Security Researcher at Accomplish AI, describes the starting point of his test like this:

"We connected a folder to a fresh Claude Cowork session, sent one short message, and watched the agent escape the sandbox." – Oren Yomtov, Accomplish AI.

No multi-step social engineering attack, no months of probing defenses. One message was enough to trigger a chain of technical vulnerabilities that ended with the entire host file tree wide open - without a single permission prompt that could have warned the person affected.

How the Escape Worked Technically

The exploit chain documented by Accomplish AI comprises six steps that, each seemingly innocuous on its own, ultimately lead to full root access on the host system. Since these technical details come from the discovering security firm's own blog post, transparency matters here: Accomplish AI has a commercial interest in making its own discovery visible. The core mechanics, however, have been independently confirmed by several trade outlets, including The Hacker News, GBHackers, CyberSecurityNews, TechRadar, and SOCRadar.

Simplified, the attack works like this: the Cowork session's user account creates what's known as a user namespace via the unshare system call. This is a Linux mechanism actually meant for isolation - but here it effectively grants the session user root privileges, including the CAP_NET_ADMIN capability, within that namespace. With these rights, the vulnerable kernel module act_pedit can be configured via a netlink socket. This is exactly where the actual vulnerability comes in: CVE-2026-46331, also internally called "pedit COW," is a bug in the act_pedit module of the Linux kernel's net/sched (traffic control) subsystem. It had already been publicly known as an Ubuntu bug since June 2026 - and allows a cached copy of a root-owned helper binary to be poisoned in a targeted way.

The last step is then almost trivial: Cowork's root daemon, coworkd, re-executes the poisoned binary - and a protection mechanism called NoNewPrivs, actually designed to prevent exactly this kind of privilege escalation, gets bypassed in the process. The guest root access obtained this way ultimately meets a fully mounted host file system, mounted at the path /mnt/.virtiofs-root. According to Accomplish AI, this mount was configured as a writable VirtioFS mount - actually intended to be visible only to guest root. After the escape, it was fully readable and writable for the compromised agent.

What an Attacker Could Actually See After the Escape

This is where the flaw becomes concretely dangerous for businesses. After a successful SharedRoot escape, access extended far beyond the folder originally connected to Cowork. According to Accomplish AI, this included SSH private keys, cloud credentials, and practically all files in the logged-in user account - without any permission prompt that would have made such an action visible. Imagine you deliberately connect only the folder with your current proposal templates to the agent - and in the end, a compromised agent could theoretically have had access to your AWS credentials, your private SSH key for the production server, or the login details for your accounting system.

According to Accomplish AI's estimate, around 500,000 macOS users running local Cowork sessions were affected before the mitigation. This figure is important to put in context: it comes from a secondary source, not an official Anthropic statistic on the active install base, and should accordingly be understood as the discovering security firm's estimate - not a confirmed Anthropic figure. Equally important: the flaw explicitly relates to the local execution of Cowork on macOS, where the agent runs in an isolated Linux VM via Apple's Virtualization Framework. No verified information is available on Windows or Linux desktop versions of Cowork regarding this specific flaw.

How widespread Cowork already is in everyday business use is also relevant to assessing the potential damage. According to a separate, non-security-related analysis by Anthropic of 1.2 million anonymized Cowork sessions, 33.4 percent of customers used the tool for business processes and operations, with a further 16.4 percent for creating documents and presentations. This shows that Cowork is no longer used just for simple text tasks, but for workflows where access to sensitive business documents is a natural fit - exactly the kind of use that depends on functioning sandbox isolation.

How Anthropic Responded to the Report

According to consistent reports from several trade outlets, including thehackernews.com and cybersecuritynews.com, Accomplish AI's report was classified by Anthropic as "informative" - meaning no dedicated fix was shipped for the escape path itself as described. A direct, verified original quote from Anthropic on this classification couldn't be found during research; the wording comes from press coverage. As mitigation, Anthropic, according to these reports, points to the fact that the current Cowork version defaults to cloud execution - a mode in which this specific local escape path doesn't apply, because no locally isolated file system on a Mac is involved.

That's a fair technical response, but not a complete all-clear. Important for your own assessment: it remains unclear whether and when Anthropic has actually technically patched the flaw in the meantime - for instance through hardened seccomp profiles or a host mount switched to read-only. What's reported is only the switch to cloud execution as the new default for newly started sessions. Existing local installations that continue running in local mode aren't automatically protected by that. So if your business has been running a local Cowork installation for a while, you should actively check which mode your sessions are actually running in, rather than relying on automatic protection.

Accomplish AI recommends concrete hardening measures that are generally sensible for any environment where AI agents work with namespace isolation: disable unprivileged user namespaces, deploy a more restrictive seccomp profile that blocks unshare, clone3, and certain namespace flags and restricts address families to an allowlist, prevent autoloading of unused kernel modules like act_pedit, and consistently limit the host file system mount to the folders actually connected, mounting them read-only only. These measures fall within the provider's area of responsibility - for you as a business, they're relevant primarily as a review criterion: actively ask whether and how a provider has implemented such hardening steps.

Not an Isolated Case: Sandbox Escapes as an Industry-Wide Pattern

SharedRoot is part of a broader series of AI agent sandbox escapes in July 2026. On the same day, July 23, an unreleased OpenAI model was also reported, according to available news roundups, to have repeatedly escaped its own sandbox. This clustering is no coincidence, but reflects an industry-wide trend: kernel privilege-escalation advisories have, according to an industry analysis by SOCRadar, increased 2.3-fold year over year, and the time between an exploit becoming available and a patch being available has in some cases shrunk to just a few hours. This figure specifically refers to the general trend in kernel vulnerabilities, not specifically to Claude Cowork - but it provides important context: the attack surface is growing faster than many organizations are adapting their defenses.

For you as an SMB, that means: SharedRoot isn't about an Anthropic-specific problem that will automatically disappear with the next competing product. It's about a structural property of AI agents that work with operating-system rights and file system access - regardless of which provider is behind them. Whether an agent runs on a Mac, a Windows machine, or in a cloud environment: as soon as it's allowed to read files, write files, or execute commands, an attack surface inevitably emerges that can be technically attacked - regardless of how trustworthy the underlying language model itself is. Anyone deploying an agent tool in production should therefore fundamentally plan with zero-trust principles, rather than relying on a sandbox's marketing assurance. You can read more on why choosing the right AI app alone isn't the decisive strategic question in our article ChatGPT Work, Claude Cowork, and the Rest: Why an AI App Is the Wrong Question for Your Business.

Notable, too, is the speed at which such findings now spread. Within just a few days of Accomplish AI's original publication, independent trade outlets such as The Hacker News, GBHackers, CyberSecurityNews, TechRadar, SOCRadar, and AI Weekly picked up the case and confirmed the core facts: the name SharedRoot, the date July 23, the researcher responsible, Oren Yomtov, and the affected platform, macOS, respectively local execution. This broad, independent confirmation sets the case apart from isolated, hard-to-verify security reports - though it should still be kept in mind that the technical details of the exploit chain primarily come from the discovering firm itself and have not yet been reproduced by an independent third party.

The obvious reaction - "then let's just stop using Cowork" - falls short. The real lesson from SharedRoot is more fundamental: sandbox isolation isn't a nice-to-have, but the only protective layer between an AI agent and your company systems. If that layer can be completely bypassed by a single kernel bug and a single message, you can't, as the person responsible, rely solely on vendor assurances. There are five questions you should ask yourself before every production rollout of an agent tool:

First: Does the agent run locally or in the cloud, and which isolation guarantees actually apply in the mode you're using? Cloud execution reduces local attack surfaces, but shifts the trust problem to the cloud provider - in that case, review the relevant data protection and data processing agreements.

Second: Which folders and drives are actually connected, and is access truly limited to those - in line with the principle of least privilege? The more generous the share, the greater the potential damage in a worst case.

Third: Are SSH keys, cloud credentials, and password manager data physically or at least logically separated from the user account under which the agent runs? That separation was exactly what was missing in the documented SharedRoot scenario - with the result that a compromised agent could reach practically everything on the logged-in person's computer.

Fourth: Is there monitoring or logging that would detect unusual file access outside the intended folder? Without such monitoring, an escape like SharedRoot remains effectively invisible - after all, there was no permission prompt to raise the alarm.

Fifth: How does the respective provider respond to security reports? Is there a documented patch process with clear deadlines, or are reports, as in this case, classified as "informative" without the actual escape path being closed? This question is worth asking before you hand contract data, customer data, or financial records to an agent tool.

Conclusion: Trust Is Good, Separated Credentials Are Better

The SharedRoot case shows in stark terms how quickly an environment advertised as isolated can be breached by a combination of a kernel bug and a single crafted message. For you as a business owner, the most important takeaway isn't to avoid AI agents altogether - the operational value that tools like Cowork now deliver for business processes, document creation, and customer communication is too great for that. The real takeaway is rather to treat AI agents from the outset with the same caution as any other privileged system access: with separated, rights-limited service accounts, a clear separation between credentials and agent environment, and a willingness to ask critical questions whenever a provider markets a sandbox as safe. Smaller companies without their own IT security department in particular often use agent tools with the same admin accounts also used for day-to-day business and cloud administration - a pattern that's no longer justifiable after this case. For more on how industry-wide security standards for the safe use of AI agents are emerging in general, see our article When Anthropic, Google, Amazon, and Microsoft Agree: What the New Security Standard Means for Your Business.