Google Agent Compute Engine: One microVM per Agent

Title

Google Agent Compute Engine: One microVM per Agent

Meta Description

Google's Agent Compute Engine gives each AI Agent its own isolated microVM with no stored credentials. This article breaks down its isolation design and credential management approach, sorts out what has and hasn't been disclosed, and offers three practices builders can adopt right away.

Article Content

Google recently put forward an infrastructure方案 for AI Agent runtimes—the Agent Compute Engine (ACE for short)—and its core idea is blunt: each Agent gets its own dedicated microVM, and no credentials are stored inside the VM. This design targets the two thorniest problems in current Agent deployment: isolation and key management.

Why do Agents need dedicated microVMs?

Most Agent frameworks today run in shared containers or processes, where tool calls, code execution, and external API access all happen in the same environment. Once an Agent is compromised via prompt injection, an attacker may gain not just control of that Agent but also the tokens left behind in the environment, the environment variables, and the data of neighboring Agents.

ACE's solution is to push isolation down to the hardware virtualization layer. microVMs (such as Firecracker and similar lightweight VMs) start fast and have low overhead while providing a stronger boundary than containers. One VM per Agent means compromising one Agent won't spread laterally to others. According to Google's description, the VM stores no credentials at all; when an Agent needs to access an external service, credentials are injected or held externally by a proxy rather than landing in the Agent's readable filesystem or environment variables.

This combination—strong isolation plus zero credential residency—downgrades the worst-case outcome of "an Agent gets compromised" from "key leakage" to "a single VM gets burned down."

microVM is a lightweight virtualization approach sitting between containers and full virtual machines. It retains the strong isolation boundary provided by hardware virtualization (such as KVM), but through a streamlined device model and a dedicated boot path, it compresses startup time to the hundreds-of-milliseconds range and cuts memory overhead to tens of MB, approaching container-like agility. Firecracker is the most representative implementation, developed and open-sourced by AWS for Lambda and Fargate, capable of running thousands of microVMs on a single host. Unlike containers, which share a kernel, microVMs each have their own kernel, so kernel vulnerabilities or container-escape-style attacks struggle to spread across VMs—precisely why ACE chose it.

Prompt injection refers to attackers hiding malicious instructions in content an Agent will read (web pages, documents, tool return values, etc.), tricking the model into deviating from its original task and performing unauthorized actions. Unlike traditional injection attacks, it exploits the model's obedience to natural-language instructions rather than code-parsing vulnerabilities, making it very hard to eradicate entirely through input filtering. In a shared runtime, an injected Agent may read environment variables, call high-privilege APIs, or access neighboring Agents' data, causing lateral movement. ACE's microVM isolation and credential externalization are designed precisely to confine the impact of a successful prompt injection to a single VM.

What Google said, and what it didn't

Based on public information, ACE is positioned as a managed runtime for Agents, emphasizing per-Agent allocation of compute resources and isolation boundaries. But it must be stated honestly: the technical details公开 so far are quite limited. The specific microVM implementation (whether based on Firecracker, gVisor, or something else), the exact credential injection mechanism (sidecar proxy, short-lived token exchange, or another approach), the default network policy configuration, and the pricing model have all not been fully disclosed.

In other words, what can be confirmed now is the design intent and architectural direction, not verifiable implementation details. For teams planning to rely on this infrastructure, this is an information gap worth noting—there's still a distance between architectural promises and actual SLAs.

Three things builders can copy today

Even if ACE itself isn't yet available, its design approach has direct reference value for teams building their own Agent infrastructure.

1. Push the isolation unit from containers down to microVMs

If your Agent executes model-generated code or calls untrusted tools, the container boundary is too thin. Use lightweight virtualization solutions like Firecracker or Cloud Hypervisor to allocate a dedicated VM per session or per Agent; startup time can be kept in the hundreds-of-milliseconds range at acceptable cost. The key is to make the blast radius equal to one VM.

2. Keep credentials out of the Agent environment

This is the most copy-worthy item from ACE. Move keys out of the Agent's env, filesystem, and memory, and have an external proxy inject them when requests are sent. Specific approaches include: routing outbound traffic through a proxy that holds credentials and performs short-lived token exchange; or using workload identity (such as SPIFFE) so the Agent accesses resources by identity rather than by key. This way, even if the Agent is fully controlled, the attacker can't obtain long-term credentials.

SPIFFE (Secure Production Identity Framework for Everyone) is a workload identity standard. It consists of the SPIFFE ID (a URI of the form spiffe://trust-domain/path) and the SVID (a short-lived cryptographic credential carrying that identity, usually an X.509 certificate or JWT), automatically issued and rotated by the Workload API on each node. Workloads prove their identity to resource owners using SVIDs, and resource owners authorize accordingly, all without static keys. For Agent scenarios, this means that even if an attacker fully controls a VM, they can only obtain identity credentials valid for a few minutes, and that identity can be revoked individually, preventing long-term access to other resources.

3. Manage resources and lifecycle at per-Agent granularity

Each Agent having its own VM means rate limiting, snapshotting, destruction, and auditing can all be done independently. Audit logs are naturally segmented by Agent, so when problems arise you can pinpoint a single runtime instead of fishing through a pile of shared logs.

Signals worth watching

The signal ACE sends matters more than its current features: mainstream cloud providers are starting to treat Agents as first-class runtime workloads rather than "an application running in a container." Isolation granularity, credential models, and lifecycle management—things developers traditionally assembled themselves—are being absorbed into the platform layer.

For developers, there's no need to wait for ACE to land in the short term—the three principles above can be implemented today with open-source components; in the medium term, it's worth watching Google's follow-up implementation details, especially the credential injection mechanism and default network policies, since these two determine the security floor of this architecture.

---

Source note: This article is compiled from public reporting from RSS sources. Implementation details about ACE in Google's official documentation have not yet been fully disclosed, and descriptions of specific mechanisms herein are limited to public information.

One-line Summary

Google ACE gives each AI Agent a dedicated microVM with no stored credentials, using strong isolation and zero credential residency to reduce the consequences of compromise.

Paragraph Summary

Google proposes the Agent Compute Engine (ACE) runtime, centered on each Agent having its own microVM with no credentials stored inside. This design addresses the risk that current Agents mostly run in shared containers, allowing prompt injection to laterally access tokens and neighboring data, by pushing isolation down to the hardware virtualization layer and moving credentials to external injection or proxy holding. The article notes that ACE's public details are limited—microVM implementation, credential injection mechanism, network policy, and pricing are all undisclosed—and there's still a gap between architectural promises and actual SLAs. For builders, three things can be adopted immediately: pushing the isolation unit down to microVMs, keeping credentials out of the Agent environment, and managing resources and lifecycle auditing at per-Agent granularity.