Claude Cowork vs Claude Code: Security Differences for Enterprise

Anthropic positions Claude Cowork as bringing "the same agentic architecture that powers Claude Code" into Claude Desktop for knowledge work. The agent loop is shared. The enterprise control story is not.
This guide is a decision framework for security teams that need to deploy one, the other, or both. We compared the two products axis-by-axis against Anthropic's own documentation. Where there is a verbatim quote that decides the question, we cite it directly.
TL;DR — Cowork vs Code
- Same agent loop, different blast radius. Cowork brings Code's architecture into the desktop and adds browser, computer use, plugins, scheduled tasks, and mobile dispatch. The threat surface is materially larger.
- Claude Code has an OS-level sandbox; Cowork's computer-use path does not. Code uses
bubblewrapon Linux andseatbelton macOS. Cowork's code execution runs in a VM, but Anthropic states there is "no sandbox between Claude and what's on your screen" for the computer-use path. - Code's enterprise controls are documented and granular.
managed-mcp.json,allowedMcpServers/deniedMcpServerspolicy files,HTTP_PROXY/NODE_EXTRA_CA_CERTS, ConfigChange hooks, OpenTelemetry, Enterprise-plan audit logs. - Cowork is explicitly out of scope for regulated workloads per Anthropic's own safety doc until you add an external control plane.
- Different lanes. Code for engineering workloads bounded by a repository. Cowork for general knowledge work behind a proxy plus policy layer.
Same architecture, different products
Cowork and Code share the planning loop, sub-agent delegation, tool selection, and permission scaffolding. What differs is what each product can reach and what enterprise controls Anthropic ships around it.
Claude Code's surface is bounded: source files in the working directory, the shell, MCP servers configured through settings files, an optional Chrome bridge, an optional cloud VM ("Claude Code on the web"), and Remote Control sessions that connect a hosted UI back to a local Code process.
Claude Cowork's surface is broader by design: local files in granted folders, browsing sessions through Claude in Chrome, computer use on host applications, plugins that bundle skills + connectors + sub-agents, scheduled tasks that run on a cadence, projects with persistent memory, and mobile dispatch for assigning tasks remotely.
The question for security teams is not "which product is safer?" It is "which controls does each ship, and where do you have to fill the gap yourself?"
The sandbox delta
Claude Code's sandbox model. Anthropic's engineering writeup on Claude Code sandboxing describes two boundaries — filesystem and network — and is explicit that "effective sandboxing requires both." Implementation is OS-primitive: bubblewrap on Linux, seatbelt on macOS. Write access is strictly confined to the working directory and its subfolders; reads can extend to parent directories where useful for dependencies. Network egress is mediated by a proxy that enforces domain restrictions and surfaces user prompts on new connections. Anthropic claims sandboxing reduces permission prompts by 84% in internal usage. Web fetch additionally uses an isolated context window so that prompt-injection content from fetched pages cannot poison the main session.
Claude Cowork's sandbox model. Anthropic's "Use Claude Cowork safely" doc describes three protective layers: code execution runs in a virtual machine, file access is scoped to folders the user grants, and deletion of files requires explicit permission. So far, comparable to Code.
Then the same doc says, plainly: there is "no sandbox between Claude and what's on your screen" when computer use is enabled. App-permission prompts and sensitive-app blocklists exist as coarse backstops, but the path that lets Claude click, type, and read pixels on the host has no execution-level isolation by design.
The structural difference is straightforward. Code's sandbox covers the only path Code has. Cowork's sandbox covers code execution, but the computer-use path bypasses it entirely — and Anthropic acknowledges this in their own documentation. That is the security reality enterprise architects need to model around.
The network and TLS-inspection delta
Claude Code's network story is well-documented. The corporate-proxy doc explicitly supports HTTP_PROXY, HTTPS_PROXY, and NO_PROXY. Custom CA certificates are trusted via NODE_EXTRA_CA_CERTS. SOCKS proxies are not supported. The cloud-execution path uses isolated Anthropic-managed VMs with their own network access controls. Remote Control sessions move data over TLS using multiple short-lived, narrowly scoped credentials. WebDAV is explicitly flagged as a Windows risk. Each path is named, and each path has documented behavior.
Claude Cowork's network story is less complete. Anthropic's Cowork doc says network access "follows the egress settings you've configured." It then carries an important caveat in the same paragraph: "Network egress permissions don't apply to the web fetch or web search tools or MCPs."
That sentence is the entire point. The documented egress controls cover some paths but not the ones most relevant to the prompt-injection attack surface — web content the agent reads, and MCP connectors that originate from Anthropic infrastructure rather than the local device.
A complete Cowork deployment has to validate each flow independently: native agent loop, code VM egress, the Chrome bridge, the user's browsing traffic, local MCP/plugin servers, computer-use app traffic, and remote MCP connector traffic. Code's deployment story collapses most of these into one well-documented proxy configuration. Cowork's deployment story spreads them across at least seven flows, only some of which the user's proxy can see. We covered each flow individually in our Cowork deployment guide.
The audit-log gap (the killer differentiator)
This is the section that decides where each product can live in a regulated organization.
Claude Code on the Enterprise plan captures user authentication events, conversation initiation and termination, tool-use actions, and administrative changes through audit logs. The Compliance API provides programmatic access to activity logs, chat histories, and file content with filtering by user and time range, plus selective deletion. Cloud execution adds: "all operations in cloud environments are logged for compliance and audit purposes." ConfigChange hooks catch settings drift mid-session. OpenTelemetry metrics provide ongoing usage signals. SSO, SCIM, DPA, and HIPAA BAA are available.
Claude Cowork:
Team and Enterprise admins can stream some Cowork events via OpenTelemetry, but Anthropic explicitly says this is "not a replacement for audit logging." Mobile dispatch and scheduled tasks add asynchronous activity that may not be visible in any console at all. We covered the full audit story across products in How to Audit Claude with the Compliance API.
The decision boundary writes itself. If the workload touches HIPAA, GLBA, SOX, PCI, or anything subject to a SOC 2 audit, Cowork is unsuitable today — until Anthropic ships parity (which they have not announced) or you wrap Cowork in your own logging pipeline through a proxy or LLM gateway. Code on the Enterprise plan, by contrast, is already in the regulated lane.
MCP and plugin control delta
Claude Code offers two MCP enforcement models per Anthropic's MCP docs: managed-mcp.json for exclusive control (users cannot add anything outside the file), or allowedMcpServers / deniedMcpServers policy lists for delegated control with restrictions. Each entry can match by server name, by exact command and arguments for stdio servers, or by URL pattern with wildcards for remote servers. First-time MCP servers require trust verification, with one important exception: trust verification is disabled when running with the -p flag for non-interactive use. That non-interactive bypass is worth flagging in your CI/CD pipeline review.
Claude Cowork treats the unit of distribution as a plugin — a bundle of skills, connectors, and sub-agents. Installing one plugin can add prompts, tools, and workflows simultaneously. Team and Enterprise admins can curate plugin marketplaces, but the enforcement granularity is at the marketplace level, not at the individual server name / command / URL level Code supports.
The MCP supply-chain attack surface is concrete. We demonstrated one exploit against Supabase's MCP integration where prompt injection through customer data leaked private SQL tables. The same class of attack applies to any MCP-enabled deployment. Code's policy file gives a place to enforce least-privilege on individual servers; Cowork's marketplace curation is broader and less surgical.
Decision framework
Use Claude Code, not Cowork, when:
- The workload is bounded by a code repository.
- You need TLS inspection on a documented, single proxy path.
- You need an audited, replayable record of every action.
- Regulated content (HIPAA, financial, attorney-client) is involved.
- You want managed MCP allowlists and ConfigChange hooks.
Use Cowork only after building a control plane when:
- The work spans files, browser, and apps in a way Code cannot reach.
- Computer use is genuinely required and no MCP or API alternative exists.
- You have routed Claude Desktop, the Chrome bridge, code-VM egress, and local MCP servers through an on-device proxy or LLM gateway.
- You have accepted in writing that the audit-log gap exists, and you are filling it through your own logging pipeline (OpenTelemetry stream + endpoint telemetry + browser policy logs).
- The use case explicitly excludes regulated data.
Use both:
- Engineering team on Claude Code, in repos, with
managed-mcp.jsonenforced. - Operations, GTM, and general knowledge work on Claude Cowork, behind a proxy and policy layer.
The distinction is not "Cowork is dangerous and Code is safe." It is that Anthropic ships a more complete enterprise control story for Code today, and the path to making Cowork enterprise-safe runs outside of Anthropic's product surface. We laid out that path in How to Secure Claude Cowork.
Claude Cowork vs Claude Code FAQ
Four questions on the enterprise security delta between Claude Cowork and Claude Code.
We Built The Control Plane
General Analysis has already done the implementation work for the Cowork side: an on-device proxy, an LLM gateway, hyper-fast policy guards, tool provenance, browser-use and computer-use policy, MCP controls, and the user-flow testing that keeps the agent useful while constraining its blast radius. The hard part of agent security is enforcing risky-action controls without adding latency or breaking the workflow that made the agent valuable in the first place.
Book a demo to see proxy-based policy enforcement running against real Cowork and Code workflows.
Related guides
Continue reading

PLAYBOOK
How to Secure Claude Cowork
Claude Cowork brings Claude Code-style agentic work to local files, browsers, apps, plugins, and scheduled tasks. Here is how to put a middleman proxy, browser controls, computer-use limits, and enterprise monitoring around it before using it on real work.
Read
PRIMER
MCP Server Security: A Threat Model for Agent Tool Supply Chains
The Model Context Protocol expanded what AI agents can reach, and expanded the attack surface across at least nine distinct vectors. A primary-source threat model for MCP servers, with concrete controls, real CVEs, and the GA Supabase exploit walked end to end.
Read
PRIMER
What Is AI Red Teaming? A Practitioner's Guide
AI red teaming is adversarial testing of AI systems to find exploitable vulnerabilities before attackers do. Learn how it works, key techniques, real exploit examples, and how to implement it.
Read
Newsletter
Get the next research note.
Short updates on agent attacks, red-team methods, runtime guardrails, and production AI security.
Occasional updates. Unsubscribe anytime.