The Agent-Sandbox Market Crystallized Into Three Architectures. Here's the Bar for Building Your Own.

Eighty-eight percent of the Fortune 100 run AI-generated code inside E2B's microVMs — or so E2B's traction claim goes, repeated across every 2026 sandbox roundup. Modal just raised $355 million at a $4.65 billion valuation to sell GPU-backed sandboxes by the second. Daytona raised $24 million in February after pivoting from human developer environments to "a computer for every agent." Three vendors, three isolation architectures, and suddenly the question for a self-hosted platform isn't whether to offer agent sandboxes. It's which trust bar your sandboxes have to clear before any tenant hands them deploy authority.

This post delivers the comparison the market consolidation demands: what each of the three architectures actually isolates, the four-boundary bar "production-grade" really means, and which starting point is honest for a Cluster-API fleet on owned hardware. The short version, before the evidence: rent Firecracker's shape for ephemeral code runs, rent Modal's shape for GPU work, and build on a real virtualization boundary — microVM or Kata-style — because a shared-kernel container is the one architecture the enterprise buyers who set this bar will not accept.

Why these three are the reference points (and who else exists)​

The "big three" frame needs an honesty note up front: funding rounds are not market share, and valuations are not votes. E2B's $21 million Series A (July 2025), Modal's $355 million Series C at $4.65 billion (May 2026, led by Redpoint and General Catalyst, per Reuters via Pulse2), and Daytona's $24 million Series A (February 2026, led by FirstMark) are investor signals, not a census. What makes the trio the reference set is different: each one is the market leader of a distinct isolation archetype, and every other contender maps onto one of the three.

The wider field is real but archetype-consistent. Vercel Sandbox and Fly.io Sprites are Firecracker microVMs — E2B's archetype with different product surfaces (Vercel caps sessions at 45 minutes; Fly pairs microVMs with private-by-default WireGuard networking). AWS Bedrock AgentCore hands each session a dedicated microVM, terminated and memory-sanitized at session end, up to 8 hours — again the microVM archetype, assembled from hyperscaler primitives. Runloop, Beam, Morph, and Cloudflare's entry orbit the same three shapes. Nobody serious is selling a fourth isolation idea. That convergence is the story: the market didn't pick three vendors, it picked three answers to "what sits between untrusted model output and your kernel," and the vendors are just the clearest instance of each.

The verdict, early: conditional, then a default​

No single architecture wins unconditionally — anyone selling you one pick for all workloads is cherry-picking the workload. The honest verdict is conditional on what the sandbox runs:

• Ephemeral code execution (run this snippet, lint this diff, browse this page): Firecracker wins. A real guest kernel per sandbox, ~150 ms boots, ~5 MB of VMM overhead per microVM, and per-second billing that makes one-sandbox-per-agent-step architecturally sane. E2B's 200M-plus sandboxes started are the existence proof that this shape scales.
• GPU-adjacent agent work (local inference, embedding batches, GPU-dependent tests): Modal's gVisor-plus-GPU shape wins. E2B exits this comparison entirely — its sandboxes are CPU-only at every tier — and Daytona's GPU story is younger. Modal bet that agents would need accelerators inside the sandbox, and the $4.65 billion valuation says the market agrees.
• Long-lived, stateful agent computers (persistent dev sandboxes, multi-hour sessions): Daytona's shape wins. Stateful snapshots, pause/resume at any point, and sub-90 ms creation optimized for computers agents keep, not microVMs they burn. E2B's 24-hour session cap and Vercel's 45-minute cap are the tell: the ephemeral archetype is designed to disappear.

And the default starting point for a self-hosted fleet on owned hardware: the microVM archetype — Firecracker directly, or Kata Containers where Kubernetes-native packaging matters. The reason is not performance, it is procurement: the enterprise buyers who wrote the 88%-of-Fortune-100 headline run security reviews, and a guest kernel is the boundary those reviews already understand. gVisor is a respectable second boundary; a shared-kernel container is the shape the bar was written to exclude. More on that below — including the uncomfortable part, which is that compute isolation is only one of four boundaries.

