By ByteBot
Google just turned the infrastructure it runs its own Gemini agents on into a cloud service — and the most important design choice is the one that sounds counterintuitive at first: your agent’s credentials are never inside the sandbox. Agent Compute Engine, announced October 22 at AGNTCon + MCPCon, gives every AI agent a dedicated hardware-isolated microVM that boots in container-class time, suspends when idle, and by design holds zero long-lived credentials.
The Problem With Every Existing Option
Running AI agents at scale puts you in an uncomfortable position. Containers are fast and dense, but they share the host kernel — a compromised container can attack the process sitting next to it. Traditional virtual machines give you real isolation, but they take seconds to spin up, waste resources while idle, and cap how many agents you can fit per server. AI agents, which typically burst through work and then pause, need something neither option was designed for.
Agent Compute Engine’s answer is a microVM using Cloud Hypervisor — a Rust-based hypervisor designed to be minimal. Each agent gets its own guest kernel and root access inside a hardware-isolation boundary. Boot time is around 125ms, roughly container speed. When an agent idles, its VM suspends automatically and releases the machine for others. Google claims 10x agent density per server compared to standard VMs, and at a test scale of 200,000 concurrent agents, suspend and resume completed in under 500 milliseconds.
Credentials Live Outside the Box
This is the part that deserves close attention. A microVM running in Agent Compute Engine holds no user credentials, no API keys, no OAuth refresh tokens, and no service account keys — in memory or on disk. The sandbox never receives them.
When the agent needs to call an external service, traffic flows out through a virtio-vsock interface to a local mediation proxy, then to Agent Gateway. The Gateway checks the agent’s SPIFFE workload identity and a hardware attestation from Google’s Titan silicon. If both pass, it performs an in-flight token swap: it inserts the real backend credential onto the wire between the agent and the destination. The agent makes the call. The agent never sees what authenticated it.
That design addresses the dominant AI agent attack pattern of 2026. The most common playbook is: compromise the agent, pull credentials out of memory or environment variables, then move laterally into databases or cloud accounts. Agent Compute Engine’s architecture makes that first exfiltration step structurally much harder. A hijacked agent finds nothing worth stealing inside its own sandbox.
The Threat Context That Makes This Necessary
Between 65% and 88% of organizations reported AI agent security incidents in the prior year, depending on which survey you read. Credential exfiltration shows up in the documented cases repeatedly: the Langflow remote code execution that leaked secret keys, a flaw in the MCP Python SDK that let malicious servers redirect OAuth exchanges to steal client credentials, an Amazon Bedrock vulnerability where a single prompt yielded credentials for every agent in the account. These are not theoretical.
Agent Compute Engine does not solve prompt injection. An attacker who can control the agent’s inputs can still make it do things you did not intend. What the architecture removes is the consequence when that happens: the agent being corrupted cannot hand over your production database credentials, because it never had them. Read the State of AI Agent Security 2026 report for the full incident breakdown.
How It Compares
The broader isolation landscape for reference:
| Technology | Boot time | Kernel isolation | Credentials in sandbox? |
|---|---|---|---|
| Containers | ~50ms | None (shared host kernel) | Yes, by default |
| gVisor | 200–600ms | Partial (user-space kernel) | Yes, by default |
| Firecracker | ~125ms | Full (own guest kernel) | Yes, by default |
| Agent Compute Engine | ~125ms | Full + Titan attestation | No — by design |
The last column is the differentiator. Firecracker gives you comparable isolation and boot speed, but you still have to build credential management on top. Agent Compute Engine packages that as part of the service.
Status: Not Yet Available
Agent Compute Engine is in use internally at Google — it runs Gemini agents for Workspace tasks, Antigravity, and internal model-evaluation pipelines — but it is not publicly available yet. Google announced a preview “in the coming months” with no GA date or pricing published. The official announcement is on the Google Cloud blog, with a separate technical deep dive covering the full architecture.
What you can do now: audit which long-lived credentials are passing directly into your agent processes. If you are self-hosting, Firecracker and Kata Containers give you the microVM isolation layer, and you can implement credential injection via a sidecar proxy without waiting for this service. Northflank’s 2026 agent sandboxing guide covers the self-hosted implementation path in detail. The pattern Agent Compute Engine embodies is not proprietary — it is just not packaged anywhere else yet.
