AWS, Azure, and Google Cloud All Built Agent Sandboxes — None the Same Way

Every major cloud provider now agrees that AI agents need their own isolated place to run untrusted code — and every major cloud provider disagrees, sharply, on what that isolation should actually look like.

What Happened

In the space of one quarter, AWS, Google Cloud, Microsoft Azure, and Cloudflare have all shipped or expanded a dedicated agent-sandboxing product, converging on the same conclusion from four different starting points. AWS built Lambda MicroVMs on Firecracker, giving each agent session its own dedicated virtual machine with up to eight hours of runtime and a suspend-resume cycle that preserves memory, disk state, and running processes across pauses. Google Cloud split the difference with two separate answers: GKE Agent Sandbox uses gVisor to intercept syscalls at the kernel level, while Cloud Run’s newly previewed sandboxes (announced at WeAreDevelopers World Congress in Berlin) add a lighter isolation boundary inside an existing Cloud Run instance. Azure took the most established route — Container Apps dynamic sessions have run on Hyper-V boundaries since 2024, and Microsoft says Copilot alone now consumes more than 400,000 of those sessions. Cloudflare, the newest entrant, built its Sandbox SDK directly on top of Workers and Durable Objects rather than a VM or kernel boundary at all.

Why It Matters

The divergence isn’t cosmetic — it reflects a real disagreement about where the isolation boundary should sit. Firecracker’s per-session VM and Hyper-V’s container boundary both trade some cold-start latency for a harder security guarantee: a full hardware-virtualized wall between the agent’s code and the host. gVisor’s kernel interception is lighter-weight and faster to spin up, but it narrows the isolation to syscall filtering rather than a separate kernel entirely. Cloudflare’s Workers-based approach is the fastest and cheapest of the four, since it reuses infrastructure built for edge compute rather than standing up new VM or container tooling — but it also means the isolation model is whatever Workers already provides, not something purpose-built for adversarial agent code. None of these are wrong; they’re optimized for different failure modes, and a platform team picking one is implicitly picking which kind of agent behavior it’s most worried about.

What This Means for Builders

For teams running agentic AI in production, the practical takeaway is that “our cloud has an agent sandbox now” is not a like-for-like checkbox across providers. A team standardized on AWS inherits Firecracker’s stronger VM isolation and longer session persistence, useful for agents that need to hold state across a multi-hour task. A team on Cloudflare inherits faster, cheaper spin-up at the cost of a less battle-tested isolation boundary for genuinely adversarial code. Azure’s 400,000-session figure from Copilot alone suggests the Hyper-V route is already carrying real production load, which matters if you’re choosing based on what’s been stress-tested at scale rather than what’s newest.

Source: The New Stack

Content created with AI assistance and reviewed for accuracy.