Securing Claude Cowork: A Security Practitioner’s Guide

‍

‍Last updated: May 20th 2026

‍
‍

1. TL;DR: The 15 Things That Matter

‍

If you read nothing else, know these twelve things before enabling Claude Cowork for your organization.

‍

1. Cowork is not a chatbot. It runs code in a VM on the user's machine, reads/writes local files, browses the web with the user's session cookies, and can execute scheduled tasks unattended.

2. OpenTelemetry is your best current visibility tool but it's imperfect. It provides usage metrics, cost data, and tool activity. It lacks some capabilities that you might expect from the Compliance API, but it is possible to track usage. Route it to your SIEM immediately. Cowork activity is explicitly excluded from all three: Audit Logs, Compliance API, and Data Exports.

3. Prompt injection is the #1 risk. Anthropic self-reports ~1% attack success rate on Claude in Chrome even after mitigations. Hidden instructions in web pages, emails, or documents can hijack Claude's actions.

4. Chrome is high-risk. Claude in Chrome screenshots your active tab, clicks buttons, fills forms, and executes JavaScript. Default blocked categories: financial services, banking, investment platforms, crypto exchanges, adult content, pirated content. Healthcare and internal tools are NOT blocked by default.

5. Conversation history is local-only. Stored on the user's machine. Not subject to Anthropic's retention policies. Cannot be centrally managed or exported by admins.

6. Plugins are powerful and risky. Each plugin bundles skills, connectors, agents, and hooks. Skills are task-specific instruction files; connectors give Claude access to external services (Slack, Notion, Google Drive, etc.); agents are specialised sub-agents; hooks are scripts that execute at defined points in a session. Installing a plugin significantly expands Claude's scope of action. Treat them like software dependencies.

7. MCP servers run with system-level access. Local MCP servers (stdio transport) may have excessive access to the machine. Remote servers (HTTP/SSE) require authentication but introduce network attack surface. Known supply chain CVEs exist (CVE-2025-59536, CVE-2026-21852).

8. Scheduled tasks run unattended. They execute while the desktop app is open but the user may not be watching. A prompt injection in a scheduled task — delivered via a poisoned data source the task reads — can execute silently and repeatedly. Keep Awake is a scheduled task setting (not Dispatch) that prevents the machine from sleeping so tasks run overnight; on macOS this uses caffeinate, which may override MDM sleep policies.

9. The org-level toggle is a prerequisite for RBAC, not a fine-grained control. Enable capabilities at org level first, then use custom roles (Enterprise) to restrict access by group. RBAC can only restrict what the org toggle has enabled — it cannot grant access to a capability the org toggle has disabled. On Team plans, the toggle remains all-or-nothing.

10. RBAC (Enterprise) now controls 14 capabilities: Chat, Cowork, Claude Code, fast mode, code execution, web search, memory, public projects, create skills, share skills (team), share skills (org), Claude for Chrome, Claude Security, and Claude Design. The correct deployment pattern: enable everything you want the company to use at org level, then restrict specific groups by assigning custom roles that disable those capabilities.

11. Dispatch is a mobile-to-desktop bridge. You send a task from the Claude mobile app; it runs on your Claude Desktop and you can check results from either device. Available on Pro, Max, and Team plans — not Enterprise. On Team plans it is admin-toggleable under Cowork settings. On Pro and Max personal accounts there is no admin toggle, so organizations with employees on personal subscriptions have no visibility or control over its use.

12. Computer Use runs outside the sandbox and is currently Pro/Max only. Computer Use lets Claude take screenshots of the desktop and interact directly with any application: clicking, typing, and navigating. Unlike normal Cowork file operations, Computer Use runs outside the VM sandbox on the user's actual desktop. It is not available on Team or Enterprise plans, but employees with personal Pro/Max accounts can use it on corporate machines unless tenant restrictions or endpoint controls prevent it. Per-app permission prompts and an app blocklist exist, but the screenshot-based approach means Claude can see anything visible on screen, including sensitive data in adjacent windows.

13. Cowork on 3P routes inference through Vertex AI, Bedrock, or a gateway you control — no conversation data reaches Anthropic (Vertex and Bedrock only; Foundry does not give this guarantee). Configured entirely via MDM (Jamf, Intune, GPO), not the claude.ai admin console. Built for regulated environments and data-residency requirements.

14. Office Agents (Claude for M365) embeds inside Excel, Word, PowerPoint, and Outlook. It is a separate product with a separate admin surface — Cowork admin settings do not apply. Outlook integration requires a one-time Microsoft Graph consent from an admin.

15. Claude in Slack operates independently of Cowork and Anthropic admin settings. Requires Slack admin approval before any user can access it. Two distinct integrations exist: Claude as a Slack bot (chat assistant), and the Slack connector for Cowork (reads your workspace from within a Cowork session). Treat each separately.

‍

‍

‍

‍

2. Pick Your Posture

Not every organization needs the same level of enablement. Based on conversations with security teams deploying Cowork today, we see three postures. Find yours and use it to scope the rest of this guide.

‍

‍

‍

2.1 Lockdown: “We’re Not Enabling Cowork Yet”

This is a valid and common posture during the research preview. But “not enabling” doesn’t mean “nothing to do.” You still need to actively prevent shadow usage and prepare for when your organization is ready.

‍

What to do right now (even if Cowork stays off)

☐ Toggle Cowork OFF: Admin Settings > Capabilities > Cowork. Do this explicitly; on Team plans it may default to on

‍

☐ Disable Claude in Chrome: Admin Settings > Claude in Chrome toggle, and/or Admin Settings > Connectors > Claude in Chrome > Toggle off

