Google Agent Compute Engine: a hardware microVM per agent, zero credentials in the sandbox

Google Agent Compute Engine: a hardware microVM per agent, zero credentials in the sandbox

🔎 Gemini's plumbing becomes a product — and that's more important than a new model

On October 22, at AGNTCon+MCPCon, organized under the auspices of the Linux Foundation, Google Cloud announced Agent Compute Engine (ACE). Not a model, not a framework: the execution infrastructure that powers the Gemini and Antigravity agents internally, industrialized and sold as a service.

Why now? Because the agent bottleneck has changed. The question is no longer how to get an agent to work — it's how to run tens of thousands of them without a single one leaking an OAuth token, and without the bill exploding for processes that sleep 95% of the time waiting for a human or a trigger.

This is exactly the problem Google claims to solve, with aggressive figures: resuming a suspended agent in under 500 ms, more than 1,000 dormant agents per host, 500 activations per second across a fleet of 200,000 agents. Vendor figures, to be taken as such — but the architecture itself holds up in the technical details.

One honest caveat remains: this is an announcement, not a general availability. Preview "in the coming months," no published pricing, no cold-start figures. What we know comes from Google Cloud's official announcement, a technical deep dive, and an analysis by The New Stack. Let's dissect what's solid, and what isn't yet.

The essentials

• A hardware-isolated microVM per agent: each agent runs in its own lightweight virtual machine with no standard network interface — all egress traffic goes through a virtio-vsock channel and then a proxy.
• Zero secrets in the sandbox: no OAuth token, no service key inside the microVM. Credentials are injected outside the sandbox by the Agent Gateway, via an in-flight token swap.
• Four agent identities: user, delegation, workload (SPIFFE), and workforce — an identity model designed for the enterprise, not for the demo.
• Pause/checkpoint with zero active resources: an idle agent is frozen, its memory shared via copy-on-write + DAX for a claimed 10x higher density.
• An open source twin: Agent Substrate, the Kubernetes version of the system, available on GKE since September 15 and compatible with Claude Code, OpenClaw, and Hermes.
• Actual status: preview "in the coming months", no pricing, no GA. An industrial statement of intent, not a purchasable product.

Recommended Tools

What Google is Announcing — and What It Is Not

Google is announcing a managed agent execution service, which is not yet available. Agent Compute Engine exposes the primitives that Google uses internally for Gemini and Antigravity—the agent-first suite launched with Antigravity 2.0. This is the classic move of the giant: the tool that runs the house becomes a product.

The context of the announcement is important. AGNTCon+MCPCon is an event of the Linux Foundation, meaning it is the neutral ground where standards are negotiated. Announcing ACE there, rather than at a commercial conference, sends a signal: Google is playing the card of shared infrastructure, backed by an open-source twin.

What it is not: an available product. The official timeline is summarized in one phrase—preview "in the coming months." No pricing, no GA date, no cold start figures. My opinion: the published benchmarks focus on suspend/resume, never on the cold start. This silence is information.

Also worth noting: the announcement packages an extended "agent governance" component—traceability and execution policies—which complements the compute part. Logic dictates: a microVM per agent without governance is useless in an enterprise setting.

One microVM per agent, no network interface: the architecture dissected

Each agent runs in a microVM isolated at the hardware level, with no standard network interface. This is the most radical choice in the announcement, and the one that best captures Google's intent: treat an agent as an untrusted process, never as a trusted colleague.

Concretely: no classic virtual network card, no IP stack exposed to the guest. All outbound communication travels over virtio-vsock, a host-guest socket channel from the virtio standard, to a host-side proxy that decides what gets through. A compromised agent cannot open an arbitrary connection to the outside: every flow is mediated, logged, and filterable by policy.

The blast radius shrinks accordingly. An agent trapped by a prompt injection — the number one risk in production — stays confined within its microVM: no lateral movement, no internal scanning, no unauthorized outbound calls. Storage follows the same logic, with a dedicated Hyperdisk volume per microVM.

This isn't a Google whim; it's a deep-seated trend. Jensen Huang wants to lock AI agents inside containers, like browsers — the parallel is exact: we learned to isolate untrusted code coming from the web, and now we're going to learn to isolate semi-autonomous code that acts on your behalf. And the stakes rise another notch now that Google Research lets agents rewrite the system that surrounds them: when the agent can modify its own environment, hardware isolation stops being optional.

Transparency note: Google doesn't detail the hypervisor used behind these microVMs. The announced "hardware" isolation sets the bar above containerized sandboxes — that's Firecracker level or equivalent.

Zero secrets in the sandbox: token swapping in flight via the Agent Gateway

