Agent Sandbox Isolation Landscape
The market for running untrusted, model-generated agent code splits along two questions: what supplies the isolation boundary (microVM, user-space kernel, or namespace), and how the sandbox is delivered (an open primitive you install, or a proprietary managed service bound to a vendor’s agent platform). GKE Agent Sandbox’s May 2026 launch is the event reshaping the second axis: it puts an open, Kubernetes-native sandbox primitive against a set of independent vendors and two proprietary hyperscaler services.
Delivery model — the axis that moved
| Offering | Delivery | Isolation boundary | Portability | Notes |
|---|---|---|---|---|
| Agent Sandbox (Google / SIG Apps) | Open CRDs + managed GKE | gVisor default; Kata/runc pluggable | Any Kubernetes cluster1 | Open primitive; managed tier adds warm-pool performance |
| AWS Bedrock AgentCore code interpreter | Proprietary managed (Bedrock) | Managed sandbox | AWS-bound | Recorded in D4; not a standalone primitive |
| Azure Foundry hosted-agent sandbox | Proprietary managed (preview) | Per-session microVM | Azure-bound | Public preview; bound to Foundry agents |
| Cloudflare Sandboxes | Proprietary managed (Workers) | Container isolation + V8 isolates | Cloudflare-bound | Edge-resident; lighter workloads on isolates2 |
| E2B | Independent SaaS / self-host | Firecracker microVM | Vendor runtime | Independent sandbox vendor; microVM boundary2 |
The headline that Agent Sandbox is “the only native agent sandbox offering among the three major hyperscalers”2 is precise only with the delivery axis attached. AWS and Azure ship sandboxes, but as managed features of their agent platforms. Agent Sandbox is the only one of the three delivered as an open, cross-cluster Kubernetes resource — the claim is about delivery model, not the existence of a sandbox.
Isolation boundary — the older axis
| Runtime | Mechanism | Startup | Boundary strength | Best fit |
|---|---|---|---|---|
| Firecracker | KVM microVM | ~125 ms | Hardware (VM) | Per-task VM on bare metal / managed VMs |
| gVisor | User-space kernel (syscall interposition) | Near-instant | Reduced syscall surface (Sentry) | Container-native / Kubernetes |
| Kata Containers | Lightweight VM per container | ~sub-second | Hardware (VM) | OCI-compatible hardware isolation |
| runc + seccomp/caps | Namespaces + syscall filter | <10 ms | Process-level | Lowest assurance; insufficient for actively targeted agents |
These are orthogonal to delivery: Agent Sandbox defaults to gVisor but treats the runtime as pluggable, so a SandboxTemplate can pin Kata for a hardware boundary where the gVisor Sentry surface is judged too large for a given risk tier.
What this means for buyers
- On EKS or AKS and need a kernel-level boundary for untrusted agent code. AWS and Azure ship managed sandboxes (AgentCore, Foundry), but neither offers them as an open Kubernetes-native primitive you install on your own EKS/AKS cluster; that specific equivalent does not ship today. The open Agent Sandbox CRDs do install on any conformant cluster, so the build-it-yourself gap is narrower than the “only on GKE” reading suggests.1 The managed performance envelope (300 sandboxes/sec, warm pools) stays GKE-specific.3
- The independent vendors are not displaced. Cloudflare’s edge residency and E2B’s hosted microVM runtime remain distinct value propositions; the open primitive pressures the managed-sandbox-as-a-product category more than it pressures edge or turnkey-SaaS positioning.
- Boundary choice is still a risk-tier decision. gVisor’s reduced-surface model trades a larger trusted computing base (the Sentry implementation) for container-native speed; a hardware VM boundary (Firecracker, Kata) is the stronger assurance for the highest-risk tasks. See gVisor for the Sentry-surface caveat.
The boundary this does not cross
Every offering here solves runtime isolation — a compromised agent cannot escape to the host. None addresses what the agent does within its granted scope: intent-blind identity tokens, sanctioned-path data exfiltration, and behavioral drift sit in the identity, egress, and observability planes of the reference architecture, and supply-chain provenance sits in its own control domain. Sandboxing is the last line of defense at the OS boundary, not a substitute for the layers above it.
See also
- GKE Agent Sandbox — the product page
- Agent Sandboxing — the practice
- CMM D4 — where sandboxing is graded
Notes
Footnotes
-
GitHub — kubernetes-sigs/agent-sandbox, 2026. SIG Apps subproject; Apache 2.0; runs on any Kubernetes cluster; gVisor/Kata pluggable runtimes. ↩ ↩2
-
InfoQ — Google Announces GKE Agent Sandbox and Hypercluster at Next ‘26, May 2026. “Only native agent sandbox offering among the three major hyperscalers”; Cloudflare Sandboxes (container + V8 isolates) and E2B (Firecracker microVMs) as the independent comparison set. ↩ ↩2 ↩3
-
Google Cloud blog — Bringing you Agent Sandbox on GKE and Agent Substrate, May 2026. 300 sandboxes/sec per cluster; 90% under 200 ms; warm pools; Pod Snapshots. ↩