Google turns the infrastructure behind Gemini agents into a cloud service
On October 22, 2026, Google Cloud unveiled Agent Compute Engine, a compute service that runs every AI agent inside its own hardware-isolated microVM with zero credentials in the sandbox. Sign up for the preview if you run Gemini agents in production, and treat the microVM-per-agent isolation model as the new baseline to replicate.
October 22, 2026. Google Cloud unveils Agent Compute Engine, a compute service purpose-built to run AI agents at scale, at the AGNTCon and MCPCon conferences. October 22, 2026. Every agent runs inside its own hardware-isolated microVM, a sandbox that holds zero credentials. October 22, 2026. The service already powers Gemini for work tasks, and a public preview is due before the end of the year. Why it matters: an agent that acts on your behalf holds keys, and Google has just built a place where it can act while holding none.
A runtime that finally treats agents as first-class
Until now, an AI agent has been just another program running somewhere — in a container, on a VM, in a Kubernetes cluster — using the same primitives as any application. The trouble is that an agent is not an ordinary application: it makes decisions, it calls tools, it reads and writes credentials, and it does so with a degree of autonomy that makes human review impractical at scale.
Agent Compute Engine answers that gap with a dedicated runtime. Google’s announcement is explicit: this is a compute service “built specifically for running AI agents at scale.” The core building block is the hardware-isolated microVM — an isolation boundary that does not rely on a container’s shared kernel but on hardware virtualization, the same technology that already separates tenants on a hypervisor.
Choosing a microVM over a container is deliberate. A container shares its host kernel; runtime compromise and privilege escalation are well-documented failure modes there. A microVM leans on a deeper boundary — typically KVM or an equivalent — and shrinks the surface a compromised agent can reach. For a service whose product is literally “an autonomous agent that operates your tools,” that depth of isolation is the floor, not a luxury.
One microVM per agent, zero credentials inside
The most striking line in the announcement is that the sandbox holds zero credentials. The agent is not handed an API key, a service token, or a database secret baked into its runtime environment. The credentials it needs to act are injected from outside the microVM, at execution time, through a mechanism that never exposes them to the process itself.
That is an inversion of current practice. Most agents today carry their secrets in environment variables or a vault reachable from the runtime — exactly the model the recent Railway breach put back in the spotlight: when the host is compromised, readable secrets become stealable secrets. By moving credential custody outside the sandbox, Google removes the agent’s ability to exfiltrate them on its own, even if it is fully compromised.
The “one microVM per agent” model also changes the blast radius of an incident. Where a fleet of agents once shared a host and a common secrets space, each agent becomes a disposable, isolated unit. A corrupted agent can neither read its neighbors’ credentials nor pivot into the infrastructure that hosts them. For a security team, the problem shifts from “how do I contain a hundred agents” to “how do I evict one agent at a time.”
Gemini is already running on it
The most reassuring part of the announcement is not marketing: Agent Compute Engine is not an empty service waiting for its first customers. Google says the infrastructure “already powers Gemini” in its agent-for-work functions. In other words, the product is being dogfooded internally before being exposed, which reduces the risk of a theoretical launch whose limits nobody has actually tested.
That detail reads a second way. If Gemini — the most exposed agent in Google’s ecosystem — is already running on this isolation layer, then the microVM-per-agent model sustains real load, with real tool calls and real secret flows. For teams reluctant to hand their own agents to a new abstraction, that is a stronger argument than a page of documentation.
The public preview, promised “later this year,” will be the moment of truth: the missing details — pricing, policy granularity, cold-start latency of a microVM — will decide whether the service holds up beyond the demo. Until then, the architecture is already legible, and that is the part worth remembering.
Governance now spans cloud, hybrid, and on-premises
The second half of the announcement is about governance. Google is expanding the governance capabilities of Gemini for business so companies can “run, govern, and scale” their agents not only in the cloud but also in hybrid and on-premises environments.
The move answers a standing objection from large organizations: you do not hand an agent that touches sensitive data to infrastructure you do not control. By extending governance across all three surfaces — cloud, hybrid, on-site — Google is trying to make its isolation model a reference that applies everywhere, not just inside its own data centers. It is also a way to satisfy regulations that impose data residency or a precise processing perimeter.
For an operator, the practical consequence is simple: the policies that govern “who can deploy which agent, with which tools, in which zone” become a first-class configuration object, on par with the access rights of any traditional service. The agent stops being an out-of-band program and becomes a governed workload.
What it changes for an SRE — and what is still missing
In the field, Agent Compute Engine does not remove work; it moves it. The SRE no longer has to defend a shared host against a fleet of agents. Instead, they must design the credential injection flow, audit the tools each agent can reach, and instrument the observability of microVMs that are born and die in seconds. The microVM answers the isolation question; it does not answer the accountability one — nobody has yet solved “who gets paged for an agent that fails.”
There is also a lack of comparison data. The closest direct rival, AWS, pushes its own agent-execution building blocks through Bedrock and ECS, while model providers such as OpenAI and Anthropic mostly sell software runtimes, not hardware boundaries. As long as Agent Compute Engine pricing and limits are unpublished, it is impossible to say whether the cost of one microVM per agent is justified against a well-configured container for the least sensitive workloads.
The most useful reading of the announcement is therefore architectural. Google has set a standard: a production agent deserves a hardware boundary and a credential-free sandbox. Whether or not you adopt the service, that requirement is now what you can legitimately demand of any agent platform.
Verdict
If you run Gemini agents in production, join the Agent Compute Engine preview as soon as it opens and start by moving the agents that handle credentials or sensitive data — they are the ones that justify the cost of a hardware boundary. If your agents run on another stack, do not stay on a shared container that carries its own secrets: replicate the one-microVM-per-agent, zero-credentials-in-the-sandbox model, if only with gVisor, Kata Containers, or Firecracker and an external vault that injects secrets at call time. If you are evaluating agent platforms, make hardware isolation and external credential custody two non-negotiable selection criteria. Google’s announcement is not one more promise: it is the first time a major cloud has turned the requirement to trust an agent into a compute product of its own.