☐ Enterprise with RBAC: Even with Cowork toggled off at the org level, consider pre-building your custom roles and group structure now. When you are ready to enable, you can migrate a pilot group to 'Custom roles' before flipping the org-level Cowork toggle, ensuring only the pilot group gets access from day one. This eliminates the brief window of org-wide access that previously existed during rollout.

☐ Team / Enterprise: Disable Dispatch under Admin Settings > Capabilities > Cowork if available. Even with Cowork off, verify Dispatch is also explicitly toggled off to prevent any future accidental enablement.

‍

Prevent account switching and shadow AI (Enterprise only)

Tenant restrictions are your primary defense against employees bypassing managed controls by using personal Claude accounts. Without them, a user on your corporate network can simply switch to a personal account where Cowork, Chrome, and all plugins are fully enabled with no admin oversight.

☐ Configure tenant restrictions by having your network proxy inject the anthropic-allowed-org-ids HTTP header into all requests to claude.ai and api.anthropic.com

☐ Find your Organization UUID in Settings > Account or Admin Settings > Organization (scroll to bottom)

☐ Header format: anthropic-allowed-org-ids: <your-org-uuid> (comma-delimited for multiple orgs, no spaces)

☐ TLS inspection is required for the proxy to inject headers into HTTPS traffic

This covers web access (claude.ai), the desktop app, and API authentication. Supported proxy platforms include Zscaler ZIA, Palo Alto Prisma Access, Cato Networks, Netskope, and any HTTPS proxy with header injection.

When blocked, users see: “Access restricted by network policy. Contact IT Administrator.” with error code tenant_restriction_violation.

☐ Test by making an API call from the restricted network with your org’s key to verify the header is being injected and validated

‍

⛔ Without tenant restrictions, your admin toggles are a suggestion, not a control. A user can switch to a personal Pro/Max account on the same machine and bypass every organizational guardrail you’ve configured. This is Enterprise-only. Team plans cannot enforce tenant restrictions.

‍

Other Lockdown actions

☐ Communicate to your org: “Cowork is not approved for use. It is disabled. If you need agentic AI capabilities, here is the process for requesting access.”

☐ Monitor: even with Cowork off, users may have personal Claude accounts. Your DLP and CASB should be watching for claude.ai traffic on non-managed accounts

☐ Team plan without tenant restrictions: consider blocking claude.ai at the proxy level entirely, or use Chrome enterprise policies (GPO/MDM) to prevent the Claude in Chrome extension from being installed on managed browsers

☐ Enable OpenTelemetry anyway. It gives you baseline visibility into Chat and Code usage that you’ll want when you eventually evaluate Cowork

☐ Track Anthropic’s roadmap. The key blocker for most regulated orgs is the audit log gap. When Cowork activity is captured in the Compliance API, re-evaluate
‍

⚠ The defaults matter. On Team plans, both Cowork and Claude in Chrome are enabled by default. If you’re on a Team plan and haven’t explicitly disabled these, your users may already have access.

‍

2.2 Controlled: “Enable with Guardrails”

This is the posture most Enterprise and mature Team organizations should target. Cowork is on, but the browser, plugins, MCP servers, and connectors are tightly scoped. The second responder in the CISO thread above describes exactly this: “default sandbox blocks most network access, not allowed browser plugin, allowlisted MCP centrally.”

‍

The minimum viable secure configuration

☐ Cowork ON, Chrome extension OFF (or strict allowlist of 5-10 trusted domains)

☐ RBAC (Enterprise only): Create custom roles granting Cowork access. Assign to approved groups. Migrate members to the 'Custom roles' built-in role. Members not in a Cowork-enabled group lose access to the Cowork capability. Note: this controls access to Cowork itself, not what Cowork can do -- Chrome, plugins, MCP, connectors, and scheduled tasks are still governed by org-wide settings.

☐ Dispatch (Team / Enterprise): Toggle Dispatch on or off under Admin Settings > Capabilities > Cowork. If enabling, ensure the Keep Awake implications are understood and communicated to users (see Section 4.7).

☐ Network egress: keep defaults. The sandbox blocks most outbound traffic already. Only allowlist domains you’ve tested

☐ MCP servers: centrally allowlisted via managed-mcp.json deployed through MDM (Jamf, Intune). Users cannot add their own

☐ Connectors: admin-approved only. Prefer read-only connectors. Disable write-access connectors (send_email, post_message) unless explicitly justified

☐ Scheduled tasks: permitted but restricted to read-only tasks (summaries, reports). No tasks that send messages, make purchases, or modify external systems

☐ Global instructions: add defensive prompts (see Section 6 for recommended text)

☐ OpenTelemetry: enabled and routed to SIEM with alerting for anomalies

☐ User training: mandatory before access. Cover prompt injection, folder hygiene, incident reporting

‍

This posture gives you meaningful value from Cowork (file processing, document generation, research synthesis, data analysis) while cutting off the highest-risk attack surfaces (browser, unvetted MCP servers, uncontrolled plugins).

‍

2.3 Open: “Full Enablement with Policy”

Appropriate for innovation teams, low-sensitivity workloads, or organizations with high risk tolerance. Browser is enabled, plugins are broadly available, and users have more autonomy. Controls shift from prevention to detection and response.

‍

Key controls for the Open posture

☐ Chrome: enabled with a blocklist covering financial services, healthcare, cloud consoles, and internal admin tools. Users can access other sites

☐ Plugins: marketplace available, users can self-install. Org-level plugins auto-installed for consistency

☐ MCP servers: allowlist at org level, but users can request additions through a lightweight review process

☐ Scheduled tasks: user discretion within the acceptable use policy. Regular audit of active tasks

☐ Monitoring: OTel to SIEM with real-time alerting. Weekly review of connector usage and scheduled task patterns

