Google Cloud Unveils Agent Compute Engine: AI Agent Credentials Kept Outside Hardware Sandbox

Every AI agent running on Google Cloud's new Agent Compute Engine starts its session with a clean slate on one deliberate point: it has no backend credentials. The service tokens, API keys, and access secrets that let an agent actually do things — read a database, call a tool, write to storage — are injected onto the wire by a separate hardware layer that the agent itself can never reach. If a prompt injection attack takes over the agent's behavior, the attacker finds an empty sandbox.

Agent Compute Engine, announced October 22, 2026 at AGNTCon + MCPCon in San Jose, California, is Google Cloud's purpose-built compute service for AI agents. It uses lightweight hardware-isolated virtual machines — microVMs — rather than containers, and it places the service's security root not in software but in a dedicated chip. That chip, Google's Titanium Infrastructure Processing Unit (IPU), holds the attestation keys for each microVM outside the guest environment entirely, meaning no software compromise inside the sandbox can reach them. The Titanium architecture is documented at Titanium offload processor architecture .

The launch places Google alongside three other major cloud providers that independently converged on microVM isolation for AI agent compute within the same calendar year — a convergence that collectively amounts to an industry verdict that containers are not the right primitive for agents that execute untrusted content, call external tools, and run code generated by users or models.

Twelve Attacks in Nine Months: Why Credential Theft Is the Design Constraint

Prompt injection — the attack where malicious instructions embedded in content processed by an AI agent cause it to deviate from intended behavior — ranked first on the OWASP Top 10 for LLM Applications and moved from theoretical to routine in 2026. Security researchers documented 12 web-based indirect injection attacks against production AI systems in the first three months of the year alone. Google's own threat research team reported a 32% increase in malicious injection payloads targeting LLM-integrated applications between November 2025 and February 2026.

The most severe confirmed case was EchoLeak — EchoLeak CVE-2025-32711 vulnerability , rated CVSS 9.3 — which exploited an indirect prompt injection vulnerability in Microsoft 365 Copilot to exfiltrate user data from documents and emails the agent was processing. The attack succeeded because the agent held credentials capable of reading and transmitting data, and a crafted document was sufficient to redirect those credentials.

Credential theft is not the only goal of a prompt injection attack — attackers can also aim to exfiltrate data through side channels or to trigger unintended actions — but it is the vector with the clearest architectural fix. Google's fix is to remove credentials from the attack surface entirely.

How the Credential-Free Sandbox Works

The technical mechanism behind Agent Compute Engine's security model is a three-layer chain that keeps backend service tokens physically separated from the agent at all times. For a full breakdown of the architecture, see Google's Agent Compute Engine deep dive .

The microVM layer : Each agent session runs in its own microVM — a lightweight virtual machine with its own guest Linux kernel, separate from the host kernel and from every other agent on the same physical machine. MicroVMs boot in approximately 125 milliseconds (ms) and impose roughly 5 megabytes (MiB) of memory overhead per agent for the agent's private memory pages; the underlying operating system template is shared across agents using copy-on-write memory, meaning the shared portion costs essentially nothing in per-agent terms. Unlike containers, which the host kernel and can be escaped via kernel exploits, each microVM has a complete hardware isolation boundary enforced by KVM-based virtualization.

The Titanium layer : Sitting beneath the hypervisor is Google's Titanium IPU — a dedicated processor separate from the host CPU that handles cryptographic operations, storage encryption, network encryption, and I/O virtualization from its own silicon. Critically, Titanium holds the private attestation keys for each microVM outside the guest environment. Google's stated design rule for the architecture: "Assume an attacker controls everything inside the sandbox, and make sure they find nothing there to use." Each microVM receives an ephemeral, session-scoped SPIFFE cryptographic identity standard (Secure Production Identity Framework for Everyone) certificate — an industry-standard cryptographic identity — plus a short-lived token that proves which agent this is but carries no backend service credentials.

The Agent Gateway layer : When the microVM makes an outbound call — to a database, an API, a tool — traffic flows through a node-local proxy to the Agent Gateway, the policy enforcement layer in Google's governance stack. The Gateway validates three things: the user delegation token, the agent's SPIFFE identity, and the Titanium-attested node identity. Once validation passes, the Gateway performs an in-flight token swap, inserting the actual backend service credential onto the wire between the agent and the destination. The credential is never transmitted to, stored in, or accessible from inside the microVM.

The result is that a successful prompt injection attack — even one that achieves full control of the agent's behavior — finds no credentials to steal. It can still cause the agent to take unintended actions using the access it legitimately has for that session, but it cannot elevate privileges or exfiltrate credentials to use in a subsequent attack.

How Does Agent Compute Engine Keep Costs Down at Scale?

Isolation at the hardware level used to mean one dedicated machine per workload — an arrangement that is prohibitively expensive for fleets of AI agents that spend most of their time waiting on model responses or external APIs. Agent Compute Engine solves this through two complementary mechanisms.

