A Runtime sandbox is a Firecracker microVM with its own Linux kernel. The
boundary between one customer's code and another's is a virtual machine, not a
shared kernel. Docker still works inside it after sudo enable-docker. A
2 vCPU, 4 GiB sandbox costs $0.08 an hour with both CPUs busy
(pricing).
Why containers can be escaped
A container is a set of ordinary host processes. Docker's documentation calls it "simply an isolated process with all of the files it needs to run". It also says that containers on one machine share that machine's kernel. The isolation comes from kernel features applied to those processes:
- Namespaces give it a private view of process IDs, mounts, the network, and more.
- Cgroups cap its CPU, memory and process count.
- Dropped capabilities make "root" inside weaker than real root.
- Seccomp blocks system calls it should not need.
Every one of these is enforced by the kernel the container can call into. An escape is anything that crosses them: a kernel bug reachable by a system call, a flaw in the container runtime, or a setting that hands the container too much, such as a mounted host directory or a disabled seccomp profile.
A real example
On 31 January 2024, runc, the low-level container runtime, published advisory GHSA-xr7r-f8xq-vfvv, titled "Several container breakouts due to internally leaked fds".
| Field | Value |
|---|---|
| CVE | CVE-2024-21626 |
| Severity | High, CVSS 8.6 |
| Affected | runc 1.0.0-rc93 through 1.1.11 |
| Fixed | runc 1.1.12 |
| Root cause | File descriptors, including one for the host's /sys/fs/cgroup, leaked into runc init |
| Effect | A new container process could start with its working directory on the host filesystem |
The advisory lists attack routes through a malicious image and through
runc exec, up to overwriting host binaries. It adds that under Docker or
Kubernetes the exploit "can be considered critical as it can be done remotely
by anyone with the rights to start a container image".
Why it matters for AI agent sandboxes
An agent runs code that nobody reviewed. A prompt injection can determine what that code does. If many users' agents share one kernel, one escape exposes all of them. When each agent has its own virtual machine, an escape from a container inside it lands in that guest. It remains behind the virtual machine boundary.
How Runtime handles it
Each sandbox has its own kernel, disk and guest environment. You are root inside the guest, but root cannot change the limits. CPU, memory, disk, network rules, leases and billing are enforced on the host, outside the guest. Host credentials and control sockets never reach customers (security). Containers you start with Docker in a sandbox run inside that guest (Docker in a sandbox).
Related: microVM vs container, run untrusted LLM code, run Docker in a sandbox, gVisor.
Sources
Checked 25 October 2026.
- runc advisory GHSA-xr7r-f8xq-vfvv (CVE-2024-21626)
- Docker Engine security
- Docker: what is a container?
- Docker seccomp profiles
Facts on this page were checked on 25 October 2026.