☐ Incident response: users trained to stop suspicious tasks immediately. Clear escalation path documented

‍

⚠ Even in the Open posture, the audit log gap means you cannot use Cowork for regulated workloads. This posture works for productivity and knowledge work, not compliance-sensitive processing.

‍

3. What the Defaults Actually Do

Cowork’s out-of-the-box defaults are more restrictive than you might expect. But those defaults vary by plan. Understanding what’s already locked down on YOUR tier helps you focus your hardening effort on the real gaps.

‍

‍

ℹ Bottom line: Enterprise gets the best defaults (Chrome off, no-training, admin controls available). Team gets admin controls but worse defaults (Chrome on, Cowork on). Pro/Max users have no admin controls at all. Your hardening work scales inversely with your plan tier.

‍

4. Key Considerations

This section covers the essential decisions and controls for each attack surface. Use it as your planning guide before diving into the detailed checklist in Section 6.

‍

4.1 Plan Tier Determines Your Controls

Your Anthropic subscription tier dictates what security controls you can actually enforce. The gap between Enterprise and Pro/Max is significant.

‍

‍

‍

⚠ Enterprise: Chrome is disabled by default. Team: Chrome is enabled by default. This means Team admins must act immediately to configure or disable Chrome on enablement.

‍

4.2 The Audit Gap

The Compliance API (Enterprise-only, NDA required via Trust Center) provides programmatic access to activity logs, chat histories, and file content for Chat and Claude Code. It now includes audit log events. However, Cowork activity is explicitly excluded from all three: Audit Logs, Compliance API, and Data Exports.

OpenTelemetry is your best current visibility tool for Claude Cowork. It provides usage metrics, cost data, and tool activity via the Claude Agent SDK's OTel events schema. If your organization is moving quickly on Cowork adoption, getting this routed to your SIEM should be an early priority.

That said, it's not plug-and-play. Standing it up requires owning the infrastructure yourself:

• You need a running OTel-compatible endpoint or receiver to collect events
• Environment variables must be configured for both collection and privacy controls
• Monitoring must be enabled in Claude admin settings

For Cowork, prompt content is included in OTel events by default — the user_prompt event captures both prompt text and length. The OTEL_LOG_USER_PROMPTS environment variable applies to Claude Code deployments only; it has no effect on Cowork. To exclude prompt content from Cowork telemetry, configure your OTLP collector to filter or redact user_prompt events before ingestion. For Cowork on 3P, the excludePromptFromTelemetry MDM flag provides this natively. Raw file contents and code snippets are not included in telemetry events.

One thing to watch: tool execution events include bash commands and file paths in the tool_parameters field, which may contain sensitive values. If your commands could include secrets or credentials, configure your telemetry backend to filter or redact tool_parameters before the data lands in your SIEM.

Cowork OTel exports five event types: user_prompt (prompt text and length), tool_result (tool name, success/fail, duration, parameters), api_request (model, cost, token counts, speed), api_error (model, error, status code), and tool_decision (tool name, allow/reject, source). The prompt.id attribute links all events from a single prompt, enabling end-to-end trace reconstruction in your SIEM.

The user.email attribute is included in all Cowork OTel events. Configure your telemetry backend to filter or hash it before ingestion if this is a privacy concern. OTel monitoring requires Claude Desktop app version 1.1.4173 or later. Setup: Admin Settings > Cowork > configure OTLP endpoint, protocol, and headers.

Of course, this is not a compliance-grade audit trail. Until Anthropic closes this gap, do not use Cowork for any workflow that requires an audit trail for regulatory compliance.

^‍

‍

4.3 Browser Automation: Know What’s Blocked

Claude in Chrome blocks the following site categories by default: financial services, banking, investment platforms, cryptocurrency exchanges, adult content, and pirated content. Anthropic acknowledges this list may not be exhaustive. The following are NOT blocked by default and should be added to your org blocklist:

☐ Healthcare portals (Epic MyChart, patient systems)

☐ Password managers (1Password, LastPass, Bitwarden web vaults)

☐ Cloud consoles (AWS, GCP, Azure portals)

☐ HR, payroll, and benefits systems

☐ SSO admin panels and identity provider dashboards

☐ Internal wikis and knowledge bases with restricted content

☐ Email with confidential data (if not already scoped via allowlist)

Enterprise admins can also disable the Chrome-to-Cowork bridge specifically by toggling off the Claude in Chrome connector in Admin Settings > Connectors.

‍

4.4 MCP and Plugin Supply Chain

MCP servers are the integration backbone. Local servers (stdio transport) run on the user’s machine with full system access. Remote servers (HTTP/SSE) communicate over the network and require authentication. Both are attack surfaces.

Real-world supply chain attacks have been demonstrated. CVE-2025-59536 (CVSS 8.7, patched October 2025) allowed RCE via malicious hooks and MCP configs in .claude/settings.json, executing commands before the trust dialog appeared. CVE-2026-21852 (CVSS 5.3, patched January 2026) allowed API key exfiltration via ANTHROPIC_BASE_URL override. Both were triggered simply by opening an untrusted repository.

Treat every MCP server like a software dependency. Maintain an allowlist. Review source code. Use scoped, short-lived credentials for authentication.

Plugins bundle four component types: skills (task-specific instruction files), connectors (access to external services such as Slack, Notion, and Google Drive), agents (specialized sub-agents for specific workflows), and hooks (scripts that execute at defined points in a session). Include hook scripts in your plugin security review checklist.

Private plugin distribution: Teams can serve plugins from a private GitHub or GitHub Enterprise repository, making it the standard path for internal plugin distribution without publishing to the public catalogue. The repository becomes a supply-chain risk — a compromised commit can push malicious plugin updates to all users with that marketplace configured. Enforce branch protection and commit signing on plugin repositories.

