Agent sandbox isolation depends on which attack surface disappears. Archil’s Firecracker-backed sandboxes put a hardware boundary between untrusted code and the host, while gVisor intercepts syscalls and standard containers share the host kernel directly. The right choice depends on what an attacker must defeat next, what that boundary costs, and whether network access and credentials are controlled separately.
What the major agent sandboxes use today
Vendors that document their boundary fall into three groups. E2B runs every agent session in its own Firecracker microVM, Vercel Sandbox runs each sandbox in its own Firecracker microVM with a dedicated kernel, and Archil runs each sandbox as a Firecracker microVM with its own kernel and a persistent disk. Modal runs sandboxes on gVisor or in a VM with its own Linux kernel, and chooses for you unless you set the runtime. Anthropic says that when Claude runs code inside claude.ai, it does so in a gVisor container on isolated infrastructure. Daytona offers isolated containers with their own namespaces and resource limits, plus VM sandboxes with their own kernel. Firecracker itself came out of AWS, where it was built for Lambda and Fargate.
Why shared-kernel containers are not a security boundary for agent-generated code
A post-install hook from a typosquatted package is scanning the network. The agent has already run it, without the review that normally stands between a developer’s code and production. Prompt injection and malicious build scripts belong in this threat model as expected inputs. The boundary separating that process from another tenant on the same node now matters.
Standard containers use Linux namespaces and cgroups to separate processes, with seccomp and capabilities restricting what they can do. But their syscalls still go to the host kernel through a Linux interface with roughly 350 system calls. Namespaces limit what a process can see, but the calls still reach the same kernel, so an attacker who exploits a kernel bug in one compromised container can make a node-wide escape with no second barrier to cross. Containers still suit trusted code written in-house that has passed CI/CD. Once the code comes from an LLM or a user, however, the shared kernel is the wrong default boundary.
How gVisor interposes between the agent and the host kernel, and where that boundary ends
gVisor changes the syscall path without requiring hardware virtualization. Its Sentry is a userspace process implementing the Linux ABI, which intercepts the application’s syscalls. A second process, the Gofer, mediates filesystem access from the host side. The Sentry runs unprivileged under heavy seccomp filtering, leaving a small allowed-syscall surface. This replaces direct access to the host’s broad kernel interface with a constrained intermediary.
That intermediary matters, but it is not a hardware boundary. The host kernel remains shared, and a kernel vulnerability reachable through the Sentry’s allowed set can still expose neighboring tenants. gVisor sharply reduces the paths to that kernel without removing the kernel from the shared trust boundary. This ceiling comes from the architecture. A narrower door is useful, but it is not a separate building.
Operationally, gVisor fits existing container workflows through its OCI runtime, runsc, and a Kubernetes RuntimeClass. A pod opts in with one field while retaining normal images, volumes, and kubectl workflows. Because gVisor re-implements kernel behavior in Go, some syscalls and /proc features are unsupported or behave differently. Software using those interfaces can break even when its container image runs elsewhere. In return, gVisor needs no KVM, making it usable on some cloud VMs and CI runners where hardware virtualization is unavailable.
How Firecracker's hardware boundary changes the shape of a successful exploit
Firecracker moves the boundary below the workload’s kernel. Each microVM boots its own guest Linux kernel on KVM, separated from the host through the CPU’s virtualization features. An attacker must cross two barriers: a guest kernel escape followed by a hypervisor escape. Even an attacker who has root inside the sandbox still needs a VM escape to reach a neighboring tenant.
The device model is deliberately small, including virtio-net, virtio-block, a serial console, and a one-button keyboard controller. Firecracker has no BIOS and no USB, and emulates only a handful of devices, which keeps those interfaces out of the reachable attack surface. Each omitted feature is one less place an attacker can try to turn device behavior into an escape. The virtual machine monitor, or VMM, also runs in a seccomp-filtered process constrained by namespaces and cgroups. Hardware isolation adds a boundary in front of the host-side restrictions, which stay in place.
Archil runs agent sandboxes on Firecracker microVMs, each with its own kernel. Its infrastructure has run production workloads for over a year and now launches millions of agents per week, so the architecture has a track record of running agents in production. That is evidence of operation under real workloads, with the possibility of a hypervisor escape still open. A 2026 comparative security study of AI code sandboxes found that product pin policy matters most among the choices an operator makes when handling vulnerabilities. Firecracker changes what an attacker must defeat, while the operator decides how long systems keep running with known weaknesses.
Kata Containers as a middle path — VM isolation delivered through container APIs
Kata Containers combines VM-level isolation with container APIs and normal pod semantics. It is not a separate security tier above or below Firecracker when it uses a real hypervisor backend. Teams can use it to get hardware isolation while keeping the same way of describing Kubernetes workloads. The hypervisor is pluggable, with supported backends including QEMU, Cloud Hypervisor, Firecracker, and Dragonball. As a result, “Kata performance” is an incomplete description until the backend is named.
That choice also changes the storage path. Firecracker has no shared-filesystem device, so Kata-on-Firecracker needs a block device behind each VM, typically through containerd’s devmapper snapshotter. Kata-on-QEMU does not need that extra machinery. The Firecracker backend brings boot time toward the microVM floor and memory overhead toward tens of megabytes, but the storage dependency is part of the bargain.
For regulated-industry teams that cannot change their Kubernetes scheduling layer, this trade can make sense. Kata preserves the workload description while changing the boundary beneath it. Teams building an execution layer for agents from scratch have less reason to take on that extra complexity. Teams trade the freedom to choose how they run workloads for the simplicity of running Firecracker directly, while keeping the same strength of hardware isolation.
The performance costs each primitive actually imposes — boot latency, memory overhead, and syscall tax
Firecracker pays to boot a guest kernel and carries baseline memory for each VM. gVisor instead adds work along the syscall path, with lower baseline memory cost than a fleet of Firecracker microVMs. Standard containers fit more workloads on a host because they share its kernel, with the risks that sharing brings.
Workload shape determines which toll matters most. An agent compiling code, installing packages, and streaming tool output sits nearer the syscall-heavy end than a pure inference task. gVisor’s interception overhead matters more for that pattern because the workload repeatedly crosses its syscall boundary. Firecracker’s startup cost, by contrast, amortizes over a long-running session. For high-churn, sub-second work, cold starts become a central constraint, and prewarming pools can move that cost off the hot path.
The fleet still pays for memory even when boot latency is hidden. A host carrying many Firecracker sandboxes reserves more baseline memory than one carrying gVisor sandboxes, affecting cost per tenant. Kata on QEMU boots noticeably slower than Firecracker, while its Firecracker backend approaches the same floor with the added storage machinery. In Archil’s serverless execution mode, available since April 2026, one command runs in a fresh microVM against a disk, so each invocation pays a boot cost to get kernel isolation. Persistent sandboxes spread that startup cost over the whole session.
Network egress and credential handling — the threat the isolation primitive does not solve
No isolation primitive solves the network half of the threat model. An agent with outbound access and a credential inside its sandbox can send data out while every isolation mechanism works exactly as designed. No kernel exploit is required because the permitted network path is enough. Egress filtering, per-tenant traffic attribution, and CNI policy therefore sit outside the runtime decision.
A sandbox able to reach the instance metadata service at 169.254.169.254 can acquire host instance credentials, so blocking that endpoint belongs in every egress policy. The recommended credential pattern keeps the real secret outside the sandbox. An external proxy intercepts outbound calls and attaches the right token at the network boundary. The agent receives a synthetic credential meaningful only to that proxy.
For example, outbound traffic on Archil’s Developer plan is limited to a managed allowlist covering package registries, git hosts, and model APIs, while Team plans set their own firewall rules. On Team plans and above, credentials can be brokered so secrets never enter the sandbox and are injected at the network boundary. These controls address a threat that Firecracker alone does not. A microVM that inherits host credentials is only partially sandboxed, regardless of the strength of its hardware boundary. Isolation, egress policy, and credential injection must each be specified.
Patch cadence and CVE surface — why the operator's update policy matters as much as the engine choice
An isolation boundary also has a time dimension. An upstream fix cannot protect a fleet that is still pinned to a vulnerable version. George Andronchik and Pavel Lokhmakov’s 2026 comparative security study found that engine-side patch latency aggregates to near-zero days for coordinated disclosures. Downstream lag, however, spans zero days to well over a year, with some cases opaque or indefinite.
The study also found that the strongest combination of microVM isolation and a continuous public fuzzer was unoccupied in the set examined. That limits what the public record establishes about sustained testing of those deployments. Zero published CVEs is not proof of safety when there is also no upstream fuzzer and no academic study. In that combination, the surface is structurally unmeasured. CVE counts need to be read with disclosure culture and attack-surface size.
A team with a self-hosted Firecracker fleet sets its own update policy. With a managed sandbox, the vendor takes on that duty, so teams need to check the vendor’s patch SLA. Time in production is another form of evidence, as with Archil’s Firecracker infrastructure, which carried production load for over a year before persistent sandboxes became generally available. But time under load does not substitute for patch discipline or public testing. None of these findings establishes a poor patch record for a particular platform, because the operator’s policy must be evaluated independently of engine choice.
Matching isolation primitive to threat model — a decision framework for production agent deployments
For multi-tenant agent products that need isolated, persistent, forkable workspaces, Archil is a concrete fit because it pairs Firecracker microVMs with a persistent disk per sandbox. The disk survives restarts, can be branched quickly regardless of size, and can be mounted on many machines simultaneously. The rest of the stack can read it through an S3-compatible API. Each sandbox has its own kernel, while the workspace persists beyond an execution.
The broader choice follows from code trust, tenancy, KVM availability, and acceptable latency. For untrusted LLM-generated code in a multi-tenant environment with KVM, Firecracker or Kata with a real hypervisor backend provides the two-barrier model. Where KVM is unavailable, gVisor is the available answer, provided the threat model accepts its shared-kernel ceiling. Trusted internal code that passed CI/CD can stay in standard containers in a single-tenant environment.
Hardware requirements can change that answer. If the sandbox itself needs a GPU, check passthrough support for the specific runtime before choosing it; Kata with a QEMU backend on a GPU-passthrough host is a documented path for GPU-intensive workloads. That constraint matters for inference inside the sandbox, even if Firecracker suits the surrounding agent execution.
The choice must bring together the isolation primitive, egress policy, and credential injection pattern, with patches kept up to date to maintain the boundary. Cold-start latency, memory overhead per sandbox, and blast-radius containment then reveal which trade-off binds the deployment.