Open Source AI Sandbox Runtimes Overview
Security boundaries and startup latency determine which sandbox fits your agent workload.
Open-source AI sandbox runtimes range from isolation primitives to orchestration controllers and full runtime platforms. To choose among them, teams must match the security boundary to the code, then check whether startup latency, state preservation, and compliance fit the workload.
Why running AI-generated code is a different problem from running application code
Traditional application code has an instruction set determined at compile or deploy time that teams can audit. Autonomous agents instead write and run new code from natural language inputs at runtime. The execution path is no longer fixed. An agent that writes Python scripts, installs packages, and manipulates file descriptors exposes risks that reviewing the application alone cannot cover.
A standard container separates processes but shares the host kernel, so a kernel vulnerability exploited inside one container can compromise the host and other containers. An agent execution sandbox therefore restricts filesystem access, network egress, and host interaction independently of the agent’s decisions. That boundary must hold even when generated code misbehaves. Browser sandboxes, code execution sandboxes, and full development environment sandboxes address different parts of this problem.
How the open-source sandbox landscape is structured in three layers
The first distinction is between providing a boundary and operating it. Layer 1 primitives, including Firecracker, gVisor, libkrun, and Kata Containers, supply isolation itself. Teams that choose this layer run their own fleet and scheduler. It answers the question of how execution is separated from the host, while leaving control of deployment and operation with the team.
Layer 2 adds orchestration without becoming a full runtime platform. Google Agent Sandbox places scheduling, warm pools, and a declarative API above an isolation primitive, principally for teams already operating Kubernetes. Layer 3 moves further up the stack. Platforms such as Northflank, Blaxel, Fly.io Machines, Vercel Sandbox, and Cloudflare Workers expose execution through APIs or SDKs and handle more of the lifecycle and networking. These layers describe architectural roles with differing open-source distribution models, and moving upward exchanges customization for less operational work.
The isolation spectrum and what each primitive protects against
Docker/OCI containers use Linux namespaces and cgroups to separate processes and resources, but the host kernel remains shared. They are fast and lightweight, but because they share that surface, they cannot be the only boundary for LLM-generated or user-supplied code. Process separation is not kernel separation.
A user-space kernel such as gVisor intercepts and re-implements syscalls rather than letting sandboxed software call the host kernel directly. This reduces exposure without requiring a full virtual machine. Compatibility is the corresponding constraint. Some Linux software depends on syscalls that are not fully emulated, so a stronger boundary can change which programs run successfully.
MicroVMs instead give each workload its own kernel through KVM hardware virtualization. A compromised guest kernel is separated from the host and other guests by that VM boundary. Confidential computing extends protection to a different threat. AMD SEV-SNP and Intel TDX encrypt memory so that even the host OS and hypervisor cannot read sandbox data. V8 isolates follow a separate track, isolating the JavaScript runtime rather than hardware or a kernel, with microsecond startup but tighter language constraints.
Firecracker, gVisor, Kata Containers, and libkrun as standalone primitives
AWS developed Firecracker for services including Lambda and Fargate. Its KVM-backed microVMs offer full Linux compatibility, startup of roughly 125ms, and roughly 5MB of memory overhead per VM. Google’s gVisor starts in roughly 100ms, has medium overhead, and can run on any Linux host without KVM. The hardware requirement separates these options immediately. Their compatibility differs too, because gVisor’s syscall emulation does not cover all Linux software.
Kata Containers wraps containers in lightweight VMs through an OCI-compatible runtime, connecting a familiar container workflow to hardware isolation. Libkrun takes an embedding-oriented approach. It is a library-based KVM virtualizer that provides container-speed startup without a full hypervisor stack, and microsandbox uses it as its isolation primitive. These designs give teams different ways to integrate a VM boundary into existing infrastructure.
Nsjail provides a process-level alternative using filtered syscalls. It starts in roughly 50ms, has very low overhead, and does not require KVM. Its isolation serves code execution and long-running processes where the workload does not require a full VM, leaving trust level central to its suitability.
Google Agent Sandbox as the Layer 2 middle path for Kubernetes teams
Google Agent Sandbox launched at KubeCon NA 2025 as a formal subproject of Kubernetes SIG Apps, hosted under kubernetes-sigs/agent-sandbox. The open-source controller provides a declarative API for isolated, stateful sandbox pods on a team’s own cluster. Kubernetes remains the operating foundation. The controller supports gVisor and Kata Containers and adds warm pools to reduce cold-start latency.
Teams can take this path without having to build orchestration around a raw primitive or move to a separate managed runtime platform. Compatibility still depends on gVisor or Kata, and the team still needs Kubernetes operational maturity. For teams outside that stack, adopting a cluster is a substantial prerequisite.
Platform-layer options and what each runtime adds
Northflank is a full-stack production infrastructure platform. It puts agents, APIs, background workers, databases, cron jobs, and sandbox execution in one control plane, with Kata Containers, Firecracker, and gVisor selectable by workload. Docker-native environments can be ephemeral or persistent, have no forced time limits, and support on-demand GPUs and customer-managed compute through BYOC. Northflank has been in production since 2021 across startups, public companies, and government deployments.
Blaxel builds around perpetual sandboxes that can remain in standby indefinitely without compute charges during standby. Its hardware-isolated microVM model supports resumption with execution state intact. The surrounding stack goes beyond code execution. Agents Hosting, Batch Jobs, MCP Servers Hosting, and a Model Gateway support hosting and LLM routing, while co-located agent hosting removes the network round trip between agent and sandbox. Blaxel is also a first-class sandbox provider in the OpenAI Agents SDK.
Fly.io Machines offers KVM hardware-isolated VMs through a REST API and accepts any OCI-compliant container image across multiple global regions. Its API supports per-user environments, ephemeral code execution, and persistent instances for stateful agents. It is a general-purpose runtime. Vercel Sandbox instead exposes Firecracker-based Linux environments through JavaScript and Python SDKs or a CLI, with command execution, files, ports, and network controls. Its integration makes it relevant to frontend-adjacent AI workloads already deployed on Vercel.
Cloudflare Workers provides native execution for scripting languages, including TypeScript, through V8 isolates across a global network. Cloudflare Sandbox SDK serves a different role. It lets Workers applications execute untrusted code in isolated Linux environments, with commands, files, background processes, streamed output, and exposed services. The Workers isolate has its own limits on language and state, which are separate from those of the SDK’s Linux execution environment. For self-hosted deployments, microsandbox offers an Apache 2.0 runtime built on libkrun, retaining control over data and deployment while leaving fleet operation to the team.
Statefulness and long-running execution and what runtimes preserve
A strongly isolated environment may disappear after every invocation, which is unsuitable when a PR review agent needs an existing repository or a data analysis agent needs datasets across tool calls. Cold-starting and rebuilding the environment each time can undermine the feature even when the security boundary is sound.
Cloudflare Workers is stateless by design, while Vercel preserves state within a session whose duration is capped. Vercel’s Hobby sessions have a shorter fixed limit, while Pro and Enterprise sessions can run for up to 24 hours. Snapshot persistence offers another model. Depending on the runtime, what survives can include filesystem contents, memory, and running processes. Blaxel resumes in under 25ms with all three intact, while Northflank supports indefinitely running environments and resumption of long-running work.
LangGraph saves graph state at each super-step to keep that state at the framework layer. Its SqliteSaver serves development and PostgresSaver serves production, allowing workflows to resume without repeating completed steps. A checkpoint is not a preserved execution environment. A save point alone also cannot ensure that work will finish or recover automatically from failure without developers coordinating it. Framework checkpoints and runtime persistence are complementary because workflow progress and the state of a running process are different things.
Computer-use agents and open-source virtual desktop runtimes
Computer-use agents need reproducible desktops in addition to isolation and state preservation. ByteDance’s UI-TARS Desktop addresses GUI grounding by treating interface elements as first-class concepts rather than asking a generalist vision-language model to infer pixel coordinates from screenshots. Bytebot addresses the desktop environment itself. It is a self-hosted agent that follows natural language commands within a containerized Linux desktop, so deployment requires evaluating the environment’s isolation boundary.
Simular Research’s Agent-S3 uses Behavior Best-of-N to select among multiple agent rollouts and reports strong performance on OSWorld and WindowsAgentArena. Exploring several rollouts raises a related runtime question. Can an agent branch a live desktop without rebuilding it? The TClone paper, arXiv:2605.17320, examines low-latency forking of live GUI environments, analogous to snapshot-based branching in code sandboxes. It is a research-stage signal for production desktop infrastructure.
Enterprise compliance requirements and how platforms address them
After selecting an isolation model, regulated teams must apply a compliance filter. Requirements can include SOC 2 Type 2, HIPAA, GDPR, RBAC, secrets management, and BYOC deployment. A VM boundary does not supply these controls. Teams that self-host raw primitives must add the audit trail, access controls, and data-handling procedures needed for compliance themselves because raw primitives do not come with them.
BYOC becomes decisive when data must remain in a customer-controlled cloud or VPC. A managed-only service cannot keep data in that location just by offering stronger isolation. Northflank supports self-service BYOC across AWS, GCP, Azure, Oracle, CoreWeave, on-premises, and bare-metal, and includes SOC 2 Type 2 and HIPAA compliance. Blaxel lists SOC 2 Type II, ISO 27001, and HIPAA, with HIPAA available through a Business Associate Agreement.
Microsoft published the open-source Agent Governance Toolkit in April 2026, illustrating that runtime governance can be layered above an execution boundary. Credentials need their own protection as well. Code may need API access without exposing secrets to the agent’s context or through its environment. Credential injection proxies, including iron-proxy and Infisical Agent Vault, handle this at the network layer regardless of which primitive the team chooses.
How to match sandbox architecture to workload type
Trust, tolerable startup latency, persistence, and compliance need to be evaluated together. Internally written code passing CI/CD can defensibly use shared-kernel containers. Generated code changes the minimum acceptable boundary. For LLM-generated code solving bounded tasks, gVisor or microVM isolation provides the required step up, while arbitrary user-uploaded binaries or autonomous agent-generated code call for microVMs or stricter isolation under a hostile-code assumption.
Latency then narrows the options within that trust model. V8 isolates offer microsecond startup for JavaScript and TypeScript workloads that can remain stateless. Short tasks can use ephemeral execution or fit within Vercel’s session limits. Long-running workflows need a different lifecycle contract. They require environments that persist and resume without rebuilding, with explicit attention to whether files alone, memory, or running processes must survive.
The operating model then sets who has to keep that contract. Teams seeking maximum control can use raw primitives or self-hosted microsandbox and implement compliance independently, while Kubernetes-native teams can use Agent Sandbox’s orchestration layer. Full platforms reduce that operational burden. A shared control plane is useful when agents also depend on persistent services and databases, provided the deployment passes the compliance filter. The decisive choice is therefore not the primitive with the strongest headline, but the architecture whose boundary, lifecycle, and operating responsibilities fit the work.