MCPB (Desktop Extensions) is a new packaging format for local MCP servers that handles cross-platform compatibility, dependency management, code signing, and centralised version updates. It is the recommended enterprise distribution path over manually deploying individual MCP server binaries. For Cowork on 3P, require signed extensions by setting isDesktopExtensionSignatureRequired: true in your MDM configuration.

Per-tool permission stances: Each tool exposed by an MCP server or connector can be set to one of three stances — Allow (runs automatically without prompting), Ask (Claude requests permission each time), or Blocked (tool cannot run at all). In standard Cowork, users configure this per-tool in the session UI. In Cowork on 3P, admins lock the stance via the toolPolicy key in managedMcpServers, overriding user preference. Example: send_message: "blocked" and read_channel: "allow" on the Slack MCP server permits read-only Slack access while preventing Claude from posting messages.

‍

‍

4.5 Data Residency and Retention

Anthropic processes data in the US, Europe, Asia, and Australia by default. Data at rest is stored in the US. Regional inference endpoints (guaranteeing processing stays in a specific region) are available via AWS Bedrock, GCP Vertex AI, and Microsoft Foundry, not as a native plan feature. For regulated workloads requiring regional data residency, deploy via these cloud providers.

Cowork conversation history is stored locally on the user’s machine and is not governed by Anthropic’s retention policies. This means your endpoint security posture (full-disk encryption, EDR, patch management) is your data protection layer for Cowork sessions.

‍

4.6 Domain Claiming: Bringing Shadow Accounts Into Enterprise

One of the more persistent governance gaps in any Enterprise Claude rollout is the personal account problem. Someone joined Claude six months ago with their work email, built up a library of custom projects and chat history, and is now sitting outside your managed workspace entirely. No admin controls. No data protection defaults. Possibly training Anthropic's models. And you can't see any of it.

Enterprise plan admins can now fix this directly. The domain claiming feature lets you identify and migrate all personal accounts (Free, Pro, or Max) using your verified domain email into the Enterprise workspace.

How it works:

When you initiate a domain claim, affected users receive an email and in-product notification with a minimum 30-day window to act. Each user then chooses one of two paths:

• Merge: their conversation history, projects, and data move into a new Enterprise account under your org's governance
• Start fresh: they get a new Enterprise account but leave personal data behind (or export it first)

Either way, the account ends up under your control, with Enterprise data protections applied from that point forward.

Why this matters:

Team plan organisations cannot claim or migrate existing personal accounts. There is no way to merge data between a personal account and a Team account. This is an Enterprise-only capability, and a meaningful one.

Before domain claiming existed, the typical outcome was a proliferation of shadow accounts: real work conversations happening outside policy, outside retention controls, and potentially contributing to model training. The only remediation was asking users to manually delete their personal accounts and start over, which most didn't bother to do.

Domain claiming closes that loop. It's not just about tidying up account sprawl. It's about ensuring that data already generated on your company's behalf is actually subject to the protections you've paid for.

Practical steps:

• In Admin Settings, verify your domain is claimed and DNS-verified (required before you can initiate a domain claim)
• Navigate to the domain claiming settings and review the list of personal accounts on your domain
• Initiate the claim. Users have at least 30 days to respond before the deadline
• Communicate to affected users in advance: explain what's happening, why, and what they need to do. Frame it as a benefit (they get Enterprise access) not a compliance action
• After the migration window closes, verify that accounts previously operating outside Enterprise are now enrolled and subject to your SSO, RBAC, and data controls

Users who don't respond before the deadline may lose access to their personal account data. Set a reminder to chase non-responders during the migration window. Don't let the deadline catch people off guard.

A user will see warning banner and need to follow the steps to migrate their account.

‍

‍
‍

‍

4.7 Role-Based Access Control (Enterprise)

Enterprise plans now support custom roles and groups for controlling who can access specific Claude capabilities. This replaces the previous all-or-nothing model where Cowork was either on for everyone or off for everyone.

Recommended deployment pattern — enable first, restrict after:

Enable all capabilities you want the company to use at the org level first. Then use custom roles to restrict specific groups that should not have those capabilities. RBAC can only restrict what the org-level toggle has enabled — it cannot grant a capability the org toggle has disabled.

Worked example: You want Cowork available company-wide except for the Finance team. Enable Cowork at the org level (must be on). Create a "Finance — Restricted" custom role with Cowork toggled off. Assign that role to the Finance group. Result: everyone else has Cowork; Finance does not.

Common mistake: Leaving Cowork disabled at org level and trying to grant it to specific groups via RBAC. This does not work — the org toggle must be on for any role to grant that capability.

‍

How it works

Custom roles define a set of capability toggles. Groups collect members (manually or via SCIM sync from your IdP). You assign custom roles to groups, then migrate members from the built-in User role to the 'Custom roles' role. From that point, their access is determined entirely by the custom roles assigned to their groups.

Permissions are additive: if a member belongs to multiple groups with different roles, they get the union of all granted capabilities. You cannot use one role to revoke a capability granted by another.

Both the org-level toggle and the custom role must grant a capability for a member to access it. If Cowork is disabled at the org level, no custom role can override that. Think of the org toggle as the main switch and RBAC as the per-team switches underneath it.

What you can control:

• Cowork access
• Claude Code access
• Fast-mode models (Claude Code)
• Code execution and file creation
• Web search
• Memory
• Chat (can now be disabled per role — useful for API or Code-only access without web chat)
• Public projects (control who can share projects org-wide)
• Create skills (control who can upload custom skill files)
• Share skills with team members
• Share skills with the full z
• Claude for Chrome (whether a user can access Claude for Chrome at all; Chrome site allowlists and blocklists are separate org-wide settings)
• Claude Security (find and fix security vulnerabilities)
• Claude Design (generate design assets)

