By NHI Mgmt Group Editorial TeamBased on Pluto Security: “Inside Claude Cowork: How Anthropic’s Autonomous Agent Actually Works” (October 20, 2026)

TL;DR: Claude Desktop’s autonomous agent architecture was reverse-engineered and found to use a multi-layer design that combines a sandboxed VM, host-side Chrome control, remote dispatch, and feature flags, according to Pluto Security, while still leaving session logs, device trust, and browser context exposed to risk. The core assumption collapses when the agent can act outside a single trusted boundary.


At a glance

What this is: This is an independent technical analysis of Claude Desktop’s autonomous agent architecture, showing how its VM, browser control, dispatch path, and logs create a larger and more complex identity and attack surface than a chat-only assistant.

Why it matters: It matters because IAM, PAM, and security teams need to treat autonomous desktop agents as operational identities with host reach, browser reach, and lifecycle risks that conventional app controls do not fully contain.


Context

Computer-use agents are AI systems that can observe a desktop, manipulate a browser, read files, and take actions on a user’s behalf. That shifts the control problem from prompt safety to identity, privilege, and execution boundaries because the agent is no longer confined to text generation.

Pluto Security’s analysis focuses on Claude Desktop’s Cowork architecture, where the agent spans a sandboxed VM, host-side Chrome control, remote dispatch from mobile, and extensive logging. The question for practitioners is not whether the interface is clever, but which governance assumptions fail when a software identity can move across boundaries inside a single task.


Key questions

Q: What breaks when an autonomous desktop agent can use the host browser session?

A: The boundary between approved task execution and inherited human privilege breaks down. The agent can act inside the user’s authenticated browser context, which means the real control point is not the prompt but the browser session and the policies around what the agent may do inside it.

Q: How should organisations govern autonomous agents differently from copilots?

A: Autonomous agents need stronger oversight because they can call tools, retrieve secrets, and generate sub-agents without the same session-bound limits as a copilot. Governance should reflect that difference in monitoring, approval, and scope controls rather than using one generic policy for every AI capability.

Q: How should security teams evaluate autonomous agent risk before deployment?

A: Start by mapping where the agent executes, what identities it inherits, which tools it can invoke, and what persists after the session ends. If those four elements are unclear, the deployment is not ready for production use in a controlled environment.

Q: What should organisations do when agent logs survive session deletion?

A: Treat that as a lifecycle failure, not a housekeeping issue. Retained transcripts and audit files can preserve sensitive commands and file contents, so the organisation should define retention, access, and deletion rules before the system is widely used.


Technical breakdown

How the VM boundary limits the agent, and where it does not

Claude Desktop’s Cowork runs the agent inside a Linux VM, but the VM is only one control plane in the architecture. The daemon runs as root with hardening disabled, which means isolation depends on the VM boundary rather than process-level confinement inside the guest. That matters because the agent’s runtime privileges are broad once it is inside the sandbox, and the sandbox itself has empty firewall rules. In practice, this is not a fine-grained least-privilege model. It is a coarse containment model that assumes the VM remains the trustworthy perimeter. See the [[L5|AI Agent Authorisation Guide]] for the governance logic behind task-scoped access. See the AI Agent Authorisation Guide.

Practical implication: Treat the VM as a containment layer, not as evidence that the agent itself is operating under least privilege.

Why browser control creates a separate trust domain

The Chrome control path is outside the VM and operates through the host browser with the user’s real session state. That means the agent can inherit cookies, open tabs, and authenticated web context that were never scoped to the VM. The security implication is straightforward: browser-mediated actions are not merely network requests, they are privileged interactions with an already authenticated human session. Visibility-aware text extraction reduces some hidden-content risk, but screenshots and rendered text remain in scope. Once browser control lives on the host, the threat model changes from sandbox escape to session abuse and cross-context influence. See the Browser and Computer-Use Agent Security Guide.

Practical implication: Assume host browser state is part of the agent’s effective privilege set and govern it accordingly.

What remote dispatch and logs reveal about identity boundaries

Dispatch and logging show that the system does not fully distinguish phone-originated commands from desktop-originated commands, and some logs retain session content even after deletion. That is a lifecycle problem as much as a security one: the command source, the execution context, and the retained evidence are not consistently tied together. For autonomous systems, this weakens attribution and complicates incident review because the trail outlives the user action. The result is a governance gap in provenance, not just a storage issue. See the [[L8|AI Agent Observability, Audit and Incident Response Guide]] for the control problem this creates. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Design remote-control and retention rules as one lifecycle, not as separate UX and logging features.


Threat narrative

Attacker objective: An attacker or misdirected task aims to use the agent’s delegated runtime to reach host context, authenticated sessions, and durable records that extend beyond the intended task boundary.

  1. Initial access begins with legitimate task dispatch into the agent’s workflow, not with external intrusion, because the user authorises the system to act on their behalf.
  2. Escalation occurs when the agent reaches beyond the VM into the host browser and inherited session context, which broadens the effective privilege boundary for the task.
  3. Impact follows when that cross-context access touches sensitive files, authenticated web sessions, or retained logs that preserve the agent’s actions after the session ends.

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

Autonomous desktop agents create an identity boundary problem, not just an application security problem. The critical issue is that the agent can span a VM, a host browser, a remote phone dispatch path, and retained logs inside one operational flow. That makes the control question broader than endpoint hardening because authority is distributed across runtime, browser state, and post-session evidence. Practitioners should treat the agent as a governed identity with multiple execution surfaces, not as a single product feature.

