Why AI agent sandboxes run in microVMs with zero inbound ports

Long-horizon episodes need the operating system and applications the work runs on, plus hard isolation, and the pattern rlresearch.ai’s reference infrastructure spec adopts is microVMs with zero inbound ports. A microVM is a lightweight virtual machine with a minimal device model that boots in milliseconds while keeping a hardware-virtualization boundary between the agent and the host. Firecracker, the microVM monitor built for AWS Lambda (Agache et al., NSDI 2020), runs Linux sessions; Cloud Hypervisor, the open-source virtual machine monitor hosted by the Linux Foundation, runs Windows Server for enterprise work that is Windows-native. All traffic flows over outbound tunnels, gateway URLs are single-session and expiring, and capacity is reserved in a database before any VM exists. Two problems remain open in every public environment stack we have examined: per-episode application-database reset for deterministic verifiers, and an action-level GUI event schema for turning desktop sessions into training data.

Key Takeaways

• The stack in the reference spec: Firecracker microVMs for Linux, Cloud Hypervisor for Windows, outbound-only tunnels, expiring gateway URLs, and capacity reserved before creation.
• A comparative security study (Andronchik et al., June 2026) separates microVMs from userspace kernels and OCI containers on attack surface and leakage, so the isolation class is a measurable choice.
• Still open as of August 2026: per-episode application-database reset and an action-level GUI event schema rich enough to turn desktop sessions into training data.

Why Firecracker for Linux and Cloud Hypervisor for Windows?

In the reference spec, Firecracker runs Linux sessions with millisecond boot times and minimal attack surface: browser, shell, and IDE reached over outbound tunnels, no inbound ports into guests. Cloud Hypervisor runs the Windows Server sessions, with the full desktop delivered through a browser-based remote-desktop gateway.

A comparative security study of AI code sandboxes measured engine-level properties (attack surface, leakage, CVE history) across microVM, userspace-kernel (gVisor-style), and OCI-container (Docker-style) designs and found the classes separate cleanly (Andronchik et al., 2026). When an RL agent will spend hours executing arbitrary actions, a hardware-virtualization boundary is the appropriate isolation class, and researchers have begun arguing for the infrastructure around agents as a design discipline (Chan et al., 2025).

The Linux/Windows split follows the work. Much enterprise work is Windows-native: audit workpapers are typically Excel workbooks, and many reliability-engineering tools run only on Windows. Grading that work on Linux measures adaptation to a substitute operating system rather than competence in the target domain. The designs reviewed treat the operating system as a scored dimension: Windows with native Office for audit and reliability work, Linux for engineering analysis where Python and pinned scientific libraries are the native toolchain.

How does the network isolation work?

The reference infrastructure spec sets four rules:

• All traffic flows over outbound tunnels. No inbound port is open on any guest VM.
• Gateway URLs issued to experts are single-session and expiring. No infrastructure credentials reach the browser.
• Network policy is enforced inside the guest. Task-level network denials are applied within the VM, so an agent cannot bypass policy by manipulating anything outside its own sandbox.
• Capacity is reserved in a control-plane database (the scheduler’s record of capacity) before any VM exists. Sessions land on autoscaled host pools, and heartbeats reconcile active sessions against reservations.

The last rule prevents over-provisioning and ensures a session request either gets a real VM or fails cleanly. Recent work quantifies the “rollout infrastructure tax,” the execution-substrate overhead that containers, sandboxes, and VMs impose on agent RL training (Graviet et al., 2026). Hard isolation adds to that overhead.

What problems remain unsolved?

Two problems remain open in every public environment stack we have examined.

The first is per-episode application-database reset. A deterministic verifier requires that every episode starts from the same initial state. Resetting a guest VM restores the operating system, but seeded application databases (an HR system, a CRM clone, a synthetic general ledger) need snapshot and restore at episode granularity. OSWorld leaned on VM snapshots for this reason, and transactional-filesystem approaches that roll back destructive agent actions are appearing (Yan et al., 2025), but application-level state at episode granularity remains the gap. Without it, verifiers cannot be deterministic and episode variants cannot be cheap.

The second is an action-level GUI event schema for trajectory labeling: tagging each recorded action so a session can be used for training. Shell sessions can be recorded with full input and output. Windows desktop sessions need input, window, and application events rich enough for labeling and replay, the structure that turns a screen recording into training data. UI-TARS trained a native GUI agent end-to-end on screenshot-and-action trajectories, so the payoff is demonstrated. The tooling for shell exists; the GUI gap remains open in every design reviewed.

What long-horizon episodes look like at scale: 100-plus autonomous runs, sandboxed on 8xH200s for up to eight days. The isolation this post describes is what makes runs like these safe to serve.

What this means

Hard isolation, outbound-only networking, expiring gateway URLs, and capacity reservation are settled design choices in the reference spec. The two unsolved problems, per-episode database reset and GUI event schemas, decide which environments can be served at scale and which cannot.

FAQ

Why are no inbound ports open on guest VMs?

No inbound ports are open because an agent inside a guest VM then has no path to receive connections, which removes a class of network exploits. All traffic leaves over outbound tunnels to a gateway whose URLs are single-session and expiring, so the agent cannot exfiltrate data by opening a listener and no external attacker can reach the guest.

What is per-episode application-database reset?

A deterministic verifier requires that every episode starts from the same initial state. If an agent modifies a database during an episode (adds a record, changes a balance, deletes a row), the next episode must start with the original database. Per-episode reset restores the application database to its seeded state after each episode. Without it, verifiers cannot be deterministic.

Why run Windows for some environments?

Because the target work runs in Windows-native applications. Grading audit workpapers on a Linux office suite measures how well the agent adapts to substitute tools rather than whether it can do the audit, so the operating system is chosen per workflow. In the reference spec, Cloud Hypervisor runs Windows Server for that work and Firecracker runs Linux where Python and pinned scientific libraries are the native toolchain.