Agents now write and run programs on their own, often after reading text they did not write: a web page, an email, a document. That text can steer the agent, so the code it produces needs a wall around it. The design question is where to put the wall. A wall close to the program is cheap and fast but has more places to leak. A wall around a whole virtual computer is stronger but heavier.
Containers
A container runs as an ordinary process on the host, fenced in by operating system features. Every container on a machine shares one kernel, so a kernel bug found inside one can reach the host and its neighbours. seccomp, AppArmor and SELinux shrink the risk. The gVisor documentation describes these as rule-based mechanisms and says gVisor was built because rules alone leave the host kernel exposed. A hardened container suits code you wrote and trust.
MicroVMs (Firecracker)
A microVM has its own kernel on hardware-enforced virtualization, so a bug the code finds stays inside the small virtual machine. Firecracker was built at AWS for Lambda and Fargate. Its README says it leaves out unneeded devices to keep memory use and attack surface small, and its default setup is 1 virtual CPU and 128 MiB of memory. The NSDI paper frames the trade: traditional virtualization gives strong security with high overhead, containers give minimal overhead with weaker security. Firecracker publishes no boot-time figure.
gVisor
According to its documentation, gVisor is an application kernel written in Go that handles the program's system calls itself, so the host kernel is not directly exposed, and it needs no hardware virtualization layer. The documentation names the price: reduced application compatibility and higher per-system-call overhead, so programs that make many system calls can run poorly.
WebAssembly
A Wasm module runs in a runtime that separates it from the host. Its memory is a separate region with a fixed maximum, every access outside it is bounds-checked and ends in a trap, and the module can reach the outside world only through interfaces the host provides. If the host offers no file or network functions, the module cannot ask for them. The WebAssembly security documentation also lists limits: race conditions, timing side channels and some nondeterminism are not prevented. Wasm suits code compiled to Wasm, not the arbitrary Python packages and native tools many agents call.
Docker's documentation says Wasm workloads in Docker Desktop are deprecated, no longer actively maintained and will be removed in a future release, so it is a poor basis for a new sandbox.
Choosing
Trusted internal scripts can run in a hardened container. Code generated from untrusted input for many customers on shared machines is where microVMs and gVisor are used. A sandbox controls what code can reach, not what an agent is permitted to do: an agent allowed to send email or call an API can still be talked into misusing that permission. Network limits, narrow credentials and human approval for risky steps remain separate jobs.
Write down what the agent's code may read, write and reach, then pick the lightest isolation that covers that list.
The original also covers Docker's Wasm deprecation in more detail and includes a short FAQ: https://syntaxradar.com/radar/sub-millisecond-sandboxes-docker-wasm-micro-vms-untrusted-ai-execution
Top comments (0)