The bar is four boundaries, not one​

Qovery's September 2026 comparison of seven isolation platforms proposes the rubric this whole market is converging on, and it is worth adopting verbatim: secure agent isolation means four independent boundaries enforced simultaneously, and three out of four is not isolation.

1. Compute: a Firecracker microVM or gVisor passes; a shared container fails, because it shares the host kernel. Kubernetes' own multi-tenancy guidance agrees — namespaces are control-plane segmentation, and tenants that don't trust each other need sandboxed containers.
2. Network: default-deny egress with FQDN allowlists, no route to the cloud metadata endpoint, no lateral reach to sibling sandboxes.
3. Tenancy: one namespace, VPC, or account per agent or environment, so blast radius stops at the boundary.
4. Identity: short-lived, OIDC-federated or projected tokens scoped to a single run. A long-lived key sitting in the sandbox is a fail.

Here's the part that reorders every vendor comparison: the dominant failure is not a container escape. Qovery's piece names it plainly — an over-scoped credential or an open egress path lets a prompt-injected agent exfiltrate data from a perfectly sandboxed process. The agent is untrusted code, a credential holder, and an outbound network client in one loop, and any content it reads can hijack its control flow. GitGuardian's State of Secrets Sprawl 2025 found public repos using AI coding assistants leaking secrets at a 6.4% rate. A sandbox that nails boundary 1 and waves through boundaries 2 and 4 is a fast, cheap, well-isolated exfiltration tool.

Score the trio against the rubric and the picture gets honest fast. E2B ships boundary 1 superbly and gives you primitives for the rest — but per-sandbox egress policy and per-run credential scoping are your architecture, not theirs. Modal's deny-by-default sandbox posture is the strongest boundary-2 story of the three, paired with the weakest compute boundary. Daytona's statefulness is a boundary-3 convenience (a computer per agent, snapshotted) that does nothing for boundary 4 by itself. No vendor sells all four as a default. Whatever the "just use the vendor" pitch promises, the enterprise security reviews behind the 88% number evaluated each buyer's whole deployment — egress policy, credential scoping, tenancy model included — not the vendor's marketing page.

Architecture-by-architecture honesty check​

Firecracker: the strongest boundary with the hardest floor. A microVM per sandbox means the guest kernel is the trust boundary — a container escape buys the attacker a Linux guest with no host privileges, not the host. Boots land in the 90-200 ms band across every vendor on the primitive because the physics are shared, not proprietary. The costs are physical too: Firecracker needs KVM, which means bare metal or nested virtualization. E2B's own fleet runs as L2 guests on GCP VMs — nested virt all the way down — which is fine at their scale and a capacity-planning fact at yours. And the archetype's product gap is GPUs: PCI passthrough into microVMs at multi-tenant density is still not a product anyone ships casually, which is exactly why E2B is CPU-only and exactly why Modal's bet has room.

gVisor: the pragmatic middle that trades kernel for compatibility. gVisor interposes a user-space kernel (Sentry) between the container and the host, filtering every syscall — a much smaller attack surface than 400-plus raw syscalls, without the cost of a guest kernel per sandbox. Modal's security posture ("virtualized using gVisor," Sandboxes API "built to run untrusted code") pairs it with deny-by-default networking and full GPU access, which is the combination that makes Modal the GPU-agent default. The honest caveat: a user-space kernel is still the host kernel underneath, and the security track record — while good — is not "separate kernel" good. Enterprises that accept gVisor do so with the rest of the four boundaries tightened to compensate. If your threat model is "tenant code must never see another tenant's memory," gVisor is a mitigation; a microVM is the boundary.

