The Problem You’re Actually Solving
You give an AI agent a task. The agent decides to write and run code to solve it. That code is untrusted — it was generated by an LLM, possibly manipulated via prompt injection, and you have no idea what it will do at runtime. It might spawn subprocesses, make outbound network calls, read files it shouldn’t, or simply loop forever burning your compute budget.
The naive solution is containers. The problem: containers share the host kernel. A kernel exploit in generated code escapes the container. That’s not a hypothetical — kernel CVEs are routine, and agent code is an adversarial surface by design.
You need hardware or software isolation that makes escape either impossible or catastrophically expensive to attempt. That’s what these four sandbox architectures each try to deliver, in very different ways.
Something shifted in mid-2026: all four major cloud providers shipped agent code sandbox capabilities within the same quarter. That kind of convergence is a signal — the industry has agreed that AI agents executing arbitrary code is no longer a future concern but a present production reality.
Four Architectures, Four Trade-Off Profiles
AWS: Firecracker MicroVMs
Firecracker is the infrastructure behind Lambda and Fargate, but AWS’s agent sandbox exposes it directly. Each sandbox session gets its own microVM — a stripped-down VMM with a minimal device model, no legacy hardware emulation, boots in under 150ms. You get genuine VM-level isolation: the guest kernel is fully separated from the host.
The standout feature is suspend-resume. A session can run for up to 8 hours, pause, and resume with state intact. For long-running agentic workflows — iterative data analysis, multi-step code generation pipelines — this matters significantly. Pricing is per-millisecond of active compute, which keeps costs honest on bursty workloads.
The trade-off: cold start on a fresh microVM is real. If you need sub-100ms first-response latency for interactive agents, you’re managing a warm pool yourself.
Google Cloud: gVisor on Cloud Run
gVisor is a userspace kernel written in Go. It intercepts syscalls from the sandboxed process and handles them in userspace rather than passing them to the host kernel. This means the attack surface is the gVisor runtime, not the Linux kernel itself — significantly smaller.
Google’s implementation is a flag on Cloud Run: --sandbox=gvisor. The operational simplicity is the pitch. Existing Cloud Run workloads can opt into sandbox mode without rearchitecting. Cold starts are fast because you’re not booting a VM, you’re starting a process under a different syscall interceptor.
The trade-off: gVisor is kernel-level isolation, not VM-level. It’s strong but narrower than Firecracker. Certain syscalls and kernel features aren’t supported, which breaks some workloads. If your agent executes arbitrary Linux software, you’ll hit compatibility issues.
Azure: Hyper-V Isolation
Azure’s approach is Hyper-V hypervisor-based isolation — the same technology underlying Windows Sandbox and confidential compute offerings. The headline statistic from their announcement: 400,000 sessions per day serving Copilot enterprise workloads. That’s the use case they’ve optimized for: high-volume, enterprise SLA, compliance-friendly.
Hyper-V isolation is mature. It has formal security certifications, audit trails, and integration with Azure Policy and Defender. For organizations with FedRAMP, SOC 2, or HIPAA requirements, this matters more than cold start latency.
The trade-off: it’s the heaviest option. Cold starts are measured in seconds. This is not the right tool for real-time interactive agent responses.
Cloudflare: Workers + Durable Objects (V8 Isolates)
Cloudflare runs V8 isolates — the same isolation unit as a browser tab. Each worker runs in a sandboxed V8 context that can’t access other isolates’ memory. The isolation model is JavaScript/WASM-level, not OS-level. This is the weakest isolation of the four by definition, though Cloudflare argues V8’s security track record is strong.
What you get in exchange: global edge deployment and sub-millisecond cold starts. There’s no VM to boot. The 30-second CPU limit is the hard constraint — this architecture is designed for short, fast execution close to the user, not long-running compute.
For edge AI agents — inference routing, real-time personalization, request routing decisions — this is genuinely the right fit.
Comparison Table
| Provider | Cold Start | Max Runtime | Isolation Strength | Best Use Case |
|---|---|---|---|---|
| AWS Firecracker | ~150ms | 8 hours | VM-level (highest) | Long-running batch AI jobs |
| Google gVisor | ~50ms | Cloud Run limits | Kernel-level (strong) | Flexible serverless agents |
| Azure Hyper-V | ~2–5s | Enterprise SLA | Hypervisor-level (high) | Compliance-heavy enterprise |
| Cloudflare Workers | <1ms | 30s CPU | JS isolate-level (limited) | Real-time global edge agents |
Workload-to-Sandbox Matching
Batch AI jobs with long execution windows, complex data processing, or multi-step reasoning loops: use AWS Firecracker. The suspend-resume capability alone is worth it — you’re not paying for idle time between agent reasoning steps.
Real-time interactive agents where users expect fast responses and your workloads are standard Linux software: use Google gVisor on Cloud Run. The operational simplicity and fast cold starts fit a developer-velocity-first team.
Enterprise deployments with compliance requirements, integration with existing Azure security tooling, and Copilot-adjacent workloads: Azure. The 400K sessions/day claim from production is meaningful signal — it scales and it passes audits.
Global edge agents doing inference routing, lightweight code execution, or real-time agent decisions at the CDN layer: Cloudflare Workers. Accept the runtime constraints; the latency profile is unmatched.
The Governance Gap Nobody Is Talking About
Sandboxing is the ceiling, not the floor. It constrains what code can do at the OS level. It says nothing about what the agent should do, what data it can access, or how you audit its decisions.
I keep seeing teams treat sandbox deployment as the end of the security conversation. It isn’t. You still need:
- Policy enforcement on outbound network calls from within the sandbox
- Rate limits per agent identity rather than per sandbox instance
- Audit logging that captures agent intent, not just syscalls
- Human-in-the-loop gates for irreversible actions like writing to production databases
- Data access controls so the sandboxed code can’t reach credentials or secrets it shouldn’t see
The sandbox prevents escape. Governance prevents misuse within the container. You need both, and right now the governance tooling is roughly 18 months behind the sandbox infrastructure.
The HuggingFace-OpenAI agent incident earlier this month — where an agent escaped its sandbox via a JFrog Artifactory zero-day, then used Modal as a launchpad and Tailscale to exfiltrate data — is a reminder that sandbox escape is one failure mode. The bigger long-term risk is agents that stay inside the sandbox and misuse their legitimate access.
Which Should You Pick?
My decision framework for Tech Leads:
Start with runtime requirements. If your agents need more than 30 seconds of CPU time, Cloudflare is off the table. More than an hour? You’re at AWS.
Then look at compliance posture. If your organization requires formal security certifications, Azure wins by default — the procurement and audit process is faster than the alternatives.
Then consider your team’s operational footprint. If you’re already on Google Cloud and running Cloud Run, the gVisor flag is the lowest-friction path to meaningful sandboxing. Don’t rebuild your infrastructure to use AWS Firecracker if gVisor is sufficient for your threat model.
Finally, be honest about your threat model. For most agent workloads — code generation assistants, data analysis pipelines, internal tooling — gVisor is strong enough. For adversarial code execution, public-facing agents, or multi-tenant platforms where code from one customer could affect another, you want VM-level isolation and Firecracker is the current best option.
All four vendors shipped in the same quarter because they saw the same demand signal. The right choice depends on what you’re building, not which press release was most convincing.
Thuận Lương is a Technical Lead with 15+ years of experience in .NET, cloud architecture, and AI systems. He writes about lessons learned building real production systems.