Research
Field guideUpdated May 6, 202618 min

Securing Claude Cowork: An Enterprise Runtime Primer

Claude Cowork is not just chat in a desktop shell. It is a local agent runtime with file access, plugins, connectors, MCP reach, browser paths, and delegated work that can outlive a single prompt.

Thesis

The right security model for Claude Cowork is action-centric: bind every observable tool event to the user, workstation, workspace, plugin, MCP server, policy, verdict, and retained evidence before the action becomes business impact.

Claude Coworkruntime securitypluginsMCP

Technical readout

Cowork runtime control model

Cowork brings useful autonomy to the employee desktop. The enterprise control plane has to separate what the agent can see, what it can do, which path exposed the action, and whether the event is enforceable before execution.

workspace and workstation

Which desktop, Cowork workspace, local session, user, and organization owned the action?

AgentKeeper registers Cowork workstations, checks hook health, records workspace IDs, and keeps session metadata tied to the same host model used by Claude Code.

plugin and MCP provenance

Was the action produced by a local plugin, custom connector, MCP server, built-in tool, or screen/browser fallback?

Normalize Cowork tool events into a shared action vocabulary while preserving source_tool=cowork, plugin names, MCP server hints, and the raw bounded context needed for investigation.

semantic operation

Is the action a read, write, shell-like operation, web fetch, prompt, or external tool call?

Map Cowork payloads into Runtime Shield actions such as Read, Write, Edit, Bash-like command, WebFetch, and MCP tool use so existing path, command, and tool policies apply.

pre-action verdict

Can policy decide before the tool touches files, SaaS data, credentials, or a connected service?

Use hooks where Cowork exposes the event, gateway control where calls need a managed middle point, and explicit product copy for blind spots that require endpoint, browser, SaaS, or identity controls.

Research artifact

Cowork enterprise control surface

A realistic Cowork rollout has several separate paths. Treating them as one monolithic desktop app creates blind spots.

Risk or surfaceObserved signalAgentKeeper controlEnterprise companion control
Local file and workspace actions

Read, Write, Edit, path, current working directory, workspace, user, and host when exposed by supported hooks.

Path restrictions, sensitive-read auditing, normalized file events, workstation ownership, and redacted activity trails.

MDM file grants, backup policy, endpoint DLP, scoped working folders, and least-privilege local accounts.

Plugins and local MCP

Plugin or MCP tool name, server hints, operation payload, source_tool=cowork, session ID, and host identity.

MCP activity, tool policy, plugin posture, inventory where the endpoint can report it, and pre-execution Runtime Shield checks.

Plugin review, signed artifacts, network allowlists, package provenance, and SaaS-side audit logs.

Remote connectors

Connector usage may originate from Anthropic infrastructure rather than the local workstation, depending on the connector path.

Correlate what Cowork exposes and use gateway patterns where the enterprise controls the upstream integration.

OAuth scopes, SaaS audit logs, connector allowlists, app consent governance, and identity conditional access.

Computer and browser use

Some events are visible only after they become network, file, or application side effects.

AgentKeeper should record observable tool and network paths, but it should not claim pixel-level omniscience.

Managed browser, app blocklists, endpoint telemetry, screen-use approvals, and user training for irreversible actions.

Research artifact

Cowork hook delivery chain

The operational health check should prove more than installation. It should prove that Cowork invoked the hook, the hook reached AgentKeeper, policy evaluated the payload, and evidence landed in Activity.

1

Install

evidence

The AgentKeeper Cowork installer places hook scripts in the user profile and installs plugin manifest hooks into the Cowork workspace.

Status shows hook script, API key, marketplace hook, cache hook, manifest hook, and Cowork plugin enabled.

2

Restart and task

evidence

Cowork must be fully quit and relaunched so its runtime loads the embedded manifest hook for a new session.

The status script records a recent last hook invocation with hook_event_name=PreToolUse and a concrete tool name.

3

Evaluate

evidence

The hook posts a bounded event envelope to AgentKeeper for Runtime Shield evaluation.

The last evaluate request has HTTP 200, a timestamp, tool name, response size, and session correlation.

