Computer-use sandboxes: desktops, browsers and pixels
A terminal agent reads files you chose. A computer-use agent reads whatever the internet serves it, in a format designed to be interpreted. That difference is the entire security story of this chapter.
Why this category is harder
Computer-use agents — ones that see a screen and click, type and navigate — are the fastest-growing and least-contained category in this guide. The threat model is not "code escapes a sandbox". It is "the agent is persuaded to do something by content it was told to read".
Four properties make this structurally harder than terminal sandboxing:
- The input is adversarial by default. A web page, a PDF, an email, a marketplace listing, an image, a screenshot — all are attacker-controllable content that the agent will read with the same trust as your instructions.
- The agent is authenticated. It acts with your session, your cookies, your logged-in accounts, which is what makes it useful and what makes the consequences real.
- Actions are irreversible at the point of contact. Sending an email, submitting a form, making a purchase, deleting a record. There is no sandbox around a bank transfer.
- The screen is the attack surface. A systematisation of computer-use vulnerabilities makes the key structural observation that safety checks live in the model, while the ability to act lives in the actuation layer — with no enforcement at that layer unless something outside the model provides it.
What the measurements say
This is one of the few areas of agent security with real numbers. They are uncomfortable, which is the point.
| Study / incident | Finding | What it implies |
|---|---|---|
| RedTeamCUA (ICLR 2026) | Hybrid web-plus-OS adversarial environment, 864 examples. A leading computer-use model showed a 42.9% attack success rate; the most robust agent evaluated still 7.6%; attempt rates up to 92.5% and success up to ~50% in realistic end-to-end settings. | Under realistic adversarial conditions, a computer-use agent is a live liability, not a theoretical one. |
| browser-use CVE-2025-47241 | A critical domain-allowlist bypass via URL userinfo syntax (https://example.com:pass@localhost:8080) affecting 1,500+ dependent projects. The agent believed it was visiting an allowlisted domain while reaching an internal service. Fixed in 0.1.45. |
The single native restriction most browser agents ship is a parsing problem, and parsing problems are where allowlists die. |
| Systematisation of CUA vulnerabilities (2025) | Documents the absence of enforcement at the actuation layer, identity ambiguity and over-delegation: agents act with user credentials but lack runtime scoping or attestation. | The architectural gap is between the model's judgement and the ability to act. Only an external gate closes it. |
| LivePI (2026) | Indirect injection against a real deployment across seven input surfaces: total attack success 10.7–29.6%, with group-chat injection reaching 100% on every evaluated backbone. A two-layer defence — prompt filter plus pre-execution tool authorisation — cut success to 0% while interrupting ~1% of benign calls. | System-side controls work; model-side robustness does not. That asymmetry is the most actionable finding in the literature. |
| The framing gap (2026) | Reframing an identical data leak as an "integrity signature" or "runtime-config field" moved a strong model's compliance from 0% to 100%. Common defences under-performed (one alignment method at 32.5%, channel separation at 38.8%), while destination allowlists and planner/reader capability splits both hit 0%. | Do not evaluate a defence against a naive attack. Assume the attacker will reframe. |
| ZombAIs demonstration | A web page prompt injection caused a computer-use host to download a file, chmod +x it and execute it, establishing a command-and-control channel. |
Browser-to-terminal escalation is a two-step attack that most setups do not gate. |
| Cross-application attacks (Muzzle framework) | An injection in one application coerced an agent into destructive admin actions in a different authenticated application sharing the same browser session. | Session isolation between tasks is part of the boundary. Reusing one logged-in browser for everything is a lateral-movement path. |
How to sandbox a desktop agent
There is no version of this where you put a screen-driving agent on your real session and are safe. The practical options, in order of how much they buy you:
1 · A VM with a desktop, no credentials, streamed to you
The reference configuration, and the one the serious projects converge on. The guest has no access to your accounts, your keys or your files; you watch through a stream and can pause or take over. Both E2B's desktop sandbox and Cua's fleets ship streaming with view-only and password-protected modes for exactly this reason.
What to check: does the stream support view-only? Can you pause the agent mid-task? Is the guest's network policy yours or the vendor's? Is there any credential in the guest image?
2 · A container desktop (Container + VNC/WebRTC)
Cheaper and lighter: a Linux desktop in a container, exposed over VNC or a web viewer. This is the pattern EdgeBox used, and the pattern is genuinely good even though that implementation is stalled. It is also what most "browser sandbox" products are underneath.
The catch: a container shares your kernel and a VNC server is a network service. Keep it off the LAN, keep the password long, and understand that this is blast-radius reduction rather than a hypervisor boundary.
3 · Accessibility trees instead of pixels
Driving applications through the OS accessibility API rather than screenshots is both more reliable and cheaper in tokens — one implementation reports moving from ~30,000 tokens for a full snapshot to a few hundred for a skeleton view with focused drilling. It also removes some classes of purely visual injection such as steganographic or invisible-text tricks.
The catch: it is still reading attacker-controllable text into the model, and it requires a real desktop session on the host unless you put it in a guest. On the platforms this guide prioritises — Windows and Linux — accessibility-tree tooling is younger than the macOS equivalent.
4 · A dedicated browser profile per task
The cheapest meaningful improvement for browser agents specifically. One profile per task means a compromise in one session does not inherit another session's cookies, and you can throw the profile away. Combine it with a browser-level egress allowlist and a policy that gates consequential actions on a human confirmation.
The catch: most browser-agent frameworks reuse one profile for convenience, and it is the convenience that makes cross-application attacks work.
Getting a desktop in front of the agent, quickly
Two different questions get collapsed into "does it do computer use": is there an isolation boundary around the desktop, and do I get a usable screen without spending an evening on it. Most projects answer one of the two, and the ones that answer both are the ones worth your time.
The delivery half is a solved problem, and it is the half people underestimate. Every one of these paths is a known quantity:
| Path | How it reaches you | The question it adds |
|---|---|---|
| Hypervisor console | The desktop-hypervisor window (VMware, VirtualBox, UTM, GNOME Boxes, Hyper-V). Zero setup. | It is a host application with clipboard and drag-and-drop conveniences. Those conveniences are one-way host→guest channels you have to switch off deliberately. On a Windows host, console keyboard/mouse handling is also the fiddliest part of the whole workflow. |
| VNC (the RFB protocol) | Any VNC server in the guest — including the ones baked into container-desktop images — to any VNC client. The classic answer and still the fastest to stand up. | VNC is a network service with historically weak authentication: use a long password, bind it to loopback or a private network, or tunnel it. A desktop exposed on a LAN interface is a bigger problem than anything the agent can do inside it. |
| RDP (xrdp, Windows guests, "enhanced session" modes) | Better performance than VNC for full desktops, with real clipboard and drive redirection options. | The convenience features are the exposure: clipboard, shared drives and printer redirection are exactly the channels you do not want between an injected desktop and your host. Turn them off, then use the desktop. |
| Web UI (KasmVNC/Selkies, noVNC, Apache Guacamole) | A desktop in a browser tab. This is what the widely used container-desktop images in the LinuxServer.io webtop family use, and what many "browser sandbox" products are underneath. | You now have a web service holding a desktop. Authentication is off by default in the common images, so a password and a network boundary are configuration you must not skip — and the base-image line moves (that project has already migrated its viewer once), which is a maintenance detail rather than a security one. |
| Vendor streaming | Managed products ship their own low-latency stream, usually with a view-only mode and a password-protected session — E2B Desktop and Cua's fleets are the documented examples here. | Ask what the stream lets you do: view-only or interactive? Can you pause the agent and take over? Who controls the guest's egress policy? Is the session recorded, and where? |
Ready-to-use desktops versus a compute boundary
The other half is where the projects actually differ, and it is where most disappointment comes from. "MicroVM sandbox" describes a kernel boundary. It says nothing about whether a browser, a window manager and an agent driver exist inside the image you are handed.
Ships a desktop or a browser you can use today
- E2B Desktop — a Firecracker microVM with a desktop, streaming and password protection. The strongest combination of boundary and screen on this list.
- Cua — local macOS/Linux VMs on Apple's Virtualisation framework plus cross-OS cloud fleets, a driver layer and a benchmark suite. macOS-centric.
- Container-desktop images (the LinuxServer.io webtop family, KasmVNC/Selkies
viewers, xrdp images) — a full Linux desktop in a browser tab or a VNC client, in one
compose up. Container boundary only. - Windows Sandbox — a disposable Hyper-V desktop with a
.wsbconfig file. Real hypervisor boundary, Windows guests, one instance at a time. - EdgeBox — a containerised desktop over VNC with MCP support, and a good shape to copy from a stalled project: skipped here.
Gives you isolation and expects you to bring the desktop
- Firecracker, Cloud Hypervisor, crosvm, libkrun — a VMM and a kernel boundary. You supply the guest image, and you build the desktop into it yourself.
- BoxLite, SmolVM, Microsandbox, Kata — run OCI images with hardware isolation, so
you get whatever image you choose: a desktop image becomes a desktop box, a bare
alpinestays a shell. - gVisor — a user-space kernel, not a desktop. It runs the browser you install in the image, and it is the option that works where no hypervisor exists.
- Plain containers and the official browser images (for instance Playwright's image) — a headless browser and its dependencies, which is often all a browser agent actually needs. No desktop, no window manager, no pixels to inject into.
That last point is worth taking seriously: if the agent only needs a browser, a headless browser in a hardened container is cheaper and smaller than any desktop, and it removes the screen from the attack surface entirely.
The many-desktops problem
"Start five agent desktops" sounds like a fan-out question and is really a memory question. The cost that scales is not the isolation mechanism, it is one guest kernel and one desktop stack per sandbox — and a browser on top of that.
| Approach | Per-sandbox floor | Ten of them | The trade |
|---|---|---|---|
| Container desktop | Shared kernel plus the desktop stack and browser: commonly a few hundred MB to about a gigabyte resident once a browser is open. | Plausible on a laptop, especially with a light desktop environment and a headless browser. | Memory-efficient, but the boundary is a shared kernel. Fine for accidents and most injection; not a hypervisor. |
| MicroVM desktop | The desktop itself, plus a small guest kernel — tens of megabytes, not gigabytes, for the kernel and a boot that is measured in hundreds of milliseconds from a snapshot. | Density is roughly the desktop's cost, so it is closer to the container case than people expect. | You buy a real kernel per sandbox and pay in file-sharing speed and image plumbing. The isolation is per-desktop rather than per-host. |
| Full VM desktop | A usable graphical Linux guest is 1–2 GB resident before the agent does anything, and a Windows guest is more. | Two or three on a laptop. Ten is a server workload. | The strongest and most conventional boundary, and the one that costs the most RAM per screen. |
| One desktop, many lanes | One guest kernel, one desktop, and cheap per-task containers or browser profiles inside it. | However many lanes the single desktop can drive — often the actual answer. | Lose per-task kernel isolation between lanes (keep it between you and the agent) and gain the density back. This is the pragmatic default. |
Provision once, clone always. Build one base desktop with the browser, the driver and your tooling installed; snapshot it while it is quiescent; then clone per task. On a copy-on-write backend — qcow2 backing files, overlayfs upper layers, reflinks, ZFS or Btrfs — the clone is cheap and the original stays immutable, which is also the cleanest rollback you can have.
Suspend instead of booting. A warm, suspended desktop resumes in a fraction of the time a guest takes to boot, which is what turns "one desktop per task" from a novelty into a workflow.
Discard state, not machines. The thing that actually accumulates compromise is the browser profile and the session, so make the profile per-task and throw it away; the machine underneath can be reused. Combine that with a light desktop environment (XFCE, Openbox) rather than GNOME, and with a headless browser wherever nobody needs to watch.
Cap the fan-out, not the isolation. Ten desktops is a resource decision you should
make with free open, not one the agent should make for you.
Fanning out: which projects get you a screen fastest
This is the practical orchestration question people actually ask: which projects make it easiest to start agent tasks in boxes that already have computer-use access — a desktop, a browser, or a VNC/streamed screen — and what is realistic if you are writing a desktop application that wants to run many of them at once. Time-to-a-screen and boundary strength are separate axes, and the table below keeps them separate on purpose.
| Route | Time to a usable screen | Boundary you get | The catch |
|---|---|---|---|
| A headless browser in a hardened container (for instance Playwright's image) | A few minutes: pull the image, run one command. | Container — shared kernel. | No screen at all, which is often the right answer: it removes the pixels from the attack surface and it is the cheapest option here. Use it whenever the agent only needs a browser. |
| A container-desktop image (LinuxServer.io webtop family, KasmVNC/Selkies viewers, xrdp images) | One compose up. The fastest path to a full Linux desktop in a browser tab or a VNC
client. |
Container — shared kernel, plus a network service in front of the desktop. | Authentication is off by default in the common images, so the password and the network boundary are configuration you must not skip. VNC and the web viewers are network services with their own history. |
| Windows Sandbox | Minutes, if the SKU supports it: a .wsb config and a launch. |
Hyper-V VM, disposable. | Pro/Enterprise/Education only, must match the host OS build, one instance at a time, nothing survives close, and there is no host workspace integration. See the Windows chapter. |
| E2B Desktop | An API call, if you accept a hosted service. | Firecracker microVM per sandbox. | The best combination of boundary and screen on this list, and the caveats are the platform ones from E2B's assessment: hosted by default, self-hosting is experimental, and the desktop still reads attacker-controlled pixels. |
| An OCI-image microVM runtime — BoxLite OSS, Microsandbox, Kata, SmolVM, Docker Sandboxes | Minutes to a shell; longer to a desktop, because you supply the image. Choose (or build) a desktop image and the box becomes a desktop box. | Own kernel per box (microVM); each of these has its own maturity, platform and licensing caveats, and only Kata has years of production use behind it. | You are adopting a young-ish runtime and a desktop image, and you own the glue between them. BoxLite is the one of these that runs OCI images inside a per-box KVM/Apple-Hypervisor VM as an embedded library, which is why it keeps appearing in agent-framework integrations. |
| Cua | Minutes on macOS with a VM path already set up; longer elsewhere. | VM on the local path; cross-OS cloud fleets as well. | macOS/Apple-Silicon-centric and a sprawling four-product surface; the host-driver path gives you no boundary at all. See its assessment. |
| A VMM you drive yourself (Firecracker, Cloud Hypervisor, crosvm, libkrun) plus your own guest image | Days to a desktop, and you will be building the image, the driver layer and the networking. | Own kernel, smallest device model you choose. | The most control and the most assembly. This is where you end up when the packaged options do not fit your threat model — see the microVM chapter. |
Only a few routes answer both questions — is there a boundary, and do I get a screen without losing an evening. E2B Desktop (microVM plus streaming), Windows Sandbox (disposable Hyper-V desktop) and a container-desktop image (a desktop in one command, weaker boundary) are the three that answer both with different trade-offs. Everything else gives you one and asks you to supply the other.
What a desktop app can plausibly fan out
If you are building a desktop application that starts many agent boxes, the useful design is not "pick a backend" — it is one interface over three backends, chosen by threat level:
| Tier | Backend | Why it is in this tier | What it costs you |
|---|---|---|---|
| Routine work you are watching | Rootless container lane | Densest and fastest; image layers are already copy-on-write, so ten lanes from one image share the immutable layers. | Shared kernel. Acceptable for accidents and most injection, not for hostile code. |
| Untrusted content or third-party code | MicroVM running an OCI image (BoxLite, Microsandbox, Kata, Cloud Hypervisor) | A real kernel per task with container-shaped ergonomics; per-box copy-on-write disks make fork and rollback cheap. | KVM required; slower file sharing; a younger runtime in most cases. |
| Windows guests, GUI tooling, or "I want it to be boring" | Full VM (Incus VM, Lima, UTM, Hyper-V/HCS) | The boundary that does not care what the agent does, and the only route to a real Windows desktop on a Windows host. | A gigabyte or more of RAM per guest, and a second machine to configure. |
- Base images and image layers. Containers from one image share immutable layers, and only the upper layer is per-lane.
- Copy-on-write disks.
qemu-img create -b base.qcow2, Incus and ZFS/Btrfs snapshots and clones, and BoxLite's per-box QCOW2 disk with clone-from-snapshot all give you a new lane for the cost of the delta. - Snapshots and suspend/resume. Resuming a suspended guest is faster than booting one, which is what makes per-task machines affordable in time.
- Warm pools. Pre-provisioning a few idle lanes turns acquisition from a two-minute install into milliseconds.
They do not turn ten active GUI VMs into one VM's RAM. Sharing the base image and the disk is a disk and startup win; each running guest still has its own kernel and its own desktop stack resident. Ten desktops cost roughly ten desktops' worth of memory, whatever the provisioning tricks — so the honest planning moves are to cap concurrency, to keep the desktop tier for the tasks that need one, and to put most lanes in containers or headless browsers. Adding a microVM tier gets you a real kernel per task at a fraction of a desktop's footprint, which is usually the best density-per-boundary available; a shared-kernel container tier is denser still and is a weaker boundary. Pick the tier per task, not per application.
Orchestrators that already speak more than one backend
Projects that abstract several of these backends behind one policy or UI exist, and they are the right thing to study even though none of them is measured here:
- Microsoft MXC — one JSON policy schema over AppContainer-style process containers, Windows Sandbox, WSLC, Hyperlight, NanVix, an isolation session, bubblewrap and LXC on Linux, and Seatbelt on macOS, with a documented per-build enforcement matrix. Its own README says no profile should be treated as a security boundary yet (Windows chapter).
- BoxLite's agent-framework integrations — Omnigent, Alibaba's AgentScope Runtime and ByteDance's deer-flow each expose it as a sandbox backend; those are statements by the consuming projects, not production evidence.
- yoloai and cco — one wrapper over many local backends, with a copy/diff/apply review workflow. The cost is the complexity of the matrix they are hiding.
- Sculptor — a desktop application for running parallel agents in isolated containers: the closest existing prior art for the container tier of the shape above, and the reason to look at it is the fan-out UX rather than the isolation.
What this section does not give you is a benchmark: we have not found a published side-by-side measurement of desktop-sandbox fan-out, so the tiering here is engineering judgement resting on documented mechanisms — copy-on-write, snapshot, memory accounting — and on the per-project claims cited above. If you build one of these, measure your own ten-desktop case before you promise a number.
The projects, and how to read them
| Project | What it is | Isolation | Assessment |
|---|---|---|---|
| Cua (trycua) | Drivers, local macOS/Linux VMs on Apple's Virtualization framework, cross-OS cloud fleets including Android, and a benchmark suite. | VM when you use the VM path; nothing when you drive the host | The most substantial open computer-use toolkit, 24k stars, MIT, very active — and macOS/Apple-Silicon centric with a sprawling four-product surface. Assessment → |
| E2B Desktop | Firecracker-backed desktop sandbox for computer use, with streaming and password protection. | MicroVM per sandbox | The right architecture; the platform caveats from E2B's assessment apply, plus the usual desktop-agent injection exposure. |
| agent-desktop | Rust CLI driving applications through accessibility trees with stable element references. | None — it runs on your session | High-quality engineering and a better approach than pixels, but macOS-only today. Assessment → |
| browser-use | The most-used browser agent framework. | None of its own | Enormous adoption, and the source of a critical allowlist-bypass CVE plus most of the published threat model. Use it inside a dedicated profile in a VM. |
| EdgeBox | Electron desktop with a containerised full desktop over VNC and MCP support. | Container desktop | Stalled since April 2026, no releases, GPL-3.0, and a README that advertises an unrelated project. Take the UX idea, leave the repo. Assessment → |
| Windows-MCP | MCP server giving an agent control of the Windows desktop. | None — it is host control | Genuinely useful, and the exact opposite of a sandbox. Assessment → |