Google launches Agent Compute Engine as managed service for AI agent infrastructure

The infrastructure powering Google's Gemini agents will soon become available to Google Cloud users through a preview program. Unveiled Thursday at the Linux Foundation's AGNTCon+MCPCon conference in San Jose, Agent Compute Engine assigns each AI agent its own hardware-isolated microVM, merging container speed with sandbox-level security. The preview will roll out to Google Cloud users later this year.

Competitive landscape for agent sandboxes

Agent sandboxing is not a novel concept. Startups E2B and Daytona both provide sandbox solutions to developers across any cloud platform. AWS offers similar capabilities through Bedrock AgentCore.

E2B operates each sandbox using Firecracker microVMs, an open source virtualization layer that AWS originally developed for Lambda. Sandboxes can be paused with memory and filesystem preserved, then restarted in approximately one second. Daytona began with container-based sandboxes but introduced microVM options in July, enabling users to pause entire machines or duplicate running instances.

AWS's AgentCore assigns every agent session its own microVM. The service does not charge for CPU cycles while agents wait for model or tool responses, though memory incurs charges until the runtime releases it. Sessions are capped at eight hours, though AWS expanded this in August by adding EC2-based runtime instances that maintain shared sessions for up to 14 days.

Google itself has prior experience in this space. GKE already provides a managed implementation of Agent Sandbox, the open source Kubernetes initiative Google introduced in November. The company also offers code-execution and computer-use sandboxes via its Gemini Enterprise Agent Platform.

Agent Compute Engine originated as internal infrastructure serving Gemini, Antigravity, and Google's model training systems.

Google's approach to agent infrastructure

Few organizations operate agentic workloads at Google's scale, whether for internal purposes or customer deployments. According to Google, agentic workloads have rapidly emerged as among the fastest-growing consumers of compute and storage across its infrastructure.

At this magnitude, infrastructure supporting autonomous agents must deliver efficiency, scalability, and critically, security. Google recognized the need for a purpose-built compute service designed specifically for agents, similar to how the company developed Borg—which later influenced Kubernetes—to manage compute resources in its early data centers.

As distinguished engineers Rohit Jnagal and Ramanathan Venkatapathy explain in a technical analysis, conventional VMs grant developers substantial control and flexibility but sacrifice performance during boot, suspension, and resumption cycles. Given agent startup and shutdown speeds, this tradeoff is unacceptable.

Containers address some limitations, yet Jnagal and Venkatapathy note that "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." Agent Compute Engine returns to fundamental principles to construct "a unified, agent compute platform for Google" and now its customers.

Persistent sandboxed computing for agents

The core concept provides each agent with a persistent, isolated computer environment. This enables agents to execute shell scripts, operate headless browsers, and run code with root access within agent loops spanning weeks.

The platform also accommodates large-scale scenarios including evaluation loops used by frontier labs to benchmark models, AI performance testing, and reinforcement learning workflows. Additionally, Agent Compute Engine runs sandboxed backends for Google's internal services.

Jnagal and Venkatapathy observe that agents typically spend most time idle, waiting for model responses or user input. When an agent completes a tool call, the host checkpoints its microVM, which consumes no active resources until the next request arrives.

Security through isolation and encryption

Beyond performance, the critical capability is ensuring agents cannot escape their sandboxes. Each agent session operates within a single-tenant, memory-safe microVM containing no 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 uses end-to-end encryption in transit, and snapshots and disks employ encryption at rest.

MicroVMs lack standard network interfaces. All traffic routes through an external proxy, and when agents need to access services like Google Drive, the Agent Gateway validates user delegation and sandbox identity before injecting actual credentials outside the sandbox.

The underlying host functions 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. MicroVMs 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 enterprise agent managing a user's inbox that encounters an email containing hidden instructions to locate API keys and transmit them externally. While models typically ignore such instructions, not always. "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 for Kubernetes deployments

Not all teams will prefer running agents in a managed Google service. For these organizations, Google provides Agent Substrate, an open source runtime for Google Kubernetes Engine (GKE) first announced in May.

Substrate builds upon Agent Sandbox, Google's Kubernetes project, and incorporates a lightweight control plane capable of handling millions of short-lived tool calls that would overwhelm standard Kubernetes.

Like Agent Compute Engine, Substrate snapshots idle agent memory and returns machines to the pool until agents receive additional work. Google reports this approach achieves up to 10 times greater density than traditional 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 microVMs or gVisor, and every agent receives its own cryptographic identity. Similar to Agent Compute Engine, egress proxies attach credentials outside the sandbox. Substrate operates on any Kubernetes cluster and works with any harness, including Claude Code, OpenClaw, and Nous Research's Hermes.

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