‍

What you still cannot control per-role:

• Chrome site allowlists/blocklists (org-wide)
• Chrome site allowlists/blocklists (domain-level allow/block rules remain org-wide; Chrome access itself is now an RBAC capability — see above)
• Claude CoWork Dispatch (not yet available on Enterprise — no per-role controls to apply)
• Claude CoWork Dispatch
• Plugin installation and marketplace access (org-wide)
• MCP server access (org-wide or MDM-managed)
• Connector permissions (org-wide)
• Scheduled task restrictions (none exist)
• Network egress rules (org-wide)
• Global instructions (org-wide)

Practical impact: RBAC is most useful for controlling who gets Cowork at all — the "Engineering gets Cowork, Finance does not" use case. RBAC now governs 14 capabilities (up from 6), making fine-grained access management meaningfully more useful. Chat restriction is new: it enables API or Code-only deployment patterns without web chat access. Skills sharing controls are new: govern who can create and distribute organization-wide skills. RBAC still does not control plugin installation, MCP server access, connector permissions, scheduled task restrictions, or network egress rules — those remain org-wide or MDM-managed.

Setup guidance: Anthropic recommends a 'base plus additive' pattern: create a base role for common capabilities (web search, memory), then layer on additive roles for specific teams (e.g. a 'Cowork Enabled' role). See Anthropic's 'Set up role-based permissions on Enterprise plans' support article for the full setup walkthrough, including SCIM integration and rollback procedures.

Key operational notes:

• Permission changes take up to five minutes to propagate. Members may need to refresh their browser.
• Members set to 'Custom roles' who are not in any group lose access to all governed capabilities. Always verify group coverage before migrating.
• SCIM-synced groups and manually created groups can coexist and both support custom role assignment.
• Group spend limits are also available, allowing per-group monthly spending caps on usage-based Enterprise plans.
• Owners and Primary Owners are unaffected by RBAC -- they always retain full access.
• For multi-org Enterprise setups: groups are managed at the parent organization level and propagate to all child z. Custom role and spend limit assignments are configured independently per child org.

‍

4.8 Dispatch and Keep Awake

Dispatch is a mobile-to-desktop bridge. You send a task from the Claude mobile app and it executes on your Claude Desktop, with results accessible from either device. The desktop app must be running and your machine awake for tasks to execute. Dispatch is available on Pro, Max, and Team plans — not Enterprise. On Team plans it is admin-toggleable under Admin Settings > Capabilities > Cowork. On Pro and Max personal accounts there is no admin toggle, creating the same shadow-AI risk profile as Computer Use for organizations whose employees have personal subscriptions.

Security note: Dispatch executes with the same permissions as a normal Cowork session on the desktop — including access to any connected MCP servers, project folders, and connectors. A task initiated from mobile inherits whatever context the active project has, including its instructions and memory. A project with manipulated instructions can silently influence tasks sent via Dispatch. Keep Awake is a scheduled tasks setting (not Dispatch) that prevents the machine from sleeping so unattended tasks can complete; on macOS this uses caffeinate, which may override MDM sleep enforcement policies.

From a security perspective, Dispatch extends Cowork's attack surface in two ways:

1. Remote task initiation: Users can now trigger desktop actions from their phone, anywhere. This means a compromised mobile device, or a prompt injection encountered on mobile, could cascade into actions on the user's desktop including file access, browser automation, and MCP server calls.

2. Keep Awake: During Dispatch setup, users can toggle on 'Keep your computer awake'. This prevents the machine from sleeping so that scheduled tasks and dispatched work can execute at any time.

‍

‍

Uses the native caffeinate utility. caffeinate is a first-party macOS process that asserts a power management assertion to prevent idle sleep.

Standard MDM sleep enforcement policies (e.g. via a configuration profile setting the display or system sleep timer) may not override an active caffeinate assertion. Organizations should test against their specific MDM vendor and profile configuration.

Windows

Uses the SetThreadExecutionState Win32 API with ES_SYSTEM_REQUIRED | ES_CONTINUOUS flags. This prevents idle-based sleep but does not override manual sleep actions (lid close, power button).

Group Policy sleep enforcement typically overrides SetThreadExecutionState. However, organizations should validate this in their specific configuration.

‍

Recommendations:

• If your organization has strict endpoint sleep policies for security reasons (e.g. to ensure screen lock after inactivity), test whether enabling Keep Awake in Dispatch conflicts with those policies before rolling out.
• Consider disabling Dispatch entirely if unattended desktop execution is not an accepted risk for your organization.
• If Dispatch is enabled, ensure users understand that Keep Awake means their machine will not sleep while the Claude Desktop app is open, even if they walk away.
• Add Dispatch-specific scenarios to your incident response playbook: a mobile-initiated prompt injection that triggers desktop actions, or an unattended machine running dispatched tasks overnight.

4.9 Computer Use (Pro/Max Only)

Computer Use is a research preview feature that lets Claude interact directly with the user's desktop: taking screenshots, clicking, typing, and navigating applications. It is currently available on Pro and Max plans only. It is not available on Team or Enterprise plans.

Why this matters for Team and Enterprise security teams:

Even though Computer Use is not available on your managed plan, employees with personal Pro or Max accounts can use it on corporate machines unless you have tenant restrictions (Enterprise only) or endpoint-level controls preventing it. This is a shadow AI concern that extends beyond Cowork's other features because Computer Use operates outside the VM sandbox.

How it works:

