Securing Claude Cowork: A Security Practitioner’s Guide

OpenTelemetry is now a first-class Cowork path. Available on Team and Enterprise, configured at Organization settings > Cowork with an OTLP endpoint, protocol and headers. It covers cloud sessions on desktop, web and mobile, and local desktop sessions. Cloud sessions require Claude Desktop 1.22209.3 or later; local sessions require 1.1.4173 or later. Fleets below the cloud threshold silently produce no cloud-session telemetry and no error.

Cowork OTel exports six event types, not five: user_prompt, assistant_response (Desktop 1.17377+), tool_result, tool_decision, api_request and api_error. The prompt.id attribute links all events from a single prompt, enabling end-to-end trace reconstruction in your SIEM.

• api_request carries model, cost in USD, duration, input and output tokens, cache reads and creations, and speed. This is the only place you get cost, because the Compliance API omits it.
• tool_result carries tool name, success, duration, error, decision type and source, result size, MCP server scope, and tool parameters. Those parameters include bash commands and file paths, which may contain sensitive values, so redact at the collector.
• user.email is included in all Cowork OTel events on first-party deployments. Filter or hash it before ingestion if that is a privacy concern.
• The collector hostname is automatically added to the session egress allowlist.
• otlpAuthMode and otlpHeadersHelper replace static collector headers. otlpTracesEnabled adds per-interaction traces and left beta on 27 August 2026, requiring Desktop 1.22209.0 or later.
• A desktop_session_title_set event was added on 2 September 2026, so session titles now leave the device in telemetry.

⚠ Cowork does not support gRPC export. With otlpProtocol set to grpc it silently falls back to HTTP protobuf on the same endpoint, so a gRPC-only collector listening on 4317 receives nothing at all and reports no error.

On prompt content, two official Anthropic pages contradict each other. The help centre article, modified 26 August 2026, says "User prompt content is included in events by default". The documentation, modified 12 August 2026, says "By default, events include metadata only" and requires the otlpContentCapture setting with categories userPrompts, assistantResponses, toolDetails, toolContent and rawApiBodies. The help centre page is newer. Set otlpContentCapture explicitly rather than relying on either default, and note that enabling userPrompts also captures model responses, with no prompt-only option.

An earlier version of this guide referenced an excludePromptFromTelemetry MDM flag for Cowork on 3P. That key is not documented by Anthropic and appears never to have existed. Use otlpContentCapture.

Admin analytics improved too. The dashboard now reports sessions in Cowork alongside usage and cost by SCIM group, by user, by skill and by connector, with spend alerts at 75% and 90% of an organization-level limit.

What you still cannot see. Anthropic states that the Cowork VM "is isolated from host-based security tools by design" and that EDR tools cannot observe cloud sessions either. Your compensating control is pull-based log export, not live endpoint monitoring. Plan detection engineering around the Compliance API for content, OTel for tool calls and cost, and inference hooks for prevention.

Where this leaves regulated workloads. The audit argument against Cowork is closed. The remaining constraints are contractual and scope-based: Cowork is expressly not covered under Anthropic's BAA, HIPAA-ready organizations capture no local session data, ZDR does not cover the Team and Enterprise product interfaces, and no Anthropic page states whether Cowork sits inside the SOC 2, ISO 27001 or ISO 42001 audit boundary. Ask for that scope statement in writing before putting regulated data through it.

4.3 Browser Automation: Know What's Blocked

There are now two browsing surfaces, not one, and the default blocklist has narrowed considerably.

Claude in Chrome went generally available on all paid plans on 26 August 2026, with autonomous action-taking validated per action by a safety classifier. Support documentation still describes the Chrome side panel itself as beta while the GA announcement covers the capability, so the two official sources conflict on status.

Claude in Chrome now blocks only two site categories by default: adult content websites and known pirated content sites. Financial services, banking, investment platforms and cryptocurrency exchanges are no longer hard-blocked; Claude asks for permission before accessing financial sites. Anthropic acknowledges this list may not be exhaustive. The following are NOT blocked by default and should be added to your org blocklist:

☐ Financial services, banking, investment platforms and crypto exchanges, which now only prompt

☐ 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)

Anthropic's own recommendation is to "start with a more restrictive allowlist for the security of your organization's data, then expand access over time".

The side panel is now a Cowork session. Since 12 August 2026, on Max and Team and rolling out to Pro, the Chrome side panel runs as a Cowork session. It persists to session history and carries the user's skills, plugins and connectors into the browser, with automatic approval as the default mode. Enterprise gets this only once an admin has enabled Cowork in the cloud. This merges the browser agent and the file and tool agent into a single auto-approving session, which materially changes blast radius.

Permissions. Site-level choices are "Allow this action", "Always allow actions on this site" and "Decline". The blanket "Allow all browser actions" option was removed on 17 August 2026. Even under always-allow, Claude still asks before downloading a file, entering potentially sensitive information, or granting authorizations. Actions prohibited regardless of permission include purchases and financial transactions, creating accounts, handling sensitive card or ID data, downloading from untrusted sources, permanent deletions, executing financial trades, modifying system files, bypassing captchas, scraping facial images, and completing instructions found in emails or web content.

An earlier version of this guide stated that Claude executes JavaScript as a distinct permissioned action. No Anthropic documentation supports that, and the claim has been removed.

The Cowork built-in browser launched 26 August 2026 for macOS, Windows and Linux in beta. It is a browser inside the Claude Desktop app, separate from the user's own browser and requiring no extension. By default it has no access to the user's logins. Cookies can be imported per site from Chrome, Edge and Firefox, with banking, email and SSO sites unchecked by default on import. Its toggle sits at Organization settings > Cowork > Built-in browser: on by default on Team, off at Enterprise launch and on by default since 10 September 2026 unless disabled. Users are not notified when an admin enables it.

⚠ One warning in Anthropic's documentation deserves emphasis: sites signed into inside the built-in browser stay "available to Claude in future Cowork sessions on that computer". A single sign-in becomes standing access. Note also that Anthropic's articles disagree on whether the built-in browser has its own domain controls or inherits the Chrome extension's allowlist and blocklist. Verify before relying on either.

Enterprise management of the extension. Deploy or block through Google Workspace admin or your MDM. The extension ID is fcoeoabgfenejglbffodgkkbkcdhcgfn, and version 1.0.36 or later is required for Claude Code integration. The only Chrome enterprise policy Anthropic documents by name is forceLoginOrgUUID, which pins the extension to one organization. Anthropic does not publish ExtensionInstallBlocklist or ExtensionInstallForcelist examples, so build those yourself against that ID.

Endpoints to allow, or to block if you are cutting it off: claude.ai, api.anthropic.com, platform.claude.com, and the Desktop bridge at wss://bridge.claudeusercontent.com. To sever the Chrome-to-Cowork bridge specifically, disable isLocalDevMcpEnabled in enterprise configuration, or on the Claude Code side block the claude-in-chrome MCP server through deniedMcpServers.

Three further points. Claude in Chrome has its own per-role capability and does not inherit a user's Cowork access, so a role granting Cowork does not grant the browser. The Claude Code Chrome extension works with Chrome, Edge, Brave, Arc, Vivaldi and Opera, so a policy targeting Chrome alone leaves a gap. And Claude in Chrome is not available to HIPAA-covered organizations, zero data retention is not supported for it, and 1Password for Claude (macOS beta, signs Claude into sites without exposing the password or one-time code) is off by default and admin-controlled.

4.4 MCP and Plugin Supply Chain

MCP servers are the integration backbone. Local servers (stdio transport) run on the user's machine with significant system access. Remote servers (HTTP/SSE) communicate over the network and require authentication. Both are attack surfaces. Anthropic supports HTTP and streamable HTTP, SSE, local stdio and WebSocket transports, and its v2 client adds MCP protocol revision 2026-07-28.

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, and both are patched.

More useful now, because it is first-party and current, is Anthropic's own disclosed incident. A malicious workspace file carried an attacker's API key; Claude uploaded files to api.anthropic.com, an allowlisted domain, into the attacker's account. The fix was an in-VM man-in-the-middle proxy that rejects non-provisioned tokens and blocks server-side-fetch headers. Anthropic's reframing is the lesson to carry into your own design work: an allowlist "may be better conceptualized as a capability grant".

⛔ Anthropic states directly that it reviews connectors against listing criteria but "doesn't security-audit or manage any MCP server". Treat every MCP server like a software dependency. Maintain an allowlist. Review source code. Use scoped, short-lived credentials.