The microVM contains no credentials: no OAuth token, no service key, ever. Injection happens outside the sandbox, at call time, performed by the Agent Gateway. This is, in my view, the most important part of the announcement.

The problem being solved is well known to teams building agents. Today, you paste the GitHub token into an environment variable, the API key into the pod's secret manager — and the agent, if manipulated through a prompt injection, can read its own environment and exfiltrate whatever it contains. A secret inside the sandbox is a secret within the attacker's reach.

The ACE approach inverts the model. The agent runs with an anonymous internal identity, with no secrets at all. When it makes an outbound call, the request goes through the Agent Gateway, which performs a token swap in flight: it strips off the internal identity and attaches the real credential — OAuth token, service key — on the final hop, outside the microVM. The agent can't leak what it never possessed.

This model rests on four distinct agent identities, as presented by Google:

• User: the agent acts as the end user, with their permissions.
• Delegation: the agent acts on behalf of the user, with restricted and traceable scopes.
• Workload: the agent's own machine identity, following the SPIFFE standard, the open source reference for workload identities.
• Workforce: the agent's identity as a member of the organization, for internal enterprise agents.

Why this is foundational: the question "who did what?" has an answer by construction, and the exfiltration surface for secrets vanishes from the sandbox. Plenty of fodder for the debate on MCP server authentication, at the heart of MCPCon. Because today's frameworks — Claude Code, OpenClaw, a homegrown agent — nearly all place your tokens in the execution environment. The day your agents run 24/7 with write access, that detail becomes the red line between demo and production.

Pause, checkpoint, 10x density: the economics of the model

An idle agent is suspended with zero active resources, and Google claims 10x density thanks to copy-on-write memory. This is the piece that makes the model economically viable — and perhaps the hardest one to replicate.

The starting observation: an agent spends most of its life doing nothing. It waits for human approval, a trigger, the result of a tool. Hosted the traditional way, it consumes CPU and RAM during that wait. At the scale of thousands of agents, this is unsustainable.

ACE's answer: pause/checkpoint. The idle agent is frozen — memory captured, zero active resources — then resumed on demand. According to Google Cloud's deep dive, resumption takes less than 500 ms, with 500 activations per second measured across a fleet of 200,000 agents. And more than 1,000 dormant agents per host, made possible by two techniques: shared base memory in copy-on-write mode (dormant agents read the same pages, copying only happens on write) and DAX-style direct mapping, which avoids duplicating the reference memory image.

In other words: serverless for agents, but with VM-level isolation instead of a container. Billing will most likely follow active time — but Google hasn't published anything on pricing, I'll say it again.

Two journalistic caveats. One: these figures are vendor claims, measured on Google's own infrastructure, not a reproducible independent benchmark. Two: they cover resume, not the cold start of a fresh microVM — a data point absent from the posts, and yet decisive for event-triggered agents.

Agent Substrate: the open source twin that defuses lock-in

Google is also releasing Agent Substrate, the open Kubernetes version of the same system, available on GKE since September 15. In other words: the most interesting part of the announcement is already testable, without waiting for the ACE preview.

Substrate brings the same primitives to a Kubernetes cluster: one microVM per agent, pause/checkpoint, and the identity model. The announced compatibility is broad — the major agent runtimes are targeted, including Claude Code (which gets the most out of Claude Opus 4.7 or Claude Sonnet 4.6 depending on your needs), OpenClaw and Hermes. On the Hermes side, the ecosystem of extensions and plugins becomes directly executable on this type of infrastructure.

Why open-source the twin of your managed product? Because it neutralizes objection number one — lock-in — at the precise moment when AWS and Azure are moving onto the same ground. And because it fuels the standardization momentum driven by the Linux Foundation: if the primitives (identity, isolation, lifecycle) become common building blocks, Google sells operational excellence, not a cage.

For teams already self-hosting their agents — typically with local models via Ollama — Substrate is the realistic path to this isolation model without depending on Google's cloud. If you're starting from scratch, our guide to creating an AI agent covers the basics before tackling this level of infrastructure.

Facing AWS AgentCore, Azure dynamic sessions, and E2B: who brings what

Today, no one combines hardware isolation, zero secrets in the sandbox, and massive suspend/resume — but Google's numbers are promises, while AWS's are a GA product.

Quick take. AgentCore is the product to beat on maturity: GA, Bedrock integration, documented limits (8 hours per session microVM, instances up to 14 days). But credential management remains largely your responsibility — which is precisely where Google strikes.

Azure dynamic sessions excels in a different niche: spinning up a code sandbox in sub-second time for an interpreter or an MCP server. This is short-cycle disposable infrastructure, not long-lived agent hosting with enterprise identity.

