AI agent sandboxes in 2026: a map of the options

01What separates one AI agent sandbox from another?

An AI agent sandbox is where the code an agent writes or downloads actually runs, so a bad command or a prompt injection lands there instead of on your laptop or production servers. The products on this map differ first on the boundary and the location, then on state, network, secrets and pricing. Each product fact below comes from that product's own documentation, read on 31 October 2026.

Containers isolate with namespaces and control groups that the host kernel provides, so every container on a host shares that kernel. gVisor puts an application kernel that runs in user space between the program and the host. MicroVMs and full VMs give each sandbox its own guest kernel through hardware virtualization. Several services let you pick the runtime for each sandbox.

• Container: Docker Engine and other container runtimes.
• User-space kernel: gVisor (runsc), offered by Modal and Northflank.
• MicroVM: Firecracker, Kata Containers, Docker Sandboxes, Vercel Sandbox, Cloudflare Containers, microsandbox, kosa8.
• VM, hypervisor not named in the docs: E2B, Runloop, Modal's VM runtime, Daytona's VM class.
• General-purpose VM on your desk: Lima, UTM.

02Containers and gVisor: the shared-kernel end of the map

Docker's security docs call namespaces the first layer of isolation. The same page says the daemon needs root unless you opt in to Rootless mode, that user namespace remapping is available but off by default, and that a container given a host directory mounted at / can change the host filesystem without restriction. For an agent, that makes the host kernel and your choice of mounts and sockets the boundary.

gVisor's Sentry intercepts the application's system calls and acts as its kernel, and a separate Gofer process handles all file access. gVisor ships as runsc, an OCI runtime for Docker and Kubernetes. Its docs list the tradeoffs: some system calls and /proc files are missing, syscall-heavy workloads run slower, and startup is faster than a VM's. Modal runs sandboxes on gVisor or on a VM runtime, and Northflank uses gVisor where microVMs are not supported.

03MicroVMs: Firecracker, Kata and Docker Sandboxes

Firecracker is an open-source virtual machine monitor built on KVM. Its site gives a boot time under 125 ms, under 5 MiB of overhead per VM and five emulated devices, with a jailer process as a second line of defense. It runs AWS Lambda, and the site lists E2B, Northflank and Kata among its integrators. Kata Containers builds lightweight VMs that accept OCI images, plug into the Kubernetes CRI and run on QEMU, Cloud Hypervisor or Firecracker.

Docker Sandboxes is a separate product from Docker Engine. It runs coding agents in microVMs, locally or on Docker-managed cloud, through the sbx CLI, and each sandbox has its own Docker daemon. Outbound TCP is denied by default and passes through a host-side proxy, which swaps a sentinel value for the real API key. Its docs also name the limits: local stdio MCP servers run on the host, and the default allow list includes broad wildcards such as *.googleapis.com. Local use is free, and cloud compute is pay-as-you-go.

04Cloud sandbox services: what each one documents

These are listed alphabetically, not ranked, with what each product's docs say about boundary, state, network and secrets.

Two patterns repeat across the list. Several services let you choose the runtime per sandbox or per class. Most offer both a block-all switch and an outbound allow-list, but they match on different things: IP ranges, the TLS server name, or a proxy.

• Cloudflare Sandbox SDK: sandboxes are reached through a Worker. Containers are microVMs, each with its own kernel and network. Your Worker decides internet access (for example enableInternet: false), and the docs advise keeping credentials in the Worker. Requires the Workers Paid plan.
• Daytona: Linux containers by default, plus Linux VM, Windows and macOS classes that run in full VMs. Start time under 90 ms. Tier 3 and 4 organizations get full internet by default, which networkAllowList (up to 10 IPv4 CIDRs) or networkBlockAll can replace, and Tiers 1 and 2 are restricted.
• E2B: each sandbox is a Linux VM. Pausing saves the filesystem and memory, and paused sandboxes are kept until you kill them. A sandbox runs for up to 24 hours on Pro or 1 hour on Hobby. Internet is on by default, and allowOut and denyOut take IPs, CIDRs or domains.
• Modal: gVisor or a VM runtime. The default lifetime is 5 minutes, adjustable up to 24 hours, and filesystem snapshots carry state forward. Network options are block_network, CIDR allowlists and a beta domain allowlist matched on the TLS server name. Secrets arrive as environment variables.
• Northflank: on your own AWS, GCP or Azure account, sandbox security installs both Kata and gVisor, and a runtime class picks one for each workload. MicroVM nodes need bare metal or nested virtualisation.
• Runloop: Devboxes are ephemeral VMs that support snapshot, suspend and resume. Network Policies restrict egress, and Agent Gateways and MCP Hub connect agents to services without putting the real credentials in the devbox.
• Vercel Sandbox: each sandbox is a Firecracker microVM. Sandboxes persist by default and support snapshots. Billing is by Active CPU, so there is no CPU charge while code waits on model calls.

05Local options: microsandbox, kosa8, Lima and UTM

A local sandbox keeps the code and the data on your own machine. In exchange, it runs on your hardware and you operate it yourself.

Running locally does not settle the boundary question. The options range from a general-purpose VM you configure by hand to a microVM built for agents, with network and secret controls included. What running locally changes is who operates the sandbox and where the data sits.

• microsandbox: a local-first microVM runtime for Apple Silicon Macs, Linux with KVM and Windows with WHP, started by the SDK without a daemon. It has a network allowlist and secrets that never enter the VM. It calls itself beta software and is Apache 2.0 licensed.
• kosa8: gives each agent its own microVM that sees one workspace folder, with a network closed except for an allow-list you write. API keys stay on the host behind an egress broker. It can checkpoint the running machine in about 0.7 seconds and rewind it in about half a second.
• Lima: Linux VMs with automatic file sharing. Its AI-agent guide recommends mounting only the project directory (limactl start --mount-only .:w) or using sync mode, where you accept, discard or diff the changes when the session ends.
• UTM: a QEMU-based VM host for macOS and iOS. You get a whole VM as the boundary, and you set up the network rules and credentials yourself.

06How to choose: six questions to ask

No ranking holds for every team. Answer these six questions, and the map narrows to two or three candidates. Then read their current docs, because limits and defaults change.

Write the answers down before you test anything. They are also the requirements a security reviewer will ask for later.

• Where must the code run? Your laptop, a vendor's cloud, or your own cloud account. Data residency often decides this first.
• What boundary do you need? A container can be enough for code you reviewed. Unreviewed code, new packages and agents that read untrusted text make the case for a separate kernel.
• What state must survive? Files only, or memory and running processes too. Check the pause and snapshot behaviour and the lifetime caps.
• How is the network controlled? Is it open or closed by default? Does the allow-list match IP ranges or domains, and is it enforced on the TLS server name or by a proxy?
• Where do the secrets live? In an environment variable the agent can read, or outside the sandbox and injected on the way out.
• How are you billed? By active CPU, by pay-as-you-go compute, on plan tiers, on your own cloud bill, or on your own hardware.