Claude Cowork EDR Sensor in the Local VM: What It Sees and What It Misses

Anthropic now lets Team and Enterprise administrators run an endpoint detection and response (EDR) sensor inside the virtual machine that Claude Cowork uses to execute shell commands and code. The feature is in beta, covers macOS and Windows, and fixes a specific blind spot: a sensor on the host cannot see inside the VM. If you manage Cowork for an organization, this is the first supported way to get that activity into your existing security console. If you only use Claude Code in a terminal, it does not apply to you, but the data-flow trade-offs it exposes are worth understanding for any agent you monitor.

This post summarizes Anthropic's help-center article, explains what the sensor can and cannot cover, and lists what to check before turning it on. Cyber Security News reported the launch on November 3, 2026.

TL;DR

What problem does this solve?

Claude Cowork splits its work across two places. The agent loop and file access run on your device, while shell commands and code execution run in an isolated VM. That isolation is the point: a command run by the agent should not have free rein over your host.

The side effect is a monitoring gap. Anthropic's article states that the host's EDR sensor cannot see inside the VM. A security team that has CrowdStrike, SentinelOne or Palo Alto Networks on every laptop would see Cowork as one busy hypervisor process, with no view of the commands, scripts or network connections inside it. For an agent that can run arbitrary code at the direction of a model, that is exactly the activity a SOC wants to see.

This is the same tension we described when looking at VM sandboxes for coding agents such as Capsem: isolation limits blast radius, but it also moves the interesting events out of reach of host tooling. Anthropic's answer is to put the sensor on the inside.

How the integration works, step by step

According to Anthropic's article:

1. An admin configures it. On macOS this is done through mobile device management (MDM); on Windows through registry policy, for example Group Policy or Intune. The admin names the vendor and enables the integration. Each vendor supplies its own sensor package and setup instructions.
2. The VM starts. The VM starts when first needed, usually when a user opens Cowork, and runs until Claude quits or the user signs out.
3. Claude Desktop copies the package into the VM. This happens every time the VM starts.
4. The signature is checked. Desktop verifies the package signature against the approved key for the vendor the admin selected. A package signed by anyone else is not installed.
5. The install script runs. If validation succeeds, Claude runs the vendor's installation script, at most once per VM start.
6. The sensor reports. The installed sensor connects to its vendor's cloud and reports activity there.

Approved vendors at launch are CrowdStrike, Evoke Security, Neo, Palo Alto Networks, Pluto Security, SentinelOne and Tanium. Other vendors can apply through a form linked from the article or through an Anthropic account team.

Anthropic's enterprise configuration reference lists the managed settings for this feature as coworkEDRIntegration (the full path to the vendor's signed sensor package) and coworkEDRIntegrationVendor (the lowercase vendor ID); on Windows they live under the machine-wide policies registry path for Claude. The EDR article itself does not spell out key names, so use the enterprise configuration page and your vendor's instructions rather than copying names from a news summary.

Requirements

• macOS: Claude Desktop 4.4212.0 or later.
• Windows: the MSIX build of Claude Desktop, 4.4212.0 or later, on Windows 10 or 11, with hardware virtualization and the Virtual Machine Platform feature enabled.
• Device management: an MDM tool on macOS, or registry policy on Windows.
• Plan: Team or Enterprise.

To check the version on a machine, open Claude Desktop's About or version screen. If your fleet is mixed, this requirement is the first thing that will quietly leave some laptops uncovered.

Where the sensor's data goes

This is the part to read twice. Anthropic's article says the sensor can see activity and content in the VM, including prompts, files and Claude's responses. That data goes to the EDR vendor. Anthropic says it does not receive or control it, and the vendor does not process it on Anthropic's behalf.

Two consequences follow:

• Your EDR vendor becomes a recipient of prompts and file contents. If Cowork touches customer data, source code or credentials, that content may now sit in a second vendor's cloud. Your data-protection review of the EDR contract needs to cover this new class of content, which classic endpoint telemetry (process names, hashes, connections) did not.
• The sensor's traffic bypasses the Cowork network allowlist. Anthropic states the sensor can send telemetry out of the VM outside the allowlist that otherwise constrains what Cowork can reach. If your threat model relies on that allowlist as an egress control, the sensor is a deliberate hole in it. It is a vendor-signed one, but it is a hole.

Anthropic also frames the legal side clearly: the EDR software is a third-party feature under your Anthropic agreement, not part of Anthropic's services, and your organization is responsible for it and for testing it.

What stays uncovered

The limits are as important as the feature:

