The limit matters as much as the feature. The sensor only covers Cowork sessions that run on the user's own PC. Sessions in Anthropic's cloud are not covered.
The blind spot this closes
Anthropic's Cowork architecture documentation explains how local sessions work. Shell commands and any code Claude writes execute inside a dedicated Linux VM, isolated from the host operating system by the platform's hypervisor (Apple Virtualization.framework on macOS, Hyper-V on Windows). The VM enforces its own network egress filtering, syscall restrictions, and per-session user isolation.
For a Windows shop, that means Cowork's commands run in a Linux guest on Hyper-V-based virtualization. They do not run as ordinary Windows processes that a host agent can watch. Anthropic says so directly: the VM is isolated from host-based security tools by design, so an EDR sensor on the host can't see inside it.
That is fine until a security team needs to know which commands an AI agent ran against which files. Now the answer can show up in the console they already use.
Summary: Cowork's sandbox protected the host but hid the agent's actions from host security tools. The beta puts a sensor inside the sandbox.
How the sensor gets into the VM
Anthropic's help documentation describes a signed, policy-driven install:
- The VM starts. This usually happens when a user first opens Cowork, and the VM keeps running until Claude quits or the user signs out.
- Claude Desktop copies in the package. Each time the Cowork VM starts, Claude Desktop copies the configured sensor package into it.
- The signature is checked. Claude Desktop verifies its signature against that vendor's approved signing key. Claude Desktop rejects packages lacking an approved vendor signature.
- The vendor's script runs. If validation succeeds, Claude runs the vendor's installation script, at most once per VM startup. If no policy is configured, nothing is installed.
- Telemetry goes out. The installed sensor connects to its vendor's cloud and reports activity. Anthropic warns that this traffic can leave the VM outside Cowork's network allowlist. Your egress rules need to allow for it.
Anthropic currently lists seven approved vendors: CrowdStrike, Evoke Security, Neo, Palo Alto Networks, Pluto Security, SentinelOne and Tanium. Vendors that aren't listed can apply to join. Customers with an Anthropic account team can also ask through that team.
Windows requirements and deployment
Anthropic's requirements apply to Windows and macOS. On Windows, they are specific:
| Requirement | Windows | macOS |
|---|---|---|
| Plan | Team or Enterprise (beta) | Team or Enterprise (beta) |
| Claude Desktop version | 4.4212.0 or later, MSIX build | 4.4212.0 or later |
| OS | Windows 10 or Windows 11 | Not specified beyond app version |
| Platform features | Hardware virtualization + Virtual Machine Platform enabled | — |
| Policy delivery | Registry policy (e.g., Group Policy or Intune) | MDM tool |
The feature also covers Claude Desktop connected to Amazon Bedrock, Google Cloud Vertex AI or Microsoft Foundry. Organizations that run Claude through Azure's Foundry are included.
A few practical points for Windows admins:
- Check the installer type first. The requirement is the MSIX build, so devices running another packaging of Claude Desktop don't qualify yet.
- Turn on virtualization at both levels. Hardware virtualization has to be enabled in firmware, and the Virtual Machine Platform optional feature has to be on in Windows. Without them, the local Cowork VM can't start, so no sensor gets installed.
- Your EDR vendor supplies the configuration. Anthropic doesn't publish one universal policy. Each vendor provides its own files and instructions. Don't guess at registry values. Get the package and the policy settings from your vendor.
Summary: For Windows, you need the MSIX build of Claude Desktop 4.4212.0 or later, virtualization turned on, and the vendor's package deployed through Group Policy or Intune.
The cloud gap
This is where expectations need adjusting. Anthropic's Team and Enterprise documentation says the EDR option is in beta on macOS and Windows, and it doesn't cover sessions in the cloud. The architecture page adds that sessions in the cloud run entirely outside your endpoints, so EDR tools can't observe them.
Anthropic's new unified Claude experience makes this more pressing. According to Anthropic's admin documentation, that experience starts as a chat and moves into a Cowork cloud session when a task needs agentic work. In that mode, each conversation that needs one gets its own virtual machine, managed by Anthropic. The same page says plainly that the EDR setting doesn't cover the cloud sandbox, because Anthropic manages that virtual machine. It also says the unified experience is meant to replace both Cowork and Cowork in the cloud over time.
So if your organization turns on the unified experience, more agent work may move to infrastructure your sensor can't reach. This is my inference from Anthropic's descriptions, not a figure Anthropic has published. Anthropic gives its own warning: if your compliance posture depends on endpoint visibility, account for this before rolling out Cowork. The architecture page also mentions OpenTelemetry-based activity monitoring as a separate option. Teams that need some visibility into cloud sessions should look at it.
Privacy: your SOC now holds prompt data
EDR sensors are built to see a lot, and this one can see Cowork content. In Anthropic's words, the sensor can see activity and content inside the VM, prompts, files, Claude responses, and other content, and that data goes to the EDR vendor, not Anthropic.
The contract terms matter here. Anthropic's terms say your organization chooses the vendor and uses the EDR software under its own agreement with that vendor. The software counts as a third-party feature, not part of Anthropic's services. The vendor doesn't handle the data on Anthropic's behalf.
The Automation Labs newsletter offered sensible advice for security leads: treat the sensor as a new data processor. It also suggested limiting who can read Cowork telemetry in the EDR console, because the SOC will now hold the prompts staff run in desktop Cowork. If your EDR console is open to a large MSSP team, your legal and privacy people should hear about it before the pilot starts.
Lifecycle details that can catch you out
Anthropic's help page lists several operational points to plan for:
- Removing the policy doesn't uninstall the sensor. Removing management settings stops future package execution but does not uninstall an existing sensor. Your offboarding plan should not assume that deleting the policy cleans up the VM.
- Signatures expire. Package signatures exclude subsequent sensor-downloaded updates and expire within two years, requiring re-signed packages. Put a renewal date on the calendar, or you'll find out when installs start failing.
- Testing is your responsibility. Anthropic also requires customers to test the software before deployment and after Claude or sensor updates. Its terms say it isn't responsible for claims that arise from a failure to test.
- Cost. Anthropic charges nothing extra during the beta, but your EDR vendor may charge for the sensor.
For a pilot, Automation Labs suggested a simple check. On a pilot seat, have Cowork create a file named edr-canary.txt. Then confirm the file creation appears in the EDR console. That is a third-party suggestion, not an Anthropic procedure, but it's a quick way to see whether telemetry is actually arriving.
Vendor support is still uneven
Being on Anthropic's approved list doesn't mean every vendor's product is ready. Palo Alto Networks announced its Cortex XDR integration with Claude Cowork on November 2. It said the integration would track accessed systems, file changes and executed commands inside the VM, and that it will be in private preview "in the coming months." Ask your own vendor what is available now and what is still roadmap before you schedule a rollout.
Analysis: a real step, with clear limits
Credit where it's due. Anthropic didn't weaken the sandbox. It built a signed, vendor-verified way to put a trusted sensor inside it. That beats the two obvious bad options: weakening the isolation, or asking security teams to trust the agent without visibility.
The limits are just as clear:
- Only local sessions are covered. Cloud and unified-experience sessions are outside EDR reach.
- It's a beta, and vendor readiness varies.
- Sensitive data goes somewhere new. Prompts and files now flow to your EDR vendor.
- Signature expiry and leftover sensors add maintenance work.
For Windows admins who already run Hyper-V-based workloads, deploy MSIX apps and use Intune, the mechanics will feel familiar. The harder questions are about policy. Which Cowork tasks are allowed to run in the cloud, where your sensor can't follow? And who in your organization should be able to read AI prompt telemetry?
Summary: If you allow Cowork on Windows endpoints, the beta is worth piloting. Plan for the cloud sessions it can't see, and get your vendor's package and data terms before you start.