Google Cloud Launches Agent Compute Engine: A MicroVM per AI Agent

Google Cloud has announced Agent Compute Engine , a compute service built specifically for AI agents. Google Agent Compute Engine gives each agent its own hardware-isolated microVM. The sandbox holds zero credentials. The service already powers Gemini as an agent for work tasks. Google unveiled it this week at AGNTCon + MCPCon. Customer preview is targeted for the coming months. The pitch: VM-grade isolation with container-like speed and density. TL;DR Unit: One hardware-isolated microVM per agent session, with its own guest kernel, root access and Hyperdisk. Runs on: Google-managed hosts using Titan silicon and the Titanium IPU. Open-source sibling Agent Substrate runs on any Kubernetes cluster. Performance: Idle agents are checkpointed to zero active resources and resumed from snapshots. Google gives no ACE boot or density numbers. Best: Agent Substrate hit 500 activations/s at under 500 ms suspend/resume across 200,000 agents. Worst: No published boot time, density, pricing or preview date for Agent Compute Engine itself. What is Google Agent Compute Engine? Agent Compute Engine is a Google Cloud service that runs each AI agent inside a dedicated microVM. Per the technical post , it powers Gemini, Antigravity, and internal evaluation and RL pipelines. Google splits every agent into 2 parts. The harness, or ‘brain,’ calls the model. The sandbox, or ‘hands,’ runs code, shell commands and browsers. The harness runs fully outside the sandbox and dispatches explicit commands into it. How does the microVM isolation work? Each session runs in a single-tenant microVM behind a Cloud Hypervisor boundary . Hosts are stateless appliances with a read-only root filesystem enforced by dm-verity. Titanium holds attestation keys outside the guest. The networking design is the unusual part: MicroVMs have no standard network interface, no default gateway and no direct VPC access. All traffic crosses a virtio-vsock boundary to a local proxy, then to an external gateway. Guests get only a session-scoped SPIFFE certificate and a short-lived identity token. Agent Gateway swaps in the real backend credential in flight, after policy checks. Google assumes an attacker controls everything inside the sandbox. A prompt-injected agent finds no secrets to steal. What are the Four Agent Identities? Google defines 4 identities for every agent workload: User identity: authenticates the overall task only. Delegated on-behalf-of identity: a scoped grant stored in a central authorization service, never on the node. Agent Workload Identity: a short-lived SPIFFE identity, the only one used for sandbox traffic. Agent Workforce Identity: an agent’s own account and resources. The workload identity is useless for direct API calls if exfiltrated. It only identifies which sandbox sent a packet. How does it keep idle agents cheap? Google team found agents spend most of their time waiting on models or users. So the sandbox signals when a tool call finishes. The host checkpoints the idle microVM to zero active resources. It resumes on the next call. Density comes from copy-on-write memory sharing . Pre-warmed snapshot images are mapped with DAX, so microVMs on a host share base OS and library pages. Only each agent’s modified pages consume private memory. Harnesses also get cloning, snapshot/forking, rewind and rollback. Storage is split 3 ways: disposable scratch overlays, shared read-only volumes, and persistent user workspaces on Hyperdisk . Harnessoutside Sandbox microVMuntrusted vsock + local proxyhost Agent Gatewayoff-node Token swapoff-node BackendWorkspace / VPC Step 1

Back Next step Auto-play

Source: Google Cloud technical deep dive, Oct 22, 2026.

State 1Running tool callCode, shell or browser executes inside the microVM. State 2"Thinking" signalSandbox reports no commands or background tasks in flight. State 3Checkpointed idleState preserved. Zero active host resources. State 4ResumeNext tool call restores the microVM from its snapshot. Copy-on-write memory, shared across 6 microVMs 1 shared copy of base OS, libraries and binaries (DAX + CoW) Base image pagesPrivate pages the agent modified Turn on CoW sharing Run idle cycle

Bar heights are illustrative. Google discloses no per-host density figure for Agent Compute Engine.

ID 1User identityStarts the taskThe authenticated user who initiated the request. Used only to authenticate the overall task, never for agentic operations. ID 2Delegated on-behalf-ofLives in central auth serviceA cryptographically scoped grant proving the user authorized the harness. These long-lived grants never sit on the compute node. Only ID in sandboxID 3Agent Workload IdentityShort-lived SPIFFE IDAssigned when the microVM spins up. Identifies which sandbox sent a packet. Useless for direct backend calls if exfiltrated. ID 4Agent Workforce IdentityAgent's own accountLets an agent act as an assistant with its own identity, account and resources.

Tap a card to reveal it. Agent Gateway translates ID 3 into the other identities off-node, after verifying host, user, sandbox, session and policy.

0agents in benchmark 0activations per second 0suspend / resume latency 0