Google Agent Compute Engine: One Isolated MicroVM for Every AI Agent

Google Cloud announced Agent Compute Engine on October 22, 2026. The service gives each agent session a dedicated, hardware-isolated microVM and keeps credentials outside the sandbox. It already powers Gemini's agent workloads internally. For customers, it remains an announced preview: Google has not published pricing, quotas, session limits, boot or resume latency, or a specific preview date.

Key takeaways

• One microVM per agent session. Each session runs in a single-tenant microVM with its own guest kernel, root access and persistent disk, per Google Cloud Launches Agent Compute Engine: A MicroVM per AI Agent.
• No credentials live inside the sandbox. The agent holds only a short-lived identity token; a gateway swaps in the real backend credential in flight, after policy checks, per the same technical breakdown.
• Idle agents are checkpointed to zero. When an agent waits, its microVM pauses and stops consuming active resources, then resumes from a snapshot on the next call.
• The open-source sibling is testable today. Agent Substrate, the Kubernetes-native counterpart, is available for non-production use, with published figures of 500 activations per second and suspend/resume under 500 milliseconds in a 200,000-agent test.

What Google actually built

Agent Compute Engine splits every agent into two parts. The harness — the "brain" that calls the model — runs fully outside the sandbox. The sandbox — the "hands" that run code, shell commands and browsers — sits inside the microVM, and the harness dispatches explicit commands into it, per Google Cloud Launches Agent Compute Engine: A MicroVM per AI Agent. The service already powers Gemini, Antigravity, and internal evaluation and reinforcement-learning pipelines, per the same report.

The trade-off Google is solving is familiar to anyone who has run agent workloads. A traditional virtual machine isolates well but takes seconds to minutes to start, pause or resume. A container starts fast but shares the host kernel, which is a wide attack surface for code an agent wrote itself — or code a hostile page suggested to it. Reporting on the launch makes the same point plainly: an agent with root access in a poorly isolated environment is a risk to everything around it, per Google Cloud unveils Agent Compute Engine for AI agents. The microVM is the attempt to get VM-grade isolation at container-like speed and density.

Google says the service already runs Gemini's agents internally. That supports the claim that the architecture operates at production scale inside Google. It does not establish the customer experience, support model or cost. Customers still face an announced preview with no specific date: the service is expected to enter a preview phase in the coming months, per Google plans isolated virtual machines for Gemini agents.

No credentials inside the sandbox

The security design assumes the attacker already controls everything inside the sandbox. MicroVMs have no standard network interface, no default gateway and no direct access to the customer's private network. All traffic crosses to a local proxy and then to an external gateway. Guests receive only a session-scoped SPIFFE certificate and a short-lived identity token, and the gateway swaps in the real credential after policy checks — so a prompt-injected agent finds no secrets to steal, per Google Cloud Launches Agent Compute Engine: A MicroVM per AI Agent.

Google also splits identity into four separate parts: the user's identity, a delegated on-behalf-of grant stored outside the node, a short-lived workload identity that is the only one used for sandbox traffic, and the agent's own workforce identity. The workload identity is useless for direct calls if it leaks, because it only identifies which sandbox sent a packet, per the same technical breakdown. An independent walkthrough of the launch reaches the same conclusion about the credential design: inside the microVM there are no API keys, OAuth tokens or service account keys, in memory or on disk, per Google Unveils Agent Compute Engine, a microVM for Every AI Agent.

That is the pattern to take from this launch, whether or not you buy the service. Most agent deployments today do the opposite: they hand the agent a long-lived key and hope the prompt holds. Google's design starts from the opposite assumption — that the prompt will not always hold, so the environment should contain nothing worth taking.

Idle agents, density, and the open-source route in

Agents spend most of their time waiting — on models, on tools, on people. Agent Compute Engine signals when a tool call finishes, checkpoints the idle microVM to zero active resources, and resumes it on the next call. Density comes from copy-on-write memory sharing: pre-warmed snapshot images are shared across microVMs on a host, and only the pages an agent actually modifies consume private memory, per Google Cloud Launches Agent Compute Engine: A MicroVM per AI Agent.

