Runtime runs the Firecracker hosts for you. A sandbox is one API call, not a host that you harden yourself. Each sandbox is a Firecracker microVM with its own Linux kernel, on dedicated servers that Runtime operates.
Why Firecracker has a jailer
Firecracker's first barrier is the virtual machine. Guest code runs on KVM, behind the processor's virtualization extensions. The jailer is a second barrier behind it, on the host. Its documentation calls it "a program designed to isolate the Firecracker process in order to enhance Firecracker's security posture". The Firecracker site calls it "a second line of defense in case the virtualization barrier is ever compromised."
The project's production guide is direct: "Firecracker should be started using
the jailer binary that's part of each Firecracker release, or executed under
process constraints equal or more restrictive than those in the jailer."
What the jailer does, in order
- Cleans its inputs. It validates the paths and VM ID, closes every open file descriptor except standard I/O, and clears the environment it inherited.
- Builds the jail directory at
<chroot_base>/<exec_file_name>/<id>/rootand copies the Firecracker binary into it. - Sets limits. It applies resource limits from
--resource-limit. It then creates cgroup sub-folders that hold the process, with values such ascpuset.cpus=0passed through--cgroup(cgroups). - Changes root. It calls
unshare()into a new mount namespace, swaps the root withpivot_root(), unmounts the old root and callschroot. - Adds only two devices inside the jail, with
mknod:/dev/net/tunand/dev/kvm. - Joins the namespaces it is given. It joins a network namespace with
--netns, and it starts a new PID namespace with--new-pid-ns(Linux namespaces). - Drops privileges to the
--uidand--gidit was given. It then execs Firecracker, which applies its own seccomp filters by default before guest code runs.
Facts
| Option | What it does, per the jailer documentation |
|---|---|
--id |
The microVM's ID: letters, digits and hyphens, up to 64 characters |
--exec-file |
Path to the Firecracker binary |
--uid, --gid |
The unprivileged user and group Firecracker runs as |
--cgroup-version |
Chooses cgroup v1 or v2 |
--netns |
Joins an existing network namespace |
--new-pid-ns |
Starts Firecracker in a new PID namespace with CLONE_NEWPID |
--daemonize |
Calls setsid() and sends standard I/O to /dev/null |
Why it matters for AI agent sandboxes
A sandbox service runs many tenants' microVMs on one server. Suppose a guest found a flaw in the monitor. The jailer then decides what the compromised process can reach: one chroot, one set of cgroup limits, and no root. Firecracker also advises that "each Firecracker process corresponds to a workload of a single tenant". One microVM per sandbox follows this advice.
How Runtime relates to it
Runtime's guides describe the boundary that customers rely on. Each sandbox has its own kernel, disk and guest environment. CPU, memory, disk, network rules, leases and billing are enforced on the host. Host credentials, control sockets and provider credentials never reach customers (security). You get this boundary without installing Firecracker, configuring KVM access or building a jail.
Related: Firecracker, virtual machine monitor, nsjail vs Firecracker, self-hosted vs managed sandbox.
Sources
Checked 25 October 2026.
Facts on this page were checked on 25 October 2026.