For two years, the answer to "how do I let my agent run the code it wrote?" was a shopping trip. You picked a third party — E2B, Modal, Daytona — signed up, and wired its sandbox into your loop. In 2026 that changed. Sandboxing stopped being an add-on you buy and became a primitive the platform ships.

If you read one line: every layer of the stack — the model labs' own agent SDKs, the hyperscaler, and the edge — now offers native code sandboxing, so the cheapest safe way to run your agent's code is increasingly whatever platform you're already standing on. The specialists aren't dead, but the default is now safe.

Four layers, one capability#

Here's what actually shipped, by layer:

The model labs, inside their own SDKs. The OpenAI Agents SDK added Sandbox Agents — agents preconfigured to work against a container so they can inspect files, run commands, and apply patches over long horizons, with a model-native harness and credential isolation (Help Net Security). Anthropic shipped a sandbox runtime for the Claude Agent SDK that uses OS primitives — bubblewrap on Linux, sandbox-exec/seatbelt on macOS — plus proxy-based network filtering, to contain bash, local MCP servers, and arbitrary processes. When the SDK you build on sandboxes by default, the "should I bother" question answers itself.

The hyperscaler. Google put Cloud Run sandboxes into public preview: a locked-down, millisecond-start microVM that runs inside a Cloud Run instance you already pay for, using its allocated CPU and memory — so there's no separate premium. Google's ADK is wiring this in as a Cloud Run sandbox code executor. We covered that market entry in full in Google Cloud Run Sandboxes Hit Preview; the point here is that it's one signal among four.

The edge. Cloudflare moved its Sandbox SDK to general availability, running untrusted code in isolated environments built on Containers, billed per active CPU rather than wall-clock time — a fit if your agent already lives on Workers.

The incumbents that started it. E2B's Firecracker microVMs and Modal's gVisor sandboxes are the reason any of this exists. They defined the category; now the platforms are absorbing the easy 80%.

What it means for founders#

The wrong read is "the specialists are finished." They aren't. Native sandboxing is convenient precisely when you're already on that platform — the moment you want portability across clouds and SDKs, or a stateful code interpreter, or the fastest cold starts, E2B and Modal are still the answer. What's been commoditized is the low end: the basic "give me a throwaway box to run this in" case that used to require a signup now comes free with the tools you already have.

So the build-vs-buy math moved, and it moved per platform:

What didn't change#

Two things survived the shift intact. First: you still choose where the code runs. A safer default is not an automatic one — Sandbox Agents and OS runtimes make the safe path easy, but they don't make the decision for you. Second, and this is the load-bearing one: a plain container is still not a security boundary. Every native option above leans on a microVM, gVisor, or OS-level sandboxing underneath the container for exactly this reason — the argument we made in Your Container Is Not a Sandbox is now the industry's default assumption, not a contrarian take.

The category grew up this year. Sandboxing is no longer the thing you remember to add — it's the thing you'd have to go out of your way to turn off. For anyone shipping an agent that writes and runs code, that's the rare platform shift that makes the safe choice the lazy one too.