Agent sandboxes are a stack, not a category: the 11 platforms compared here sit on four different architectural layers

Asked:

“I'd love to see a proper comparison of Agent Sandboxes, their architectures and the evolution of the Agent Sandbox space. Below are some of the names I know https://modal.com/ https://github.com/liquidmetal-dev/flintlock https://github.com/e2b-dev https://www.daytona.io https://render.com/”

This landscape covers 11 products and platforms, built from 944 distinct official-domain pages scanned across them, current to 2 September 2026. Of the five names you listed, Modal, E2B and Daytona are agent-facing managed sandboxes; Flintlock is a self-hosted microVM lifecycle primitive; Render is an application PaaS adjacent to the space rather than a per-agent sandbox.

What the layer map cannot say alone

Three of the four Firecracker-based platforms now treat state as a first-class feature — Vercel Sandbox snapshots and forks filesystems by default, E2B pauses and resumes over gRPC, Sprites keeps a persistent two-tier filesystem — a clear shift away from throwaway execution. vercel.com

Flintlock is not a competitor to E2B or Modal: it gives you microVM lifecycle on containerd, and the operator must build the agent-facing control plane, tenancy, policy, images, secrets, observability and fleet operations on top. github.com

Render answers “deploy an app or service”, not “create a short-lived, policy-controlled environment per agent task” — its security surface (inbound IP rules) is inbound-facing, while agent sandboxes lead with egress control and credential mediation. render.com

Egress policy is becoming the defining agent-security control: E2B translates network policies into firewall updates, Runloop attaches NetworkPolicies to blueprints, devboxes and snapshot resumes, and Docker Sandboxes enforces approved endpoints at the proxy and mount level rather than as an advisory layer. docker.com

Cloudflare uniquely combines two paths in one SDK: millisecond V8 isolates for code snippets, delegating to full sandbox containers when the job needs a repo clone, dependency install or test run. blog.cloudflare.com

Architecture, product by product

The five names from your question come first. Boundary colour and state badge match the map above; blank cells in the source scan are left as unknown rather than guessed.

How the space evolved: five architectural eras

Era 1 · containers & PaaS

Shared-kernel containers and application platforms (the Render model): deploy a long-running service, trust the code you deploy. No per-task isolation semantics.

Era 2 · stronger isolation foundations

Lightweight isolation primitives arrive — gVisor's user-space kernel was announced and open-sourced under Apache 2.0 in May 2018 (grokipedia.com), and Firecracker-era microVMs made sub-second hardware-boundary boots practical.

Era 3 · programmable sandbox APIs

Cloud APIs turn isolation into a product: create, exec, destroy an environment per code-interpreter call or coding-agent task — the E2B, Modal and Daytona pattern. Vercel shipped its Sandbox SDK on Firecracker microVMs in June 2025 (artificialus.com).

Era 4 · state & policy

Snapshot, fork, pause/resume and persistent filesystems join policy-controlled networking and credential mediation — the strongest transition visible in the 2026 documentation set, from stateless execution toward rich state management.

Era 5 · convergence

One sandbox model across local, cloud and edge (Docker's laptop/Kubernetes/cloud parity, Cloudflare's isolate+container split), plus computer-use and long-running agent workspaces (Sprites' persistent computers).

Milestone dates come from a small, non-exhaustive secondary-source sample and are cited only where internally credible; they establish sequence, not first-mover claims. One sampled row misdating Firecracker's open-source release to 2026 was excluded as an article-date artefact.

Buyer's checklist: twelve questions before you pick

Threat model — is the code merely untested, or actively adversarial LLM output?
Kernel boundary — shared kernel, user-space kernel (gVisor), or hardware microVM? Architectural isolation is not the same as product-level security controls.
Startup & concurrency — cold-start latency and how many environments can run at once.
State semantics — ephemeral, snapshot/fork, pause/resume, or persistent filesystem.
Network policy — per-sandbox egress allowlists, or inbound rules only.
Secrets — credential mediation and injection, not env vars the agent can read.
Custom images — template/blueprint model and build pipeline.
GPUs — available inside the sandbox boundary or not.
Observability — logs, audit trails, session replay per environment.
Region & residency — placement control for data-residency needs.
Self-hosting — managed only, in-VPC, or fully self-operated (Flintlock).
Unit economics — per-second compute vs idle/paused pricing; verify current quotas directly, documentation moves fast.

Fit, not a winner: Modal when you want sandboxes fused with serverless compute behind a gVisor boundary; E2B for a focused managed sandbox API with templates; Daytona for agent workspaces with lifecycle automation; Flintlock when you are deliberately building and operating your own microVM platform; Render for long-running deployed services, not per-task untrusted execution. Beyond the named five: Vercel Sandbox and Fly Machines for Firecracker microVMs, Sprites for persistent hardware-isolated computers, Runloop for coding-agent devboxes, Docker Sandboxes for local-to-cloud policy parity, Cloudflare for isolate-plus-container reach at the edge.

The full comparison

Method: 11 products/platforms compared from 944 distinct official-domain pages scanned to 2 September 2026; one row per product with market position, isolation boundary, lifecycle/state, deployment model, agent/security feature, openness and pages scanned. Blank cells mean the scan did not establish the fact, not that the capability is absent. A 14-row secondary-source milestone sample informed the era narrative; one row misdating Firecracker was excluded. Long documentation quotes are truncated for space; verify current quotas and pricing on the linked pages.

This report was generated automatically by Keenable SELECT at a user's request, from publicly available web sources linked herein. Keenable does not review, verify, or endorse its contents and makes no representation as to accuracy, completeness, or timeliness; AI-based extraction may contain errors. Nothing in this report is investment, legal, financial, or other professional advice. All trademarks and referenced content remain the property of their respective owners; no affiliation or endorsement is implied. To report an error, rights concern, or request removal: legal@keenable.ai.