Isolation: what kind of computer you get

The idea

A sandbox is a boundary before it is a computer. The boundary is drawn by the host: a container shares the host's kernel, a virtual machine has its own. The stronger the boundary, the more the inside behaves like a real server, and the more it costs to start.

Four kinds show up in this market. A container shares the host kernel and is the weakest boundary. gVisor intercepts system calls in user space, which is stronger than a container but still not a kernel of its own. A microVM, usually Firecracker or Cloud Hypervisor, has its own kernel and starts in milliseconds. A full VM is the same idea with a conventional machine model, and it is the only kind where nested virtualisation is routinely expected.

The boundary and the capability list are different things. A microVM can still refuse kernel modules, omit systemd, or ship without Docker. So the useful question is not “is it a VM?” but “what can I run inside it, and what happens when the agent breaks it?”

Where providers split

The claim on the left, the provider's own words on the right

The default type is often the weaker one

Agent 37's default instance is a gVisor container. Docker does not work there; you choose the vm type, at 2.5× the compute rate, to get a real kernel. Its own docs describe the vm type as being for Docker, Kubernetes, databases and Android emulators.

Most of the others make the microVM the default: E2B, Vercel, Sandboxer, InstaBox, Lizard, Runtime and Sprites all describe a per-sandbox kernel. Morph goes further and sells full VMs with Docker-in-Docker and systemd as the normal case.

A real kernel does not guarantee a normal server

Sprites is a hardware-isolated microVM, but it does not run systemd; its own service manager starts services on wake. Blaxel's default kernel refuses module loading and kernel tracing to every process, including root, and iptables has to be enabled at creation. Lizard documents root but not whether a Docker daemon runs inside.

E2B is the opposite asymmetry: the boundary is strong, but the default template user is an ordinary user, not root. Root is a template choice, not the default.

What to watch for

The details that decide the answer in practice

01
Docker on the default type: at Agent 37 it needs the vm type at 2.5× the rate.
02
systemd: Sprites does not run it, and several providers do not document it either way.
03
Kernel modules: Blaxel refuses them by default; E2B's kernel is missing at least one module.
04
Nested virtualisation: Runtime exposes /dev/kvm; Sandboxer and Morph document it, Morph as experimental.
05
Root inside the guest is not root on the host, whatever the provider's marketing implies.

Compare all twelve

Docs read 28 October 2026

Every provider says “sandbox”. Underneath, it is a container, a gVisor container, a microVM or a full virtual machine, and that decides what your agent can install, run and break.
Provider	Does it?	What that means
Agent 37	Partly	A gVisor container by default, with no Docker; the vm type gives a real kernel at 2.5× compute, and performance gives dedicated cores at 4×.
“vm is a whole virtual machine with its own kernel, for Docker, Kubernetes, databases, and Android emulators, at 2.5x the default compute rate” Agent 37docs-confirmed
Blaxel	Partly	A microVM boundary, root by default, but the default kernel refuses module loading and kernel tracing, and iptables needs enabling at creation.
“the microVM boundary remains the isolation guarantee between your sandbox and everything else.” Blaxeldocs-confirmed
Boat	Yes	A full Ubuntu VM with its own kernel, Docker, SSH and root. The closest thing here to an ordinary server.
“boat gives you full Ubuntu virtual machines (sandboxes) for AI agents and code, billed per second.” Boatdocs-confirmed
boxd	Yes	A KVM microVM with its own kernel, network stack and disk. Docker, systemd, kernel modules and breaking the OS all stay inside the machine.
“Every boxd machine is a KVM microVM with its own kernel, network stack, and disk.” boxddocs-confirmed
E2B	Yes	A Firecracker microVM with its own kernel. Docker is documented, but the default template user is user, not root, and some kernel modules are missing.
“not a container. Each one boots its own kernel” E2Bdocs-confirmed
InstaBox	Yes	A Firecracker microVM running Debian 13 with its own kernel, root, passwordless sudo and Docker.
“A whole machine, with its own kernel.” InstaBoxdocs-confirmed
Lizard	Partly	A Firecracker microVM with its own kernel and root by default, but Docker inside a sandbox is not documented either way.
“Sandboxes run as Firecracker microVMs, each with its own kernel.” Lizarddocs-confirmed
Morph	Yes	Full VMs with Docker-in-Docker, systemd, root and FUSE. Nested virtualisation and other guest operating systems are experimental.
“Full virtual machines capable of running any configuration of containers: docker‑in‑docker, a local Kubernetes cluster, self‑hosted Supabase, etc.” Morphdocs-confirmed
Runtime	Yes	A Firecracker microVM with its own kernel, and new sandboxes expose /dev/kvm, so nested virtualisation works.
“Runtime Cloud is a cloud for AI agents' code: Linux sandboxes, each a Firecracker microVM” Runtimedocs-confirmed
Sandboxer	Yes	A Cloud Hypervisor microVM with its own kernel, systemd, Docker with BuildKit and Compose, and /dev/kvm.
“Each sandbox is a separate Cloud Hypervisor microVM with its own kernel.” Sandboxerdocs-confirmed
Sprites	Partly	A hardware-isolated microVM with root and Docker reported, but it does not run systemd: a built-in service manager starts services on wake.
“Sprites don't run systemd; the log files and the create/start streams are how you see service output.” Spritesdocs-confirmed
Vercel Sandbox	Partly	A Firecracker microVM with a dedicated kernel, root, Docker and FUSE. systemd and nested virtualisation are not published.
“each sandbox runs in its own Firecracker microVM with a dedicated kernel.” Vercel Sandboxdocs-confirmed

Part of The machine. Next: put two or three providers side by side.