Claude Cowork Security: What’s Actually Documented, Not What’s Assumed
Published:
Last Updated:
A researcher connected a single folder to a fresh Cowork session, sent one short message, and watched the agent escape its sandbox. From inside the virtual machine, it read and wrote files across the entire host Mac, credentials included, with no permission prompt at any point. Anthropic reviewed the report and closed it as informative. No fix shipped for local sessions.
That’s not a hypothetical. It’s SharedRoot, disclosed July 23, 2026, and it’s the clearest evidence yet that Claude Cowork security has to be evaluated against what’s actually documented, not against what a chatbot-shaped mental model would predict.
One disclosure up front: Obot is our platform. It doesn’t secure Cowork itself. It governs the MCP connectors coworkers depend on, and the machines they’re installed on, and this piece is explicit about where that line sits.
What Cowork Actually Does, and Why That Changes the Threat Model
Claude Cowork gives Claude real capabilities: reading local files, browsing the web, executing code, using connected apps, and running scheduled tasks unattended. That’s Anthropic’s own framing, and it’s precise. The impact of anything going wrong depends on two variables: what Claude can read, and what Claude is allowed to do.
Anthropic separates Claude access into two categories. Read tools let Claude access and view content, an email inbox, a screenshot, internal tools a team already runs. Write tools let Claude take action, create a file, run a command, click on the screen. Write tools carry materially more risk, which is why Cowork treats them differently and recommends human oversight for consequential ones.
Where the code actually runs is more nuanced than most coverage of this topic states. Cowork sessions can run remotely, in an isolated, temporary environment on Anthropic’s servers, reaching a user’s machine only through the Claude desktop app and only for connected folders. But Cowork also supports local execution on macOS, where the agent’s work happens inside a Linux virtual machine created via Apple’s Virtualization framework, running directly on the host. As of the most recent release, cloud execution is the default. Users who opt into local execution are running a materially different architecture, and the distinction matters for the vulnerability below.
Enabling Cowork for a team also means accepting that it can autonomously generate reports, organize files, and carry out multi-step workflows without anyone writing code to drive them. That capability is the entire value proposition. It’s also why the read/write distinction above determines the actual risk of any given task, not the task’s stated purpose.
SharedRoot: The Sandbox Escape Anthropic Didn’t Patch
Security firm Accomplish AI disclosed SharedRoot to The Hacker News on July 23, 2026, describing a sandbox escape affecting local Cowork sessions on macOS. Roughly 500,000 macOS users running local sessions were exposed before Cowork switched to cloud execution by default.
The mechanism is specific and worth understanding, not just naming. Cowork’s macOS local execution runs the agent’s work inside a Linux VM, with every session getting its own disposable, unprivileged user and a seccomp filter for sandboxing. A root daemon called coworkd shares the connected folders into that VM, but it does so by mounting the entire host filesystem, root included, read-write, visible only to guest-root inside the VM at a fixed mount point. Any path to guest-root inside the VM is therefore a path to the whole host.
Accomplish AI’s researchers found that path: loading the Linux kernel’s act_pedit traffic-control packet-editing subsystem inside an unprivileged user namespace, then exploiting CVE-2026-46331, a recently disclosed kernel bug nicknamed pedit COW, to obtain guest-root. From there, the agent could read or write sensitive files anywhere on the host Mac as the logged-in user, including SSH keys and cloud credentials, entirely outside the folder the user had actually connected.
Anthropic’s response is the part worth sitting with. Following responsible disclosure, Anthropic closed the report as informative and did not issue a fix for the underlying issue. According to the researchers, Anthropic’s reasoning was that the kernel CVE fell inside its program’s 30-day public-disclosure window and that the proposed hardening amounted to defense in depth rather than a fix for a discrete flaw. The mitigation that exists is architectural, not a patch: the latest version of Cowork defaults to cloud execution, which sidesteps the local VM’s shared-mount design entirely. Users who still opt into local execution remain exposed. Put plainly: the fix is “don’t run it this way,” not “the bug is gone.”
The January 2026 File Exfiltration Vulnerability
SharedRoot wasn’t the first documented Cowork vulnerability, and the earlier one shows a different failure mode: not a sandbox boundary, but the model’s own judgment under prompt injection.
Security firm PromptArmor disclosed the issue in mid-January 2026, within days of Cowork’s research preview launch. A malicious document, disguised as a Claude Skill file, contained hidden instructions embedded in the file (1-point font, white on white) invisible to a human reader but fully legible to Claude. When Cowork analyzed the file as part of a legitimate task, the hidden instructions triggered a curl command to Anthropic’s own Files API, using the attacker’s API key rather than the victim’s, causing API key exfiltration and uploading the largest available local file to the attacker’s account. No additional user approval was required at any point in the chain, and the resulting data exfiltration touched financial figures and partial SSNs in PromptArmor’s demonstration.
The attack succeeded because the code execution environment’s egress restrictions whitelisted Anthropic’s own API domain as trusted traffic, which is reasonable for most purposes and became the exfiltration channel here. It worked against Claude Haiku and, in a separate test involving a simulated malicious integration guide, against Claude Opus 4.5 as well. PromptArmor’s account also states that the underlying isolation gap had been reported against Claude.ai chat before Cowork existed, by security researcher Johann Rehberger, a claim that traces to PromptArmor’s own reporting rather than something independently re-verified here.
Two distinct incidents, six months apart, with two different root causes: one an isolation boundary in the local execution architecture, one a trust decision baked into the egress allowlist. Cowork can exfiltrate data through more than one channel, and neither is the kind of thing a chatbot threat model would surface.
Browser Automation: What Claude in Chrome Adds to the Threat Model
Browser automation through Claude in Chrome is a separate risk surface from file and code access, and it deserves separate treatment because the numbers here come directly from Anthropic, not a third-party researcher.
In its own launch documentation for Claude in Chrome, Anthropic reported a 23.6% attack success rate against prompt injection before mitigations, and 11.2% with its current defenses in place. That is Anthropic’s own measurement of how often a hidden instruction on a web page successfully hijacked the agent, not a rounded estimate. An 11.2% residual rate, by Anthropic’s own numbers, means roughly one attempt in nine still gets through the current defenses.
Independent researchers have found more than the residual injection rate would suggest on its own. Koi Security’s ShadowPrompt research, disclosed and patched in January 2026, chained an overly permissive origin allowlist with a cross-site scripting flaw in a CAPTCHA subdomain to let any website silently inject prompts into a user’s Claude Chrome session, no click and no permission prompt required. Separately, LayerX researchers demonstrated that any browser extension, including ones with no special permissions, could pass instructions to the Claude extension and extract files from connected Google Drive folders. A third piece of independent research, published by Origin, found that the extension’s automation tools run arbitrary JavaScript in the page context using the user’s authenticated session cookies, meaning a successful compromise inherits whatever that browser session was already logged into, and that the extension’s local storage held an Anthropic API key and OAuth refresh token with no encryption and no OS keychain integration.
That combination, cookie inheritance plus unencrypted local credential storage, is why Anthropic’s own guidance recommends a dedicated, managed browser profile for Cowork and Claude in Chrome rather than an everyday personal profile signed into banking or personal Claude accounts. A separate profile limits what a successful injection can actually reach; it doesn’t reduce the injection success rate itself.
Claude Code and What Actually Transfers to Cowork
Cowork is not the only Anthropic agentic product with a documented history of configuration-based exploits, and it’s worth being precise about which findings actually apply here and which don’t.
Claude Code, Anthropic’s terminal-based coding agent, had two vulnerabilities disclosed by Check Point Research in February 2026: CVE-2025-59536, a code injection flaw that let a malicious project’s hooks or MCP server configuration execute shell commands before the user ever saw the trust dialog, and CVE-2026-21852, which exfiltrated API keys by overriding an environment variable to redirect authenticated traffic. Both were fixed, in Claude Code 1.0.111 and 2.0.65 respectively, months before SharedRoot was even disclosed.
Neither CVE applies directly to Cowork. They’re relevant here for a narrower reason: they establish that AI security risks tied to configuration files and MCP setup, not just prompt content, are a recurring pattern across Anthropic’s agentic product line, not a one-off. A team securing Cowork should treat that as a reason to vet MCP configuration the same way regardless of which Anthropic product is running it, not as evidence about Cowork specifically.
What Anthropic’s Own Safeguards Actually Cover
None of this means Cowork ships without defenses. Anthropic’s own documentation is specific about what’s actually in place, and the honest version of this section states those defenses accurately rather than dismissing them to make a sharper point later.
Anthropic’s model training uses reinforcement learning so Claude recognizes and refuses malicious instructions, even ones phrased with apparent authority or urgency. Content classifiers scan untrusted input entering Claude’s context and flag potential indirect prompt injection before it can affect behavior. In “Automatically approve” mode, Claude screens each action for safety before running it and blocks anything it assesses as unsafe. Permanent file deletion requires an explicit permission prompt in every mode. Computer use, where Claude interacts directly with the screen, has its own separate permission layer, since it operates with no sandbox between Claude and what’s on screen.
Anthropic states plainly that these measures reduce risk without eliminating it: the chance of a successful attack is non-zero. Set against its own published 11.2% residual injection rate for the browser surface, that’s a candid number, not a marketing one, and it’s a more useful reference point than a vendor’s narrower internal test condition.
Where the Real Enterprise Exposure Sits: Connectors and MCPs
Cowork connects to the tools a team already runs: Google Workspace, Slack, Notion, Microsoft 365, GitHub, and a growing catalog of connected services, all built on Model Context Protocol, the open standard Anthropic authored for exactly this kind of tool access. Each connector authenticates through OAuth or an API key and inherits the permissions of the underlying account, which is a sound default, and granting access through a connector is scoped to what that account can already see. It’s also where the actual enterprise attack surface concentrates once the sandbox and injection questions above are answered.
Anthropic’s own guidance is direct about this: desktop extensions and plugins expand what Claude can do, and each one introduces new ways for attacks to reach Claude. A local MCP server bundled with a plugin runs with the same permissions as any other program a user installs, which means MCP server access is effectively blanket access to whatever that user account can already reach. There’s no Anthropic-native, centralized view of which MCP servers are actually installed across an organization’s fleet of Cowork users, what each one’s MCP server calls actually touch, or whether a given server’s behavior has changed since it was approved. That’s a real supply chain risk, the same one documented across the broader MCP ecosystem: a server that was safe at approval time isn’t guaranteed to stay that way, and nothing native to Cowork tracks the difference.
Where Obot Fits, and Where It Doesn’t
Obot does not touch Cowork’s sandbox architecture, its browser automation, or its computer-use permission model. Anthropic owns that layer, and nothing at the MCP level changes what SharedRoot or the January exfiltration bug exposed. What Obot does cover is the connector layer described above, through its Enterprise AI Control Plane: define what agents can reach, choose where they run, and prove what they did.
Gateway: Define What Agents Can Reach
Obot MCP Gateway covers which MCP servers and connectors are actually approved for use with Cowork across enterprise environments, what an approved server can reach once it’s connected, and an audit trail for MCP tools calls that holds up independently of whether OpenTelemetry export was configured correctly for a given workspace (more on that in the compliance section below). It’s open-source under the MIT license, self-hostable on Kubernetes or Docker, and also available as a managed service, same product either way. It enforces tool-level access control rather than just server-level access, and it maintains audit logs at the tool-call level, the same granularity a security team needs to answer what a specific connector actually did across internal systems, regardless of which execution mode a given Cowork session happened to use.
Device: Watch and Enforce With Obot Sentry
The connector section above ends on a gap: there’s no Anthropic-native view of which MCP servers are installed across an organization’s Cowork users. That’s the gap Obot Sentry is built for. It scans AI client configurations on employee machines, including Claude Desktop, and reports which MCP servers, skills, and plugins each one loads, so a server added through a plugin shows up in an inventory instead of staying invisible.
Hosted: Claude Environments
Obot v0.27 added Claude Environments, hosted Claude Code environments that run under the same control plane. They’re for coding agents rather than Cowork itself, but they apply the same lesson SharedRoot teaches: keep agent execution off the employee’s machine and make its connections come from policy.
The honest scope statement: this covers the connector layer and the machines connectors are installed on, not Cowork itself. An organization’s overall endpoint security posture still has to account for the local execution risk SharedRoot demonstrated and the browser risk documented above; Obot addresses neither. Governance built at the MCP layer, before a connector is misbehaving in production, is infrastructure. Governance that turns out to be necessary only after an incident is a recovery project.
This is the section where most coverage of this topic overstates or understates the same fact, so it’s worth being exact.
Anthropic’s own Help Center states that Cowork activity is not captured in audit logs, the Compliance API, or data exports at this time, meaning security teams relying on that API get no record of what a Cowork session touched. That’s the accurate starting point, and it’s a real gap for regulated data, the kind that would sit inside cardholder data environments or similar compliance scopes: organizations that built their compliance evidence pipeline around that API have a documented hole for Cowork sessions specifically, and data exports through that same pipeline won’t include Cowork activity either.
It’s not the whole picture. The same documentation states that Team and Enterprise plan owners can stream Cowork events to a SIEM or observability tool through OpenTelemetry. That’s a real, Anthropic-built export path, not a third-party workaround. A security team that hasn’t configured it before rollout has the same practical blind spot as one working with no export option at all, but the two situations are different problems: one is “the capability doesn’t exist,” the other is “the capability exists and wasn’t turned on.” Content that states the compliance gap as absolute, without this distinction, is describing last year’s product or an incomplete read of the current one.
Data retention for conversation history is worth the same precision. With cloud execution as the current default, Cowork’s own documentation states that work the agent does, including local files it opens through the desktop app, is processed on Anthropic’s servers rather than staying on the user’s machine. That cuts against any claim that conversation history is simply stored locally by default; whether it’s retained, and for how long, is governed by the plan’s data handling terms, not by the machine the desktop app happens to run on.
Best Practices for Access Control When Connecting Claude to Enterprise Systems
Grant access to a dedicated working folder rather than broad directory access, and apply least privilege to that grant specifically; excessive permissions have severe consequences precisely because the agent, once it has broad access to sensitive data, can’t be relied on to self-limit under a successful injection. Vet every MCP server before connecting Claude to it, the same way a team would vet a new software dependency, since a connector’s trustworthiness at install time is the only guarantee Cowork’s own architecture provides. Disable web search for users who don’t need it, since network egress permissions don’t gate the web fetch, web search, or MCP tool paths the same way they gate file access. Use a separate, managed browser profile for Claude in Chrome rather than a personal one signed into confidential data sources, given the session-cookie inheritance risk described above. Implement tenant restrictions so employees can’t route Cowork traffic through personal Claude accounts on corporate networks, which closes an entire shadow-AI path rather than one specific technique. Monitor scheduled task creation as a high-priority security event rather than a routine one, since scheduled tasks run unattended and Anthropic’s own guidance singles them out for extra caution precisely because nobody is watching in real time when they execute. And maintain human oversight on consequential write actions specifically; it’s the one control that reduces the impact of a mistake after every other layer has already been bypassed, rather than one that tries to prevent the bypass in the first place.
None of this is specific to Obot, and it shouldn’t be. It’s what Anthropic’s own documentation and the independent research above already point toward. What it doesn’t cover is the connector layer, which is where the controls in the Obot section above come in.
FAQs
Is Claude Cowork safe to use?
Anthropic has built real safeguards, RL training against malicious instructions, content classifiers on untrusted input, action screening, and mandatory permission prompts for deletion, and states plainly that attack risk remains non-zero. Two documented incidents in 2026, a sandbox escape and a file exfiltration bug, show that risk is not theoretical, and Anthropic’s own published 11.2% residual prompt injection rate for the browser surface confirms the risk is measurable, not hypothetical.
Can Obot secure Claude Cowork?
Not Cowork itself. Obot doesn’t change Cowork’s sandbox, browser automation, or computer-use permissions. It governs the MCP connectors Cowork uses: Obot MCP Gateway controls which servers are approved and logs every tool call, and Obot Sentry inventories the MCP servers and plugins installed on employee machines.
What was the Claude Cowork sandbox escape vulnerability?
Disclosed July 23, 2026 by Accomplish AI and codenamed SharedRoot, it affected local Cowork sessions on macOS, where the entire host filesystem was mounted read-write into the agent’s Linux VM. Exploiting a kernel bug (CVE-2026-46331) let the agent obtain guest-root and read or write files anywhere on the host, with no permission prompt. Anthropic closed the report without a fix for local sessions; the current default of cloud execution avoids the issue.
What was the Claude Cowork file exfiltration vulnerability?
PromptArmor disclosed it in mid-January 2026: a hidden prompt injection in a disguised document caused Cowork to upload a user’s file to an attacker’s Anthropic account via the Files API, exploiting the fact that Anthropic’s own API domain was allowlisted in the execution environment’s egress restrictions.
How risky is browser automation with Claude in Chrome?
By Anthropic’s own published figures, prompt injection succeeded 23.6% of the time before mitigations and 11.2% with current defenses in place. Independent researchers have separately shown session-cookie inheritance and unencrypted local credential storage in the extension, which is why a dedicated, managed browser profile is a meaningfully different risk posture than a personal one.
Does Cowork activity show up in compliance and audit logs?
Not through the Compliance API, which Anthropic’s own documentation states does not capture Cowork activity. Team and Enterprise plan owners can export Cowork events to a SIEM through OpenTelemetry, which is a real, documented path, but it has to be configured; it isn’t automatic.
Is Claude Cowork a local agent running on my machine?
It depends on the execution mode. Cloud execution, the current default, runs Claude’s work in an isolated, temporary environment on Anthropic’s servers, reaching local files and the browser only through the desktop app. Local execution on macOS runs the agent inside a Linux VM directly on the host, which is the mode SharedRoot exploited.
Do the Claude Code vulnerabilities (CVE-2025-59536) affect Cowork?
No. Those were configuration-based code injection and API key exfiltration flaws specific to Claude Code’s project trust dialog and MCP setup, patched months before SharedRoot was disclosed. They’re relevant as evidence of a recurring pattern across Anthropic’s agentic products, not as a Cowork-specific vulnerability.
What is the biggest enterprise risk with Cowork’s MCP connectors?
Anthropic’s own guidance states that each installed MCP server or plugin introduces a new path for an attack to reach Claude, and there’s no Anthropic-native centralized view of what’s installed and what it can reach across an organization’s Cowork users. That visibility gap, not any single vulnerability, is the recurring enterprise exposure.
