Short answer: Claude Cowork can access the workspace folder you connect, the apps and browser session on your screen, the web, and any connectors or Model Context Protocol (MCP) servers you add (Anthropic, 2026). It uses a split local design: the agent loop, connected-folder file access, web fetches, and local MCP servers run natively on your device, while shell commands and code execution run in an isolated virtual machine (VM). For enterprises the risk is not only which files it reads. It is what Cowork can send, what tools it can invoke, and what audit evidence remains afterward. Aurascape helps security teams discover local AI agents, govern those interactions inline, control MCP and tool execution, and keep reviewable records.

Last updated: June 2026.

What Claude Cowork can reach on your computer

Claude Cowork is not just a chatbot that answers questions. It is an agent that can take actions on your machine. Adoption is what makes the access question urgent: AI is now in 88% of organizations (Stanford HAI, 2026), and a growing share of that use acts on local data. Anthropic states that Cowork works on your computer with access to your files, browser, connected services, and apps, and that when something goes wrong the impact depends on two things: what Claude can read and see, and what Claude is allowed to do. This article covers the data-access question; for the broader operational picture, see the risks of using Claude Cowork at work.

In practice, the access surface includes the workspace folder you grant it, code that runs inside its VM, the web through the Claude in Chrome connector using your authenticated session, local and remote MCP servers, business connectors, scheduled tasks, and direct control of on-screen applications. Each of those is a separate grant. The folder is the floor; everything you connect raises the ceiling. For how that access model compares with Anthropic’s other agent clients, see Claude Code vs Claude Cowork vs Claude Desktop.

How Cowork is contained: a split local design, not one sandbox

The common shorthand that Cowork runs inside a VM is only half right, and the half it gets wrong matters for data access. Cowork uses two execution environments on the device (Anthropic, 2026). The agent loop runs natively on your machine: conversation handling, file reads and writes in connected folders, web fetches, and local plugin MCP servers, all gated by an application-layer permission system that enforces your connected-folder rules and your organization’s network egress settings. Only code execution and shell commands run inside an isolated Linux VM on the platform hypervisor (Apple Virtualization framework on macOS, Hyper-V on Windows), which enforces its own egress filtering, syscall restrictions, and per-session isolation.

So the VM caps the blast radius of code Claude writes and runs; it is not the boundary for file access. Anthropic confirms the split plainly: if the VM cannot start, Cowork keeps running its file and web tools while only code execution reports as unavailable. Anthropic also notes that local MCP servers were moved outside the VM to run on the host the same way they do in Claude Desktop, leaving admins to decide which local servers to enable, so they execute with your operating-system permissions rather than under VM isolation (Anthropic, 2026). Credentials stay in the host keychain and never enter the guest VM, which holds only a per-session, scoped-down token that can be revoked on its own.

What constrains file access, then, is the connected-folder permission system, not the sandbox. You choose which folder Cowork connects to and how far it can act inside it. Anthropic offers three file-access modes, and enterprise admins can pin scope with mount-path allowlists in mobile device management (MDM) settings, disable local MCP servers and desktop extensions, and gate Cowork for the whole organization.

Connectors and MCP servers are where the reach actually grows

Cowork’s reach grows fastest through what you connect to it, and connected tools tend to inherit your own permissions. Because a local MCP server runs on the host with your operating-system permissions rather than inside the VM, it can operate outside Cowork’s connected-folder boundary if the server’s code and permissions allow. Treat each enabled local MCP server as endpoint software you are approving, not just a Cowork setting. Remote connectors raise a different problem: an audited connector is not the same as audited data, and a hosted connector can change behavior after you approve it, so your install-time trust may no longer apply.

OWASP names this class of risk Excessive Agency, listed as LLM06 in its Top 10 for LLM Applications (OWASP, 2025): harm that follows from giving an agent more capability, autonomy, or permission than the task needs. The browser connector compounds it, because Cowork browses with your logged-in session, inheriting whatever you are authenticated to. Treat every connector and MCP server as a vendor you are onboarding, and grant the least access each task needs.

A file in the folder can carry instructions, not just data

Anything Cowork reads can try to steer it, which makes prompt injection a top risk for any agent that processes outside content. Anthropic frames it precisely: an injection succeeds only when two conditions hold at once, that Claude can read content outside your trusted boundary and that it can take an action able to compromise you. OWASP ranks Prompt Injection as LLM01, the first risk in its Top 10 for LLM Applications (OWASP, 2025).

Anthropic has documented a concrete case it received through disclosure: a malicious file placed in a mounted workspace carried hidden instructions and an attacker-controlled API key, and Claude followed them, read other files, and uploaded them to the attacker account through an allowed domain. Anthropic fixed it with a defensive proxy inside the VM that passes only requests carrying the VM session token. The lesson generalizes: an egress allowlist is a capability grant, not just a destination filter, and once a poisoned input steers the agent, the log shows a successful, authorized action with no obvious signal to find.

What your security team can see, and what it still cannot

Cowork can be monitored more closely than many teams assume, but visibility is not the same as control. On Team and Enterprise plans, OpenTelemetry can stream a real-time, structured feed of Cowork events into your security information and event management (SIEM) system: user prompts, every tool and MCP invocation, the file paths Claude reads or modifies, which skills and plugins run, and each human approval decision, all linked by a shared prompt identifier (Anthropic, 2026). That is a strong observability story, with two limits worth stating plainly. It is off by default and requires an administrator to configure it on a recent desktop version, so personal Pro or Max use produces none of this organization-managed telemetry. And it records what happened; it does not allow, coach, warn, block, or redact at the moment of action.

