· 8 min read · Engineering
Your Agents Aren't Too Insecure. They're Too Awake.
When people talk about running AI agents on Kubernetes, they almost always talk about one thing: isolation. How do you keep an agent that can run arbitrary code from reading another tenant’s secrets, escaping its container, or turning your node into someone else’s crypto miner? It’s a real question, and the answers—microVMs, user-space kernels, syscall filtering—are good engineering.
But isolation is not where the money is.
Google published the number. In the GKE Agent Sandbox benchmark from July 2026, a single n2-standard-48 node running an OpenClaw agent profile went from 61 agents to 274 agents—more than 3x more agents than the baseline on the same hardware.
That jump comes from two separate techniques stacked on the same node. The sandbox—the isolation layer everyone writes about—accounts for the smaller piece.
The Sandbox Is the Smaller Half
The benchmark measures three points on the same node: the baseline, the sandbox alone, and the sandbox with suspend and resume on top.
Running each agent inside gVisor, Google’s user-space kernel, instead of giving it a full VM, took the node from 61 agents to 88 before reliability failed. That is the isolation lever, and it is worth 44%.
Then snapshotting idle agents to disk and freeing their memory carried the same node from 88 to 274. Google reports that lifecycle lever as worth up to 3.5x on its own.
44% against 3.5x. The sandbox is the smaller half.
The Sandbox Buys You a Kernel You Can Trust
A normal Linux container is not a security boundary you’d hand an adversary. Every container on a node shares the host’s single Linux kernel, and the kernel’s system-call surface is enormous—hundreds of calls, any one of which might carry a bug that lets code break out. For code you wrote, that’s a fine trade. For an AI agent executing whatever a language model decided to exec, it is not.
gVisor closes that gap by putting a second, much smaller kernel—written in memory-safe Go, running in user space—between the agent and the host. When the agent makes a system call, gVisor intercepts and services it instead of the host kernel. The agent never touches the real syscall surface. The cost is overhead: that interception isn’t free, and gVisor historically trades some raw I/O and syscall performance for the safety. But it’s far lighter than a full virtual machine, which needs its own guest kernel, its own boot, and its own reserved memory. That lightness is the isolation win: you fit more agents because each boundary is cheaper than a VM’s.
Suspend and Resume Stops You Paying for Idle
An agent spends most of its life waiting. It’s holding a conversation, then sitting idle while a human reads its last answer, then waking to do a few seconds of work. During every one of those idle stretches, its pod is still resident: the process is alive, and its memory—often gigabytes of model context, loaded libraries, and working state—is still pinned in the node’s RAM. Memory, not CPU, is what runs out first on an agent node. Idle agents don’t burn cycles; they hoard RAM. And a node full of agents hoarding RAM is a node that can’t accept a single new one, no matter how idle everyone is.
A pod snapshot changes the deal. When an agent goes idle, you checkpoint it: freeze the whole pod, write its memory and process state to disk, and delete the running pod. The RAM comes back to the node. When a request arrives for that agent, you restore it from the snapshot—the process comes back exactly where it left off, mid-conversation, with its state intact—and it services the request. The restore is transparent to the agent’s compute, not to its network: GKE’s own Pod snapshots documentation is explicit that memory, threads, CPU registers, and open file descriptors survive intact, but the restored pod gets a new IP and its external connections are terminated. In-flight process state comes back; live sockets have to be re-established. The node still got its memory back for the entire idle window.
That’s the lifecycle lever. You’re no longer paying to keep idle agents resident. You’re paying only for the ones actually doing something right now, plus the disk to park the rest.
flowchart TB
subgraph Isolation["The isolation view"]
direction LR
A1["Agent"] --> G1["gVisor: cheaper boundary<br/>than a full VM"]
G1 --> N1["More agents fit<br/>per node"]
end
subgraph Lifecycle["The lifecycle view"]
direction LR
A2["Idle agent<br/>hoarding RAM"] --> S["Checkpoint:<br/>snapshot to disk,<br/>reclaim memory"]
S --> R["Restore on demand,<br/>mid-conversation"]
R --> N2["You pay only for<br/>active agents"]
end
Isolation -.->|"the smaller half"| Total[">3x density<br/>(61 → 88 → 274 agents/node)"]
Lifecycle -.->|"the bigger half"| Total
Kubernetes 1.37 Makes the Lifecycle Lever a Primitive
On July 22, 2026, Kubernetes merged two new remote-procedure calls—CheckpointPod and RestorePod—into the Container Runtime Interface (pull request #140366). They ship in 1.37.
The CRI is the stable API boundary the kubelet—the node daemon that manages every pod on that machine—uses to talk to whatever runtime is actually running your containers (containerd, CRI-O, and others). Anything in that interface is a capability every conforming runtime implements. Anything outside it is something you reach around the interface to get.
Checkpoint and restore spent most of Kubernetes’ life outside it. The underlying mechanism is old: freezing a running process and its memory to disk and thawing it later has existed on Linux for years as CRIU, “Checkpoint/Restore In Userspace.” Getting it into a cluster meant vendor extensions and out-of-band tooling.
Now the kubelet can ask any conforming runtime to do it. That moves the lifecycle lever from something a cloud sells you to something the platform does—so GKE Agent Sandbox becomes the production-hardened version of a capability that belongs to upstream, and the bigger half of the density win travels with Kubernetes rather than with a vendor.
The Constraint Already Moved to the Control Plane
If you assume the node is the bottleneck—too few machines, too little RAM per machine—then you spend your effort on the node: cheaper sandboxes, denser packing, bigger instances. But watch where the Agent Sandbox project itself has been spending its effort, and you’ll see the engineers who build this have already concluded the node isn’t the binding constraint anymore.
Look at two releases. In v0.5.0, from June 24, 2026, the project graduated its API group agents.x-k8s.io to v1beta1, replaced spec.replicas with a spec.operatingMode field, and reworked how a SandboxClaim references a warm pool of pre-started sandboxes through a warmpoolRef. That’s API maturation—the reshaping a project does when it’s settling into what the object model should really be.
Then look at v0.5.4, from July 30, 2026. Nearly every change in it is about pressure on one thing: the Kubernetes API server, the control plane’s front door that every controller and kubelet talks to. The release shards its HTTP/2 connections and gives watches a dedicated connection so a flood of updates on one can’t starve the others. It adds ReplicaSet-style expectations tracking so the controller stops over-creating warm-pool sandboxes while it waits for earlier creations to register. It moves to optimistic-locked status writes to avoid clobbering concurrent updates. It adds a scoped-token router authorizer that answers an authorization question locally instead of making a round-trip to the API server for it.
When you’re packing thousands of agents onto a fleet—creating them, snapshotting them, restoring them, tearing them down, all constantly—the thing that buckles isn’t the node’s RAM. It’s the control plane trying to keep up with the churn. The binding constraint on agent density has already moved off the node and onto the API server.
The sandbox is the smaller half because isolation is a per-node property; you solve it once per node and it’s solved. But lifecycle—suspending, resuming, and the constant creation and destruction that density demands—is a per-operation property, and every one of those operations is a conversation with the control plane. The more agents you pack, the more the control plane, not the node, decides how far you can go.
Start with the Lifecycle, Not the Box
The single largest lever on density is not keeping idle agents resident—it’s suspending them and reclaiming their memory. Design for agents that can be checkpointed and restored cleanly, and treat isolation as the necessary, cheaper property that comes with it. If you want to try the lifecycle lever on managed infrastructure, the Pod snapshots how-to walks through saving and restoring an Agent Sandbox environment—the bigger half of the density win, made hands-on.
Bet on the primitive, not just the product. Suspend and resume is arriving in upstream Kubernetes as a CRI capability, not staying locked to one cloud. You can adopt the managed version today for the operational polish—Google Kubernetes Engine ships both halves as Agent Sandbox for the gVisor isolation and Pod snapshots for the lifecycle—and know the underlying capability is becoming portable as those RPCs land upstream.
And watch your control plane, not just your nodes. If you push agent density hard, the API server is where you’ll hit the wall first. The projects building this have already turned their attention there—read the release notes on kubernetes-sigs/agent-sandbox and you’ll see the churn moving off the node. If you’re planning for scale, so should you.
Go measure it on something you run. Take one agent workload, snapshot it while it sits idle, and watch what comes back to the node—GKE Agent Sandbox Pod snapshots is the shortest path from reading this to seeing the memory come free. If you would rather stay on your own cluster, kubernetes-sigs/agent-sandbox is the upstream project, Apache-2.0, and the same lifecycle machinery lands in every Kubernetes 1.37 cluster once those CRI calls ship. Either way, the number that matters is the one you get on your own workload, not the one in the benchmark.