Buy, build, or borrow: the sandbox verdict
Three chapters built the case: agents need microVM-grade isolation (Chapter 28), a real sandbox service is five components with one exotic piece (Chapter 29), and isolation is only the first of five controls (Chapter 30). Now the decision every team actually faces: run the agent's code in a managed sandbox, build the Firecracker service, or borrow a hardened container runtime. This chapter scores the three on the axes that decide it and gives a default with the honesty the earlier chapters earned.
The three options, named
- Buy: a managed sandbox. AgentCore Code Interpreter and Browser (Chapter 19), or an independent sandbox provider (the E2B, Modal, Daytona tier), or Anthropic's server-side code execution. Someone else runs the microVMs; you call an API.
- Build: the Chapter 29 service. Firecracker on your own metal, your rootfs, your egress policy, your on-call.
- Borrow: a hardened container runtime. Ordinary containers are the wrong wall for hostile code (Chapter 28), but gVisor (a user-space kernel that intercepts the container's syscalls, shrinking the shared-kernel surface) and Kata Containers (which quietly back each "container" with a lightweight VM, often Firecracker itself) are the real middle. Borrowing means adopting one of these rather than building the VM layer yourself.
The axes that decide it
| Axis | Buy | Build | Borrow (gVisor / Kata) |
|---|---|---|---|
| Isolation strength | MicroVM, maintained by specialists | MicroVM, maintained by you | gVisor: strong-ish (still one host kernel behind the interceptor); Kata: microVM, so VM-grade |
| Start latency | Good, not yours to tune | Snapshot-restore, tunable to best-in-class | Container-ish (gVisor) to microVM (Kata) |
| Egress control | Whatever the product exposes | Arbitrary: your proxy, your allowlist, your DLP | Yours (it runs in your cluster) |
| Custom images / statefulness | The product's languages and session model | Anything | Anything (your images) |
| Price at low volume | Effectively free (per-second, tiny) | Wasteful (metal sits idle) | Cluster you may already run |
| Price at fleet scale | A real per-second premium | Cheap once saturated | Between the two |
| Operational load | Near zero | A whole service | Moderate (a runtime, not a fleet) |
| Time to first sandbox | Minutes | Weeks | Days |
No column wins every row, which is why this is a decision and not a recommendation with caveats. But the rows cluster into a clear default and clear exceptions.
The default: buy first
For almost every team starting out, buy. The reasoning is the same shape as the memory and runtime verdicts, and it is strongest here. A managed microVM sandbox on day one gives you the correct isolation boundary (the one most teams would otherwise get wrong by reaching for plain containers), at a price that is a rounding error until real volume, with an operational load of essentially zero. Against that, building buys you tuning and control you almost certainly do not need yet, at the cost of a metal fleet and an on-call rotation. The switching cost later is low because the interface is narrow: "run this code, return the result" and "drive this page, return observations" are a handful of calls, so a future migration to a built or borrowed backend is days of adapter work, not a rewrite. Buy, and revisit with the token ledger as evidence.
When to build, and when to borrow
The exceptions are specific, and each maps to a row above:
Build the Firecracker service when a hard requirement forces it:
- Egress policy the product cannot express. If hostile input demands an allowlist the managed sandbox does not support, and Chapter 30 argued egress is the control that matters most, this alone can force the build.
- Exotic runtimes or persistent state the product's session model does not offer.
- Regulatory or residency placement that requires the microVMs on infrastructure you control.
- Fleet-scale economics where the per-second premium, multiplied by a saturated overnight fleet, exceeds the cost of metal you keep busy, the crossover the lab catalog's arithmetic finds for your workload.
Borrow (gVisor or Kata) when you already operate a Kubernetes fleet and want stronger-than-container isolation without standing up a separate metal service: Kata gives you a microVM boundary inside your existing cluster, gVisor a cheaper-but-weaker interceptor, and both are a runtime you adopt rather than infrastructure you build. This is the pragmatic path for a platform team that has containers everywhere and one workload (the agent's code) that needs a better wall.
The one non-negotiable
Whatever the column, one rule survives from Chapter 28 and admits no exception: plain containers are not an acceptable sandbox for hostile code. Not "suboptimal", not "fine with care" for arbitrary attacker-influenced code sharing your host kernel. If the honest answer to "where does the agent's code run" is "a normal container next to our other workloads," the design has failed gate 2 of the production bar, and buy, build, or borrow all exist to keep you from that sentence.
Don't be confused: the sandbox is a plane, not a vendor. The reference architecture drew the sandbox as its own plane precisely so this decision stays swappable. The agent calls "execute code"; whether that resolves to a managed API, your Firecracker service, or a Kata pod is a configuration behind a narrow interface. Teams that wire a specific sandbox vendor deep into their agent logic lose that swappability and turn a days- long migration into a rewrite. Keep the plane; swap the implementation.
Part 5 is complete: the isolation substrate opened up, a service built around it, the controls that isolation alone does not provide, and the buy-build-borrow decision scored. The agent's most dangerous capability, running untrusted code, now has an architecture rather than a hope.
👉 Next, per the map: the remaining planes that turn this machinery into a platform, memory and state (Part 7), trust (Part 8), and operations (Part 9), on the road to the capstones.