E2B remains my default choice for prototyping: open source, excellent developer experience, Firecracker microVMs. But you handle the secrets problem yourself there — exactly what ACE claims to industrialize.

The honest verdict: Google's claimed lead is real on paper (credentials + pause/resume + density), but it's unverifiable as long as there's neither a public preview nor pricing. AWS has GA experience; Google may have the better architecture. The answer will be written at GA time — and at pricing time.

What it changes depending on your profile

Nothing today if you are not on GCP; much tomorrow if you are producing enterprise agents. The adoption timeline depends less on the technology and more on your current platform.

You are a company on GCP: test Agent Substrate on GKE right now; it has been available since September 15th. This is the best way to evaluate the ACE promise with your own workloads before the managed preview opens.

You are an AWS team: AgentCore Runtime is in GA and handles session isolation. Keep an eye on the ACE pricing upon release—the battle will be fought over the cost of a dormant agent and identity governance.

You are a solo developer or small team: E2B or self-hosted Substrate covers 90% of needs. For your experiments, a simple VPS is more than enough—Hostinger runs a monitoring agent for just a few euros per month. On the model side, free AI APIs allow you to test without a credit card, and our selection of the best LLMs for AI agents helps you choose the brain—from a generalist GPT-5.5 to a Claude Opus 4.7 for long reasoning.

You are a CISO or security architect: the four-identity model is the conversation to start now, even before the preview. Map which agents in your IT infrastructure act as who—user, delegation, workload, workforce—and you will have a head start when the tool arrives.

And to choose above the infrastructure: our comparison of the best autonomous AI agents scrutinizes the runtimes that will be running in these microVMs tomorrow.

❌ Common Mistakes

Mistake 1: Planning a migration based on an announcement

ACE has no pricing, no GA, no cold start figures. What's wrong: building a roadmap on a blog post. The solution: pilot Agent Substrate on GKE to validate the primitives, and keep ACE as a purchase option to evaluate when GA arrives.

Mistake 2: Believing the microVM replaces your governance

Hardware isolation and the token swap eliminate two classes of risk — lateral movement and secret exfiltration. Not the others. Authorization policies, action auditing, scope limiting in delegation: that's still your job. And don't import your tokens into the environment out of habit: the model only holds up if the sandbox stays empty.

Mistake 3: Comparing announcement benchmarks to production SLAs

The 500 ms resume and the 1,000 dormant agents per host are Google's numbers, measured on Google's fleet. They are not SLAs, and nothing indicates they will be contractual at preview. Benchmark on your own workloads, with your own models — an agent powered by Gemini 3.1 Pro doesn't have the same memory profile as a GPT-5.5 agent loaded with heavy tools.

❓ Frequently Asked Questions

When will Agent Compute Engine be available?

Google has announced a preview "in the coming months," with no GA date or access conditions. In the meantime, Agent Substrate — the open source twin — has been available on GKE since September 15. The two Google Cloud blog posts remain the reference sources for tracking the timeline.

What is the price of Agent Compute Engine?

No pricing was published at the announcement. We can expect billing based on active time — the pause/checkpoint feature points in that direction — as well as per vCPU, memory, and Hyperdisk storage, but that's speculation. Compare at GA time with AgentCore's usage-based billing, and verify on cloud.google.com.

Does Agent Substrate replace Agent Compute Engine?

No, they are two faces of the same system. Substrate is the open source version on Kubernetes, which you operate yourself on GKE or elsewhere. ACE is the managed service, with Google's scale optimizations (10x density, activations per second). Substrate for control, ACE for delegating operations.

Is it compatible with Claude Code, OpenClaw or Hermes?

Agent Substrate claims compatibility with all three runtimes, making it possible to run agents powered by Claude Opus 4.7, GPT-5.5, or a local model in isolated microVMs. For ACE, Google has only shown its own stack — third-party runtime compatibility remains to be confirmed at the preview.

Should you leave AWS AgentCore for ACE?

No, not today. AgentCore is in GA with clear limits (sessions up to 8 hours per microVM, instances up to 14 days) and full AWS integration. ACE is a promising architecture but unavailable and without pricing. Re-evaluate at GA, with your real numbers of dormant agents.

✅ Conclusion

Google has just said out loud what the agent industry has been whispering for months: the battle is being fought in the infrastructure—hardware isolation, zero secrets, agents that sleep without costing a penny—and not in another benchmark point. The Agent Compute Engine architecture is the most mature ever publicly presented; the product, however, is yet to be born. While waiting for the preview, test Agent Substrate on GKE—it is the only piece of this announcement you can touch today.