Hardened OCI containers: the fastest shape and the weakest claim. Sub-90 ms creation, full Docker compatibility, stateful pause/resume — Daytona's archetype wins every developer-experience benchmark because it is barely more than a container with good lifecycle tooling. The Kata/Sysbox options harden it (Kata wraps each pod in a lightweight VM, which quietly promotes you to the microVM archetype — notice how the market keeps collapsing back to three shapes, then to two). But plain Docker-backed sandboxes share the host kernel, which fails boundary 1 outright under the rubric above. Daytona's other catch is licensing, not technology: self-hosting Daytona is AGPL-3.0, which is a non-starter for platforms that would embed or offer it commercially without legal review. E2B's Apache-2.0 infra repo is the friendlier license attached to the harder ops story (Nomad, Consul, Terraform, KVM hosts you operate).

Reproducing the bar on machines you own​

So what does clearing this bar concretely take on a Cluster-API fleet on Hetzner-class hardware? The build list, with the hard parts labeled:

• The compute boundary: KVM hosts running Kata or Firecracker. Hetzner dedicated boxes give you real /dev/kvm — no nested-virt tax, unlike cloud VMs where E2B-style self-hosting needs nested virtualization (GCP supported, AWS beta, your fleet on your own). Kata Containers is the honest Kubernetes-native default: each sandbox pod gets a lightweight VM with minimal manifest changes, and it runs inside your existing CAPI-provisioned node pools. Firecracker-Containerd is the purist path with more operational surface. Either way, budget for snapshot templates and warm pools — sub-second starts don't happen without them.
• The network boundary: default-deny NetworkPolicies per sandbox namespace, plus egress allowlisting. This is the boundary most self-hosted builds skip and the one that matters most after compute. A per-agent namespace with a default-deny policy and an FQDN-aware egress proxy (not just IP blocks — agents resolve new domains constantly) reproduces Modal's deny-by-default posture on your own CNI.
• The tenancy boundary: one namespace per agent run, reaped aggressively. Cheap on Kubernetes, and the reaping discipline doubles as cost control: idle sandboxes are the same meter-trap self-hosted or rented.
• The identity boundary: projected service-account tokens with short TTLs, no static keys in the sandbox. OIDC federation to whatever the agent is allowed to touch (your deploy API, a scoped container registry), with the token's lifetime bound to the run. This is pure configuration — and the boundary most teams fail by leaving a CI-style long-lived token mounted "temporarily."

The known hard parts, stated without flinching: GPU node pooling for agent sandboxes is still genuinely hard (DRA-based scheduling matured through Kubernetes 1.36, but fractional-GPU bin-packing across tenants is still young; Modal earned its valuation here). Snapshot and warm-pool lifecycle at scale is the undifferentiated heavy lifting E2B already did for you. And the four-boundary rubric needs continuous verification — a NetworkPolicy someone loosened during an incident is a silent boundary-2 fail, so the bar needs a conformance check in CI, not just a design doc.

The pattern worth naming​

Per-second billing plus sub-second starts made the sandbox disposable, and disposable sandboxes made agent architectures possible — that pairing, not any single vendor, was the market's real invention. The crystallization into three archetypes just tells you which disposability physics survived contact with enterprise security reviews: a kernel per sandbox for untrusted code, syscall interception where GPUs matter more than kernels, and fast containers where the trust boundary lives elsewhere in the stack.

The build-vs-rent rule follows the workload, not the brand. Prototyping agents and spiky evals: rent — E2B's free tier and Modal's free compute fund the experiment. Steady sandbox-hours on hardware you already rent: build the microVM archetype on your own KVM hosts, where the marginal sandbox costs near zero and the GPUs E2B can't sell you sit in the next rack. Regulated data or deploy authority for tenants: build all four boundaries and verify them in CI, because no vendor's default ships the complete rubric. Rent the primitive to learn what your agents need; own the fleet once the hours are steady enough to forecast — and never mistake a fast sandbox for an isolated one.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agent sandboxes as first-class infrastructure, not a rented afterthought. Star the repo on GitHub or deploy your first app today.