Executive Summary
Google launched Agent Compute Engine on October 22, a compute service that gives every AI agent its own hardware-isolated microVM with no credentials inside it. The rule behind the design is blunt. Assume an attacker controls the sandbox, then make sure the sandbox holds nothing worth taking. No OAuth refresh token, no service account key, no metadata server. Just a short lived certificate bound to one session. Google says the service already runs its Gemini agent for work tasks and opens as a preview in the coming months.
The finding worth carrying away is that the isolation boundary is becoming the product in AI infrastructure, not the model endpoint. Google’s published benchmark for the Kubernetes agent runtime behind it ran 200,000 agents at 500 suspend and resume activations per second, under 500 milliseconds each, which it puts at ten times the density of traditional compute. A fleet that waits on a model or a human costs money only while it is awake, and any team injecting API keys into an agent environment is carrying the exposure this design exists to remove.
A virtual machine gives you a hypervisor boundary and takes seconds to minutes to boot. A container starts in milliseconds because it shares the host kernel, which is fine until the code inside wants root. Google needed both, plus a system that can tell when an agent is thinking rather than working.
The sandbox is a small room with the door welded shut
Every agent session runs in a single-tenant microVM on a Cloud Hypervisor boundary, with its own guest kernel and its own root. The guest gets no network interface, no default gateway, and no direct path into the VPC. Traffic leaves over virtio-vsock to an unprivileged proxy, which forwards to a second proxy that enforces outbound policy.
The part that matters is what the guest does not hold. Google’s technical deep dive says a sandbox contains zero persistent secrets, no cloud service account keys, and no route to the instance metadata server. What it has instead is one ephemeral SPIFFE certificate and a short lived token, delivered over a per-VM local listener. Real user credentials stay off the host, swapped in by Agent Gateway once it validates the sandbox certificate and the egress policy.
That is the difference between a policy and a control. Most deployments today hand the model an environment with an API key inside and hope the model behaves. This one treats the model as hostile. If the sandbox falls, an attacker with root finds no token to replay.
Pausing idle agents is where the density comes from
Agents spend most of their life waiting. The microVM signals that it is idle when the agent enters its thinking phase, then moves off the active pool. Many agents share one operating system template through copy-on-write memory, and an idle microVM is checkpointed and resumed from a snapshot on the next tool call.
Each microVM also carries its own Hyperdisk, so a coding agent keeps its workspace across days of work. Kubernetes alone cannot do this. A Pod has no hibernation and no cheap restore, which is why the open source version, Agent Substrate on GKE, bolts a second control plane onto Kubernetes to own actors rather than Pods. Treat the density number as Google’s claim, not a measured result.
A preview leaves the harness, and the bill, with you
Three things stay yours. The harness sits outside the sandbox by design, so the quality of its audit trail is your problem. Portability is limited, because the managed service is Google Cloud only and the open option is the runtime on GKE. And pricing has not been published, so a preview is a preference rather than a plan.
The governance layer is where the hold sits. Agent Gateway brokers traffic, Agent Registry tracks approved agents and MCP servers, and Agent Identity issues the SPIFFE credentials. Google is extending enforcement to other clouds through Envoy proxies and to laptops through an OS-level sandbox for coding agents. Token budgets and model routing arrive at the gateway next.
Our earlier reporting on AgentCore showed what happens when a sandbox can be talked into acting for the host. One injected prompt reached the instance metadata service and took over every agent in the region. Google’s answer is to make that reach pointless. Modal’s numbers made the same case from the revenue side. A third of a billion dollar run rate came from running untrusted code, not from selling GPU hours.
Before you pay for any of this, ask three questions about your own fleet. Does the sandbox hold a credential, a token, or a metadata path the agent can reach? Can your platform pause an idle agent without destroying its working state? And who owns the harness when it dispatches a destructive command?
It moved the security question from how well the model behaves to what the sandbox physically contains. The model will eventually be talked into something. An empty box is a better answer than a better prompt.
Source, the Google Cloud announcement and the technical deep dive, both October 22 2026.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.
[…] same lesson keeps arriving. Google built an agent sandbox that holds one short lived certificate, so a hijacked agent has nothing to take. OpenAI pulled internet access from frontier training […]
[…] reading. We covered Google’s agent sandbox, India’s CERT-In list of agent attack vectors and the OpenCode key […]