Securing Claude Cowork: A Security Practitioner’s Guide

Claude Cowork gives employees a local AI agent that can write code, browse the web, manage files, and run scheduled tasks — all on their machine. That's a meaningfully different threat surface than a chatbot.

You can't eliminate the risk, but you can control it. This guide covers what security teams need to know and maps relevant controls to NIST CSF and AI RMF so you can act quickly.

Note: Cowork is in research preview and the control landscape is evolving. We'll update this guide as capabilities and admin options change.

‍
Last updated: April 20th 2026

‍
‍

1. TL;DR: The 12 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, slash commands, sub-agents, and MCP servers. Installing one 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 loop in a scheduled task could run for hours.

9. The admin toggle is all-or-nothing. Cowork access cannot be limited by user or role during the research preview. It’s organization-wide: everyone has access or no one does.

10. RBAC is now available on Enterprise, but its scope is limited (Enterprise only). Enterprise plans can now use custom roles and groups to control who gets access to Cowork, Claude Code, web search, memory, code execution, and fast-mode models. This is a meaningful improvement over the all-or-nothing toggle. However, RBAC only governs access to six high-level capabilities. It does not control Chrome site restrictions, plugin installation, MCP server access, connector permissions, or scheduled task rules. Those remain org-wide. Team and Pro/Max plans still have no per-user access controls.

11. Dispatch adds mobile-to-desktop task assignment and a Keep Awake toggle. Dispatch lets users assign tasks from the Claude mobile app that execute on their desktop. It is available on Team and Enterprise plans and can be toggled on or off by admins under Cowork settings. Dispatch includes a 'Keep Awake' option that prevents the machine from sleeping. On macOS this uses the native caffeinate utility; on Windows it uses the SetThreadExecutionState API. Standard MDM sleep enforcement policies may not override caffeinate on macOS. Factor this into your endpoint management strategy.

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.

‍

‍

‍

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

On privacy: user prompt content is not collected by default and only prompt length is recorded. To include prompt content, set OTEL_LOG_USER_PROMPTS=1. Raw file contents and code snippets are never included in metrics or 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.

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.

‍

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 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.

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

What you still cannot control per-role:

• Chrome site allowlists/blocklists (org-wide)
• 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, not for fine-grained control over what Cowork can do. If your goal is 'Engineering gets Cowork, Marketing does not', RBAC solves that. If your goal is 'Engineering gets Cowork but can only browse these five domains', you still need org-wide Chrome controls and there is no per-group differentiation.

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 organisation level and propagate to all child organisations. Custom role and spend limit assignments are configured independently per child org.

‍

4.7 Dispatch and Keep Awake

Dispatch is a feature that lets users assign tasks to Claude from the mobile app while Claude executes them on the user's desktop. It creates a single persistent conversation thread that syncs across mobile and desktop. Dispatch is available on Team and Enterprise plans and can be toggled on or off by admins under Cowork settings.

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. Organisations 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, organisations should validate this in their specific configuration.

‍

Recommendations:

• If your organisation 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 organisation.
• 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.8 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 organisational 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.

‍

‍

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

‍

‍

‍