When Claude does not have a connector or Chrome extension path for a task, it falls back to screen interaction. Claude takes periodic screenshots of the desktop to understand the current state, then issues click, type, and navigation actions to interact with applications. The priority order is: connectors first, then Chrome, then screen interaction.

Key risk characteristics:

• Runs outside the VM sandbox. Unlike normal Cowork file and code operations which run in an isolated VM, Computer Use operates on the user's actual desktop. There is no sandboxing layer.
• Screenshot-based visibility. Claude takes screenshots to navigate. This means it can see anything visible on screen, including sensitive data in adjacent windows, notification pop-ups, or background applications. Users should close sensitive applications before using Computer Use.
• Per-app permission model. Claude asks for permission before accessing each application. Users must approve. Some categories are blocked by default (investment/trading platforms, cryptocurrency). An app blocklist is available for users to configure.
• No admin controls. Because Computer Use is Pro/Max only, there are no organizational admin controls. No allowlist, no blocklist management, no monitoring via OTel. The user is solely responsible for what they approve.
• Cross-app side effects. Actions in one app can trigger effects in another. For example, clicking a link in an email app may open Chrome, even if the user has not granted Chrome access. Claude cannot prevent the OS-level action.
• Prompt injection via screen content. Any text visible on screen, including web pages, notifications, or document content, could contain injected instructions that Claude might follow. The screenshot-based approach makes every pixel a potential injection surface.

Trained safeguards (not absolute):

Claude is trained to avoid: engaging in stock trading or investment transactions, inputting sensitive data, and gathering or scraping facial images. These are behavioural guardrails, not technical controls. They can be circumvented by prompt injection or edge cases.

What to do:

• Enterprise: Ensure tenant restrictions are configured. This prevents employees from using personal Pro/Max accounts on the corporate network, which is the only way Computer Use could appear on a managed device.
• Team: Consider blocking claude.ai at the proxy level for non-managed accounts, or use Chrome enterprise policies to prevent the Claude Desktop app from running outside your managed workspace.
• All: Include Computer Use in your Acceptable Use Policy. State whether personal Claude accounts are permitted on corporate devices and what controls are expected.
• All: If Computer Use comes to Team or Enterprise in future, treat it as the highest-risk Cowork capability. It combines the prompt injection surface of Chrome with direct desktop control and no sandbox isolation.

‍

4.10 Skills

Skills are instruction files (SKILL.md) that Claude loads on demand when a task matches the skill description. They can include scripts and additional resource files loaded at runtime. Skills follow the open Agent Skills specification (agentskills.io) and are portable across platforms that adopt the standard. Skills require code execution to be enabled — document this dependency in your capability rollout plan.

Skill types and their security profile:

• Anthropic built-in: pre-installed for document creation (Excel, Word, PowerPoint, PDF). Low risk — source is Anthropic.
• Partner: delivered via plugin marketplace (e.g. Notion, Figma, Atlassian). Subject to plugin supply-chain governance — see Section 4.4.
• Org-provisioned: deployed org-wide by Team or Enterprise administrators via plugin or MDM. The only skill type with a meaningful admin audit trail. Recommended for Controlled posture deployments.
• User-created: uploaded by individual users. Requires the Create skills RBAC capability (Enterprise). Disable for most users; reserve for a designated skills-author group.
• User-shared: shared with team members or the full organization. Governed by Share skills RBAC capabilities. Restrict org-wide sharing to prevent unreviewed skills proliferating.

‍

Security: Skills are injected into context at activation — a maliciously authored SKILL.md is a prompt injection vector. Audit the entire skill directory, not just SKILL.md: skills can load additional scripts at runtime. Treat user-uploaded skills like untrusted code.

‍

4.11 Projects and Live Artifacts

Projects are named containers that group local folders, standing instructions, reference links, and a persistent per-project memory store. Sessions started inside a project inherit all of this automatically. Projects are stored on the local machine — not synced to Anthropic, not shareable between users.

Security considerations for projects: Project instructions are not visible in the admin console — they function as a per-user system prompt that security teams cannot review centrally. Local filesystem access to a project's instruction file can influence every subsequent session in that project, including sessions triggered by Dispatch. Project memory persists on local disk and must be included in your endpoint FDE and EDR scope. AUP recommendation: prohibit mounting home directories, Desktop, Downloads, or cloud-synced folders as project roots. Include project instructions in manipulated-context tabletop scenarios.

Live artifacts are persistent HTML files saved to the user's outputs folder. They are interactive applications: each time one is opened, it calls connector tools (MCP) in its manifest as live authenticated API calls, not cached data. Artifacts can run lightweight inference and trigger scheduled tasks. Artifacts have a Share button — they can be shared with users inside or outside the organization.

Shadow app sprawl risk: When a colleague opens a shared artifact, it executes in their Cowork session and calls connector APIs using their credentials — without them necessarily understanding what API calls are being made. An artifact shared informally via Slack or email that calls Salesforce, Gmail, and Slack connectors is functionally a mini-application with access to real production systems. There is no admin visibility into which artifacts are circulating or what connector calls they trigger.

A maliciously crafted artifact delivered via a compromised plugin or shared file could exfiltrate data by calling connectors and forwarding results to an external endpoint. Treat shared artifacts from external or unverified sources as you would a macro-enabled spreadsheet.

Controls: Add artifacts to your AUP — define what connector access is appropriate and whether sharing outside the organization is permitted. Artifact connector calls appear as tool_result events in OTel. For Cowork on 3P locked-down deployments, disableNonessentialServices: true disables artifact previews entirely.

‍

4.12 Cowork on 3P (Third-Party Inference)