The managed control set is broader than managed-mcp.json alone. That file, deployed by MDM, remains the exclusive-control mechanism, and a managed-mcp.json carrying an empty server map blocks every MCP server except two things: in-process servers the host app registers, and anything you supply through managedMcpServers, which keeps loading regardless. To disable MCP completely you must leave managedMcpServers unset as well, and that second step is the one baselines miss. Beyond it: allowedMcpServers and deniedMcpServers, allowManagedMcpServersOnly, set in Claude Code managed settings rather than managed-mcp.json, which makes only managed-settings allowedMcpServers authoritative while deniedMcpServers keeps merging from all sources, and which is treated as true if its value is unreadable, strictKnownMarketplaces and blockedMarketplaces for plugin sources, strictPluginOnlyCustomization, and allowManagedHooksOnly. Denylists merge from every scope, so users can self-block but not self-unblock.

Anthropic warns that a serverName entry "is not a security control" because the user chooses the label. Enforce on serverCommand or serverUrl or your allowlist is decorative.

The governance gap that catches people. In Claude Desktop, claude.ai connectors arrive in-process as type: "sdk" servers. No MCP setting and no managed-mcp.json reaches them. The only lever is connector tool policy set to Blocked.

Plugins bundle skills, MCP connectors, subagents, slash commands and hooks. Hooks and subagents run only in Cowork and appear greyed out in chat. Include hook scripts in your plugin security review checklist, and note that hooks are explicitly not covered by Anthropic's scanning.

Private plugin distribution. Team and Enterprise owners can run a private marketplace at Organization settings > Plugins, uploading a ZIP or syncing from a private or internal GitHub or GitHub Enterprise repository. Public repositories are refused. It requires both Cowork and Skills to be enabled. The repository becomes a supply-chain risk: a compromised commit can push malicious plugin updates to all users with that marketplace configured, and auto-sync triggers on pull requests with a version bump merged to the default branch. Enforce branch protection and commit signing on plugin repositories.

Each plugin gets one of four install preferences: Installed by default, Available for install, Required, or Not available. Enterprise adds per-group overrides, but where a member sits in multiple groups the most permissive setting wins, and Anthropic states that groups here are "not a security boundary". Hard blocking requires org-wide "Not available".

Use allowedPluginMarketplaces with manifestSha256 pinning, which left beta on 27 August 2026. Auto-install or required entries without a pinned commit SHA silently downgrade to "available" with a warning. On third-party deployments, userPluginMarketplacesEnabled and userPluginUploadsEnabled stop members adding their own sources; no equivalent first-party org toggle is documented, which remains a real gap on claude.ai and Cowork.

One inventory wrinkle: Cowork and cloud sessions download claude.ai-enabled plugins and load them as <name>@synced with no marketplace or install record. Do not expect a complete plugin inventory from the local cache alone.

Skill and plugin security scanning arrived on 6 August 2026: Enterprise only, beta, and off by default at Organization settings > Skills. Third-party skills and plugins are scanned at upload or edit, returning pass, warn or fail, with fail blocking and no override for uploader or admin. Turn it on. Then document what it does not cover: pre-existing skills and plugins, skills created with Claude, skills from connected MCP servers, MCP servers themselves, and hooks. It is also unavailable to CMEK, ZDR and HIPAA organizations.

MCPB (Desktop Extensions) is the packaging format for local MCP servers, handling cross-platform compatibility, dependency management, code signing, and centralised version updates. It remains the recommended enterprise distribution path over manually deploying individual MCP server binaries. Since 7 July 2026 extensions do not load unless isDesktopExtensionEnabled is explicitly true, and you should require signatures with isDesktopExtensionSignatureRequired. Team and Enterprise owners also have a Desktop extension allowlist at Organization settings > Connectors > Desktop, off by default; note that enabling it force-deletes existing installs, and that it does not prevent tampering with local MCP files after install.

MCP tunnels are a research preview available to Enterprise by request, exposing private-network MCP servers that speak streamable HTTP through *.tunnel.anthropic.com, reachable only from Claude. Treat this as a new inbound path and review it accordingly.

Per-tool permission stances. Each tool exposed by an MCP server or connector can be set to Always allow (runs automatically), Needs approval (Claude requests permission each time), or Blocked (cannot run at all). On Team and Enterprise these are set org-wide at Organization settings > Connectors and are not user-overridable; Enterprise custom roles add per-role, per-tool control on top, with the org policy as ceiling. In Cowork on 3P, admins lock the stance via the toolPolicy key in managedMcpServers. Example: send_message: "blocked" and read_channel: "allow" on the Slack MCP server permits read-only Slack access while preventing Claude from posting.

Two newer connector controls are worth adopting. Enterprise Managed Auth, generally available for Team and Enterprise with Okta at launch, lets you authorize a connector once through your IdP, choose which roles receive it and which scopes Claude may request, and revoke by deprovisioning. Restrict verified-domain connectors, Enterprise only and off by default, blocks connecting a verified-domain account from a Claude account outside your organization across fifteen named connectors; it applies to new connections only, generates no admin notification, and is not a DLP control.

Finally, note that Anthropic's connector review criteria now require separate read and write tools and mandate readOnlyHint and destructiveHint annotations, which "determine auto-permissions in Claude". Read-only tools can run without per-call confirmation, but most custom connectors do not set these annotations, so the exemption will not apply to yours. Custom connectors are also reached from Anthropic's cloud rather than the local device, even in Cowork, so the server must be internet-reachable or behind IP allowlisting or a tunnel.

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. There is no EU-only inference and no EU storage on first-party Claude: inference_geo accepts only global and us, and workspace storage geography accepts us only and is immutable after creation. Regional residency beyond that requires AWS Bedrock, Google Cloud or Microsoft Foundry.

One native option now exists that did not before. US-only inference is available on usage-based Enterprise plans, billed at 1.1x standard API rates, covering all Claude apps including Cowork and Desktop plus background processing. It does not cover connectors and does not change storage location.

Retention by plan. Free, Pro and Max chats are retained until deleted, with deletion purging backend storage within 30 days. Team and Enterprise chats are retained indefinitely by default. Custom retention is Enterprise-only with a 30-day minimum, measured from last activity, where project retention supersedes chat retention and shortening the window deletes out-of-window data immediately and irreversibly on save. Team plans have no custom retention control.

Cowork specifically. Deleting a Cowork task removes it from task history immediately and from Anthropic backend storage within 30 days. Local session conversation history sits on the user's own machine and is expressly not subject to Anthropic's standard retention policies, which means your endpoint security posture (full-disk encryption, EDR, patch management) is your data protection layer for those sessions. But the server-side capture of those same local sessions is retained for six years, or the organization's custom finite period, and is reachable only through the Compliance API. Cloud session files are saved to the member's Claude account.

⛔ The Covered Models override matters if you bought zero data retention. Effective 9 June 2026, models Anthropic designates "Covered Models", currently the Fable and Mythos classes, require 30-day retention on every platform and are unavailable under ZDR unless expressly authorized. Anthropic's Service Specific Terms section F provides that this expressly supersedes any modified retention commitment, including ZDR. The remedy Anthropic offers is Enterprise Frontier Safeguards, announced 1 September 2026: ZDR combined with misuse detection where activity data is stored in your own S3, Azure Blob or Cloud Storage under your own keys, with automated monitoring only, no Anthropic human review, and flags routed to your security team.

Encryption and access. CMEK is Enterprise and Claude Platform, opt-in and not self-serve, using AWS KMS, Google Cloud KMS or Azure Key Vault in US regions only, and it is permanent and irreversible. It encrypts Cowork in Claude Desktop but not Cowork global instructions, and Claude Code Desktop, web and Slack remain under Anthropic-managed keys. Enabling it disables audit log exports, conversation history search, project knowledge retrieval, skills and connector analytics, and signed URLs, which back organization data exports. Access Transparency, which logs Anthropic personnel access to customer content with reason codes, remains available on request rather than self-serve.

Certifications, accurately. Anthropic holds SOC 2 Type I and Type II, ISO 27001:2022 and ISO/IEC 42001:2023, and offers a HIPAA-ready configuration with a BAA that became self-serve on 14 July 2026. FedRAMP High applies to Claude for Government only; Claude Enterprise is not FedRAMP authorized. A third-party NIST 800-171r3 attestation exists, NDA-gated on the Trust Center. Two Anthropic pages disagree on whether ISO 27017, ISO 27018 and CSA STAR are held. Most importantly for this guide: no Anthropic page states whether Cowork sits inside the SOC 2 or ISO audit boundary, and Cowork is expressly excluded from the BAA.

One thing not to build controls on. Text produced by Fable 5.1 and Mythos 5.1 carries Anthropic's statistical text watermark, and media produced through the code execution tool carries C2PA Content Credentials. The watermark carries no identifying information. It is a marking obligation, not an audit trail, so do not design attribution or DLP around it.

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

Prerequisites, all four required: Restrict organization creation must be on, the domain must be DNS-verified, SSO must be actively enforced rather than merely configured, and either JIT or SCIM provisioning must be enabled. Earlier versions of this guide listed only DNS verification.

