Google Gives Every AI Agent Its Own Keyless MicroVM

Every serious agent platform eventually hits the same wall: an agent needs a computer to act on, but the moment you give a model root access to a real machine, you have handed an unpredictable process a set of credentials. Google spent the last year solving that for Gemini at planetary scale, and on October 22 at AGNTCon + MCPCon it packaged the result as Agent Compute Engine, a service that gives each agent its own hardware-isolated microVM and, crucially, no secrets to steal. It lands in preview in the coming months. The architecture matters more than the launch.

What Google actually shipped

Agent Compute Engine is not a new VM size or a sandbox wrapper. Google built it as a unified runtime shared by four very different workloads: interactive consumer and enterprise chat agents that write and execute code, autonomous software engineering workspaces that keep root access and compilers alive for weeks, massive evaluation and reinforcement learning sweeps that fork thousands of parallel environments, and lightweight sandbox backends for internal Google services. The common abstraction is a microVM per agent session, with container-like boot speed and a hardware isolation boundary enforced by Cloud Hypervisor, including its own guest kernel and root.

The silicon underneath is the interesting part. Google runs the fleet on Titanium, its offload infrastructure processing unit, so attestation keys never exist inside the guest. Hosts are stateless appliances with read-only root filesystems verified through dm-verity, and blocking storage attachments are hardware-mediated with instance-bound cryptographic grants, meaning a compromised sandbox or a compromised host OS cannot mount volumes across tenant boundaries. Each microVM also gets a Hyperdisk, so an agent's workspace and context survive between turns, days and OS versions.

For teams that already live on Kubernetes, Google ships the same idea as Agent Substrate, an open-source runtime on GKE. It runs on any cluster, works with any harness including Claude Code, OpenClaw and Hermes, and in Google's 200,000-agent benchmark sustained 500 suspend and resume activations per second at under 500 ms latency with roughly 10x the compute density of traditional container runtimes.

The sandbox that holds no credentials

The design rule Google states outright is worth stealing: assume an attacker controls everything inside the sandbox and make sure there is nothing there to use. That inverts the usual agent security posture, which leans on system prompts and model goodwill to ignore a malicious instruction hidden in an email or a web page.

Inside an Agent Compute Engine microVM there are no OAuth refresh tokens, no API keys, no service account keys and no access to the instance metadata server. The guest gets only an ephemeral, session-scoped SPIFFE certificate and a short-lived identity token delivered through a dedicated per-VM listener. The microVM has no standard network interface and no default gateway; all traffic crosses a point-to-point virtio-vsock boundary into an unprivileged local proxy, then out to a gateway that validates policy before anything reaches the network.

That gateway performs what Google calls an in-flight token swap: it verifies the user's delegated grant, the agent's attested workload identity and the node identity, evaluates egress and data-loss policies, and only then inserts the backend credential on the wire. Google separates four identities, a user identity, a delegated on-behalf-of grant, an agent workload identity and an agent workforce identity, and keeps the long-lived grants off the compute node entirely. An exfiltrated sandbox identity is useless for calling an API directly, because its only job is to prove which sandbox a packet came from.

This is the same problem 1Password attacked from the other end this week with agent sign-in that never exposes a password, and the fact that both arrived within days says the industry has stopped treating credential exposure as a prompting problem and started treating it as an architecture problem.

The idle problem nobody budgets for

Google measured its own fleet and found that agents spend most of their lives waiting, on the model, on the user, on a tool. Only a small fraction of open sessions were running code at any moment. Billing reserved CPU and memory for every open session would have made the product uneconomic, so the team co-designed the sandbox command runtime with the host executor to give the infrastructure application awareness.

When an agent finishes a tool call and enters the thinking phase, the sandbox signals that nothing is in flight and the host checkpoints it into an idle state that consumes zero active resources, then restores it on the next call. Google pairs that with pre-warmed snapshot images mapped into physical memory using DAX and copy-on-write clones, so hundreds of agents on one host share the exact same physical pages for the base OS, Python runtime and browser, allocating memory only for the private delta each agent modifies. The company also spreads the load in time, steering flexible work such as nightly evaluation sweeps and background research into the troughs between consumer morning and evening peaks and enterprise business hours.

The honest caveat: none of this is measurable from outside yet. Google published activation benchmarks for Agent Substrate but no pricing, no latency distribution for representative agent loops and no independent third-party numbers for Agent Compute Engine. Preview timing is "the coming months", which in Google Cloud practice has meant anywhere from one quarter to three.

What it means for builders

If you run agents in production, three patterns from this design are worth copying regardless of which cloud you use. First, decouple the harness from the sandbox and make the sandbox the only place untrusted code runs, with egress forced through a proxy that injects credentials after policy evaluation; that single change neutralises most prompt-injection-to-exfiltration chains. Second, give every agent a short-lived, cryptographically attested workload identity such as SPIFFE instead of shared API keys, and keep delegated user grants in a central authorization service rather than on the machine. Third, treat idle as the default state: if your runtime bills a full container for every open session, your unit economics will break the moment sessions get long and conversational.

The strategic read is that per-agent compute is consolidating fast. Daytona raised $60 million this week on the thesis of a computer behind every agent, and now the largest cloud provider is shipping the same primitive with silicon-rooted isolation and an identity model attached. For platform teams the practical decision is no longer whether agents get isolated sandboxes, but whether those sandboxes are keyless, attributable and cheap when idle.

What to watch

Watch for Agent Compute Engine pricing and regional availability at preview, since cost per idle agent decides whether always-on personal agents are a product or a demo. Watch whether the zero-secrets model extends to local coding agents on developer laptops, where Google has promised OS-level sandboxing and governance for tools like Claude Code and Antigravity CLI. And watch whether Agent Substrate's open-source runtime becomes a de facto standard the way Kubernetes did, because if it does, the isolation and credential-injection patterns Google documented here will show up in every agent framework within a year.