The published performance numbers belong to the sibling product, and the distinction matters. Google presents Agent Substrate as available for non-production use on its managed Kubernetes service since September 15, 2026, offering microVM or gVisor sandboxes. Google reports up to 10x higher compute density than traditional compute, 500 activations per second at under 500 milliseconds suspend/resume in a 200,000-agent benchmark, and over 1,000 dormant agents per host, per the same MarkTechPost breakdown. It works with harnesses including Claude Code, OpenClaw and Hermes, is open to all managed-Kubernetes customers for non-production use, and reaches production only through an allowlist. A second analysis of the launch frames the same split for buyers: the managed service is still months from customer preview, but the open-source runtime lets teams start experimenting today, per Google Agent Compute Engine Gives AI Agents Secure VMs.

Two cautions belong on the record. First, the density and activation figures are vendor-reported benchmarks; the workload, host configuration and measurement point behind them have not been published, and no independent validation exists yet. Second, Agent Compute Engine itself has no published boot time, density figure, pricing or preview date. Anyone building a budget around it today is building around a gap.

Governance is the second half of the announcement

Google is extending its agent governance stack — gateway, registry, identity and OpenTelemetry-based observability — across Agent Runtime, Cloud Run, Agent Sandboxes, managed Kubernetes and Agent Compute Engine, per Google Cloud Launches Agent Compute Engine: A MicroVM per AI Agent. Token management, model routing, and delegated authorization through external identity providers are slated for preview this quarter. Two further pieces are described only as preview soon, with no quarter attached: enforcement points for hybrid and multi-platform setups, and governance for local coding agents running on managed devices, per the same report.

Read together, the two halves say the same thing. The runtime isolates what an agent can touch. The governance layer logs and traces its actions, attributes its cost, and identifies whose authority it acted under. Neither half is optional at fleet scale.

What this means for your business

Start with fit. This class of runtime matters most for agents that execute generated or untrusted code, operate a browser, run shell commands, or work with sensitive data under delegated authority. For a fixed workflow that calls approved APIs with deterministic inputs, a microVM per session may be more infrastructure than the risk justifies.

1. Audit where your agents' credentials live today. If an agent holds a long-lived API key, a stored OAuth token or a broad service account, treat credential placement as a primary design decision, not an implementation detail. Move credentials behind a gateway or proxy that swaps them in per call, scoped to the task, even on infrastructure you already own.

2. Price idle time, not just tokens. Agent costs include more than model tokens. Measure active compute, idle or checkpointed time, storage, gateway controls and observability — as one cost per completed task — before scaling a fleet.

3. Test the pattern now on the open-source runtime. Agent Substrate runs on any Kubernetes cluster for non-production use. Pilot one internal, code-executing workflow and record cold and warm start latency, resume failures, cost per completed task and operator effort. That teaches your team more about agent operations than any preview registration form.

4. Do not budget the managed service yet. There is no price, quota or date to plan against. Register interest if isolated sandboxes for untrusted code are a real requirement, but before any commitment, get written answers on the pricing model, quotas, session limits, boot and resume latency, data handling, log retention, identity scope, and the terms that will govern the move from preview to general availability. Keep production plans on infrastructure you can buy today.

5. Make identity, budgets and inventory a buying requirement now. Require a central inventory of approved agents, tools and models, a named owner for every agent, approval before deployment, periodic access review, a documented way to suspend or remove an agent, and an incident process for unauthorized tool use. Log every model call and tool use from day one, and require per-agent token tracking and budget caps in every agent procurement, from any vendor.

6. Price the exit before you enter. The managed stack is proprietary end to end — silicon, disk, gateway and registry are all one vendor's pieces, and the stronger the integration, the more expensive a later move becomes. The open-source runtime is the portability hedge. Decide in advance which parts of your agent stack must stay portable, and keep them there.

The direction is clear even while the price list is missing: isolation per agent, credentials held outside the sandbox, idle fleets checkpointed instead of billed, and governance that follows the agent wherever it runs. A business does not need this exact service to act on that. It needs the underlying controls in place before agent counts, permissions and spend outgrow manual review.

Want an independent review of where isolated agent runtimes, credential design and agent governance belong in your operation? Get a free AI audit — we'll map your highest-leverage automation opportunities in one session.