How to Govern Claude Cowork: Org Settings, MDM, and OpenTelemetry in Four Layers

Cowork reached general availability on all paid plans on April 9, 2026, alongside a set of enterprise controls: groups, custom roles, spend limits, usage analytics, and OpenTelemetry. Before any of that, there is one premise to internalize. Cowork has two session types that execute in different places, and that distinction determines where history is stored, which audit channel applies, and what your security tooling can see.

The practical takeaway: if your organization uses Cowork primarily through the desktop app, nothing is recorded on the organization's side unless you configure telemetry. With that premise set, here are the four layers.

Organization-side controls live under Organization settings > Cowork in the admin console. The top-level switch is "Enable for your organization." How fine-grained you can get below that depends on the plan.

• Team — all-or-nothing. The toggle applies to every member; there is no per-team carve-out.
• Enterprise — organize users into groups (manually or synced via SCIM from your identity provider), then use custom roles to enable Cowork for specific teams only.

Cloud sessions (the "Run Cowork in the cloud" toggle) have opposite defaults per plan: on Team it is on by default (owners can disable it anytime); on Enterprise it is off by default, and owners must enable it and then grant the capability through custom roles. If an Enterprise user reports that Cowork doesn't work from the web, check this default first.

Next, approval policy. The "Allow 'Always allow' for connector tools" toggle under Organization settings > Cowork > Permissions decides, org-wide, whether members may skip per-task approval for write-capable connector tools. Turn it off and every write action requires an explicit approval, every time. Read-only tools bypass approval only when the connector explicitly annotates them as read-only. On top of that, Enterprise admin controls include per-tool connector restrictions — for example, disabling write operations within a connector organization-wide while leaving reads available.

• Plugins — owners create plugin marketplaces and control distribution through four levels: "Installed by default," "Available," "Required," and "Not available." On Enterprise this can be customized per group.
• Network access — the Code execution settings under Organization settings > Capabilities control which external destinations sessions can reach. Changes apply to new sessions only, and the web fetch / web search tools are exempt from these egress rules.

Organization settings govern what happens after sign-in. The device-side boundary comes from Claude Desktop's managed policies, available to Team and Enterprise admins. On macOS, deploy configuration profiles under the domain com.anthropic.claudefordesktop (Jamf Pro, Kandji, Intune). On Windows, deploy via Group Policy or Intune to machine-level (HKLM) or per-user (HKCU) registry paths — machine-level wins.

The two keys to deploy first are forceLoginOrgUUID and allowedWorkspaceFolders. The former closes the path where Cowork runs under a personal account your organization can't see; the latter bounds the blast radius of a mistake or a prompt injection to the folders you chose to expose. The MCP and extension keys are a choice of where to govern connectors: per-action approval on the organization side, or a blanket device-side block.

As an agent that drives tools autonomously, Cowork burns tokens less predictably than Chat. The cost lever depends on your plan's billing model. On Enterprise (usage-based), every token is metered, so the backstop is group spend limits set from the admin console — per-team budgets you adjust as adoption grows. On Team, Cowork usage draws from each seat's included allowance, and overage is governed by the org- and member-level limits on usage credits. For choosing between the plans themselves, see our companion post Claude Team vs. Enterprise.

For visibility, there are two official surfaces. The admin dashboard shows Cowork sessions and active users across date ranges, and the Analytics API goes deeper: per-user Cowork activity, skill and connector invocations, and DAU/WAU/MAU, alongside Chat and Claude Code data. Use the Analytics API for scheduled reporting; use telemetry (next section) when you need to see what sessions actually did, in near-real time.

There are two official audit channels. First, the Compliance API (Enterprise). Cowork used to be excluded, but web and mobile cloud sessions are now captured in the same audit trail as Chat, with every session attributable to an individual user. SIEM and DLP integrations ride on this channel.

But per the premise above, local desktop sessions are not covered by the Compliance API. Their conversation history lives on the device, outside standard data-retention policies, and cannot be centrally managed or exported. The only official channel for observing local sessions at the organization level is OpenTelemetry.

Cowork's OpenTelemetry export is available on Team and Enterprise plans. Version requirements: Claude Desktop v1.1.4173+ for local sessions, and v1.22209.3+ to capture cloud (web/mobile) sessions. An admin configures it under Organization settings > Cowork, and there are only three fields.

OTLP endpoint:   https://collector.example.com     # your collector URL
OTLP protocol:   HTTP/protobuf                      # or HTTP/JSON (gRPC not supported)
OTLP headers:    Authorization=Bearer <token>       # auth headers, encrypted at rest

Two properties matter. First, no data flows by default — events are exported only after an admin configures an endpoint. Second, what flows is not just metrics; it is the substance of each session.

• Full text of user prompts
• Tool and MCP invocations — server name, tool name, parameters, success or failure, execution time
• File access — paths read or modified
• Skills and plugins invoked
• Approval decisions — approved by the user, rejected, or executed automatically under an existing permission
• Per-request model, token counts, estimated cost, duration, and errors

Events share a prompt.id attribute, so everything triggered by one instruction can be reconstructed as a single trail, and attributes include the user's email address for attribution. The stream feeds standard SIEM pipelines (Splunk, Cribl, and the like) and runs in parallel with the Compliance API, joined on user identifiers.

Here is the four-layer model turned into a deployment sequence. The one non-obvious rule: turn on observability (OpenTelemetry) before you roll Cowork out. Telemetry records only from the moment it is configured — add it later and the early-adoption data you most wanted is gone for good.

1. Decide the policy — who gets Cowork (on Enterprise, start with group design), whether cloud sessions are allowed, and whether "Always allow" is acceptable for write-capable tools.
2. Deploy MDM first — force organization accounts with forceLoginOrgUUID, bound mountable folders with allowedWorkspaceFolders, and set secureVmFeaturesEnabled to false on device groups that shouldn't have Cowork at all.
3. Configure OpenTelemetry — enter the endpoint, protocol, and auth headers under Organization settings > Cowork, and confirm events arrive using a test user.
4. Enable in organization settings — org-wide on Team; pilot group first on Enterprise. Verify the cloud-sessions default (Team: on / Enterprise: off) matches your intent.
5. Start with strict approvals — disallow "Always allow" and require per-task approval at first; loosen once the workflow proves itself. Going the other direction is much harder to sell.
6. Watch spend and usage — usage distribution via the dashboard and Analytics API, execution detail and cost via telemetry; adjust group spend limits and scope as you learn.

If you already govern Claude Code with telemetry, step 3 is just reusing the destination. If not, our companion post on Claude Code cost governance walks through that implementation.