Anthropic's reference implementation for computer use runs in a Linux container with a virtual display and a browser. Then the agent meets the enterprise, where the work lives in a Windows thick client with no API, on a network segment reachable only from a managed desktop, under a compliance regime that wants a record of every session. Enterprises that run non-persistent VDI already govern a fleet of exactly those desktops: built from one image, reset at logoff, often recorded and centrally controlled. The desktop clouds now sell that idea as an agent product. What they cannot sell you is the list of what your own estate still lacks, or the difference, in one invoice queue, between an agent in its own reset desktop and the same agent under a clerk's login.

Thesis: For agents that must drive the enterprise's real desktop applications, the VDI estate is the natural sandbox, provided the agent signs in as itself and never as the human it works for.

What a Desktop Agent Actually Needs

Anthropic's computer-use documentation lists four precautions: "a dedicated virtual machine or container with minimal privileges," no access to sensitive data "such as account login information," internet access limited to an allowlist of domains, and a human to confirm decisions with real-world consequences. Its reference implementation is the container from the opening, running Firefox and LibreOffice on a virtual X11 display.

That is the right sandbox for a demo or for browser work, and the wrong one for work that lives in a thick client, because of fidelity. The invoice queue is not in Firefox. It is in a Windows client that signs in against the corporate directory, reaches its database only from managed endpoints, and misbehaves without the right drivers and certificates. A test on a lookalike proves only the lookalike.

Now read the precautions as an end-user computing (EUC) team would. A dedicated machine is a pooled desktop. A known starting state is a golden image; reset after every task is non-persistence. Session recording and DLP cover part of the compliance record. The application with no API is often already a published app. So VDI covers the machine, the known state and the reset. Minimal privilege, credentials kept from the model, an allowlist and human sign-off still have to be built. Minimal privilege is the hardest of these, because a corporate desktop is built to reach things; "When the Opposite Wins" takes that on.

The reset is what turns a desktop into a sandbox: the next task inherits no cached answer, no leftover file and no half-finished state.

The Desktop Vendors Have Noticed

Amazon made WorkSpaces for agents generally available on June 30, 2026, for desktop applications such as "ERP systems, CRMs, mainframes, and proprietary tools," running on "the same infrastructure for agents as organizations have trusted for over a decade." Microsoft describes Windows 365 for Agents as "a brand-new class of Cloud PCs for agent use," built on its existing Cloud PC platform, with machines that are "agent-only," pooled, checked out per task, and "Reset after every agent session, with no state carried forward."

Neither is a recommendation here: both run agents on a desktop platform they already sold to humans, and what they had to add (an identity for the agent, a sign-in the model never handles, billing by use) is the gap your estate will have too.

How the Options Compare