Least privilege is designed for actors whose scope is knowable before execution begins. That assumption fails when the actor is autonomous because it can decide at runtime whether to browse, read files, or invoke host-side controls. The implication is that privilege review based only on provisioning state will miss the real exposure window. Security programmes need to rethink whether the access is stable enough to certify at all.

Browser session inheritance is the most important hidden control in this architecture. Once the agent uses the human’s real Chrome session, the privilege boundary shifts from the VM to the authenticated browser context. That blurs responsibility between the user, the agent, and the platform, which is exactly where identity governance often becomes weakest. Computer-use agent security becomes a governance issue because the browser is no longer just a UI, it is an access environment.

Retention is part of the attack surface for autonomous agents. If transcripts, screenshots, and child audit files survive session deletion, the system creates durable records that may contain sensitive material and operational detail. The governance failure is not simply incomplete cleanup. It is that offboarding for an autonomous session is not being treated as a first-class identity lifecycle event. Practitioners should manage agent retirement, evidence retention, and access revocation as one control set.

Runtime autonomy moves the control point from request approval to execution governance. In a desktop agent model, the risky moment is no longer only whether a request was approved. It is what the agent can still do after approval, across host context, browser context, and persistent logs. That is why autonomous identity governance needs to be built around task scope, session scope, and evidence scope together.

Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Autonomous desktop control turns the browser into an identity boundary. Once the agent operates through the user’s real Chrome session, the question is no longer only whether the model is safe. It is whether the organisation is comfortable letting a non-human actor inherit human-authenticated context inside an interface that was never designed for delegated runtime authority.

Runtime governance will matter more than static approval. Access reviews and policy documents assume a stable identity footprint, but desktop agents can shift between VM execution, host interaction, and remote dispatch in the same workflow. That means security teams need controls that watch the session as it runs, not just the account that launched it.

Session deletion is becoming an identity lifecycle control for agents. If audit data and transcripts outlive the session, the programme has not actually completed offboarding. The practical next step is to define what evidence should persist, what should vanish, and who is accountable for that decision across the agent lifecycle.


For practitioners

  • Define the agent’s execution boundary Document exactly which capabilities run in the VM, which run on the host, and which inherit the user’s browser session so the trust boundary is explicit.
  • Treat browser context as privileged access Review whether host Chrome sessions, cookies, and open tabs should be available to an autonomous agent at all, especially for regulated or high-impact workflows.
  • Separate command origin from execution logging Record whether a task came from mobile or desktop, what identity triggered it, and what the agent actually did so incident review has usable provenance.
  • Audit session deletion and evidence retention Verify that screenshots, transcripts, and child audit files are removed or retained under a documented policy rather than left behind by default.
  • Review agent approval gates for high-risk actions Require human confirmation for destructive commands, external transfers, and browser actions that operate on the user’s authenticated session.

Key takeaways

  • Autonomous desktop agents extend identity governance beyond login and authorization into host access, browser inheritance, and runtime delegation.
  • The most exposed control points in this architecture are the host browser session, cross-boundary command paths, and retained audit data.
  • Security teams should govern agent execution, provenance, and retention together because those controls fail together when autonomy crosses from the VM to the host.

Related NHI Mgmt Group resources: Browser and Computer-Use Agent Security Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · AI Agent Identity Security Buyer's Guide


Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe article focuses on an autonomous agent inheriting host and browser privilege across execution surfaces.
ASI02 — Tool MisuseThe browser, file, and dispatch tools create misuse paths if the agent is steered or overextended.
ASI09 — Human-Agent Trust ExploitationThe design relies on human trust in remote dispatch and inherited browser context.
Recommendation — Map delegated browser and desktop authority to ASI03 and restrict the agent to explicitly scoped runtime privileges. Constrain tool availability by task and block high-risk tool combinations that are not required for the workflow. Require confirmation for actions that rely on human-authenticated context and limit trust transfer to the agent.
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationRemote dispatch and host browser reuse create authentication trust boundaries that can be abused.
NHI-08 — Environment IsolationThe architecture depends on VM isolation while also reaching into the host browser and files.
NHI-10 — Human Use of NHIThe agent operates on behalf of a human and inherits human session context across controls.
Recommendation — Bind agent sessions to explicit authentication checks and separate desktop control from ambient user login state. Separate host, browser, and agent execution environments so one boundary failure does not expose the full session. Prevent human sessions from being reused as ambient authority for autonomous agent actions.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementThe post discusses how delegated browser access and host reach can widen credential and movement exposure.
Recommendation — Monitor delegated agent activity for credential exposure and cross-boundary movement into host contexts.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about how access permissions expand across VM, browser, and dispatch layers.
Recommendation — Review entitlements for agent execution paths and remove any permission not required for the task.

Key terms

  • Autonomous desktop agent: An autonomous desktop agent is a software identity that can operate a user interface, browse sites, read files, and take actions without a human approving every step. In governance terms, the important issue is not automation alone, but whether the agent can make runtime decisions and use delegated access across multiple execution surfaces.
  • Browser Session Inheritance: Browser session inheritance is when an AI agent acts through the authenticated browser context already established by a user. It matters because the agent can reach whatever the session can reach, which turns human login state into machine-executed operational privilege.
  • Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.
  • Session evidence: Session evidence is the record of what an identity actually did after access was granted, including commands, queries, configuration changes, and resource actions. It is the proof layer that lets security and compliance teams reconstruct activity, investigate incidents, and validate that privilege did not exceed policy.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org