Checkpoint-restore lets the system snapshot a microVM's complete state the moment an agent enters an idle phase — waiting on an LLM response, waiting on a human, waiting on an external system. The snapshot frees the underlying hardware resources (CPU, memory, I/O capacity), which are reallocated to active agents. When the idle agent's turn comes around again, the system restores from the snapshot in under 500ms, and the agent resumes from exactly where it stopped. The agent experiences no gap; the hardware operates at much higher utilization.

Copy-on-write memory means that 50 agents running on the same OS template do not consume 50 copies of that OS template's memory. They the same physical memory pages for the template and maintain only their individual modifications as private pages. The ~5 MiB per-agent overhead figure reflects this: an agent's memory cost is its own writes, not the full OS.

The open-source runtime that implements this model on Kubernetes — Agent Substrate on GKE — achieves compute density as much as 10 times higher than traditional compute while maintaining per-agent kernel isolation, at up to 500 agent activations per second with under 500ms suspend/resume latency, validated in an Agent Substrate benchmark validation run of 200,000 agents. Agent Substrate uses either gVisor or Cloud Hypervisor for kernel isolation and runs on any Kubernetes cluster, including on-premises and multi-cloud environments. It is available now as an open-source project at the Agent Substrate open-source site .

Governance: Controlling Agents Wherever They Run

Alongside the compute announcement, Google expanded its agent governance platform beyond Google Cloud runtimes to cover multi-cloud, on-premises, and managed endpoint devices.

The governance stack has four components. Agent Gateway provides centralized policy enforcement for all agent-to-agent and client-to-agent traffic, with built-in sensitive data protection, attack defense, and semantic policy controls. Agent Registry maintains a single source of truth for all approved agents, tools, MCP servers, skills, models, and endpoints — runtime access is governed by applied policies. Agent Identity issues per-agent cryptographic identifiers based on the SPIFFE standard, enabling authentication, access control, and audit trails that follow an agent across runtimes. Agent Observability delivers OpenTelemetry W3C tracing standard -compliant telemetry covering every model call, tool invocation, and agent hop, enabling distributed tracing across multi-agent pipelines.

OpenTelemetry's W3C trace-context standard propagates trace IDs across agent hops, meaning a single distributed trace can show every model call, tool invocation, and sub-agent interaction in a complex pipeline — enabling the root-cause analysis that agent failures require and the audit trails that regulated industries and the EU AI Act's requirements for high-risk AI systems will demand.

New capabilities arriving in preview this quarter include token and cost governance — allowing enterprises to attribute compute spend per agent and enforce budget guardrails — and model routing policies that direct requests to the right model based on cost and performance objectives. Governance for coding agents running on managed endpoint devices, including Claude Code, is also arriving in preview.

L'Oréal, whose Beauty Tech Agentic Platform is among the early enterprise deployments, cited the cross-runtime governance reach as the enabling factor:

"Google Cloud's agent governance provides us the foundation to scale this ambition with confidence, unifying identity, policy and observability across runtimes such as Cloud Run. Our developers can innovate faster while we maintain clear control over what each agent can access." — Alexandre Frizzo, AI Lead Engineer, L'Oréal

"Google Cloud's agent governance provides us the foundation to scale this ambition with confidence, unifying identity, policy and observability across runtimes such as Cloud Run. Our developers can innovate faster while we maintain clear control over what each agent can access." — Alexandre Frizzo, AI Lead Engineer, L'Oréal

Four Providers, One Architecture: Containers Have Failed for Agent Compute

Google's launch follows a sequence of identical conclusions from competitors across 2026 — each arrived at independently, within months of the others.

AWS introduced AWS Lambda MicroVMs launch on June 22, 2026, built on Firecracker, the open-source KVM-based VMM that AWS open-sourced in December 2018 and now uses to process trillions of Lambda executions monthly. The Lambda MicroVM offering targets multi-tenant execution of user- and AI-generated code, with session windows of up to eight hours — longer than traditional serverless functions, specifically to accommodate agentic work patterns.

Docker launched Docker Cloud Sandboxes launch on September 24, 2026, using Intel VT-x / AMD-V microVMs. Docker's president Mark Cavage was unambiguous at the launch: containers "weren't designed for the level of isolation AI agents demand." That statement, from the company that created the container ecosystem, carries specific weight as an industry-level diagnosis.

DigitalOcean entered private preview for a Firecracker-based MicroVM service targeting agent infrastructure builders in October 2026, as documented in the DigitalOcean MicroVMs private preview announcement.

Google announced Agent Compute Engine on October 22, 2026. Four providers. Four months. Four independent conclusions.

The differentiation in Google's approach is not the microVM primitive itself — Firecracker is open-source and available to all four — but the vertical integration of the security chain. ACE's credential model is anchored in Titanium silicon, not software. A software-based isolation approach can, in principle, be undermined by a sufficiently capable kernel exploit or hypervisor vulnerability. Titanium's architecture moves the attestation root off the CPU and onto a separate processor, making the chain of trust independent of the software stack the agent runs on.

