AWS, Google Cloud, Microsoft Azure, and Cloudflare now all offer agent sandboxes. None built them the same way.

Google Cloud quietly finished a race nobody officially announced. With Cloud Run sandboxes hitting public preview at WeAreDevelopers in Berlin this month, and AWS having shipped its own version just weeks earlier, all four major cloud providers now sell some flavor of isolated code execution for AI agents. The pitch is identical everywhere: an agent writes code, and that code needs somewhere safe to run before anyone trusts it near production credentials or the calling application.

What's interesting is how little agreement there is under the hood. AWS leans on Firecracker, giving each Lambda session its own dedicated microVM, up to eight hours of runtime, and a suspend-resume trick that keeps memory and disk state intact. Google split the difference, using gVisor kernel interception for GKE's Agent Sandbox while Cloud Run instead carves out a lightweight execution boundary inside an instance that's already running. Cloudflare went with full VM isolation per sandbox, wired together through Workers and Durable Objects. And Microsoft, easy to forget, got here first. Azure Container Apps has run dynamic sessions on Hyper-V boundaries since 2024, and Copilot alone reportedly burns through more than 400,000 of those sessions a day.

Cloud Run's version makes the shift almost comically simple. Add a --sandbox-launcher flag to your deploy command, and it mounts a binary the app can shell out to like any other subprocess. There's no separate charge, because the sandbox just borrows CPU and memory the instance already has. Google showed off a demo spinning up, running, and tearing down 1,000 sandboxes at roughly 500 milliseconds apiece — and its announcement pointedly noted that the alternative is either building sandboxing infrastructure yourself on container clusters or paying a specialized microVM vendor. That line is clearly aimed at a specific set of startups that built businesses in exactly that gap between shared-kernel containers and slow-booting VMs.

But isolation solving the containment problem doesn't mean anyone solved the harder one. A Firecracker VM keeps generated code away from the host and other sessions, sure. It says nothing about what that code does once you've handed it real credentials and network access — that's a governance decision made somewhere else entirely, and it's the expensive half of the problem. Meanwhile the vendor-specific limits stay stubbornly real: Lambda MicroVMs only run on Graviton, only in five regions, and cap out at eight hours, so teams needing x86 or longer sessions still have to build their own orchestration around it. Cloud Run sandboxes share CPU with their parent instance, meaning a runaway agent script can starve the very service that launched it.

So the commoditization story isn't quite finished. Every cloud has converged on the same basic principle — don't let agents run code directly on the host — but the sharp edges around region availability, runtime caps, and resource contention leave plenty of room for neutral, multi-cloud sandbox vendors to keep making their case. The argument has just moved one layer up: everyone agrees code should be contained, and now the fight is over who gets to govern what it does once it's safely inside the box.