Running AI agents in microVMs with zero inbound ports

Long-horizon episodes need real operating systems, real applications, and hard isolation. The emerging pattern is microVMs with zero inbound ports. Firecracker microVMs run Linux sessions; Cloud Hypervisor runs Windows Server for enterprise work that is Windows-native. All traffic flows over outbound tunnels. Gateway URLs are single-session and expiring. Capacity is reserved in a database before any VM exists. Two problems remain unsolved across the industry: per-episode application-database reset for deterministic verifiers, and an action-level GUI event schema for trajectory labeling.

Key Takeaways

• The converging stack: Firecracker microVMs for Linux, Cloud Hypervisor for Windows, outbound-only tunnels, expiring gateway URLs, and capacity reserved before creation.
• Isolation class is a measurable choice, not a preference: comparative security studies separate microVMs from userspace kernels and OCI containers on attack surface and leakage.
• Two problems are still open industry-wide: 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?

Firecracker, the microVM monitor built for AWS Lambda (Agache et al., NSDI ‘20), 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 Windows Server, with the full desktop delivered through a browser-based remote-desktop gateway.

The isolation class is not a matter of taste. A comparative security study of AI code sandboxes measured engine-level properties, attack surface, leakage, CVE history, across microVM, userspace-kernel, and OCI-container designs and found the classes separate cleanly (Andronchik et al., 2026). When an RL agent will spend hours executing arbitrary actions, you want the hardware-virtualization boundary, and the field is starting to treat agent infrastructure as its own design discipline (Chan et al., 2025).

The Linux/Windows split isn’t arbitrary either. Enterprise work is Windows-native. Audit workpapers live in Excel. Reliability engineering tools run on Windows. Grading that work on Linux measures adaptation to a substitute operating system, not competence in the target domain. Serious environment designs treat the operating system as a measured variable: 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 isolation stack has 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 ever reach the browser.
• Network policy is enforced inside the guest, not by trust. 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 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. None of this is free: 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). The tax is worth paying. It’s still a tax.

What problems remain unsolved?

Two problems nobody in the industry has solved cleanly.

First, 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 exactly 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 can’t be deterministic and episode variants can’t be cheap.

Second, an action-level GUI event schema for trajectory labeling. Shell sessions can be recorded with full input and output. Windows desktop sessions need input, window, and application events rich enough for trajectory labeling and replay, the structure that turns a screen recording into training data. The payoff is proven: UI-TARS trained a native GUI agent end-to-end on screenshot-and-action trajectories. The tooling for shell exists. The GUI gap is open across every vendor.

What this means

The infrastructure pattern is converging: microVMs, outbound-only networking, expiring gateway URLs, and capacity reservation before creation. The unsolved problems, per-episode database reset and GUI event schemas, are the gaps that determine which environments can be served at scale and which cannot.

FAQ

Why are no inbound ports open on guest VMs?

Security. An agent running inside a guest VM has no path to receive inbound connections, which eliminates an entire class of network-based exploits. All traffic flows over outbound tunnels to a gateway, and gateway URLs are single-session and expiring. 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, not the modified one. Per-episode reset restores the application database to its seeded state after each episode. Without it, verifiers cannot be deterministic.

Why does the operating system matter?

An environment that grades audit work on LibreOffice measures tool adaptation, not audit competence. Windows and native Office are selected for audit work because workbook formulas, review behavior, and final artifacts are part of the target skill. The operating system is a measured variable: the question is whether the tool choice affects what is being measured.