Google now gives every agent its own microVM. The decision is whether you integrate it or rent it

# Google just productised agent isolation. The hard part is the invoice.

On 22 October 2026, at the Linux Foundation's AGNTCon + MCPCon in San Jose, Google Cloud announced Agent Compute Engine: a managed compute service that gives every AI agent its own hardware-isolated microVM, with its own guest kernel and its own root privileges inside that boundary. A customer preview is promised for later in the year. Nothing is generally available yet.

That announcement matters less for what it is than for what it proves. For eighteen months, the industry's answer to "how do we run agent-generated code safely" was a container with a network policy and a credential injected into the environment. Google has now put a named, billable, cloud product behind the stronger version of that answer, and it has said out loud how it works: the microVM holds nothing worth stealing.

That is a real engineering position, and it is the one most vendors will now be measured against. It is also, at this moment, an incomplete commercial proposition, because Google has published no price, no regions, no API surface and no boot-time figure. So the decision in front of a platform team in late October 2026 is not whether isolation matters. It is whether you are about to standardise on a vendor's model of agent sessions, sessions, checkpoints and identity, at a moment when not one of the numbers that determine your unit economics exist yet.

What was actually announced

The architecture described in the launch post and the technical deep dive has four moving parts, and it is worth reading them precisely, because the marketing summary compresses away the two that matter most for a security review.

The first is the isolation boundary itself. Each agent session runs in a single-tenant microVM behind a hardware-isolated Cloud Hypervisor boundary. Hosts are stateless appliances whose root filesystem is read-only, enforced with dm-verity. Attestation keys live in Google's Titanium offload infrastructure processing unit, outside the guest. The design rule Google states in the deep dive is unambiguous: assume an attacker controls everything inside the sandbox and make sure they find nothing there to use.

The second is the network. This is the part most people skim and most people should not. The microVM has no standard network interface, no default gateway and no direct VPC access. All traffic crosses a virtio-vsock boundary to a local proxy and then out to an external gateway. No interface is not the same thing as a locked-down interface. An agent that manages to inject hostile instructions does not have a lateral route to your project assets, because there is no route. That is an architectural property rather than a firewall rule someone can relax under deadline pressure.

The third is identity and credentials, split across three governance components. Agent Gateway is positioned as the air traffic controller for traffic between clients and agents, carrying policies for sensitive data protection, agent attack protection and semantic governance, plus the ability to bring your own policy. Agent Registry is the central source of truth for which agents, tools, MCP servers, skills, models and endpoints are approved. Agent Identity assigns each agent a unique SPIFFE-based identifier that acts as a digital signature for authentication, authorisation and audit.

The fourth is efficiency. MicroVMs boot quickly, share memory through copy-on-write over a single OS template, and each carries its own Hyperdisk so an agent can keep its workspace and its context across long-running sessions. When an agent finishes a tool call and enters the thinking phase of the agent loop, the microVM signals idle and the host moves it from active to idle through fast checkpoint and restore.

The number that is missing, and the number that belongs to something else

Here is where a procurement conversation can go badly wrong, so it is worth being pedantic about it.

Google has not published a price. Nor a SKU or billing unit, nor a version number, nor a list of regions, nor CPU and memory limits, nor quotas, nor an API or SDK surface, nor a boot time, nor a density figure for the managed service, nor even a named product lead. On the managed platform's density, the only statement on the record is that it hosts orders of magnitude more live microVMs per node than conventional virtual machines. Without a number attached, that is a marketing claim, not a capacity plan.

Worse, the numbers that circulate widely are not this service's numbers. The 10x compute density, the 500 activations per second, the sub-500ms suspend and resume, the 200,000-agent benchmark and the 1,000-plus dormant agents per host are all real, and all belong to Agent Substrate. Agent Substrate is the open-source, Kubernetes-native sibling of Agent Compute Engine, available on GKE since 15 September 2026. It is a secure-by-default agent execution runtime offering Cloud Hypervisor microVMs or gVisor sandboxes, with egress proxies that enforce granular network policy and inject credentials outside the reach of agents themselves. Google states that it works with any harness and names Claude Code, OpenClaw and Hermes. It is open to all GKE customers for non-production workloads, with production support gated behind an allowlist.

It is entirely possible that the managed service inherits the same internals. It is also entirely possible it does not, and right now nobody outside Google knows. Budgeting on those figures as if they priced the managed product is a one-directional error.

One more trap. A Gemini platform pricing page has been reported to list an "Agent Compute" meter with a 50-hour monthly free allowance and published rates of $0.085 per vCPU-hour and $0.009 per GiB-hour of memory. That is a single-source reading. Nothing confirms the meter belongs to Agent Compute Engine, and the sensible commercial instruction is to treat it as noise until Google puts a price on the record.

The competitive field is now crowded, and the comparison that matters is not the logo

Three years ago, agent sandboxing was an implementation detail. It is now a product line with a reference architecture, and the vendors are clear about where they sit.