Two gaps sit underneath that telemetry. Cowork activity is not captured in Anthropic’s Compliance API, audit logs, or data exports, so the compliance system of record does not see it; the OpenTelemetry events carry a user identifier you can use to correlate back to Compliance API records, but the stream is operational telemetry, not the compliance audit trail. And host endpoint detection and response (EDR) cannot inspect inside the VM, because from the host the VM is an opaque hypervisor process. Monitoring sees the activity; it does not govern what the agent does next.

The inventory problem comes first. Only 21% of organizations maintain a real-time inventory of their active AI agents (Cloud Security Alliance, 2026), so a local client like Cowork tends to arrive faster than security teams catalog it. And the risk is rarely a sophisticated attacker. It is ordinary, ungoverned use that no one is positioned to see in the moment, which is exactly what interaction-level control is built to catch before data leaves.

Answering the access question fully means answering an evidence question too. A complete interaction record should be able to show:

How to let employees use Claude Cowork without losing control

Govern Cowork at the AI interaction, where what it reads, what it sends, and what tools it calls all become visible. A practical sequence:

1. Start with AI discovery: inventory where Cowork and other local AI agents already run across your endpoints before setting policy.
2. Scope the workspace to least privilege: prefer read-only or read-write-no-delete for sensitive folders, and pin mount paths through MDM.
3. Govern connectors and local MCP servers with an allowlist, and review each one like a third-party vendor before enabling it.
4. Enforce the approved enterprise tenant and block personal accounts, so sanctioned use is governed and personal use is not a side door.
5. Put an inline control point in front of both the intelligence channel and the tool-execution channel of the two-channel agentic AI security architecture: classify sensitive data, and apply policy as the interaction happens.
6. Layer inline control over native telemetry: OpenTelemetry can stream Cowork events to your SIEM on Team and Enterprise, but add an interaction-level control point so policy applies before data leaves, not only after it is logged.

This is where Aurascape fits. Native telemetry shows teams what happened once it is configured; what enterprises still need is inline control over what data leaves, which tenant is in use, and which tools an agent can invoke. Aurascape discovers and secures local AI agents and their interactions across the network, endpoint, and application programming interface (API) planes, including local agents that network-only and identity-only tools miss (Aurascape, 2026). Its patented AI discovery recognizes new AI tools as they launch, so emerging usage is governed before it becomes unmanaged. At the interaction it can allow, coach, warn, block, or redact, classifying sensitive data across more than 600 categories (Aurascape, 2026) and keeping interaction records for audit and effectiveness, governed by role-based access control (RBAC) for privacy. For MCP-connected workflows, the Zero-Bypass MCP Gateway signs approved tool calls and blocks unsigned ones (Aurascape, 2026), giving teams control over the tool-execution path rather than only after-the-fact visibility.

These controls do not replace your endpoint, network, or data-loss-prevention stack. Aurascape stays additive to an existing secure service edge (SSE), data loss prevention (DLP), and secure web gateway (SWG) deployment, with no rip-and-replace, and it governs sanctioned, licensed tools as well as shadow usage through Intentions and entitlement, allowing the approved tenant while controlling what each user can do inside it. Here is a side-by-side comparison of where each control layer operates for a local agent like Cowork.

Frequently asked questions

Can Claude Cowork access files outside the folder I select?

Not by default. Cowork reads and writes only inside the workspace folder you connect and its .claude folder, and that access is governed by an application-layer permission system rather than by the VM, which contains code execution. Your credentials stay in the host keychain. Adding connectors, local MCP servers, the browser connector, or computer use extends its reach beyond that folder, which is why the folder grant is only the starting point.

Can Claude Cowork read my passwords or credentials?

Credentials kept in the host keychain do not enter the Cowork VM. The practical exceptions are reach you add yourself: computer use can interact with any application open on your screen, including a password manager, without the permission checks that gate other Cowork tools, and a local MCP server runs with your own operating-system permissions. Keep sensitive applications out of the workspace and off the screen during a session.

Does Claude Cowork keep an audit log my security team can review?

Not in the compliance system of record. Anthropic states that Cowork activity is not captured in the Compliance API, audit logs, or data exports. On Team and Enterprise, OpenTelemetry can stream a real-time feed of prompts, tool and MCP calls, file access, and approval decisions to your SIEM, but that is operational telemetry, not the compliance audit trail, and host EDR cannot see inside the VM. Inline, reviewable records come from a control layer that sits in the AI interaction itself.

How do we let employees use Claude Cowork without exposing company data?

Govern it at the interaction rather than at the destination. Discover where Cowork runs, scope what it can touch, allowlist its connectors and MCP servers, enforce the enterprise tenant, classify sensitive data inline, and keep reviewable records. Aurascape applies that model to Cowork and other local AI agents so data stays protected and risk is minimized as adoption grows.

Aurascape answers the access question that decides whether Cowork is safe to approve: it discovers local AI agents on your endpoints, decodes what they read and send, governs their MCP tool calls inline, and keeps interaction records your security and compliance teams can actually use, all while staying additive to the stack you already run. The result is faster, governed AI adoption instead of a blanket block.

See how Aurascape governs Claude Cowork and other local AI agents →