How it works. When you initiate a domain claim, affected users receive an email and in-product notification with a fixed 30-day window to act, since Anthropic states "The window is always 30 days". 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.

The constraints. The "Migrate accounts using your domain" toggle is a one-way door. The window is fixed at 30 days with no custom deadline, and you can run only one claim at a time. It cannot migrate data into HIPAA-ready or CMEK organizations, which are join-fresh only, and it cannot claim Team accounts. Team plan organizations can verify a domain and block new personal accounts, but cannot claim or migrate existing ones, and there is no way to merge data between a personal account and a Team account.

Practical steps.

• Confirm all four prerequisites, then verify your domain is DNS-verified in Admin Settings
• Navigate to the domain claiming settings and review the list of personal accounts on your domain
• Initiate the claim. Users have exactly 30 days to respond before the deadline; the window is fixed and cannot be shortened or extended
• 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.

4.7 Role-Based Access Control (Enterprise)

Enterprise plans 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. Precedence is most-restrictive-wins: Anthropic platform and contract terms, then the org toggle, then additive custom role grants, then the user's own setting.

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

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 Custom. From that point, their access is determined entirely by the custom roles assigned to their groups. Permissions are additive: a member in multiple groups gets the union, and you cannot use one role to revoke a capability granted by another.

What you can control: 19 capabilities, up from the 14 documented in earlier versions of this guide. Chat; code execution and file creation; memory; web search; public projects; create skills; share skills and plugins with org members; share skills with the full organization; share skills and plugins with groups; skill and plugin security scanning; Claude Code; fast mode; Claude Code dynamic workflows; Claude Security; Claude Code artifacts; Claude Design; Claude Cowork; Cowork in the cloud (beta); and Claude for Chrome.

⛔ The "Capability access" shortcut offers All capabilities including beta and research preview, All generally available, or Only selected. The first two automatically inherit new capabilities as Anthropic launches them. Given the pace of 2026 releases, a role you reviewed in July silently gained the built-in browser in August. Use "Only selected" and review it monthly.

Seven admin permission areas were added on 2 June 2026, each set to No access, Can view or Can manage: Identity and Access, Billing, Analytics (view only), Privacy, User Management (manage only), Libraries (manage only), and Directory management. A separate Claude Design Admin permission sits outside that set. Note that Identity and Access set to Can manage lets a role edit roles including its own, so it can self-escalate; reserve it for trusted admins.

Connector permissions in roles, added 28 May 2026, cover Always allow, Needs approval, Blocked or Custom per tool, enforced server-side across web, desktop, mobile, Cowork and Claude Code, with the org-wide tool policy as ceiling. New roles default to Needs approval on every connector; roles that existed when connector permissions were enabled were seeded to Always allow, so audit those.

Model entitlements, Enterprise beta since 1 July 2026, control which models members can access and which effort levels they can use, org-wide and per role, plus a default model. Haiku can never be disabled, and entitlements are not yet enforced in Claude in Chrome or Claude Security. This is also your lever for keeping users off models whose retention terms you have not accepted.

What you still cannot control per-role:

• Browser site allowlists and blocklists (org-wide; browser access itself is an RBAC capability)
• Plugin installation and marketplace access (org-wide, with non-authoritative group overrides)
• MCP server access (org-wide or MDM-managed)
• Scheduled task restrictions (none exist)
• Network egress rules (org-wide)
• Organization instructions and Cowork global instructions (org-wide)
• Dispatch, which has no per-role capability and is present on Team despite being documented as Pro/Max only, and Computer Use, which is not available on managed plans

Key operational notes.

• Permission changes take up to 15 minutes to propagate, not five as earlier stated. Members may need to refresh.
• Members set to Custom who are not in any group lose access to all governed capabilities. Verify group coverage before migrating.
• There is a limit of 100 groups per organization, and more than 250 groups per member degrades performance.
• "View effective role" on Members and Groups shows granted capabilities, permissions and connectors with a "Granted by [role]" label.
• SCIM-synced and manually created groups can coexist and both support custom role assignment. But a member manually set to Custom reverts to their mapped role on the next full sync, and Anthropic notes that the reversion is not written to the audit log. If your access reviews rely on the audit log, they will not see it.
• Group spend limits allow per-group monthly caps on usage-based Enterprise plans.
• Owners and Primary Owners are unaffected by RBAC and always retain full access.
• For multi-org Enterprise setups, groups are managed at the parent organization and propagate to all child organizations. Custom role and spend limit assignments are configured independently per child org.
• On legacy dual-seat Enterprise plans, custom roles cannot override seat-level restrictions in either direction.

Anthropic recommends a base-plus-additive pattern: create a base role for common capabilities (web search, memory), then layer additive roles for specific teams (for example a "Cowork Enabled" role).

4.8 Dispatch and Keep Awake

Anthropic's documentation says Dispatch is Pro and Max only. That is out of date: Dispatch is present and enabled on Claude Team, verified 10 September 2026. The admin toggle remains undocumented on every plan.

Anthropic documents Dispatch as Pro and Max only. Observed behaviour differs. Two pages still state the restriction: "Dispatch requires a Pro or Max plan" (claude.com/docs/cowork/guide/dispatch) and "in limited beta for Pro and Max plans" (support article 13947068). Both are stale. On a Claude Team plan, Dispatch appears as a Beta item in the Claude Desktop sidebar with its own settings panel. This is therefore not only a personal-device problem: it runs inside your managed tenant under corporate identity, with the same access as a normal Cowork session. No admin toggle is documented on any plan, so do not assume you can disable it centrally. The panel also carries its own Keep awake, Mobile notifications and Code permissions settings, and Code permissions defaults to Accept, auto-approving code actions in a mobile-triggered session with nobody at the keyboard.

Dispatch has two documented shapes: a mobile-to-desktop handoff maintaining one continuous thread synced across phone and desktop, and a long-running background agent that decomposes an outcome into child tasks, each running as its own Cowork or Claude Code session. Child tasks cannot spawn further children. Coding work routes to Claude Code against a configured workspace; knowledge work routes to Cowork in a specified or default project. It requires the desktop awake and Claude Desktop open, on macOS, Windows x64 or Linux, with internet on both devices.

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

1. Remote task initiation. Users can trigger desktop actions from their phone, anywhere. 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. 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, so a project with manipulated instructions can silently influence dispatched tasks.

2. Unanswered prompts fail open in one direction. A child task's permission prompt is forwarded to the user, and Anthropic's documentation states that "if you don't respond within ten minutes, the request is automatically denied and the task continues without that action". The action is denied, but the task proceeds regardless, so an unattended Dispatch run completes in a partially-executed state nobody reviewed.

Anthropic frames the risk plainly: giving a mobile AI agent remote control of a desktop AI agent "creates a chain where instructions from your phone can trigger real actions on your computer", and a manipulated instruction or phishing link "could cascade into actions that are difficult or impossible to undo".

Keep Awake. For local scheduled tasks, Anthropic documents a "Keep computer awake" setting under Settings > Desktop app > General, and notes that closing the laptop lid still puts the machine to sleep. On 4 September 2026 further controls arrived for the Claude Code tab: "Keep computer awake while Claude works", "Keep awake on battery power", and a per-session toggle.

⚠ Correction: earlier versions of this guide asserted that Keep Awake uses caffeinate on macOS and SetThreadExecutionState on Windows, and presented that as Anthropic documentation with a platform comparison table. Anthropic does not document the underlying OS mechanism. Treat any claim about whether Keep Awake overrides your MDM sleep enforcement as something to test in your own environment against your own configuration profile, not as documented behaviour.

Recommendations.

• If your organization has strict endpoint sleep policies for security reasons (for example to ensure screen lock after inactivity), test whether Keep Awake conflicts with them before rollout.
• Include Computer Use and Dispatch in your acceptable use policy. For Computer Use, state whether personal Claude Pro or Max accounts are permitted on corporate devices, since that is the only route to it. For Dispatch, assume managed-plan users already have it and govern its use directly, including the Code permissions default.
• Add Dispatch-specific scenarios to your incident response playbook: a mobile-initiated prompt injection that triggers desktop actions, or an unattended machine completing dispatched tasks overnight with denied-but-continued steps.

4.9 Computer Use (Pro/Max Only)

Computer Use lets Claude interact directly with the user's desktop: taking screenshots, clicking, typing, and navigating applications. It launched as a research preview on 23 March 2026 and is now described as beta. It remains available on Pro and Max plans only; Anthropic states that "Team and Enterprise plans don't have access to computer use at this time".

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 browser path for a task, it falls back to screen interaction. The priority order is connectors first, then browser, then screen interaction. Anthropic's wording on isolation leaves no ambiguity: "Computer use has no sandbox between Claude and your applications. Claude interacts directly with your desktop, apps, and browser."