AWS offers Bedrock AgentCore Runtime with a dedicated microVM per session, an eight-hour maximum session length, per-second billing that typically skips I/O wait, and availability across 38 listed regions. Microsoft offers dynamic sessions built on a Hyper-V sandbox per session, ephemeral and destroyed after a configurable cooldown. E2B runs Firecracker microVMs with a snapshot on pause and roughly a one-second resume. Around them sit Vercel Sandbox, Cloudflare Sandbox SDK, Modal, Daytona and NVIDIA's OpenShell policy runtime. The venture money confirms the market: E2B has started more than a billion sandboxes and reaches 94% of the Fortune 100, Modal raised $355M at a $4.65B valuation, and Daytona took a $24M Series A with Datadog and Figma Ventures participating.

But the logo is the least important axis. The technical taxonomy is short and decisive. Firecracker-class microVMs give hardware-level separation and boot in under 200 milliseconds. gVisor intercepts system calls in user space above a shared host kernel, trading some isolation depth for faster custom-image starts. Shared-kernel containers are the fastest and the weakest against a genuine sandbox escape. One comparative analysis of agent infrastructure platforms puts it plainly: isolation technology is the core decision, and almost everything else follows from it, because it determines how much damage a sandbox escape can do, how fast a session can start, and what the provider is permitted to charge for.

There is a useful four-frontier test floating around vendor comparisons, and it is worth adopting regardless of who you buy from. Isolating an agent workload takes four independent boundaries at once: per-agent compute sandboxing, default-deny egress, a per-tenant namespace or VPC, and credentials scoped to a single run. Three out of four is not isolation. That is an unusually crisp way to describe the gap between what most teams actually run today and what Google has just put on the roadmap.

Two days before the keynote, the industry got a proof of concept it did not want

There is a timing problem with this announcement that almost nobody in the press noticed.

On 20 October 2026, two days before AGNTCon, researchers from Pwn.ai published PwnEscape, tracked as CVE-2026-99999, in the context of a $1M challenge to break Vercel's sandbox platform. The flaw was not in the KVM hypervisor. It was in the Linux host kernel's networking stack: checksum offload lets guest-controlled metadata modify an IPv4 header that the host had already validated, and the subsequent fragmentation step copies bytes beyond the valid data. The researchers demonstrated host memory disclosure against production sandboxes, and separately achieved root-level code execution on systems they controlled. Patches shipped upstream through a commit authored by a Red Hat engineer, with distribution packages following.

The lesson is not that Vercel is unsafe. The lesson is that "the agent runs in an isolated sandbox" is a claim that has to be audited, not a property you inherit. A hypervisor can be flawless while the host remains the attack surface, because KVM lives inside the Linux kernel. When Google says its microVM is separated by hardware with Titanium holding attestation keys outside the guest, the reasonable next question is not whether that is true. It is what breaks when the host is the target.

That question is also the strongest argument for the managed service. If your isolation depends on your own kernel patching discipline across every node in a fleet you operate, your isolation is a treadmill you pay to keep running. If it depends on a provider's fleet and a provider's patch cadence, it is a vendor dependency you need to price. Both are legitimate positions. Most teams have not decided which one they are in.

What to write down before the preview opens

You cannot plan a pilot with this information, and it is better to say so plainly than to fill the gaps with plausible numbers. What you can do is fix the terms of the decision now, because the preview is exactly the window in which architectural commitments get made without anyone having looked at a bill.

Start by writing your own four-frontier matrix. For every candidate, including the stack you already run, note which frontier the provider covers, which you cover yourself, and which nobody covers. That third column is the one that will hurt. The most common finding will not be a bad vendor. It will be a shared container with default-deny egress and long-lived credentials injected into the container, which is the default pattern of most agent orchestration written in the last two years.

Then measure idle cost before someone charges you for it. The difference between billing only active CPU and billing wall-clock time moves real cost by a factor of two to five on identical workloads, and agent checkpoint policy is precisely what determines that bill. If your agent spends most of its wall-clock time thinking, you are paying, or about to pay, for a machine that is doing nothing. Google claims idle microVMs checkpoint to zero active resources and resume from snapshot. The number you need is the cost of an idle minute, and you do not have it yet.

Separate the data residency question from the credential question. The zero-secrets model means your agent holds nothing, which is excellent, but it also means the actual authority lives in a gateway outside your VPC. Your compliance question stops being what can my agent read and becomes what does the gateway that swaps my credentials see and log. With no regions published, residency is not plannable, so ask for it in writing before you commit.

Finally, price the exit. If you adopt a provider's model of session, identity and checkpoint, every line of your platform that depends on it becomes migration debt. The alternative is not writing your own hypervisor. It is using the entry point Google has just opened with Agent Substrate, which is open source, runs on any Kubernetes cluster, is portable, and works with the harnesses your developers already use. You can start there today, without waiting for the preview, and decide later whether the managed service saves you money or chains you to it.

The takeaway

Google has done the thing the rest of the industry had been avoiding saying out loud: agent isolation is now a managed, purchasable product with a microVM per session and the hardest design rule in the category, which is that there is nothing inside worth stealing.

The part to read with a magnifying glass is the other half: the service is not available, has no price, no regions, no published API, and the numbers being quoted belong to a different product. The part to prepare is the third one. When the preview arrives, the conversation will be about the cost of an agent-hour, and the only way that conversation does not surprise you is if your frontier matrix and your idle-cost model are already written down before it starts.

Isolation has stopped being an engineering problem and become a commercial commitment. The good news is that you can now buy it. The warning is that you still cannot budget it.