What is a container escape?
A container escape is when code inside a container breaks its isolation and reaches the host or other containers on the same machine.
A Runtime sandbox is a Firecracker microVM with its own Linux kernel, so the
boundary between one customer's code and the next is a virtual machine, not a
shared kernel. Docker still works inside it after sudo enable-docker, and 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", and explains that containers on one machine share its 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 same 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 nobody reviewed, and a prompt injection can choose what that code is. If many users' agents share one kernel, one escape exposes all of them. Keeping each agent in its own virtual machine means an escape from a container inside it lands in that guest, still behind the virtual machine boundary.
How Runtime handles it
Each sandbox has its own kernel, disk and guest environment. You are root inside, and it does not matter: CPU, memory, disk, network rules, leases and billing are enforced on the host, outside the guest, and host credentials and control sockets never reach customers (security). Containers you start with Docker in a sandbox live inside that guest (Docker in a sandbox).
Related: microVM vs container, run untrusted LLM code, run Docker in a sandbox, gVisor.
Sources
Checked 25 September 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 September 2026.