Google Launches Agent Compute Engine as Managed Cloud Service for AI Agents

The infrastructure powering Google's Gemini agents will soon be available to Google Cloud users through a new managed service. Announced Thursday at the Linux Foundation's AGNTCon+MCPCon in San Jose, Agent Compute Engine will enter preview later this year, providing each AI agent with its own hardware-isolated microVM that merges container speed with sandbox-level security.

Competing approaches to agent isolation

Agent sandboxes have become a crowded space. Startups E2B and Daytona both offer sandbox environments to developers across any cloud platform. AWS provides similar functionality through Bedrock AgentCore, which assigns each agent session its own microVM. E2B leverages Firecracker, the open source virtualization technology AWS created for Lambda, and can pause and resume sandboxes in roughly one second. Daytona began with containers before adding microVM sandboxes in July, allowing full machine pauses or forking of running instances into identical copies.

AWS's AgentCore charges for memory during agent sessions but not for CPU time spent waiting on model or tool calls, with sessions capped at eight hours. In August, AWS introduced EC2-based runtime instances capable of maintaining shared sessions for up to 14 days. Google itself already offers a managed version of Agent Sandbox through GKE, the open source Kubernetes project it launched last November, and sells code-execution and computer-use sandboxes via its Gemini Enterprise Agent Platform.

Agent Compute Engine originated as internal infrastructure for Gemini, Antigravity, and Google's model training pipelines before being adapted for external use.

Why Google built its own infrastructure

Few organizations manage agentic workloads at Google's scale. The company reports that such workloads have rapidly become among the fastest-growing consumers of compute and storage across its infrastructure. At this volume, the systems supporting autonomous agents must deliver efficiency, scalability, and above all, security. Google determined it needed purpose-built compute infrastructure for agents, much as it had needed to develop Borg—the predecessor to Kubernetes—to manage compute resources in its early data centers.

Distinguished engineers Rohit Jnagal and Ramanathan Venkatapathy explained the technical reasoning in a detailed analysis. Traditional virtual machines offer control and flexibility but suffer from slow boot, suspend, and resume times—problematic for agents that start and stop rapidly. Containers address speed concerns but fall short for workloads requiring complete isolation and kernel- or root-level control. "Containers solve some of this," they note, "but there are multiple examples like coding agents and developer assistants that need complete isolation as well as kernel- and root-level control of the agentic environment." The team built Agent Compute Engine by returning to first principles to create "a unified, agent compute platform for Google" and now its customers.

A dedicated sandbox for each agent

Agent Compute Engine fundamentally provides every agent with a persistent, isolated computer environment. This enables agents to execute shell scripts, operate headless browsers, and run code with root permissions within agent loops that could persist for weeks. The platform also supports large-scale use cases including evaluation loops used by frontier labs to test models, AI benchmarking, and reinforcement learning. Google designed it to power sandboxed backends for its own services as well.

Agents typically spend most of their time idle, waiting for model responses or user input. Once an agent completes a tool call, the host checkpoints its microVM, which then consumes no active resources until the next request arrives.

Security through isolation and encryption

The platform's defining feature beyond performance is trustworthy containment—ensuring agents cannot escape their sandboxes. Each agent session runs in a single-tenant, memory-safe microVM containing no stored secrets in memory or on disk. Agent identity consists solely of short-lived, session-scoped credentials delivered through a single per-VM local listener. All traffic is encrypted end-to-end in transit, while snapshots and disks are encrypted at rest.

MicroVMs lack standard network interfaces; all traffic routes through an external proxy. When an agent needs to access a service like Google Drive, the Agent Gateway verifies the user's delegation and sandbox identity before supplying actual credentials outside the sandbox. The underlying host operates as a stateless appliance with a read-only filesystem, with hardware and firmware cryptographically verified at each boot. Google's Titan and Titanium IPU security platform backs this architecture. The microVMs themselves run on Cloud Hypervisor, an open source virtual machine monitor, with each receiving its own guest kernel and root access.

Jnagal and Venkatapathy illustrate the threat model with an example: an enterprise agent managing a user's inbox reads an email containing hidden instructions to locate API keys and exfiltrate them. While models typically ignore such prompts, they sometimes don't. "We started from one rule: Assume an attacker controls everything inside the sandbox, and make sure they find nothing there to use," the team writes.

Agent Substrate extends the model to Kubernetes

Not all teams will prefer running agents on a managed Google service. For those organizations, Google offers Agent Substrate, an open source runtime for Google Kubernetes Engine that debuted in May. Built atop Agent Sandbox, Google's Kubernetes project, Substrate adds a lightweight control plane designed to handle millions of short-lived tool calls that would overwhelm standard Kubernetes.

Like Agent Compute Engine, Substrate snapshots idle agent memory and returns the machine to the available pool until the agent receives additional work. Google claims this approach delivers up to 10 times the density of conventional compute. In a 200,000-agent benchmark, Substrate processed 500 activations per second, with agents suspending and resuming in under half a second.

Teams can isolate each sandbox using either a microVM or gVisor, and every agent receives its own cryptographic identity. Like Agent Compute Engine, egress proxies attach credentials outside the sandbox. Substrate operates on any Kubernetes cluster and integrates with various harnesses, including Claude Code, OpenClaw, and Nous Research's Hermes.

Hervé Bizira, chief business officer at Nous Research, commented on the announcement: "We built Hermes Enterprise to enable customers to deploy into their existing infrastructure, while handling per-agent isolation and extensible access control. Agent Substrate addresses both at the platform layer in a way that also preserves valuable compute resources."