The Category Just Became Table Stakes
In a July 24, 2026 analysis, The New Stack's Janakiram MSV made a simple observation with large implications: all four major clouds now offer isolated code execution as a native primitive, and they built it with materially different isolation stacks and lifecycle models. The trigger was Google Cloud pushing Cloud Run sandboxes into public preview on July 9, which completed the set. Every hyperscale cloud now ships a dedicated environment where untrusted code from an AI agent can run without endangering the host application.
This matters because agent workloads have made sandboxing a mainstream requirement rather than a niche concern. When a language model generates and executes arbitrary code millions of times a day, the blast radius of a single malicious or buggy snippet becomes a board-level security question. The clouds are responding by making a hardened execution boundary something you request as a first-class service. For platform teams, the question has shifted from whether to sandbox agent code to which provider's model fits your architecture.
AWS Bet on Firecracker MicroVMs
AWS built its Bedrock AgentCore Runtime on Firecracker, the same microVM technology that powers Lambda. Each user session gets its own dedicated microVM with isolated compute, memory, and filesystem. Sessions can run for up to eight hours, and a suspend-resume cycle preserves memory, disk, and running processes across pauses. When a session ends, the entire microVM is destroyed and all session data goes with it. Firecracker itself boots in roughly 125 milliseconds with about 5 megabytes of overhead.
The AWS design optimizes for long-lived, stateful agent work. An eight-hour ceiling and process-preserving suspend-resume suit agents that carry out extended tasks with intermediate state worth keeping. The tradeoff is that a full microVM per session is heavier than a lightweight in-instance boundary, which shapes both cost and cold-start behavior. For teams already committed to Bedrock, AgentCore Runtime folds sandboxing into the same managed surface as the rest of their agent stack, which is a meaningful reduction in integration work.
Google Went Two Directions at Once
Google chose not to standardize on a single model. For Kubernetes workloads, the GKE Agent Sandbox uses gVisor, which intercepts and mediates system calls to give container-like ergonomics with a stronger boundary. For serverless workloads, Cloud Run sandboxes add a lightweight isolated execution boundary inside an existing Cloud Run instance. The Cloud Run approach starts in roughly 500 milliseconds on average, and Google demonstrated spinning up, executing, and stopping 1,000 sandboxes at that latency.
The Cloud Run model is deliberately frugal. Sandboxes run on the CPU and memory you already allocated, so there is no additional charge. Security rests on three boundaries: no access to service environment variables or the metadata server, deny-by-default network egress that requires an explicit allow-egress flag, and a read-only filesystem overlay whose changes are discarded after execution. That profile fits LLM code interpreters, headless browsers, and user-submitted scripts, which is exactly the workload mix Google names in its documentation.
Azure and Cloudflare Took the Remaining Corners
Microsoft got there earliest. Azure Container Apps dynamic sessions have run on Hyper-V isolation boundaries since 2024, well before the current wave of agent sandboxing. The scale is the striking part: Microsoft reports that Copilot alone consumes more than 400,000 of these sessions per day. That volume is a useful reality check on how much untrusted code execution a production assistant actually generates once it is in wide use.
Cloudflare approached the problem from the edge. Its Agents offering combines Durable Objects, the Agents SDK, and Workflows to provide persistent state and durable execution close to users. When an agent needs a real filesystem or shell, Cloudflare Sandbox runs that code in an isolated container. The design trades the microVM-grade boundary of AWS for edge proximity and a programming model built around durable, stateful agents. For teams already running on Workers, it keeps agent execution inside the same runtime rather than reaching back to a central region.
The Isolation Choice Is the Whole Story
The reason these four designs diverge is that the underlying security question has one hard answer. A container shares a kernel with roughly 40 million lines of C code and functions as a resource-control mechanism rather than a security boundary. Once agents execute arbitrary code at scale, that distinction stops being academic. It explains why AWS reached for Firecracker microVMs, why Google layered gVisor system-call interception on top of containers, and why Azure sits on Hyper-V.
For engineering leaders, the isolation model is the specification that should drive selection, not the marketing name. MicroVMs give the strongest boundary at the highest weight. gVisor and in-instance boundaries trade some isolation strength for startup speed and cost. The right choice depends on whether your agents run untrusted third-party code, how long sessions live, and how much state they carry. Reading the isolation stack tells you what threat model the provider actually designed against.
What This Means for Build Versus Buy
The immediate consequence is that rolling your own agent sandbox is now harder to justify. Firecracker also powers independent offerings like E2B and Vercel Sandbox, so the same microVM boundary is available whether you buy from a hyperscaler or a specialist. For most teams, the managed primitive from a cloud they already use will beat maintaining a custom isolation layer that has to keep pace with kernel security research.
The strategic risk to watch is portability. Because the four providers chose different lifecycle models and different isolation technologies, an agent architecture built tightly around one sandbox will not lift cleanly to another. Teams that expect to run multi-cloud, or that want negotiating leverage, should abstract sandbox invocation behind a vendor-neutral interface early. Vendor-agnostic execution SDKs already exist for exactly this reason. The sandbox layer is becoming commodity infrastructure, and the teams that treat it that way will keep their options open.
