Runtime gives every sandbox a Firecracker microVM. The microVM's monitor is built around a handful of virtio devices.
Why virtio exists
A virtual machine needs devices, and every guest operating system needs drivers for them. virtio gives both sides one agreed family of virtual devices. Its introduction says "virtual environments and guests should have a straightforward, efficient, standard and extensible mechanism for virtual devices, rather than boutique per-environment or per-OS mechanisms." The devices deliberately look like ordinary hardware to the guest, so standard driver discovery finds them.
Data moves through virtqueues: "rings of descriptors for both input and output, which are neatly laid out to avoid cache effects from both driver and device writing to the same cache lines." Feature bits, acknowledged when the device starts, let a newer device and an older driver agree on what both support.
Facts
| Property | virtio, as the OASIS specification states it |
|---|---|
| Publisher | OASIS Virtual I/O Device (VIRTIO) TC |
| Latest version | 1.4, Committee Specification 01, dated 8 April 2026 |
| Transport | PCI, memory-mapped I/O (MMIO) or channel I/O |
| Data path | Virtqueues of buffer descriptors |
| Compatibility | Feature bits negotiated between device and driver |
| Device IDs (some) | 1 network, 2 block, 3 console, 4 entropy, 5 balloon, 19 socket (vsock) |
Which virtio devices does Firecracker use?
Firecracker's site says "only 5 emulated devices are available". Three of them are virtio devices: net, block and vsock. The other two are a serial console and a minimal keyboard controller. The keyboard controller is used only to stop the microVM. Firecracker's design document says that one VMM thread emulates the virtio network, block and vsock devices in a single event loop. The devices are backed by host TAP devices and files, and rate limiting applies at the I/O boundary. The vsock device is the one that carries sockets between guest and host without a network.
Why virtio matters for AI agent sandboxes
Every emulated device is host code that parses what the guest sends it. In an agent sandbox, the guest may run hostile code. A small set of purpose-built virtio devices keeps that code short. It also keeps disk and network fast enough that an agent installing packages or cloning a repository does not wait on emulation.
How Runtime relates to it
Each Runtime sandbox is a Firecracker microVM with its own kernel and disk. The guides describe the result, not the devices. A sandbox has no network card. Every outbound connection goes through a proxy on the host, and root inside the sandbox cannot bypass it (the network). The virtio disk reaches up to about 1 GB/s when the server's other sandboxes are quiet. It never drops below about 40 MB/s when they are busy (disk, CPU and memory).
Related: Firecracker, virtual machine monitor, QEMU vs Firecracker.
Sources
Checked 25 October 2026.
- Virtual I/O Device (VIRTIO) Version 1.4, OASIS
- VIRTIO 1.4 directory, OASIS
- Firecracker
- Firecracker design
Facts on this page were checked on 25 October 2026.