Agent Sandboxes: The Cloud Compute Paradigm Shift

Part 1: The Paradigm Shift — From Human Cloud to Agent Cloud

The Arc of Cloud Computing

Each step removed a layer of human involvement. But Lambda MicroVMs isn't just the next step — it's a change in who the primary consumer of compute is.

Why Agents Need Different Infrastructure

Traditional serverless (Lambda) was built for human-designed workflows: HTTP request comes in → function runs → response goes out. Stateless by design. 15-minute max. No persistent filesystem.

AI agents break every assumption:

This isn't a feature gap — it's a category difference. Lambda is compute-as-a-function. What agents need is compute-as-a-computer.

The Economic Shift: Human-Initiated → Agent-Initiated Compute

Today, most cloud compute is triggered by human actions: page loads, API calls from apps humans use, scheduled jobs humans configured. In 2-3 years, the majority of compute consumption will likely be agent-initiated:

• Coding agents running test suites across hundreds of sandboxes

• Research agents spawning isolated environments to validate findings

• DevOps agents provisioning and testing infrastructure changes

• QA agents running regression suites on every commit

The infrastructure layer is adapting:

• From stateless → stateful (Lambda → Lambda MicroVMs)

• From event-driven → session-based (request-response → long-lived interactive)

• From developer-deployed → agent-controlled (git push → API-controlled lifecycle)

• From always-running or instant-death → suspend/resume (new billing model)

Why Agent Sandboxing Is the Critical Missing Layer

Every major agent framework eventually needs to execute arbitrary code. The landscape today:

Agents without human-in-the-loop need a machine-level security boundary. Real incidents:

• Agent "cleaning up test data" ran DELETE FROM users WHERE created_at < '2024-01-01' — on production

• Code-gen agent executed pip install malicious-package in the host process with network access

• Agent in a retry loop called a paid API 10,000 times — $2,400 in 3 minutes

The sandbox isn't a nice-to-have. It's the equivalent of process isolation in operating systems — without it, one bad actor compromises everything.

The Opportunity: Cloud-for-Agents as a Category

Just as Vercel owns "cloud-for-frontend" and Supabase owns "cloud-for-backend," the "cloud-for-agents" category is forming. The stack:

The sandbox layer is where the developer experience lives: clean SDKs, multi-tenant auth, resource limits, audit trails, cost controls. The cloud primitives (Firecracker/MicroVMs) are now commoditized — both E2B (open source) and AWS (managed service) offer them. The value is in the platform on top.

Part 2: How E2B Works (Architecture Deep Dive)

The Problem E2B Solved

AI agents need to run arbitrary code. Docker containers share a kernel (escape vectors exist). Full VMs are slow to boot. WASM is too limited. E2B found the sweet spot: Firecracker microVMs that boot in ~150ms with VM-level isolation.

The key insight: don't boot a VM — resume a pre-booted snapshot.

E2B System Architecture

The Three Tricks Behind Sub-Second Launch

E2B doesn't cold-boot VMs. It resumes pre-booted snapshots using three techniques that together achieve ~150ms start time:

1. UFFD (Userfaultfd) — Lazy Memory Loading

The critical innovation. Instead of loading an entire memory snapshot before the VM can execute:

A 512MB sandbox may only touch 5-20 memory pages in the first 100ms of execution. Why load 131,072 pages when you only need 20?

This is the same principle as operating system demand paging, but applied at the hypervisor level for VM snapshots.

2. NBD Rootfs Overlay — Copy-on-Write Filesystem

No filesystem is copied when a sandbox is created:

100 sandboxes from the same template share one rootfs on disk. Each gets a tiny overlay that only stores their writes. Create time: near-zero (just allocate the overlay file).

3. Access-Pattern Prefetching

During template build, E2B records which memory pages are accessed and in what order. On resume, a background goroutine prefetches those pages before demand faults hit:

The prefetcher works probabilistically — it loads pages the template historically needs, so by the time user code runs, most hot pages are already in memory.

E2B Self-Hosting Requirements

To run E2B yourself:

Control plane:    3x t3.medium       (Nomad + Consul scheduler)
API nodes:        1x t3.xlarge       (API + proxy + ingress + OTEL)
Client nodes:     Nx m8i.4xlarge     (Firecracker host, nested virt required)
Build nodes:      Nx m8i.2xlarge     (template builder)
ClickHouse:       1x t3.xlarge       (analytics)

Plus: PostgreSQL, Redis, S3, Cloudflare, Terraform 1.7.5, Packer, Go, Docker.

Minimum cost: ~$1,150/month before a single sandbox runs.

The operational complexity is significant: you're running a distributed VM orchestration platform with custom kernel page-fault handling, block device management, network pool allocation, and multi-zone scheduling.

Part 3: AWS Lambda MicroVMs — Firecracker-as-a-Service

What Changed on June 22, 2026