Nous Research, whose Hermes Enterprise agent platform has been built on the Agent Substrate architecture, confirmed the isolation model's practical value:

"We built Hermes Enterprise to enable customers to deploy into their existing infrastructure, while handling per-agent isolation and extensible access control. Agent Substrate addresses both at the platform layer in a way that also preserves valuable compute resources." — Hervé Bizira, Chief Business Officer, Nous Research

"We built Hermes Enterprise to enable customers to deploy into their existing infrastructure, while handling per-agent isolation and extensible access control. Agent Substrate addresses both at the platform layer in a way that also preserves valuable compute resources." — Hervé Bizira, Chief Business Officer, Nous Research

Gautham Thambidorai, VP and Google Fellow for Gemini, described the scale at which ACE has already been validated internally:

"Scaling the Gemini agent to planet scale requires compute that spins up rapidly and operates with extreme efficiency. Agent Compute Engine microVMs give us the responsiveness, hardware isolation, and workload density needed to deliver interactive agent sandboxes to our users around the world." — Gautham Thambidorai, VP & Google Fellow, Gemini

"Scaling the Gemini agent to planet scale requires compute that spins up rapidly and operates with extreme efficiency. Agent Compute Engine microVMs give us the responsiveness, hardware isolation, and workload density needed to deliver interactive agent sandboxes to our users around the world." — Gautham Thambidorai, VP & Google Fellow, Gemini

What's Available Now and What Comes

Agent Substrate on GKE is available today as an open-source project at the Agent Substrate project site . It supports agent frameworks including Claude Code, OpenClaw, and Hermes, and runs on any Kubernetes cluster.

The fully managed Agent Compute Engine, which adds the Titanium-rooted isolation layer and Google-managed lifecycle controls, will enter customer preview in the coming months. Google Cloud's interest form is open for sign-up.

The expanded agent governance capabilities — cross-cloud reach, endpoint governance for coding agents, token and cost governance, model routing policies — are expected in preview before the end of Q4 2026.

Google is hosting an "AI Infrastructure Future" event on November 9 focused on co-designed open systems for scaling agentic AI, where further technical detail on Agent Compute Engine's architecture is expected.

Frequently Asked Questions

How does Agent Compute Engine prevent prompt injection attacks from stealing credentials?

Service credentials are never placed inside the microVM where an agent runs. Instead, outbound traffic flows through a node-local proxy to the Agent Gateway, which validates the agent's cryptographic identity (a SPIFFE certificate issued by Titanium hardware) and then performs an in-flight token swap — inserting the actual backend credential onto the wire between the agent and the destination service. An attacker who successfully injects instructions into the agent's behavior finds no credentials inside the sandbox to steal, because none are there. The attestation keys that prove the microVM's identity are held by a separate Titanium processor outside the guest environment, not by the guest operating system or any software the agent can reach. See the Agent Compute Engine deep dive for the full architecture.

What is the difference between a microVM and a container, and why does it matter for AI agents?

A container shares the host operating system's kernel with every other container on the same machine. A kernel vulnerability in one container can, in principle, affect others. A microVM runs its own guest kernel inside a hardware virtualization boundary (enforced by KVM and the underlying CPU's virtualization extensions); compromising the guest kernel does not give access to the host or other VMs. For AI agents, which routinely execute untrusted content — user-provided code, web pages, documents from unknown sources — shared-kernel isolation is insufficient. The container isolation model was designed for trusted application code, not for agents that process adversarial input as a normal part of their operation. The OWASP Top 10 for LLM Applications identifies prompt injection as the leading LLM vulnerability, specifically because agents with real capabilities can be redirected by adversarial inputs they process.

Does this mean all cloud providers now use microVMs for AI agent compute?

Every major cloud infrastructure provider that announced an AI agent compute service in 2026 chose microVM-based isolation: AWS Lambda MicroVMs (June), Docker Cloud Sandboxes (September), DigitalOcean MicroVMs (October), and Google Agent Compute Engine (October). The convergence is independent — each provider built its own implementation. The Cloud Security Alliance AI guidance and OWASP's LLM Top 10 both identify isolation from the host as a foundational requirement for agent deployments, and microVMs are the only generally available primitive that provides kernel-level isolation at cloud scale and sub-second latency.

What does Agent Substrate on GKE offer that the fully managed Agent Compute Engine does not?

Agent Substrate on GKE is open-source, Kubernetes-native, and runs on any cluster — including on-premises and multi-cloud environments. It provides per-agent kernel isolation using either gVisor or Cloud Hypervisor. What it does not include is the Titanium silicon layer: Agent Substrate's trust root is software-based, not hardware-anchored. The fully managed Agent Compute Engine adds Titanium-rooted attestation (meaning the chain of trust is independent of any software the agent could compromise) and Google-managed lifecycle controls. Agent Substrate is available today; Agent Compute Engine will enter customer preview in the coming months.