Cowork on 3P routes all model inference through a provider you control: Google Cloud Vertex AI, Amazon Bedrock, Azure AI Foundry, or a compatible gateway (LiteLLM, Portkey, or an in-house Anthropic Messages API proxy). The desktop app, VM sandbox, and tools are identical to standard Cowork. Only inference moves.

Standard Cowork: inference to Anthropic API; identity via Anthropic account; configuration in the claude.ai admin console; conversations stored on Anthropic backend.

Cowork on 3P: inference to your Vertex/Bedrock/Foundry/gateway endpoint; identity is local device identity only; configuration via OS-native MDM (Jamf, Intune, Workspace ONE, Group Policy); conversations stored on local disk.

Microsoft Foundry caveat: Azure AI Foundry routes through Anthropic's infrastructure. The "no conversation data to Anthropic" guarantee applies only to Vertex AI and Bedrock. Organizations selecting Cowork on 3P for data sovereignty must use Vertex AI or Bedrock, not Foundry, unless they accept Anthropic's standard data processing terms.

Admin control model: Standard Cowork is configured via the claude.ai admin console. Cowork on 3P is configured entirely through OS-native managed preferences: .mobileconfig profiles on macOS, registry policy on Windows. Your MDM team owns this configuration. When a managed profile is present it wins and cannot be overridden by end users. The in-app Developer menu exports configuration directly to .mobileconfig or .reg format.

What Anthropic still receives with Vertex/Bedrock (all can be disabled via MDM config):

• Crash reports — disable with disableEssentialTelemetry: true.
• Product analytics — disable with disableNonessentialTelemetry: true.
• Auto-update checks — disable with disableAutoUpdates: true.
• With all three disabled, Anthropic receives nothing from the deployed app.

Key security configuration keys:

• disabledBuiltinTools — remove built-in tools entirely (e.g. ["WebSearch", "Bash", "WebFetch"])
• allowedWorkspaceFolders — restrict which local folders users can mount
• coworkEgressAllowedHosts — lock sandbox network egress to specific hostnames; empty array blocks all sandbox egress
• isLocalDevMcpEnabled — prevent users adding their own local MCP servers
• isDesktopExtensionEnabled — block desktop extension (MCPB) installation
• isDesktopExtensionSignatureRequired — require code-signed extensions only
• toolPolicy (per server in managedMcpServers) — lock Allow/Ask/Blocked stance per tool
• inferenceMaxTokensPerWindow — per-device token usage cap enforced locally
• otlpEndpoint — route full session activity to your own OTel collector

‍

Three reference security profiles from Anthropic documentation:

Standard: signed extensions required, 24-hour update enforcement, OTel enabled. Recommended for most enterprise deployments.

Restricted: user MCP and extensions disabled, egress locked to your org domain, non-essential telemetry off. For regulated environments.

Locked down: all Anthropic telemetry disabled, auto-updates off, WebSearch and WebFetch removed, zero sandbox egress, workspace folders restricted to ~/Documents/Claude. Your team owns update distribution and log collection.

‍

Framework note: The "do not use Cowork for regulated workloads" guidance elsewhere in this guide should be qualified. Cowork on 3P via Vertex AI or Bedrock may satisfy regulated workload requirements, subject to your specific obligations and your cloud provider's BAAs. Evaluate per workload and jurisdiction. See the Trust Centre for the Cowork Desktop Security Architecture Overview and the Cowork Security Overview (Third-Party Platforms) documents.

‍

4.13 Claude in Slack

There are two distinct Claude and Slack integrations with separate controls and different security profiles.

Claude in Slack (the bot): Claude as a Slack-native chat assistant. Users interact via direct message, the AI assistant panel, or by mentioning @Claude in threads. Requires Slack admin approval in the Slack App Marketplace before any user can access it. This approval is governed by your Slack admin, not the Anthropic admin console. Cowork admin settings have no effect on this integration.

Security considerations: Verify whether your Slack admin has already approved Claude without security team involvement — access may already be live in your workspace. Team and Enterprise users with Claude Code access can route coding tasks to Claude Code via @Claude in Slack, meaning a Slack message can trigger Code-level execution if the user has the desktop app open. Conversations stay separate from Claude web history and auto-delete within 30 days of disconnection, but Slack's own retention policies apply to the Slack-side messages. There is no OTel visibility into Slack-side interactions.

Recommended controls: Require security team sign-off before the Slack admin approves the Claude app — treat it as any third-party Slack integration. Add to your AUP: what data categories are appropriate to discuss via @Claude in Slack.

Slack connector (for Cowork): A separate integration that allows Cowork sessions to read your Slack workspace — channels, DMs, and files. Requires Claude in Slack to be installed first. Enabled by Owners in Admin Settings > Connectors; users also connect it individually. Available on Team and Enterprise plans.

Security considerations for the Slack connector: Grants Cowork read access to all channels and DMs the authenticated user can see, including private channels. A scheduled task or arteifact with the Slack connector can silently read Slack content in the background. Write-access tools (post messages, create channels) exist in the connector — apply per-tool permission stances (Section 4.4): read_channel: allow, send_message: blocked.

4.14 Office Agents (Claude for M365)

Claude for M365 is a set of add-ins that embed Claude inside Microsoft 365 applications: Excel, Word, PowerPoint, and Outlook. It is a separate product from Cowork with its own admin surface. Cowork admin settings have no effect on Office Agents.

Capabilities by application:

