Agent Compute Engine is a new Google Cloud service that gives every AI agent its own hardware-isolated microVM, with container-level speed and zero credentials held inside the sandbox. The post frames it as a response to the next foundational shift in computing: agentic AI that goes beyond answering questions to taking action. Across Google, AI agents are writing and executing code, running tools, driving browsers, and orchestrating enterprise workflows, and agentic workloads have quickly become one of the fastest-growing consumers of compute and storage in the fleet.

Existing compute primitives do not fit this workload. Traditional VMs give full control and hypervisor-enforced isolation, but booting, suspending, and resuming takes seconds to minutes, which is too slow for agents that start, pause, and resume constantly. Containers are fast because they share the host kernel, but coding agents and developer assistants need complete isolation plus kernel- and root-level control. The Gemini team and the Gemini for business team both split agents into a harness (the “brain”) that calls the model and decides next steps, and a sandbox (the “hands”) that runs code, shell commands, and a browser. The missing form factor is one that combines VM isolation with container speed and density, and that knows when an agent is working versus waiting.

The platform offers a simple microVM abstraction rather than raw infrastructure primitives. It is built for four workload classes: interactive consumer and enterprise agent surfaces (chat that writes and runs code, interactive shells, headless browser sandboxes); autonomous software engineering workspaces with root access and persistent git workspaces; massive-scale evaluation and reinforcement learning pipelines that spin up and branch thousands of parallel environments; and lightweight sandbox backends for internal Google services.

Security follows a defense-in-depth architecture. Node attestation keys live in Google’s Titan silicon and Titanium IPU, outside the guest; hosts are stateless immutable appliances with dm-verity read-only root filesystems and zero persistent local state; and every agentic session runs in a dedicated, single-tenant, memory-safe microVM with CPU side-channel mitigations. The zero-secrets principle assumes an attacker controls everything inside the sandbox. Guest environments hold no persistent secrets or cloud credentials, have no access to the metadata server, and boot without a standard network interface — all traffic traverses virtio-vsock to a local unprivileged mediation proxy and then an external gateway that enforces scoped, policy-driven outbound brokering. Each microVM receives only an ephemeral session-scoped SPIFFE certificate via a per-VM local listener, and long-lived credentials are swapped in off-node by the Agent Gateway only after validating mTLS identity and egress policy.

Governance is expressed as four identities: the user identity, a delegated on-behalf-of grant held only in the central authorization service, a short-lived SPIFFE-based agent workload identity (the only identity used for sandbox traffic, and not usable to call backend APIs if exfiltrated), and an agent workforce identity. When sandbox code makes an outbound request, the local proxy binds node and Titanium-backed attestation and forwards it to the gateway, which validates user delegation, agent identity, and node identity, enforces fine-grained egress and data-loss-prevention policies, and performs an in-flight token swap. The downstream backend sees a clean, auditable identity; the sandbox never sees a credential.

Measurements showed agents spend most of their lives waiting, so the host uses application-aware idle detection: when a sandbox signals no active commands are in flight, the host checkpoints it and restores it on the next tool call, consuming zero active resources while idle. One node can therefore host orders of magnitude more living microVMs than conventional VMs. Pre-warmed snapshot images with Direct Access (DAX) and Copy-on-Write memory clones let every microVM on a host share the same physical RAM pages for the base OS and libraries, allocating memory only for private page deltas. Storage splits into ephemeral scratch overlays, read-only shared volumes (base images, toolchains, package caches), and persistent user workspaces served via encrypted Hyperdisk.

For enterprise customers, the same identity and gateway design enforces policy-driven VPC and Workspace reachability through Private Service Connect and VPC Service Controls, so sensitive data is not copied to another vendor and no firewall port needs opening for an agent. Because demand curves for consumer chat, enterprise business hours, and evaluation pipelines do not peak together, a global policy-aware scheduler steers sessions to available capacity, deferred and scheduled workloads fill off-peak troughs, and a unified fungible hardware pool absorbs uncorrelated peaks. Agent Compute Engine is targeted for preview on Google Cloud in the coming months, letting developers control each environment’s image, identity, network access, and lifecycle while Google manages the underlying fleet.