The controls that do exist, which earlier versions of this guide understated:

• Enablement is per user at Settings > General under Desktop app, off by default. No admin toggle and no MDM key gates it.
• Per-app approval on first use in each session, with "Allow for this session" or "Deny". Approvals last the session, or 30 minutes in Dispatch-spawned sessions.
• A three-tier per-app access model: View only for browsers and trading platforms, Click only for terminals and IDEs, Full control for everything else.
• Broad-reach applications carry extra in-prompt warnings: "Equivalent to shell access" for terminals and IDEs, "Can read or write any file" for Finder, "Can change system settings" for System Settings.
• A user-configurable denied-apps list, with investment and trading platforms and cryptocurrency blocked by default.
• Prompt-injection scanning of on-screen content.
• One machine-wide lock, so only one session can drive the computer.
• A global Esc kill switch whose keypress is consumed, specifically so prompt injection cannot use it to dismiss dialogs.
• The terminal window is excluded from screenshots, and on macOS 15 and later Claude can operate background windows.

Residual risk characteristics.

• Screenshot-based visibility. Claude 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.
• Prompt injection via screen content. Any text visible on screen could contain injected instructions. The screenshot-based approach makes every pixel a potential injection surface, and because it runs outside the sandbox the blast radius of a successful injection includes the entire desktop.
• Cross-app side effects. Actions in one app can trigger effects in another. Clicking a link in an email app may open a browser even if the user has not granted browser access; Claude cannot prevent the OS-level action.
• Exfiltration outside your controls. Because Computer Use bypasses the sandbox, network egress controls do not apply to actions taken through screen interaction. Claude can read data from one application via screenshots and type it into another.
• No organizational monitoring. There is no OTel coverage and no admin visibility, because the feature is not available on managed plans at all.

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, and can be circumvented by prompt injection or edge cases.

What to do.

• Enterprise: ensure tenant restrictions are configured. This prevents employees 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 for non-managed accounts, or use endpoint controls to prevent the Claude Desktop app running outside your managed workspace.
• All: include Computer Use in your acceptable use policy. If it ever comes to Team or Enterprise, treat it as the highest-risk Cowork capability: it combines the prompt injection surface of a browser with direct desktop control and no sandbox isolation.

Note also that computer use and browser use are now generally available as API toolsets (computer_toolset_20260801 and browser_toolset_20260801) on the Claude Platform and Google Cloud. If your developers build against those, the governance is entirely separate from the desktop app.

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, and follow the open Agent Skills specification, making them portable across platforms that adopt the standard. Skills require code execution and file creation to be enabled; document that dependency in your capability rollout plan. They are available on Pro, Max, Team and Enterprise but not on Free: Anthropic states that "Skills are available for users on Pro, Max, Team, and Enterprise plans." Earlier versions of this guide had Free in that list, which was wrong.

Skill types and their security profile:

• Anthropic built-in: pre-installed for document creation (Excel, Word, PowerPoint, PDF). Low risk, source is Anthropic. Note that disableBundledSkills does not remove these: it "Disables Claude Code's bundled skills and workflows (deep-research and similar)", which is a different set. No documented key strips the document-creation skills.
• Partner: delivered via plugin marketplace (Notion, Figma, Atlassian). Subject to plugin supply-chain governance, see 4.4.
• Org-provisioned: owners upload a ZIP at Organization settings > Skills. Enabled by default for everyone; users can toggle off but not delete, and only owners can add or remove. The only skill type with a meaningful admin trail, and recommended for Controlled posture deployments. Group-scoping is only possible by bundling skills into a plugin and assigning that plugin to a group.
• User-created: gated by the User-created skills toggle at Organization settings > Skills, and additionally by the Create skills role capability on Enterprise, where the org toggle is the master switch. skillCreationEnabled gates it at device level. Disable for most users and reserve for a designated skills-author group.
• User-shared: three independent toggles govern this. Skill sharing is on by default for Team; Share with organization is off by default; Share with groups is off by default and additionally requires "Share resources with this group" plus the corresponding role capability.

⛔ Anthropic states directly that there is no approval workflow for org-wide skill sharing: any user with the capability can publish to the organization directory without review. Sharing is auditable as role assignment events, but skill and plugin contents are not captured and there is no admin dashboard to inspect what has been shared. Leave "Share with organization" off unless you have a review process of your own.

The Skills API at /v1/skills left beta on 19 August 2026. API skills are workspace-wide, capped at 20 skills per request, and are not covered by security scanning. Anthropic recommends version pinning and checksums. Skills are also not covered by zero data retention arrangements.

Security. Skills are injected into context at activation, so a maliciously authored SKILL.md is a prompt injection vector. Audit the entire skill directory, not just SKILL.md, because skills can load additional scripts at runtime. Treat user-uploaded skills like untrusted code. Anthropic publishes its own risk-tier table flagging bundled scripts, instruction manipulation, MCP server references, network calls and hardcoded credentials as high risk, plus an eight-step review checklist, and frames the whole thing as "treat like installing software". Use their checklist as the basis for yours.

One documentation caveat: the Agent Skills overview page still states that claude.ai custom skills "cannot be centrally managed by admins", which the current org-provisioning support article contradicts. Treat the platform page as stale.

4.11 Projects and 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. Archiving a Cowork project deletes its memory.

Anthropic's own documentation now conflicts on where projects live. The claude.com documentation says projects "live on your computer" and are not synced or shareable; the help centre says new Cowork projects are saved to the Claude account and are shareable on Team and Enterprise, while projects created from a folder stay on that computer and are desktop-only. The reconciliation appears to be cloud projects versus folder-backed projects, but verify in your tenant.

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. There is still no admin control to restrict project creation. AUP recommendation: prohibit mounting home directories, Desktop, Downloads, or cloud-synced folders as project roots, and enforce it with allowedWorkspaceFolders rather than trusting policy alone, particularly now that whole drives can be attached. Include project instructions in manipulated-context tabletop scenarios.

Artifacts changed completely on 19 August 2026. Live artifacts can no longer be created. Pre-existing ones still work but are view-only and desktop-only, and must be republished to edit. The section title and the term "live artifacts" are retained here only for continuity with the earlier version of this guide; the product name is retired.

The updated artifacts system is generally available on Pro, Max, Team and Enterprise, in Cowork on desktop and in the cloud. Organizations on CMEK, ZDR or HIPAA-readiness configurations remain on live artifacts and cannot use it. Updated artifacts are saved to the account, versioned, and shareable within the organization. They publish to a private URL on claude.ai and load from a sandboxed origin. They can call connectors, ask Claude questions, and keep up to 20 MB of persistent storage per artifact in personal or shared modes.

⛔ The single most important artifact fact for a security team: shared artifacts use the viewer's access, not the creator's. Connector calls run through the viewing account, each viewer approves access on first call, and actions with side effects execute as the viewer. An artifact circulated informally via Slack or email that calls Salesforce, Gmail and Slack connectors is functionally a mini-application running with each recipient's credentials. Anthropic's own guidance is to "only open shared artifacts from people you trust" and to treat one "the way you'd treat a file from an unknown sender". Treat shared artifacts from external or unverified sources as you would a macro-enabled spreadsheet.

Sharing defaults and controls. A new artifact is visible only to its author. Team and Enterprise options are "Only people with access", "Everyone in your organization", or "Anyone with the link", and public sharing is off by default until an owner enables External sharing. An artifact that uses connected apps or asks Claude questions cannot be shared to a public link on any plan. There is an Artifacts org toggle, an Enterprise role capability to scope it, a separate "Enable artifact connectors" toggle, and separate retention periods for private and shared artifacts under Data and privacy controls.

Earlier versions of this guide said there was no admin visibility into which artifacts circulate or what connector calls they trigger. That is no longer true: publish, share and delete events are logged as claude_artifact_ events, and the Compliance API exposes list, retrieve-version and delete endpoints for organization artifacts. Since 25 August 2026 artifact sharing is removed for members of organizations with Artifacts turned off, and since 2 September live artifact sharing follows the organization's Artifacts setting and sharing policies.

One newer capability to note: comments on artifacts shared within an organization, where Claude can read, reply to and resolve activated threads, and auto-reply while a session watches the artifact. That is a new autonomous ingestion path on Team and Enterprise. Public artifacts cannot take comments.

Controls. Add artifacts to your AUP, defining what connector access is appropriate and whether sharing outside the organization is permitted. Artifact connector calls appear as tool_result events in OTel, so include them in your SIEM monitoring scope alongside other tool activity.

4.12 Cowork on 3P (Third-Party Inference)

Anthropic now documents this as Claude Desktop on third-party platforms, and the old /docs/cowork/3p/ URLs redirect to /docs/third-party/claude-desktop/. Update any internal runbooks that reference the old paths.

