BENGALURU, India — October 25, 2026, 5:00 PM IST — Google Cloud has introduced Agent Compute Engine, a purpose-built service that gives each AI agent a persistent, hardware-isolated microVM, while expanding identity, policy and observability controls across agent runtimes.
The launch moves a difficult production problem into the cloud infrastructure layer. Coding agents, browser operators and workflow agents need computers that can execute untrusted code, retain work between sessions and reach business systems. Conventional containers start quickly but share a host kernel; dedicated virtual machines offer a stronger boundary but are slower and expensive to keep alive while an agent waits.
For developers and platform teams, the important development is not a new model. It is Google’s attempt to make the execution environment, identity boundary and network policy as explicit as the model endpoint. That matters as organizations move from short prompts to agents that run shell commands, call tools and act asynchronously.
What Google announced
According to Google Cloud’s October 22 announcement, Agent Compute Engine already supports Gemini agent workloads inside Google and is targeted for customer preview in the coming months. Google has not announced general availability, pricing or a service-level agreement, so teams cannot yet treat it as a production service they can buy today.
Each session runs in a dedicated microVM with its own guest kernel and root access. Google says the design uses its Titan and Titanium infrastructure for hardware-rooted trust, keeps long-lived credentials outside the guest, and routes network traffic through external mediation rather than giving the sandbox a standard network interface.
The service separates the trusted agent harness from the execution sandbox. The harness decides what action to take; the sandbox performs code execution, browser work or shell commands. An ephemeral SPIFFE-based workload identity identifies the microVM, while Agent Gateway validates the user delegation, agent identity, node identity and policy before inserting the required backend credential into outbound traffic.
That design does not make an agent safe by itself. Prompt injection, excessive authorization and harmful tool choices remain application risks. It does reduce the damage available inside a compromised sandbox because persistent API keys and refresh tokens are not meant to be present there.
Checkpointing targets the cost of waiting
Agent workloads are unusually idle. A sandbox may wait for a model response, an external API or a human decision while still holding a filesystem and process state that will be needed on the next step. Reserving a full VM throughout that pause wastes capacity; destroying the environment forces a costly rebuild.
Google’s technical deep dive says Agent Compute Engine detects when no commands or background tasks are active, checkpoints the microVM, and returns its active resources to the host. Pre-warmed images and copy-on-write memory let multiple microVMs share unchanged operating-system and runtime pages, while persistent workspaces retain user data on Hyperdisk.
The architecture also supports snapshot, fork, rewind and rollback operations. Those primitives could be useful for parallel coding experiments, evaluation runs and reinforcement-learning environments, but Google has not published customer-facing prices or independently verified comparisons. Cost benefits will depend on duty cycle, restore behavior, storage and network use.
An open Kubernetes path remains available
For teams that want control or multi-cloud portability, Google is also highlighting Agent Substrate, an open-source Kubernetes runtime that can use microVM or gVisor isolation. Google says it works on any Kubernetes cluster and supports agent harnesses including Claude Code, OpenClaw and Hermes.
In Google-run validation involving 200,000 agents, Agent Substrate sustained 500 activations per second with suspend and resume latency below 500 milliseconds, while delivering up to ten times the compute density of traditional approaches. Those are vendor-reported benchmark figures, not guarantees for arbitrary clusters. Storage, image size, kernel choice, scheduling pressure and network policy can materially change the result.
GravityDevOps previously examined Google’s earlier GKE agent sandbox cost tests. The new announcement broadens that work: Agent Substrate provides the open Kubernetes path, while Agent Compute Engine packages a related execution model into a managed Google Cloud service and connects it to a wider governance plane.
Governance expands beyond one runtime
Google is extending Agent Gateway, Agent Registry, Agent Identity and OpenTelemetry-compatible agent observability across Cloud Run, GKE, Agent Runtime, Agent Sandboxes and the forthcoming Agent Compute Engine. Cross-cloud policy enforcement through Envoy-based points and governance for local coding agents are described as coming previews.
The company also plans token and cost governance, model-routing policies, service extensions and delegated authorization integrations this quarter. These features remain preview commitments rather than generally available controls. Platform teams should verify current product status instead of designing production requirements around the announcement alone.
The practical pattern is still useful: give every agent a distinct workload identity, keep credentials out of the execution environment, mediate egress, log every model and tool hop, and bind actions to the human or service that delegated authority. Those controls fit the broader discipline described in GravityDevOps’ guides to AI agent security and LLMOps.
What platform teams should do now
Teams do not need to wait for the preview to test the operating model. They can inventory which agents execute untrusted code, identify where secrets enter sandboxes, map all outbound destinations, and confirm that user delegation and workload identity appear in audit logs. Long-running agents should also be classified by latency objective and idle duty cycle before checkpointing is treated as a cost strategy.
Any evaluation should compare isolation strength, resume time, persistent-storage behavior, image maintenance, telemetry coverage and failure recovery. A container, gVisor sandbox and microVM are not interchangeable security boundaries, and the right choice depends on the code being executed and the assets an agent can reach.
Agent Compute Engine is therefore best read as a direction of travel, not a finished procurement decision. Google has confirmed the architecture and preview plan, and the open-source Agent Substrate code is available now. Pricing, customer availability and real-world performance remain open questions. The larger signal is clear: as agents gain durable state and authority, their runtime is becoming a first-class platform and security concern.
Sources
Primary sources include Google Cloud’s launch announcement, its Agent Compute Engine architecture deep dive, the Agent Substrate overview, and the open-source repository. Independent context on availability, lock-in and missing commercial details came from InfoWorld.