Developer laptop Container MicroVM sandbox Hosted agent sandbox VDI / DaaS desktop
Isolation None from the owner's files and credentials Process-level; shares the host kernel Hardware-virtualized, own guest kernel The provider's boundary, as the provider describes it A VM per desktop (multi-session hosts share one), inside segmentation you already run
Startup Instant Fast Firecracker cites under 125 ms for a minimal guest Provider-dependent Depends on the pool; Microsoft sells an always-available tier for latency-sensitive work
Cost shape Hidden in someone's day Cheap and dense Dense; Firecracker cites under 5 MiB overhead per VM Metered per use A full desktop per session; the agent offerings bill hourly or by active session time
Fidelity to the user's environment Real, but one person's Usually Linux and a browser Linux guests (Firecracker's FAQ) Whatever image the provider offers; some offer Linux desktops The actual corporate image and its Windows apps
Governance and audit Whatever the endpoint tools see Build it Build it The provider's logs, on the provider's terms Recording, DLP and central policy already in place
Identity The human's Whatever you inject Whatever you inject Whatever you inject Built for named humans; the agent's identity is the gap

The laptop deserves its own warning. OpenAI's sandbox guidance puts it plainly: "Agents that share an environment can access the same files, credentials, and other resources." On a laptop, that environment is the developer's.

What VDI Does Not Give You for Free

An identity for the agent. The easy path runs the agent in a human's desktop under her login, and every action it takes is then, in the audit log, hers. Neither vendor's design starts there. Microsoft gives each agent "a dedicated Microsoft Entra agent user identity, separate from human users," and says agents "never reuse or impersonate user credentials." Amazon's domain-joined fleets let agents "take on a known identity within Active Directory," so that audit logs attribute actions "to a directory identity rather than a generic agent account." The mechanisms differ (a dedicated agent identity type, or an account in your existing directory), but in both the agent is an identity the audit can name. Give the agent its own account, scoped to the task's role, not its human's.

Credential handling. The model should never see a secret, and the image should never contain one. The platform signs the agent in; the model works the screen it is handed. That is Anthropic's second precaution restated as architecture, and Amazon makes certificate-based authentication mandatory for agents "to avoid the agent directly reading or using production Active Directory credentials."

A record of what the agent did, not only what the screen showed. Session recording is video, and Amazon's screenshot storage "captures what the agent saw during each session." An audit needs a queryable record: who asked, what the agent decided, which action it took and, since Microsoft's design lets a supervisor take control mid-session, which actions were the human's. That record should go to a check that is not the agent, the rule The Clean Room sets for any maker.

Density and cost for short, bursty work. An agent task may last minutes and arrive in bursts, and the agent offerings price only partly for that. Windows 365 for Agents bills $0.40 per hour in the US, with usage in each hourly window "rounded up to the next full hour," and its always-available tier costs $5 per Cloud PC per month, "in addition to any Pay-as-you-go based usage." Amazon prices on active session time. Firecracker cites a boot in under 125 ms, but for a minimal Linux guest, not a desktop with an application signed in and ready; it is no like-for-like benchmark.

Licensing that counts agents. Microsoft draws the line itself: its agent product "is not a feature add-on to user-assigned Windows 365 plans." The application inside the desktop is another matter. If the thick client is licensed per named user, read that contract before an agent signs in.

An Example: The Invoice Exception Queue

Take an accounts-payable team at a manufacturer. Invoices that fail automatic matching land in an exception queue inside an ERP client older than most of the team. It has no API worth the name. The EUC team already publishes it as an app on non-persistent desktops, because that was the only safe way to give clerks remote access.

flowchart LR
    Q["Exception queue"] --> ID["Agent's own identity<br/>clerk-level rights only"]
    ID --> CO["Check out a desktop<br/>from the agent pool"]
    CO --> ACT["Work the exception<br/>in the real ERP client"]
    ACT --> REC["Structured action record<br/>plus session recording"]
    REC --> CHK["Separate check<br/>and human approval"]
    ACT --> RST["Reset to the<br/>golden image"]
    RST --> CO

    style ID fill:#5a5a8a,color:#fff
    style REC fill:#5a5a8a,color:#fff
    style CHK fill:#5a5a8a,color:#fff
    style CO fill:#2d6a4f,color:#fff
    style ACT fill:#2d6a4f,color:#fff
    style RST fill:#2d6a4f,color:#fff

The green steps are what the estate already does. The purple ones are what the team has to add. The agent checks out a desktop from a pool reserved for agents, built from the same golden image the clerks use, on a segment that reaches the ERP and the document store and nothing else. It signs in as itself, with rights to match and code an invoice but not to approve above a limit or edit a supplier's payment details. It works the exception in the real client, writes a structured record of what it found and what it changed, and releases the desktop, which resets. A human approves the batch; a separate check samples the agent's records against the ERP.

Now the naive version: the agent runs in a senior clerk's persistent desktop, under her login, with her approval rights. The audit log shows her working the queue at two in the morning on a desktop that has drifted for a year. Same infrastructure; only the identity, the pool and the reset changed.

When the Opposite Wins

Headless code agents. An agent that needs a shell, a repository and a test runner gains nothing from a Windows desktop. A container or microVM is faster, denser and closer to its real environment, which is a build machine.

High-volume, short tasks. When the work is a flood of sub-minute jobs that need only Linux and a browser or a shell, a microVM's fast start and density beat a desktop billed in hourly windows.

Anywhere structured access exists. Driving pixels should be the actuator of last resort, and one desktop vendor's direction points the same way: Amazon added "MCP tool forwarding" so agents can reach applications and the desktop operating system "through direct MCP calls rather than using computer use tools," which it says improves accuracy and cuts latency and cost. Bind the Goal, Not the Gesture makes the general case: treat the desktop drive as a discovery instrument, and re-bind the task to a stronger interface the day one appears.

An estate that is not really non-persistent. If your desktops are persistent, hand-tended and years from their last image refresh, the agent inherits the drift. Without the reset, VDI is not a sandbox yet.

The strongest objection is about blast radius. Anthropic asks for minimal privileges and an internet allowlist. A domain-joined corporate desktop is built for the opposite: it trusts the directory and reaches internal systems. An agent misled by a poisoned document or web page on that desktop can do more harm than one in an internet-facing container that reaches nothing. The objection is right, and it is why the agent's desktop cannot be a human's. The example's answer is containment by architecture: an agent-only pool, a narrow segment, a clerk's rights rather than an approver's, a reset per task and a human on the money. Where you cannot draw the boundary that tightly, the container wins.

The other objection is cost: the money belongs in building the API. Where it can be built, agreed. The thick client in the example is unlikely to get one soon, and the governed desktop is the bridge until it does, with every desktop-driven task logged as a candidate for re-binding.

What to Do Next

  • Inventory the apps with no API that a work queue depends on. Those are the agent candidates, and many are already published apps.
  • Build a separate agent pool: single-session, non-persistent, from the golden image, on its own segment, never shared with human sessions.
  • Settle identity before the pilot. Agent accounts distinct from humans, scoped to the task's role, with no borrowed or shared human logins.
  • Measure request-to-ready time and task length against billing granularity from day one, so cost surprises arrive in the pilot, not the invoice.
  • Read the licences of the applications agents will drive for named-user terms.
  • Sign the agent in from the platform, never through the model or the image, and send a structured action record per task to a check that is not the agent.
  • Route by actuator: API or MCP first, the desktop only when nothing else exists, and shell-only or high-volume work on microVMs.

Related reading: Bind the Goal, Not the Gesture on why the desktop drive should be temporary, The Clean Room on why the agent's record needs a separate check, Confidence Is Not Consent on what an agent may run unasked, and Headless AI: Every App Is a Head on the API-first world the desktop bridges to.

Disclosure: my employer sells VDI infrastructure; this post recommends no vendor.