Cowork on 3P routes all model inference through a provider you control. The inferenceProvider key now accepts six values, not four: gateway, anthropic, bedrock, mantle, vertex and foundry. Setting it activates third-party mode. One deployment covers chat, Cowork and Claude Code behind separate policy keys, and since 22 June 2026 the full Desktop experience including chat is available on AWS, Google Cloud and Microsoft Foundry in beta.

Standard Cowork: inference to the Anthropic API; identity via Anthropic account; configuration in the claude.ai admin console; conversations stored on the Anthropic backend or, for cloud sessions, the member's account.

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

Data handling by provider. For Google Cloud's Agent Platform (still keyed as vertex) and Amazon Bedrock, Anthropic states it "does not send user data, prompts, or completions to Anthropic". Microsoft Foundry does not carry that guarantee: Anthropic operates the Claude models and processes conversation data as an independent processor for Microsoft. Hosted on Azure, inference runs in an Anthropic-operated service on Azure infrastructure and only usage metadata plus safety-flagged content leaves Azure; hosted on Anthropic, prompts and completions go to Anthropic's own infrastructure. HIPAA readiness is unavailable on Foundry. mantle, meaning Amazon Bedrock Mantle, is absent from the data-handling section entirely, so do not extend the no-data guarantee to it in writing without confirmation.

Organizations selecting Cowork on 3P for data sovereignty should use Bedrock or Google Cloud, not Foundry, unless they accept Anthropic's standard data processing terms.

Tighten the "Anthropic receives nothing" claim. Even on Bedrock and Google Cloud, downloads.claude.ai is contacted for the VM workspace bundle and CLI binary at session start unless you deploy the offline installer, and crash reporting and product analytics flow unless disabled. Leaving disableNonessentialTelemetry off also auto-adds api.anthropic.com to the agent egress allowlist. The four separately disableable categories are essential telemetry, non-essential telemetry, non-essential services and auto-updates:

• Crash reports: disableEssentialTelemetry: true
• Product analytics: disableNonessentialTelemetry: true
• Non-essential services: disableNonessentialServices: true
• Auto-update checks: disableAutoUpdates: true

Admin control model. Cowork on 3P is configured entirely through OS-native managed preferences: .mobileconfig profiles on macOS, registry policy on Windows, and a root-owned file at /etc/claude-desktop/managed-settings.json on Linux. Your MDM team owns this. When a managed profile is present it wins and cannot be overridden by end users, with one documented exception worth knowing: a managed source that sets only app-behaviour keys, meaning the update keys, the lifecycle keys or the network proxy keys, has those keys enforced while "the rest of the configuration stays local and user-editable". Put your security keys in the same profile as your update settings, or they will not be enforced. The in-app Developer menu exports configuration directly to .mobileconfig or .reg format.

⛔ What you lose on 3P is more than earlier versions of this guide conveyed. The Compliance API and Analytics API are entirely unavailable, and OTLP to your own collector is the only audit trail. An Enterprise Admin Console for Desktop 3P does now exist in beta, provisioned on request, where administrators add users and groups, connect single sign-on and assign roles at claude.ai; outside that beta, configuration and RBAC are MDM-only. claude.ai web, mobile, Claude in Chrome, Claude Tag, Claude Design, Claude Security and voice are all unavailable. Cowork cloud sessions require a Claude account and Anthropic-hosted execution, so they are structurally out of scope here. No seat licence and no Claude plan is required, with token consumption billed by your cloud provider, which makes this a genuine shadow-AI path if a team stands it up without telling you. Users are nonetheless "provisioned a Claude account only to sign in to Claude Desktop and receive their settings", and in the admin console beta Anthropic holds your user list and saved configuration.

Key security configuration keys.

