Claude Cowork exposes a workstation agent gap in enterprise controls

At a glance

What this is: This analysis argues that Claude Cowork creates a workstation-level agent risk that sits outside Anthropic’s native compliance visibility and extends far beyond chatbot-style prompt injection.

Why it matters: IAM, PAM, and NHI teams need to treat workstation agents as governed identities because file access, browser sessions, MCP connections, and scheduled tasks all expand the control surface.

Context

Claude Cowork is a local agent running on employee machines, so the security problem is not just prompt injection but governed execution on endpoints, inside browser sessions, file mounts, and enterprise connectors. The relevant question is whether identity and access controls can still bound an actor that can act with the user’s session and continue work after the user disengages.

For security teams, the gap is structural: native compliance views are not enough when the agent can read local files, call MCP servers, and trigger scheduled tasks outside the usual chatbot audit model. MCP security guidance becomes relevant here because tool access, invocation control, and trust boundaries now sit inside the agent workflow rather than around it.

Key questions

Q: What should security teams do first when deploying a workstation AI agent?

A: Start by treating the agent as an enterprise access surface, not a productivity add-on. Require the highest-control subscription tier, enforce SSO and SCIM, push managed settings through MDM, and define which files, domains, and connectors are in scope before users receive access.

Q: Why do AI agents increase operational risk compared with chatbots?

A: AI agents can take actions, not just generate text, so a bad decision can become an unauthorised workflow, a data exposure, or a transactional error. That changes the control problem from content moderation to access scoping, execution monitoring, and tool-call governance. The more the system can do, the more important runtime constraints become.

Q: How do you know if AI agent monitoring is actually working?

A: It is working when you can explain why a sequence of actions was allowed, blocked, or escalated, using evidence from the full chain rather than a single request. If monitoring only shows isolated inputs, it is not capturing agent intent, which is where misuse usually appears.

Q: How should organisations govern MCP connectors used by AI agents?

A: Treat every connector like a trusted dependency that can extend the agent’s reach into data and workflow systems. The decision is not only whether the connector works, but whether it has been reviewed, constrained, and placed inside a trust boundary that matches the agent’s job.

Technical breakdown

Why a workstation agent changes the trust boundary

A workstation agent differs from a hosted chatbot because it runs on the endpoint, not just in a remote service boundary. That means it can inherit the user’s authenticated browser session, touch local files, and interact with desktop applications through the same machine context the user relies on. The trust model shifts from conversation safety to execution safety. Once code execution, browser automation, and connector access are available in one runtime, a prompt injection can become an action chain rather than a single malicious response. Practical implication: define the endpoint, browser, and connector boundaries as part of identity governance, not just endpoint security. See the NHI Authentication Guide.

Practical implication: Treat workstation agent activity as an execution plane that must be governed alongside endpoint and identity controls.

Why native compliance tooling misses the real evidence trail

When an agent’s activity is excluded from audit logs, compliance APIs, and exports, the missing evidence is not an implementation detail. It is the record of what the agent actually accessed, invoked, or modified. That matters because identity governance depends on reconstructable usage history. OpenTelemetry can provide telemetry, but telemetry is not the same as full auditability, especially when prompts, tool names, and MCP server names are suppressed by default. Practical implication: route agent telemetry into your own logging stack and treat it as a separate evidentiary source, not a replacement for native audit records. See the Cloud Logging and Audit Trail Guide.

Practical implication: Build an independent evidence path for agent activity because native audit features do not reconstruct the full session.

How MCP, connectors, and scheduled tasks expand the attack surface

MCP servers, plugins, connectors, and scheduled tasks turn a local agent into a delegated access hub. Each integration inherits whatever permissions the user already has, which means a compromise can move from conversation context into enterprise systems, outbound messages, and persistent task execution. This is why allowlisting, version control, and per-tool authorization matter more than generic bot controls. The risk is not just that one tool is abused. It is that the toolchain becomes a supply chain of delegated actions with different blast radii. Practical implication: govern every tool that extends the agent as if it were a privileged identity path.

Practical implication: Apply per-tool authorization and allowlisting to every integration path the agent can invoke.

Threat narrative

Attacker objective: The attacker aims to turn a trusted workstation agent into a durable delegated access path for code execution, secret theft, and enterprise-system abuse.

1. Entry occurs when a developer clones a repository containing malicious hooks or settings that alter the workstation agent’s behavior before normal trust prompts appear.
2. Credential access follows when the agent is directed to read secrets, use the user’s authenticated browser session, or redirect traffic through attacker-controlled settings.
3. Escalation and persistence occur when the agent executes code, reaches connected enterprise tools, or schedules tasks that continue without the user present.
4. Impact is achieved when files, messages, API keys, or enterprise actions are exfiltrated or executed under the user’s identity.