AWS launched Lambda MicroVMs — effectively productizing the same Firecracker technology that powers both Lambda and E2B, but as a managed API:

What AWS Handles For You

All the complexity E2B built from scratch — UFFD, NBD, network pools, scheduling, cgroup management — is abstracted behind an API:

# Create a VM image from a Dockerfile
aws lambda-microvms create-microvm-image \
  --image-name python-sandbox \
  --dockerfile-path ./Dockerfile \
  --code-s3-uri s3://bucket/code.zip

# Run a MicroVM
aws lambda-microvms run-microvm \
  --image-name python-sandbox \
  --cpu 2 --memory 4096 \
  --execution-role-arn arn:aws:iam::123:role/SandboxRole

# Suspend (snapshot memory + disk → S3)
aws lambda-microvms suspend-microvm --microvm-id mvm-abc123

# Resume (from snapshot, ~1-2s)
aws lambda-microvms resume-microvm --microvm-id mvm-abc123

Pricing Breakdown

Key insight: $0 when suspended. You pay only for snapshot storage (~$0.01/GB/month). E2B's hosted service charges while paused. E2B self-hosted charges for the fleet whether sandboxes are running or not.

What Lambda MicroVMs Doesn't Give You

It's a compute primitive, not a sandbox platform. You still need:

1. SDK — developer-facing API (create, run commands, read files)

2. Control plane — sandbox lifecycle management, user auth, multi-tenancy

3. Daemon inside the VM — handles commands, filesystem ops, PTY

4. Template system — build and manage VM images

5. Dashboard — visibility into running sandboxes

This is what clouda-sandbox provides.

Part 4: clouda-sandbox — An Open-Source Experiment (Work in Progress)

Status: Early development. Not production-ready. I'm building this to learn the space and contribute an open-source option. Star/watch the repo if interested — contributions welcome once the foundation stabilizes.

Design Principles

1. Zero idle cost — suspended sandboxes cost only snapshot storage

2. Zero ops — fully serverless control plane (no fleet to manage)

3. Clean SDK — intuitive API for sandbox lifecycle, commands, and files

4. Cloud-native — IAM, VPC, CloudWatch, no extra infrastructure

5. Multi-tenant ready — team-scoped resources from day one

Architecture

What's Different From E2B

SDK Usage

from clouda_sandbox import Sandbox, Config

config = Config(api_key="sk_user_abc123")

# Create — spins up a MicroVM
sandbox = await Sandbox.create(template="python-data", config=config)

# Run commands
result = await sandbox.commands.run("pip install torch && python train.py")
print(result.stdout)

# File operations
await sandbox.files.write("/app/config.yaml", "model: gpt-4")
content = await sandbox.files.read("/app/output.json")

# Suspend — snapshots memory + disk, stops billing
await sandbox.suspend()

# Resume later — restores full state
sandbox = await Sandbox.resume(sandbox.id, config=config)

# Kill — terminates and cleans up
await sandbox.kill()

Control Plane Flow

Part 5: Tradeoffs and When to Use What

Decision Matrix

Current Limitations of clouda-sandbox

1. ARM64 only — Lambda MicroVMs run on Graviton. Most Python/Node code works unchanged. Some native binaries need ARM builds.

2. 8-hour max runtime — Lambda MicroVMs cap at 8 hours. E2B Pro allows 24 hours. For long-running agents, you need periodic suspend/resume.

3. No custom kernel — E2B lets you bring your own vmlinux.bin. Lambda MicroVMs use AWS's kernel.

Part 6: Open-Source Plan

All components (SDK, infrastructure, daemon, dashboard) will be open-sourced under the Apache 2.0 license once the core lifecycle works end-to-end reliably—the same open-source license as the E2B project. It's not published yet—building in the open.

The goal: help people explore agent computing with zero cost to start. Lambda MicroVMs' pay-only-when-running model means you can spin up sandboxes, experiment with agent workflows, and pay nothing when idle. No fleet to provision, no minimum spend. Just deploy the CDK stack and start building.

Conclusion: What I Learned

The infrastructure story here is surprisingly clean:

• Firecracker (2018) proved VM-level isolation can be fast enough for interactive workloads

• E2B (2023) proved you can build a developer-friendly sandbox platform on Firecracker

• Lambda MicroVMs (June 2026) commoditized the underlying compute — zero ops, zero idle cost

The hard VM orchestration problem (UFFD, NBD, scheduling, network pools) is now either open-source (E2B) or managed (AWS). What's left is the platform layer: SDKs, multi-tenancy, auth, cost controls.

That's what clouda-sandbox is exploring — can you build a useful sandbox platform purely on managed serverless primitives? No fleet, no ops, zero idle cost. I don't know yet if the tradeoffs (ARM64 only, 8-hour max, no custom kernel) are acceptable for real agent workloads. Building it to find out.

If you're working on agent infrastructure and have opinions on what matters most in a sandbox API, I'd love to hear. The repo will be public once the foundation is stable enough to be useful.