• Cloud sessions. Cowork sessions hosted on Anthropic's servers are out of scope; you cannot install a sensor there.
• Host-side activity. The sensor sits in the VM. The agent loop, connected-folder file access and anything running natively on the device remain the job of your host EDR. Anthropic's article says the sensor covers the local VM only; check the Cowork architecture overview for what runs outside it.
• Sensor updates. Package signatures cover the package file only, not updates the sensor downloads later. Your vendor maintains the package.
• Signature expiry. Signatures expire within two years. You must deploy a re-signed package from your vendor before then, or the integration stops installing.
• Removal. Removing the MDM or registry settings does not uninstall an installed sensor. Claude just stops running the package on later VM starts.
• It is detection, not prevention. An EDR sensor reports and may alert or contain according to the vendor's policy. It does not change what Cowork is permitted to do.

It also should not be confused with a vulnerability fix. The reporting that accompanied the launch notes that this is not a fix for an earlier Cowork sandbox flaw (a Windows attack chain to root inside the Linux sandbox); this feature is monitoring, not a patch for that issue.

What this means if you run AI coding agents

If you administer Cowork for a team, a practical checklist:

1. Decide whether VM-level visibility is worth the data flow. Ask your EDR vendor, in writing, how long they retain prompt and file content from the sensor, who can query it, and whether it can be disabled per field.
2. Pilot before rollout. Anthropic makes testing your organization's responsibility, before deployment and after every Claude or sensor update. Build a small ring of machines, run a typical Cowork task and confirm alerts appear in the console.
3. Verify the minimum version everywhere. Inventory Claude Desktop versions; machines below 4.4212.0 will not run the integration. On Windows confirm the MSIX build and that Virtual Machine Platform is on.
4. Calendar the signature expiry. Put a reminder well inside the two-year window to obtain a re-signed package.
5. Update your egress documentation. Record that the sensor's telemetry is outside the Cowork allowlist, so auditors do not assume the allowlist is airtight.
6. Plan offboarding. If you stop using the integration, remove the sensor yourself; clearing the policy alone leaves it in place.
7. Keep cloud and host coverage in mind. Decide separately how you will observe cloud sessions and host-side activity.

For individual developers using Claude Code or Codex rather than Cowork, the general lesson is the same one we drew when reviewing OpenTelemetry-based agent observability: the more detailed the telemetry, the more sensitive the telemetry itself becomes. Prompt and file content in a log is a secret store. The Warp vendor breach is a reminder of what happens when agent traces sit in someone else's cloud.

How Beam handles this

Beam covers a related job from a different angle. It is local, privacy-first security and observability for coding agents: it watches what Claude Code, Codex and similar agents do on your machine, flags risky actions such as credential exposure and destructive commands, scans skills and MCP configs before you run them, and keeps data on-device, with secrets redacted before storage. Nothing is sent to a vendor cloud by default, which is the main contrast with an EDR sensor shipping VM content off the device.

The limits are real. Beam's deny works through Claude Code and Codex PreToolUse hooks, not a kernel sandbox; scanning is heuristic (11 patterns plus an MCP version-pin check); and missing cached policy is fail-open. Beam's documentation does not describe Cowork's VM as a monitored surface, so do not read this as a Cowork replacement or as a substitute for enterprise EDR. See what Beam watches and how it works.

Related reading

• CrowdStrike Falcon Guardian AI Kill Switch: what it stops and what it cannot
• Capsem: a VM sandbox for AI coding agents, and how it compares to Beam
• OpenTelemetry for AI agent observability and prompt capture
• Warp vendor breach: agent traces and telemetry, claimed vs verified
• Google's microVM sandbox with no credentials inside
• Claude Code Desktop preview pane exfiltration
• Primary source: Anthropic help center, EDR sensor in Claude Cowork

Frequently asked questions

Why could host EDR not see Claude Cowork activity before?

Cowork runs shell commands and code inside an isolated virtual machine. From the host, that VM is an opaque process, so the host EDR sensor cannot inspect the commands and files inside it. Anthropic added the integration to close that gap.

Which EDR vendors are supported?

Anthropic lists CrowdStrike, Evoke Security, Neo, Palo Alto Networks, Pluto Security, SentinelOne and Tanium. Only a package signed with the approved key of the vendor you configure is installed. Other vendors can apply through Anthropic.

Does the sensor cover every Cowork session?

No. It covers only the local VM on a user's computer, on macOS and Windows with Claude Desktop 4.4212.0 or later. Cloud Cowork sessions run on Anthropic's servers, where you cannot install a sensor.

Where does the sensor data go?

To the EDR vendor, not Anthropic. Anthropic says the sensor can see prompts, files and Claude's responses in the VM, and can send telemetry out of the VM outside the Cowork network allowlist. Review the vendor's data handling before enabling it.

Does removing the setting uninstall the sensor?

No. Removing the managed setting only stops Claude from running the package at later VM starts. An already installed sensor stays until you remove it.

Is this a fix for a Cowork vulnerability?

No. It is a monitoring feature, not a patch. It adds visibility; it does not change what the agent is allowed to do inside the VM.

Details reflect Anthropic's documentation and press reporting as of November 3, 2026. The integration is in beta and may change; check the help-center article before deploying.