• Excel: read and write cells, formulas, formatting, pivot tables, and charts.
• Word: draft, redline, and review documents with tracked changes and comment-driven editing.
• PowerPoint: read, edit, and generate slides using existing templates.
• Outlook: triage inbox, draft replies, summarize threads, find meeting times. Requires a one-time Microsoft Graph consent from an admin before deployment.
• Cross-app context: conversation state is shared across all four apps in a session, so content from one file can inform what Claude does in another within the same session.
• Distinct security surface: The injection surface is the document or email currently open — malicious content in a received email or shared document can contain instructions that Claude follows. Cross-app context means content from one application can flow to another within a session. Admins must complete Microsoft Graph consent for Outlook before deployment.
• Monitoring: Office Agents have their own OTel pipeline, separate from Cowork OTel. Verify what is and is not captured before using Office Agents for workloads that require an audit trail.
• 3P inference: Claude for M365 supports Bedrock, Vertex AI, and Foundry. If your organization deploys Cowork on 3P for data residency, evaluate whether the same configuration is required for Office Agents.

Controls: Add to your AUP — employees may self-install the add-in without approval. Withhold Outlook Graph consent if inbox access is not an approved use case. Add Office Agents to your vendor risk register separately from Cowork. Route Office Agent OTel to the same SIEM collector as Cowork for unified visibility.

‍

‍

5. Threat Model for Agentic Desktop AI

Cowork’s threat model is fundamentally different from Chat. The attack surface includes every data source Claude touches, every tool it can call, and every action it can take autonomously.

‍

5.1 Prompt Injection (Highest Risk)

Indirect prompt injection is the primary threat. Malicious instructions hidden in documents, web pages, emails, or calendar events can hijack Claude’s behavior. Because Cowork can act (write files, browse, execute code), a successful injection has real consequences beyond text output.

Attack surface by integration:

☐ Chrome: any web page Claude visits can contain hidden instructions. ~1% success rate per Anthropic’s testing

☐ Local files: a document in the working folder could contain injected instructions

☐ MCP servers: a compromised server can return poisoned tool results

☐ Connectors: data from external services (email, calendar, Slack) may contain injections

☐ Cross-app flow: data moves between Excel, PowerPoint, Chrome, and local files within a session

☐ Dispatch: tasks initiated from mobile traverse the same attack surfaces on the desktop. A prompt injection encountered on mobile (e.g. via a link in a push notification) could trigger desktop-side actions.

☐ Computer Use (Pro/Max): every pixel on screen is a potential injection surface. Text in any visible window, notification, or dialog box could contain instructions that Claude follows. Because Computer Use runs outside the sandbox, the blast radius of a successful injection includes the entire desktop.

‍

‍

5.2 Supply Chain Attacks

Configuration files are now an attack surface. CVE-2025-59536 demonstrated that .claude/settings.json and .mcp.json files in cloned repositories can execute arbitrary code before the user sees a trust dialog. Plugins sourced from public marketplaces or GitHub repos carry similar risk.

Mitigations: use private plugin marketplaces, vet all plugin source code, enforce branch protection on plugin repos, and keep Claude Desktop updated (both CVEs are patched).

5.3 Data Exfiltration

Cowork can exfiltrate data through multiple channels: MCP server network calls, Chrome browser actions, file writes to external paths, or API calls to external endpoints. The PromptArmor demonstration showed that a model can be tricked into uploading documents via cURL to an attacker’s endpoint. Because anthropic.com is typically on the network egress allowlist, exfiltration to Anthropic’s own API is difficult to block.

Computer Use (Pro/Max) adds a further exfiltration channel: Claude can read sensitive data from one application via screenshots and type or paste it into another, including a browser window or a messaging app. Because Computer Use bypasses the sandbox, network egress controls do not apply to actions taken through screen interaction.

5.4 Unattended Execution

Scheduled tasks run without real-time human oversight. A prompt injection that takes hold during a scheduled task has no human to stop it. Compound this with Chrome access and the risk of an automated, recurring prompt injection attack becomes real.

Dispatch compounds this risk. With Keep Awake enabled, the machine stays on indefinitely while the desktop app is open. A dispatched task initiated from mobile runs on the desktop with full access to local files, connectors, and plugins, with no guaranteed human presence at the keyboard.

‍

6. Deployment Checklist

Three phases: prepare your environment, configure on day of rollout, and maintain ongoing operations.

‍

‍

‍

7. Control Mapping

Reference table for integrating Cowork controls into your existing governance framework.

‍

NIST CSF 2.0

‍

‍

NIST AI RMF

‍

‍

Anthropic Cowork Resources and References

• Set up role-based permissions on Enterprise plans: https://support.claude.com/en/articles/13930458
• Manage custom roles on Enterprise plans: https://support.claude.com/en/articles/13930452
• Manage groups and group spend limits on Enterprise plans: https://support.claude.com/en/articles/13799932
• Assign tasks from anywhere in Cowork (Dispatch): https://support.claude.com/en/articles/13947068
• Schedule recurring tasks in Cowork: https://support.claude.com/en/articles/13854387
• Use Cowork on Team and Enterprise plans: https://support.claude.com/en/articles/13455879
• Let Claude use your computer in Cowork (Computer Use): https://support.claude.com/en/articles/14128542
• Cowork overview: https://claude.com/docs/cowork/overview
• Cowork monitoring (OTel): https://claude.com/docs/cowork/monitoring
• Cowork on 3P overview: https://claude.com/docs/cowork/3p/overview
• Cowork on 3P configuration reference: https://claude.com/docs/cowork/3p/configuration
• Run tasks with Dispatch: https://claude.com/docs/cowork/guide/dispatch
• Organise work with projects: https://claude.com/docs/cowork/guide/projects
• Install plugins in Cowork: https://claude.com/docs/cowork/guide/plugins
• Skills overview: https://claude.com/docs/skills/overview
• Slack integration: https://claude.com/docs/connectors/slack
• Claude for M365 overview: https://claude.com/docs/office-agents/overview
• Connectors overview: https://claude.com/docs/connectors/overview

‍

‍

‍