4

Review

evidence

Activity shows the event with source Cowork, host, tool, verdict, reason, and raw context after redaction.

Analysts can pivot from workstation to sessions, policy, MCP activity, and any blocked or warned actions.

Research artifact

Enablement ramp

A good Cowork rollout starts in visibility mode, then moves only the highest-confidence controls into blocking.

Inventory and hook health

95%

Before enforcement, prove the customer can see active Cowork hosts, last check-in, and last evaluated event.

Audit all tool actions

82%

Capture passed events so the security team learns normal Cowork behavior and avoids overblocking.

Warn on sensitive reads

68%

Move secrets, PHI-like paths, customer exports, and credential directories into analyst-visible warning mode.

Block destructive operations

54%

Deny high-confidence write/delete/exfil patterns, risky shell-like actions, and forbidden MCP tools.

Cowork is a runtime, not a chat tab

The first mistake is to treat Claude Cowork as a normal assistant conversation. Cowork can take a goal, keep working, use local files, operate through plugins, reach connectors, use MCP-style tools, run code in controlled environments, and in some modes interact with browser or desktop surfaces. The user prompt is only the beginning of the execution graph.

That execution graph has to be governed at the action boundary. A policy that only reviews prompts cannot distinguish between a harmless summary and a plugin call that exports a customer list. A network control that only sees domains cannot explain which agent session, workspace, policy, and tool argument produced the request.

AgentKeeper's Cowork posture is deliberately action-centric

AgentKeeper uses the same operating model it applies to Claude Code: collect the host and session envelope, normalize the proposed action, evaluate policy, and retain enough evidence for review. The Cowork-specific work is mapping a desktop/plugin runtime into that policy model without pretending every Cowork capability exposes the same fidelity.

For supported Cowork hook paths, AgentKeeper can record source_tool=cowork, workstation, workspace, hook event, tool name, tool input summary, semantic action, policy verdict, and redacted context. That means file restrictions and MCP/tool policies can apply to Cowork without creating a separate policy universe for every agent surface.

Visibility has to be proven with live health signals

Cowork deployment should not be considered complete because a script printed installed. A serious rollout needs a self-test, a last hook invocation timestamp, a last evaluate request timestamp, the tool name that was evaluated, an HTTP status, and a workstation record that moves from offline to active when Cowork actually invokes the hook.

Those details matter because desktop agents fail in ordinary ways: cached plugin manifests, stale app sessions, changed workspace paths, old shell versions, missing API keys, corporate proxy interference, and users who forget to fully restart the desktop application. The status page should make those failures diagnosable without asking an enterprise pilot user to reverse engineer their app bundle.

The honest limit is also the selling point

No Cowork security product should claim to see every pixel-level decision or every SaaS-side connector action from the local desktop. Some paths need managed browser policy, SaaS audit logs, identity controls, endpoint telemetry, or a gateway owned by the organization. The value of AgentKeeper is that it captures the high-fidelity agent events that do pass through supported hooks and turns them into enforceable, explainable policy.

That is the enablement argument. Security can start with visibility, prove which workstations and actions are covered, tune policies from real passed events, then block the small set of operations that create unacceptable blast radius.

Technical model

From delegated task to governed action

Cowork security is strongest when the platform evaluates actions at the moment the agent turns task context into a concrete operation.

Signals in the model

Cowork task context

User prompt, project instructions, memory, connected files, plugin skills, connector state, and tool output.

Action proposal

Local file read, write, shell-like operation, browser path, MCP tool call, connector request, or plugin execution.

AgentKeeper policy

Identity, workstation, workspace, source_tool, path, command, MCP server, tool name, arguments, and policy pack.

Verdict and evidence

Pass, warn, or block with bounded context, redaction, host/session correlation, and analyst review trails.

Cowork can remain useful while high-impact actions become visible, explainable, and enforceable.

Related AgentKeeper surface

Cowork plugin, Runtime Shield, Activity, Workstations, and Agent Inventory. Product docs are available after login.

Sign in for docs

Sources and inspiration