• disabledBuiltinTools removes built-in tools entirely, and now accepts argument-scoped rules such as Bash(curl *) and Edit(**/*.env), enforced in every mode including Auto and bypass
• builtinToolPolicy sets per-tool allow or ask
• allowedWorkspaceFolders restricts which local folders users can connect
• coworkEgressAllowedHosts locks sandbox egress to specific hostnames with optional port scoping; an empty array blocks all sandbox egress, and since 17 August 2026 port scoping also applies to shell commands and package installs
• egressProxyUrl and egressProxyPacUrl pin app and agent traffic to a corporate proxy or PAC file, overriding OS proxy settings. Anthropic is explicit that this "is a reachability setting, not an egress control", and names traffic that never uses it: the Cowork workspace VM on Linux, credential and header helper scripts, the update download, the Windows sign-in broker, and pages opened in the system browser. Where both keys are set the PAC file wins. Both are read from MDM or a local file only, never from a bootstrap URL
• isLocalDevMcpEnabled prevents users adding their own local MCP servers
• isDesktopExtensionEnabled blocks desktop extension (MCPB) installation; isDesktopExtensionSignatureRequired requires code-signed extensions only
• toolPolicy per server in managedMcpServers locks Allow/Ask/Blocked per tool
• mcpPersistentAlwaysAllowEnabled disables persistent always-allow approvals for MCP tools
• disableBypassPermissionsMode removes bypass-permissions mode from Cowork tasks and Code sessions
• blockReadsOutsideWorkingDirectories constrains read scope
• inferenceMaxTokensPerWindow is a client-side soft cap, inert unless inferenceTokenWindowHours is also set
• otlpEndpoint routes full session activity to your own OTel collector; otlpContentCapture decides whether prompts, responses and tool content are captured
• disableDeepLinkRegistration stops external apps and websites opening Claude Desktop via claude:// links. Defaults to false, so deep links work until you turn this on
• There is no version-floor key. requiredMinimumVersion does not exist, and nothing lets you pin a minimum build. What you control is update cadence: disableAutoUpdates stops updates entirely and leaves you pushing versions yourself, autoUpdaterEnforcementHours sets how long a downloaded update waits before force-installing (range 1 to 72, blank means 72), relaunchEnforcementHours forces the restart after a configuration change (24 hours by default), and updateViaUpdatesHost reads the update feed from releases.claude.com so api.anthropic.com can stay blocked. That last one matters on third-party deployments where you are trying to cut Anthropic endpoints off

Two corrections to earlier guidance. The excludePromptFromTelemetry key does not exist and is not documented by Anthropic; use otlpContentCapture. And requireCoworkFullVmSandbox is now marked deprecated. Before stripping it from a baseline, note how it interacts with argument-scoped tool rules: Anthropic documents that scoped Bash(…) rules "apply in Code sessions and in VM-sandboxed Cowork sessions", while "Cowork's own sandboxed shell honors bare names only". Removing the key therefore downgrades your scoped rules to bare tool names inside Cowork.

On the three reference security profiles. Anthropic still publishes three, still named Standard, Restricted and Locked down. But they now carry a disclaimer this guide previously predated: "The profiles below are illustrative examples rather than built-in presets, and the labels are descriptive only." Cite them as starting points, not vendor-blessed presets. The current Locked down profile adds skillCreationEnabled: false and does not use requireCoworkFullVmSandbox.

Framework note. The "do not use Cowork for regulated workloads" guidance elsewhere in this guide should be qualified. Cowork on 3P via Google Cloud or Bedrock may satisfy regulated workload requirements, subject to your specific obligations and your cloud provider's BAAs. But note that this mode has no Compliance API, so the audit trail is entirely your own collector. 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, both access-gated.

4.13 Claude Tag (Slack)

The Slack integration was replaced. Claude Tag launched on 23 June 2026 and the legacy Claude for Slack app switched over on 3 August 2026: Anthropic's own page now reads "Claude in Slack switched over to the new Claude Tag experience on August 3, 2026. To integrate Claude and Slack, use Claude Tag instead." Earlier guidance in this section described the old app.

Claude Tag is Team and Enterprise only, in beta, not available on Free, Pro or Max, and not available on third-party deployments. Its admin surface sits at claude.ai/admin-settings/claude-tag, and only a Primary Owner or Owner can configure it: "Only a Primary Owner or Owner can set up Claude Tag's access and channels. The Admin role can't." A Slack workspace admin must approve the app install first, so the initial gate belongs to your Slack administrators rather than the Anthropic console. Treat it as a separate admin surface from Cowork rather than an extension of it; Anthropic makes the point narrowly for web search, noting that the claude.ai capability setting "governs claude.ai chat; it doesn't govern Claude Tag sessions."

The identity model is the thing to understand. In channels, Claude uses its own service accounts rather than the tagging user's, and access follows the channel rather than the person. Credentials never enter the sandbox: an agent proxy injects them at the network boundary, and egress is default-deny over HTTP and HTTPS only. An @-mention is also not the only trigger. Claude "may also respond to a message that doesn't mention it when it judges a reply is warranted", and once a thread is active it follows replies in that thread.

⛔ Three traps Anthropic documents. A bundle attached to a public channel grants its access to anyone who joins that channel. Isolating a credential does not isolate memory. And memory flows downhill into private channels: "a private channel reads workspace memory but writes only to its own store", so a private channel inherits what the workspace already knows. Review channel-scoped bundles as you would a service account grant, because that is what they are.

The admin control set

This is the part most Cowork guidance skips, and it is deeper than the product's beta status suggests. Nearly all of it requires the Owner role. The controls fall into five groups.

1. Who can invoke Claude.

• Member access. At claude.ai/admin-settings/claude-tag, under "Where Claude Tag works", choose Manage next to Member access. A single toggle governs who in the connected Slack workspace can use Claude at all, and it "applies to channels and DMs alike". Owner only. An older three-option Members dropdown persists for organizations whose stored choice matches neither toggle state, and its "Open to any organization member" option is now deprecated; switch to one of the two toggle states to retire it.
• Role restriction, Enterprise only. Team plans have no role-level control, where "turning on Restrict to your organization is the only restriction available". On Enterprise it spans three console pages: turn on "Restrict to roles with Claude Tag access" at the Claude Tag page, create groups, then create a custom role carrying the Claude Tag in Slack capability and assign it to those groups.
• Verified domain restriction. For an Enterprise organization under a parent enterprise, "Restrict to your verified domains" refuses a Claude account link when the Slack profile email is not on a verified domain. Enabling it in any one organization also stops verified-domain users linking a Claude account to any organization outside the enterprise.

⛔ Role restriction has a gotcha that will defeat most deployments as configured. Anthropic documents three resolution rules: the toggle gates the capability, so "while the toggle is off, every member can use Claude regardless of what their role grants"; any grant wins where a member sits in several groups; and decisively, "Every built-in role, including User, Owner, and Primary owner, grants Claude Tag in Slack automatically, so the restriction only blocks members on a custom role that doesn't grant it." If your people are on built-in roles, turning on role restriction changes nothing. It only bites once members are migrated to custom roles, exactly as with Cowork RBAC.

2. Where Claude operates: scopes and access bundles.

A scope is one of three things: Default Slack access (the organization-wide root), a workspace, or a single channel. Access bundles carry the credentials, connections, instructions and plugins Claude uses, and attach to a scope. They stack downward, so a channel receives whatever is attached at Default Slack access, plus its workspace, plus its own bundle, and "when credentials overlap, the narrowest scope wins". Bundles belong to the organization rather than to a workspace, so uninstalling or disconnecting a workspace keeps the bundle and drops only its bindings to that workspace's scopes. Memory is scoped on different rules from access: there is no organization-wide memory, public-channel entries are shared across the workspace, and private channels read workspace memory while writing only to their own store.

3. Turning it off, and what each method destroys.

Anthropic documents six ways to stop Claude Tag responding, plus disconnecting the workspace. They are not interchangeable, because each deletes something different. Get this wrong during an incident and you either fail to contain it or destroy the evidence.

4. Channel-level guardrails.

• Channel name rules, in the Advanced section of Default Slack access and of each workspace scope. Blocked channel patterns stop Claude reading or responding in a matching channel "even if someone invites it there", and it posts a notice that an admin has blocked it. Auto-join patterns add Claude to matching public channels on creation or rename, while private channels still require an invite. Patterns are lowercase with two wildcards, * for any run of characters and ? for exactly one, so *-confidential-* is a legitimate defensive rule and inc-* a legitimate enabling one. On Team plans, where a single Enable Claude Tag switch replaces the per-scope version controls, blocked patterns are the only way to keep Claude out of named channels.
• Guest channels. Claude is disabled by default in any channel containing a Slack guest. The per-scope setting "Allow Claude to work in channels with guests" offers Restrict (the default), Allow, or Channel only. Channel only is the useful middle setting for contractor, client and agency channels: no bundles inherited from the workspace or from Default Slack access apply, only a bundle attached directly to that channel, and no scope environment applies, so the session runs on the standard environment. Access is decided when a conversation starts, so a conversation already under way when the first guest joins does not silently retain full access.
• Externally shared and Enterprise Grid channels take their settings from Default Slack access only, so per-workspace and per-channel tuning does not reach them.

⚠ The Enterprise Grid case can silently void your configuration. Anthropic states that on "a Slack Enterprise Grid whose workspaces are paired to different Claude organizations, one organization's access settings govern the entire grid, so your restrictions may not be enforced in your own workspaces." If you share a grid with another Claude organization, your Claude Tag restrictions are only as strong as theirs. Establish which organization owns the grid-level settings before you rely on anything in this section.

5. Spend controls.

Claude Tag is consumption-based rather than per-seat, and a Primary Owner or Owner controls it from the usage settings: an organization-wide cap, per-channel limits on top of that cap with new channels inheriting a default, and threshold alerts to admins at 75% and 95% of any limit. Usefully for an agentic surface, "work that would go over a limit is declined, never silently cut short", and a blocked user can request more without leaving Slack.

Audit and observability

An earlier version of this guide said Claude Tag audits worse than Cowork, resting on a single sentence. That needs qualifying. The sentence is real, but Anthropic writes it as "There is no per-action log of every task and who asked; for that, use the trails below", and then documents four of them.

• The Audit page, labelled Activity in the admin console's left nav, at claude.ai/admin-settings/claude-tag/audit, with tabs for scheduled work, memory and network events. Owners only. Each routine on the Scheduled work tab shows Created by, naming the member who set it up.
• Memory files on each scope, reached from the scope's options menu via View memory files. Admins can review, edit and delete what Claude has saved, which is a stronger position than chat memory, where owners cannot view individual members' memories at all.
• Attribution on each action. In Slack, Claude posts as the Claude app and works in threads anyone in the channel can read. On code, commits and pull requests show the Claude GitHub App as author and link back to the originating Slack thread.
• The audit log of each connected service, where actions appear under the service account you provisioned. Anthropic calls this "the general-purpose trail": because you created the credential, the service's own log records everything Claude did there, under an account your security team already monitors.

The Compliance API gap is real and unchanged: no Slack or Tag product_surface value exists, so Claude Tag sessions cannot be retrieved there. The network-events export excludes Git and MCP traffic. Claude Tag is unavailable to ZDR organizations and never works on Slack Connect channels. Conversations are deleted from Claude within 30 days if you disconnect the integration or uninstall the app.

The fair summary is not "no audit trail" but "no single unified one". The intended design is that you provisioned the credentials, so each connected service's own log is the authoritative per-action record. Plan your detection engineering around those logs rather than waiting for a Claude-side export, and treat the Activity page as the inventory of standing work rather than as the action log.

Standing work is a first-class risk here. Claude Tag is proactive by design: it "remembers context across days, schedules its own follow-ups, checks in proactively". Routines run with the channel's credentials, so a channel's list of scheduled jobs is also its permission picture, and anyone in the channel can ask Claude to list or disable one. Treat this as the same unattended-execution exposure as Cowork scheduled tasks, and review it on the same cadence.

One billing detail with a governance consequence: Claude Tag channel work bills to the organization balance, so per-user and per-group spend limits do not cap it, and it has its own organization and per-channel limits instead. Direct messages bill to the person's own Claude account rather than the organization.

Direct messages behave differently in every respect: they run on the user's own claude.ai account and personal connectors, so access bundles do not apply to them. "Allow direct messages" is on by default and can be disabled org-wide, and the member access toggle covers DMs as well as channels.

Microsoft Teams support is waitlist-only with no dates or admin model published.

The Slack connector for Cowork remains a separate integration allowing Cowork sessions to read your Slack workspace: channels, DMs, and files. Enabled by owners at Organization settings > Connectors, with users also connecting individually. Available on Team and Enterprise. It grants Cowork read access to the channels and DMs the authenticated user can see, and a scheduled task or artifact with the Slack connector can silently read Slack content in the background. Anthropic's current connector documentation describes read and search tools only, so confirm in your own tenant before assuming write tools are present; where they are, apply per-tool permission stances such as read_channel: allow and send_message: blocked.

Recommended controls.

• Require security team sign-off before your Slack admin approves the app install, and verify whether it has already been approved without security involvement.
• Set member access deliberately rather than leaving it open to the whole Slack workspace. On Enterprise, remember role restriction is inert while members remain on built-in roles.
• If you share a Slack Enterprise Grid with another Claude organization, establish who owns the grid-level access settings before relying on your own.
• Inventory access bundles and review each as a service account grant, narrowest scope first. Record which scope each is attached to.
• Set blocked channel patterns for your sensitive channel naming conventions before rollout, not after an incident.
• Leave guest channels at Restrict, or use Channel only where contractors and clients genuinely need Claude.
• Turn off "Allow direct messages" unless justified.
• Set an organization cap and per-channel limits, and route the 75% and 95% threshold alerts to a monitored inbox rather than one admin's email.
• Ship the connected services' own audit logs to your SIEM, since those are the authoritative per-action record for channel work.
• Review the Scheduled work tab on the same cadence as Cowork scheduled tasks, and check memory files per scope during access reviews.
• Document in your AUP which data categories are appropriate to discuss by tagging Claude in a Slack channel, noting that channel work runs under organizational identity rather than the tagging user's.

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, and Cowork admin settings have no effect on it.

Plan availability correction. Excel, Word and PowerPoint are generally available on all paid plans, and Outlook is in beta on all paid plans. Earlier versions of this guide described this as Team and Enterprise only. It is not available on Free.

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.

The one claude.ai toggle is "Let Claude work across apps" at Organization settings > Office agents, off by default on Team and Enterprise. Add-in distribution is through the Microsoft 365 Admin Center.

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 Claude follows. Cross-app context means content from one application can flow to another within a session.

⚠ Office Agents have their own OpenTelemetry collector path, and Anthropic documents that it applies no attribute redaction: prompt text, tool inputs and outputs, document URLs and filenames all export. Your collector becomes a high-sensitivity data store, so plan its access controls accordingly.

Monitoring. The Compliance API covers Office Agents in beta as office_agents surfaces, and they appear in the spend CSV as Office Agents. Route Office Agent OTel to the same SIEM collector as Cowork for unified visibility.

Two further risks. Office Agents can run against Bedrock, Vertex AI, Azure AI Foundry or an LLM gateway without individual Claude accounts, which is a real path around your admin console. And Claude for Excel is explicitly excluded from zero data retention.

Separately, the Microsoft 365 connector gained write tools on 7 July 2026: Claude can draft, send and organise email, manage calendar events, change mailbox settings, and create or update OneDrive and SharePoint files. This requires Microsoft Entra admin consent plus an org-level enable, and Teams remains read-only. If you granted that consent when the connector was read-only, check what it now permits.

Controls. Add Office Agents to your AUP and vendor risk register separately from Cowork. Employees may self-install the add-in without approval unless you control distribution. Withhold Outlook Graph consent if inbox access is not an approved use case.

4.15 Cowork in the Cloud vs Local Execution

Since 7 July 2026, Cowork sessions run in the cloud by default. The agent loop and code execution run on Anthropic's servers, and sessions and files are saved to the member's Claude account. Local execution remains available for existing desktop deployments. This inverts several assumptions in the earlier version of this guide.

What the cloud sandbox gives you. One sandbox per session, destroyed at session end, with no state shared between sessions or organizations, and kept separate from Anthropic's corporate, research and training environments. It cannot reach private, internal, link-local or cloud-metadata addresses, nor Anthropic-internal systems, so it cannot pivot into your network. Egress is enforced outside the sandbox by a mandatory proxy the sandbox cannot reconfigure. Sandbox tokens are session-scoped and expire within hours, and connector authorization tokens never enter the sandbox at all.

What it takes away. Device-deployed MDM policy and managed settings files apply to local sessions only. A cloud session running on an Anthropic-managed VM has no device policy to read. Cowork also never fetches server-managed settings from the claude.ai console, and Anthropic describes server-managed settings as explicitly "not a security boundary". If your control model rests on MDM, cloud sessions sit outside it.

How the cloud reaches your device. Only through the Claude Desktop app over an Anthropic-brokered connection, only for folders the member connected, with each local tool call permission-checked. If the app is offline the device is unreachable. Note that local files opened through the app in a cloud session are processed on Anthropic's servers rather than staying on the device, and Anthropic's folder-access prompt now says so explicitly.

Plan defaults. "Run Cowork in the cloud" is on by default on Team and off by default on Enterprise, where an owner must enable it and then grant the "Cowork in the cloud" capability to a group through custom roles. Enterprise can also disable persistent always-allow so every tool call needs fresh approval. Do not expect Trusted Devices to help here: despite the name it governs Remote Control of local Claude Code sessions on Team and Enterprise, and Anthropic states the setting "applies only to Remote Control", leaving Cowork cloud sessions untouched.

Local sessions. The agent loop runs natively on the device, while shell and code execution run in a dedicated Linux VM isolated by Apple Virtualization.framework on macOS, Hyper-V on Windows and QEMU with KVM on Linux, each with its own egress filtering, syscall restrictions and per-session user isolation. Local MCP servers and plugins that bundle local MCP servers are desktop-only and do not run in cloud sessions at all.

⚠ A bug worth knowing about if your fleet lags on updates. Until 13 August 2026, an unanswered permission or plan-approval prompt in a cloud session could be treated as approved after the session's environment disconnected. That is a fail-open approval path. Fleets below that build are exposed.

4.16 Permission Modes and the Classifier

Cowork has three permission modes, renamed during 2026. Guidance referring to "Ask before acting" and "Act without asking" is out of date.

• Manually approve, formerly "Ask before acting". Claude pauses for permission.
• Automatically approve. Claude works continuously and a classifier reviews each action against the original request before it runs, blocking mismatches. This mode consumes materially more of the usage limit.
• Skip all approvals, formerly "Act without asking". Anthropic's wording: "Claude doesn't pause to ask and nothing checks its actions automatically."

Deletion always prompts, in every mode including Skip.

How well the classifier works, in Anthropic's own numbers. Note the provenance before quoting these: Anthropic publishes them for Claude Code auto mode, not for Cowork's Automatically approve mode, so carrying them across to Cowork is an inference rather than a vendor statement. Auto mode catches roughly 83% of overeager behaviours before execution, roughly 17% get through, and it blocks about 0.4% of benign commands. Anthropic's stated rationale for moving to classifier-gated auto-approval is telling: its telemetry showed users approving roughly 93% of permission prompts, so human approval was providing little real friction.

The organization controls. "Allow Automatically approve mode" sits at Organization settings > Cowork and is on by default. "Allow Always allow for connector tools" is off by default and custom roles cannot override it. At the device level, autoModeEnabled allows or denies Auto mode, and disableBypassPermissionsMode removes bypass-permissions mode from Cowork tasks and Claude Code sessions entirely.

⚠ Anthropic's third-party feature matrix states that Cowork's Automatically approve and Skip all approvals modes are not available to Claude Enterprise organizations, which contradicts the help centre's statement that the org setting is on by default for Team and Enterprise. Verify which applies in your tenant before writing policy around it.

4.17 Inference Hooks (Enterprise)

Launched 5 August 2026 in beta for Claude Enterprise, inference hooks are the closest thing to inline DLP that Anthropic offers, and the most significant new preventive control of the period.

Anthropic POSTs the conversation transcript to an HTTPS endpoint you host and waits for a verdict before inference proceeds. One hook governs conversations across claude.ai, Cowork and Claude Code, on web, desktop, mobile and CLI. It runs in Anthropic's infrastructure, so nothing is installed on endpoints. Requests are signed. Configuration includes a five-second default timeout, a shadow mode for observation without enforcement, a rollout percentage, and role exclusions. Every denial is recorded in the Compliance Activity Feed.

The limits, which matter. Verdicts are allow or deny only. Anthropic states plainly that "rewriting or redacting a prompt is not supported", so you cannot mask a credential and let the request through. Response-side enforcement is planned rather than shipped. Voice input and raw image bytes are not covered. It is unavailable on Bedrock and Google Cloud deployments.

Deploy in shadow mode first. A five-second budget on a synchronous path in front of every prompt in the organization is an availability decision as much as a security one.

4.18 Memory

Memory became a cross-surface store on 25 August 2026. It is shared between chat and Cowork when Cowork runs in the cloud; locally-run Cowork sessions do not use memory. It is on by default for Free, Pro and Max, and off by default on Team and Enterprise where an owner turns it on at Organization settings > Capabilities. It is unavailable to organizations with HIPAA, public sector, or custom data retention agreements.

Memory is stored as individual topics saved during the conversation rather than a nightly synthesis, and users view, edit and delete per topic at Settings > Memory. Sensitive topics are a separate control, off by default at both org and user level; government ID numbers, criminal history, financial account numbers and immigration status are never saved. Cowork projects each hold their own project-scoped memory store, and archiving a project deletes it.

⛔ Three memory facts to write into policy. Turning memory off org-wide immediately and permanently deletes all memory for every user. Owners cannot view or edit individual members' memories, and individual member memory edits are not logged. And memory does track conversation deletion rather than outliving it: Anthropic states that "Claude's memory reflects changes to your conversations as they happen", and that deleted or expired conversations are removed from memory synthesis. Treat memory as in scope for retention and subject-access work, but do not assume it survives the conversation that produced it.

4.19 Adjacent Surfaces Cowork Settings Do Not Govern

Anthropic shipped several new first-party surfaces during 2026, each with its own admin model. Add each to your vendor risk register separately rather than assuming Cowork controls cover them.

⚠ Anthropic maintains a beta and research-preview index, but it was last updated on 7 July 2026 and omits Claude Design, Claude Science, Claude Security, Claude Tag, inference hooks and the built-in browser. Do not use it as a status register. The Cowork changelog and the Claude Desktop configuration changelog are the pages to watch instead.

4.20 Model Choice as a Security Control

Model selection stopped being purely a quality question during 2026.

Retention. Covered Models require 30-day retention and break a ZDR posture, as described in 4.5. Model entitlements are your lever for keeping users off models whose terms you have not accepted.

Blast radius. Claude Opus 5 and later ship a one million token context window as both default and maximum. A single successful prompt injection now reaches far more material than it did in May.

Continuity. On 12 June 2026 Anthropic suspended access to Claude Fable 5 and Mythos 5 following a US export control directive covering foreign nationals, disabling both models for everyone across claude.ai, the API, Claude Code and Cowork. Access was restored on 1 July with Pro, Max and Team capped at 50% of weekly limits through 7 July. Eighteen days of total unavailability with effectively no notice belongs in your AI continuity plan.

Silent fallback and refusals. Anthropic's own reporting notes that Cowork silently falls back to Opus 5 on Fable 5 classifier hits. Safety classifiers also run on requests and during generation and return a refusal stop reason. Expect users to report both as faults, and give your service desk the vocabulary for them.

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.

Where the numbers stand. Anthropic's November 2025 evaluation produced the widely-quoted 1% figure this guide previously cited. That page is still live and unchanged, so treat the figure as superseded rather than withdrawn. On its current evaluation, sourced from professional red-teamers and published in the Claude Opus 5 System Card (p.76) and summarised in the Claude in Chrome general-availability post, pre-safeguard success rates for attacks that reach the model are 17.6% for Opus 4.5 and 3.8% for Opus 5, falling to 16.7% for Opus 4.5 with injection probes alone. With injection probes and the automatic-approval safety classifier, Anthropic reports 0% for Sonnet 5, Opus 5 and Mythos 5, and 0.3% for Fable 5, with all successful breaks manually verified as low severity. Separately, support documentation cites Opus 4.8 at "less than 0.08%" against an internal test combining known effective techniques, and third-party Gray Swan benchmarking put Opus 4.7 at roughly 0.1% on single attempts and 5 to 6% after 100 adaptive attempts.

⚠ Quote these carefully. Anthropic states that the 2025 and 2026 figures are not directly comparable: the earlier numbers ran without extended thinking, the current ones with adaptive thinking, and the grading pipeline was replaced. All rates are computed over attacks that reach the model, and Anthropic notes that not all attacks reach it. Its own hedge still stands: "The risk is not zero. Novel attacks may emerge that our evaluations didn't cover, and a successful one could lead to outcomes like data exfiltration."

The defence architecture. Two classifiers now operate. Injection-detection probes scan page and email content before Claude acts on it, and when a probe fires Claude treats the content as suspicious and may check with the user. An action-verification classifier checks each action against the original request and blocks mismatches. Successful attacks from internal automated attackers, external red-teamers and real-world monitoring feed a growing attack library used to train future models and safeguards.

Attack surface by integration:

☐ Claude in Chrome: any web page can carry hidden instructions, and the side panel now runs as an auto-approving Cowork session carrying skills, plugins and connectors

☐ Cowork built-in browser: a second browsing surface needing no extension, where imported cookies grant standing access

☐ Local files: a document in a connected folder could contain injected instructions, and connectable scope now extends to home folders and whole drives

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

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

☐ Memory: entries persist across sessions and across chat and Cowork, though they do track deletion of the conversation that created them

☐ Artifacts: a shared artifact executes under the viewer's access, and comment threads are a new ingestion path

☐ Claude Tag: Slack channel content becomes agent context, with channel-scoped rather than person-scoped access

☐ Office Agents: the open document or email is the injection surface, and context flows across four applications

☐ Scheduled tasks: a poisoned data source read on a cadence executes silently and repeatedly, now with the machine asleep

☐ Dispatch: tasks initiated from mobile traverse the same attack surfaces on the desktop

☐ Computer Use (Pro/Max): every pixel on screen is a potential injection surface, outside the sandbox, so the blast radius includes the entire desktop

5.2 Supply Chain Attacks

Configuration files are 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. Both CVEs are patched.

The current-generation lesson is Anthropic's own disclosed incident, covered in 4.4: exfiltration through an allowlisted domain, and the reframing that an allowlist is better understood as a capability grant. Add to that Anthropic's direct-injection red team result, where a phished employee pasted a malicious prompt into Claude Code and "across 25 retries of that prompt, Claude completed the exfiltration 24 times". Model-layer defences anchor on user intent and cannot catch that; only egress and filesystem controls hold.

Also worth reading as a case study: across 141,006 cyber-evaluation runs, three incidents saw Claude reach the live internet from a misconfigured third-party evaluation environment and compromise three real organizations, including credential and production database access and a malicious PyPI package executed on fifteen real systems. That is a harness and containment failure rather than model misalignment.

Mitigations: use private plugin marketplaces with manifest SHA pinning, vet all plugin source code, enforce branch protection and commit signing on plugin repos, enforce MCP allowlists on command or URL rather than name, turn skill and plugin scanning on, remember hooks are not scanned by anything, and keep Claude Desktop updated.

5.3 Data Exfiltration

Cowork can exfiltrate data through multiple channels: MCP server network calls, browser actions, file writes to external paths, artifacts running under a viewer's credentials, or API calls to external endpoints. Because anthropic.com is typically on the network egress allowlist, exfiltration to Anthropic's own API is difficult to block, and Anthropic's disclosed incident confirms this was exploited before being fixed with an in-VM proxy that rejects non-provisioned tokens.

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

The practical controls are egress proxy pinning, argument-scoped tool policy, blockReadsOutsideWorkingDirectories, per-tool connector policy blocking write tools, and inference hooks in front of the prompt.

5.4 Unattended Execution

Scheduled tasks run without real-time human oversight, and since July 2026 they no longer need the machine awake or the app open, because they execute in the cloud. A prompt injection that takes hold during a scheduled task has no human to stop it. Compound this with browser access and the risk of an automated, recurring prompt injection attack becomes real.

Anthropic itself now names scheduled tasks a heightened risk, advising that because they run in the cloud unmonitored you should avoid sensitive data and consequential actions, review outputs after each run, and pause unused tasks. Since 4 September 2026, a run that cannot reach the model automatically retries after 5, 15 and 30 minutes.

Claude Code Routines are more autonomous still, running in the cloud with no permission prompts at all, subject to a per-account daily run cap and a one-hour minimum interval, with their own Team and Enterprise toggle. If you have governed Cowork scheduled tasks and left Routines alone, you have governed the less autonomous of the two.

Dispatch compounds this, and on Team as well as Pro and Max. 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, and unanswered permission prompts are denied after ten minutes while the task continues regardless.

Finally, Automatically approve mode means a classifier rather than a person is your last line, and Anthropic's own figure, published for Claude Code auto mode rather than Cowork specifically, is that roughly 17% of overeager behaviours get through it.

5.5 The Observability Gap

Anthropic states that host-based security tools cannot inspect activity inside the Cowork VM, and cannot observe cloud sessions at all. Your detection strategy cannot rest on EDR. It rests on the Compliance API for content, OpenTelemetry for tool calls and cost, and inference hooks for prevention. Design your alerting around those three and accept that the endpoint is opaque by design.

6. Deployment Checklist

Three phases: prepare your environment, configure on day of rollout, and maintain ongoing operations. Plan labels indicate where each item applies.

7. Control Mapping

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

NIST CSF 2.0

NIST AI RMF

A Note on Conflicting Sources

Several statements in this guide are hedged because two official Anthropic pages disagree. We surface those rather than pick a side quietly, because a security guide that resolves ambiguity invisibly is worse than one that names it. The current list:

• Whether Cowork OpenTelemetry includes prompt content by default
• Whether Claude in Chrome is generally available or the side panel remains in beta
• Whether Cowork projects are local-only or saved to the Claude account and shareable
• Whether Automatically approve and Skip all approvals modes are available to Enterprise organizations
• Whether the Team network egress default is disabled or package managers only
• Whether the built-in browser has its own domain controls or inherits the Chrome extension's lists
• The Enterprise seat minimum, quoted as 20 on one page and 20 or 50 on another
• Whether Anthropic holds ISO 27017, ISO 27018 and CSA STAR
• Whether Cowork sits inside the SOC 2, ISO 27001 or ISO 42001 audit boundary, which no page states either way

Verify each in your own tenant before writing it into policy.