Breaches seen in the wild

• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Claude Cowork is not a chatbot risk, it is a delegated execution risk. Once a local agent can execute code, browse with the user’s session, and run scheduled tasks, the security question changes from conversational safety to governed action. The blast radius is no longer limited to model output. It extends to files, credentials, and enterprise systems that the user can already reach. Practitioners need to evaluate the whole execution context, not just the model interface.

Native compliance assumptions collapse when agent activity is excluded from the audit plane. Audit logs, compliance APIs, and exports were designed for observable system activity. That assumption fails when the actor is a workstation agent because the relevant actions happen locally, may be stored locally, and may never surface in the vendor’s native evidence path. The implication is that auditability has to be redefined around endpoint telemetry, not vendor-provided reporting.

Workstation agent governance is an identity problem because the agent inherits and amplifies user privilege. A connector that can send messages, a browser session that carries authenticated cookies, or an MCP server that reaches internal tools all turns ordinary user access into delegated machine action. That is a form of identity extension, not just software integration. The practical conclusion is that access scope, offboarding, and entitlement review must include the agent’s delegated channels, not only the human account.

Ephemeral trust does not exist here; persistent local context does. The local machine stores conversation history, mounts files, and can keep scheduled tasks alive after the user walks away. That means the control problem is not merely whether a prompt is safe at the moment it is issued. It is whether the resulting state can persist beyond the user’s immediate supervision. Practitioners should think in terms of identity blast radius, not session convenience.

MCP governance is now an endpoint governance issue. Allowlists, version pinning, and per-tool authorization are necessary because the agent’s power comes from what it can reach through integrations. If those controls are managed only at the application layer, the local workstation remains a bypass path. The operational conclusion is simple: control the toolchain at the machine boundary, or the agent will inherit whatever the machine can touch.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Agent governance now depends on control outside the model boundary. When a workstation agent can operate through browser sessions, local files, and scheduled tasks, the meaningful control point moves to the endpoint and the connector layer. That is why governance programmes need a named concept for the failure mode here: delegated execution drift: the agent’s effective privilege expands through tools, not through formal role assignment.

The practical signal is that review cycles built for static entitlements no longer capture agent behaviour. If a session can create work that persists after the user leaves, the programme has to measure invocation patterns, task creation, and file access as first-class governance events. The most important question is no longer whether the agent is approved, but whether its delegated actions stay inside a boundary the organisation can actually observe.

For practitioners

• Enforce enterprise-only deployment Do not allow Team, Pro, or Max subscriptions for work use when organizational controls are required. Require SSO, SCIM, tenant restrictions, and managed settings before any rollout.
• Push managed settings through MDM Disable bypass permissions, restrict egress, and set mount controls centrally so users cannot override the agent’s security posture on managed devices.
• Build an MCP allowlist Approve only specific servers, version-pin them, and review every tool before it is added to the allowlist. Treat each server as a delegated access path that can expand privilege.
• Route telemetry into your SIEM Send OpenTelemetry session events, tool invocations, file access, and scheduled task creation into your own monitoring stack so agent activity becomes reviewable.
• Restrict browser and connector abuse paths Disable web search where possible, prefer read-only connector scopes, and block connector actions that can send messages or modify data unless there is a documented need.

Key takeaways

• Claude Cowork expands the identity problem from conversational access to governed execution on endpoints, where file access, browser cookies, connectors, and scheduled tasks all matter.
• The key control gap is evidentiary as much as technical, because native compliance tooling does not cover Cowork activity and therefore cannot reconstruct what the agent actually did.
• Enterprises need machine-enforced settings, independent telemetry, and per-tool governance if they want workstation agents to remain inside a reviewable access boundary.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · Cloud Logging and Audit Trail Guide · Low-Code Agent Platform Security Guide

Key terms

• Workstation AI Agent: An AI agent that runs on a user endpoint and acts with local context, tools, and permissions. It can read files, browser state, or workspace data, then take actions in other systems on the user’s behalf. The security challenge is that it blends trusted access with untrusted inputs and unpredictable runtime decisions.
• Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.
• MCP Allowlist: An MCP allowlist is a controlled set of approved Model Context Protocol servers that an agent is permitted to reach. It reduces tool sprawl by limiting which external capabilities can be invoked, but it only works when versioning, ownership, and invocation logging are also governed.
• Agent telemetry: Operational data describing what an AI agent did, which tools it called, how much it consumed, and what resources it touched. Telemetry is essential for audit, incident response, and behavioural governance because agent decisions are otherwise difficult to reconstruct.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.