Google Cloud Launches Agent Compute Engine: One MicroVM per AI Agent

Google Cloud has launched Agent Compute Engine, turning "one isolated virtual machine per AI agent" into a foundational abstraction of its cloud service. This is more than a product update—it's a redesign of the security model for agent execution.

Core Design: Agents Hold No Credentials, Each MicroVM Is Hardware-Isolated

According to MarkTechPost, Agent Compute Engine allocates a hardware-isolated microVM to each AI agent, and no credentials are stored inside the virtual machine. Combined, these two points mean that even if an agent is compromised via prompt injection, the attacker only gets a "hollow shell" machine—not a key to enterprise data and APIs.

Traditional agent deployments often stuff long-lived credentials directly into the runtime. The more capable the agent, the greater the credential privileges, and the more concentrated the risk. Agent Compute Engine's approach is to strip credentials out of the execution environment, separating the agent's execution plane from its authorization plane.

The Essential Difference Between microVM and Container Isolation

A microVM (such as AWS Firecracker or solutions at the same layer as Google gVisor) is a lightweight virtual machine based on hardware virtualization (typically KVM). It runs a guest OS on an independent kernel, so there is no shared kernel between it and the host or other instances. Containers, by contrast, rely on namespaces and cgroups for logical isolation and still share the host kernel. If a privilege-escalation vulnerability exists in the kernel, an attacker may cross container boundaries. This is exactly where the value of "hardware isolation" lies in the agent scenario: after a prompt injection compromise, the attacker controls at most their own microVM and cannot use a shared kernel to move laterally to other agents or host services. The trade-off is that microVMs require dedicated memory and kernel images, so startup and scheduling overhead is higher than containers—which is why the industry uses minimal device models like Firecracker to push cold starts down to the hundreds of milliseconds.

Prompt Injection and the "Separation of Execution Plane and Authorization Plane"

Prompt injection refers to an attacker mixing malicious instructions into content the agent reads (web pages, emails, tool return values), inducing the agent to deviate from its original task and perform operations the attacker intends. Traditional deployments write long-lived API keys or OAuth tokens into the agent runtime. Once an agent is hijacked via injection, the attacker also gains the full privileges of those credentials—this is the main reason the harm of prompt injection is amplified. The so-called separation of the execution plane and the authorization plane means the agent's reasoning and tool calls (the execution plane) run in an environment containing no secrets, while the actual authentication (the authorization plane) is handled by an external trusted component—for example, issuing short-lived, least-privilege tokens on demand, or having a gateway call downstream APIs on the agent's behalf. Thus, even if the execution plane is compromised, the attacker cannot directly reuse long-lived credentials, and the exposure surface is compressed into a single, limited, auditable call.

Already Running on Gemini Agents, Preview Coming Soon

Google says the service already powers Gemini agents internally and plans to enter preview in the coming months. In other words, this is not a lab concept but a path of internal dogfooding first, then external availability.

For enterprises, this cadence sends a clear signal: Google has already stepped on the landmines of agent infrastructure itself, and is now selling the architecture that resulted from those lessons.

Why "One VM per Agent" May Become the Default for Agent Cloud

Multi-agent systems in 2026 are being deployed faster than identity and isolation systems are being built. When dozens or hundreds of agents execute tasks concurrently, the lateral movement risk of a shared runtime is amplified. The granularity of microVMs sits precisely between "lightweight enough to start and stop in bulk" and "isolated enough not to share a kernel."

This path is not cheap: one virtual machine per agent means scheduling and cold-start overhead are real money. Google is clearly betting that enterprises are willing to pay this bill for the risk of runaway agents.

Lateral Movement Risk

Lateral movement is a security term referring to an attacker, after compromising one entry point, gradually penetrating other systems via internal trust relationships, shared credentials, or co-hosted resources. In multi-agent systems, the risk is significantly amplified: dozens or hundreds of agents often share the same runtime, the same set of environment variables, or the same service account. If one agent is compromised via prompt injection, the attacker can read the state of other agents in the same process, reuse their credentials, and send malicious tasks to co-hosted agents, leading to cascading failures. The coarser the isolation granularity, the larger the blast radius of a single point of failure; microVMs lock each agent into a box with an independent kernel precisely to cut this lateral path and confine failures and intrusions to a single instance.

Several Open Questions Worth Watching

Public information is still limited: startup latency of the microVMs, billing granularity, how it integrates with existing IAM systems, and whether communication between agents also goes through isolated channels—none of these have clear answers yet. How a credential-free agent performs operations requiring authorization—whether through short-lived token injection or external service-proxied authentication—will be key to judging the maturity of this architecture.

For enterprises building agent platforms, Agent Compute Engine offers a reference architecture worth benchmarking against: isolate first, then authorize, and only then talk about capability.

One-line Summary

Google launches Agent Compute Engine, allocating a credential-free isolated microVM per agent.

Paragraph Summary

Google Cloud has launched Agent Compute Engine, making "one isolated virtual machine per AI agent" a foundational abstraction of its cloud service. Its core design allocates a hardware-isolated microVM to each agent with no credentials stored inside, thereby separating the execution plane from the authorization plane: even if an agent is compromised via prompt injection, the attacker gets only a hollow shell machine, not the keys to enterprise data and APIs. The service already powers Gemini agents internally and is planned to enter preview in the coming months. The article argues that, with multi-agent concurrency being deployed faster than identity and isolation systems are built, microVM isolation granularity may become the default form of agent cloud, at the cost of scheduling and cold-start overhead. Details such as startup latency, billing granularity, and IAM integration have not yet been disclosed.