Innhold Show
If an AI agent is allowed to run code, open a browser, and work inside company systems, asking the model nicely to behave is nowhere near enough. Google Agent Compute Engine tackles that problem at the infrastructure level: every agent gets its own hardware-isolated microVM, while valuable credentials stay outside the environment the agent controls.
That is a far more interesting security model than adding yet another layer of system instructions. An agent can read a malicious email, misinterpret a website, or run code that nobody should trust. Google’s starting point is therefore that everything inside the sandbox could be compromised. If that happens, an attacker should not find API keys, OAuth tokens, or direct network access waiting inside.
Agent Compute Engine already runs Gemini agents internally at Google, but the service is not generally available. Google announced on October 22, 2026 that it will enter preview “in the coming months.” There is no public price yet, and I have not tested the service. Even so, the architecture makes an important point: AI agents increasingly need their own layer of compute, identity, and security – not just a model connected to a handful of tools.
What is Google Agent Compute Engine?
Google Agent Compute Engine is a new cloud service that gives each agent session a persistent, hardware-isolated microVM. According to Google’s October 22 launch announcement, the service is designed for agents that write and run code, use tools, control browsers, and carry out workflows over time.
Google splits the agent into two parts. The “brain” is the agent harness, the layer that talks to the model and decides what to do next. The “hands” are the sandbox that actually runs shell commands, the browser, and the code. The brain remains outside the microVM, while the potentially untrusted execution happens inside it.
This gives the agent more freedom than a locked-down container environment, including its own operating system, kernel, and root access. At the same time, each session gets a stronger boundary from its neighbors than an ordinary container sharing the host kernel. The practical goal is to combine VM isolation with the startup speed and density needed for short, bursty agent workloads.
Why does the microVM matter for security?
The microVM matters because an AI agent does more than process text. It may have access to a file system, install packages, open websites, and run commands on a user’s behalf. In Google’s technical deep dive, the core rule is ruthlessly sensible: Assume an attacker controls everything inside the sandbox, then make sure there is nothing useful to steal there.
The microVM is therefore not supposed to store API keys, OAuth refresh tokens, or service account keys, either in memory or on disk. It cannot access the cloud metadata service either. Instead, each session gets a short-lived SPIFFE identity and its own cryptographic attestation.
When the agent requests access to an external service, the traffic passes through a controlled gateway outside the microVM. The gateway checks user delegation, agent identity, the destination host, and the current policy before injecting the correct credentials on the way out. In other words, the sandbox can use an approved service without ever holding the key that unlocks it.
This is exactly the kind of separation production agents need. Prompt injection does not disappear because an agent has a microVM. The model can still do something stupid. The difference is that a stupid or malicious action hits a technical boundary around identity, networking, and secrets. Security then depends less on the model interpreting every piece of text correctly – an expectation history has already mocked rather thoroughly.
How can one microVM per agent be affordable?
Google plans to make this affordable by exploiting the fact that agents spend much of their time waiting. They wait for the next model response, an external system, or the user. When the runtime detects that no commands or background jobs are active, it can freeze the microVM, preserve its state, and release the active compute resources.
When the next tool call arrives, the environment resumes from a checkpoint. Google says an idle agent session can therefore consume close to zero active compute without throwing away its files and working state. That matters if a service is expected to host thousands or millions of long-lived agents that only work in short bursts.
Active microVMs can also share unchanged parts of the operating system, libraries, and prewarmed applications through copy-on-write memory. Only the pages changed by a particular agent require private physical memory. This does not mean the agents share a workspace or security boundary. They share identical, static building blocks beneath the surface.
Google has not announced a price for Agent Compute Engine. That leaves no way to know whether these technical choices will produce an attractive bill for small developers and businesses. The architecture explains how Google intends to make the economics work, but “efficient” remains a vendor claim until the preview can be measured against real alternatives.
What happens to files and work between sessions?
Each microVM can have a persistent Hyperdisk workspace. The agent can keep installed tools, source code, and results between conversations and work sessions instead of rebuilding the entire environment every time. For a coding agent working on the same repository over several days, that is far more useful than a disposable, one-shot sandbox.
Google describes three storage tiers. Temporary logs and build artifacts can live in fast, disposable storage. Shared base images, toolchains, and package caches can be mounted as read-only resources. Only the user’s actual working state and saved results need persistent, private storage.
Persistent workspaces also create a new responsibility. A disk that remembers useful files can remember dangerous files and bad changes too. Google’s snapshot, forking, rewind, and rollback features may therefore prove at least as important as the storage itself. Teams need to be able to trace what the agent changed and return to a known state.
Is Agent Compute Engine only for Gemini?
No. The plan is for developers to use Agent Compute Engine with their own agents. Google says customers will control the environment image, identity, network access, and lifecycle while Google operates the underlying fleet. The service already supports Gemini, Antigravity, and internal evaluation and training workloads, but outside access will begin with the preview.
Google also introduced Agent Substrate for teams that want more control or prefer to run on Kubernetes. It is an open runtime for GKE and other Kubernetes environments, using either microVMs or gVisor for isolation. Google claims up to 10 times greater compute density than traditional compute and reports a validation run involving 200,000 agents, 500 activations per second, and pause-and-resume latency below 500 milliseconds.
Those figures apply to Agent Substrate, not to a public performance test of Agent Compute Engine. That distinction matters. MarkTechPost highlighted the microVM-per-agent design, but Google has not published pricing or customer benchmarks that would allow a fair comparison between the coming managed service and Firecracker, gVisor, ordinary VMs, or other agent sandboxes.
For developers, the architecture is worth studying now, while any buying decision should wait. Agent Substrate may suit teams that already operate Kubernetes and want to experiment with the same basic approach. Agent Compute Engine is the managed version for teams that would rather buy the runtime as a service.
What should businesses examine before the preview?
Start with the boundary between the agent’s decision layer and its execution environment. Can code launched by the agent reach the model’s system instructions, the user’s long-lived credentials, or another agent’s session? If the answer is yes, calling the environment a sandbox does not help much.
Next come identity and networking. The agent should receive short-lived, narrowly scoped access to exactly what the task requires. Outbound traffic should pass through policy enforcement and logging, not an ordinary network connection with an API key sitting in an environment variable. Google describes four identity levels covering the user, delegation, the workload, and an optional separate agent account. That may sound elaborate, but it is better than pretending every action is still performed directly by the human who started the session.
Finally, measure the economics with real workflows. How quickly does a frozen agent wake up? What does storage cost when a workspace remains alive for months? How easily can a team export data, images, and policies if it wants to change providers? And how clearly does the bill separate active execution, idle time, disk, and networking?
Agent Compute Engine does not solve agent reliability. It does not make the model smarter, and it cannot prevent every harmful action. What Google is building is a better place for an unreliable agent to work. That is an important distinction – and in my view, a far more mature direction than giving increasingly powerful agents an ever-growing pile of keys and hoping the prompt holds.
Frequently asked questions
When will Google Agent Compute Engine become available?
Google says Agent Compute Engine will enter preview in the months following its October 22, 2026 announcement. The company has not provided an exact date, a list of supported regions, or a timeline for general availability.
Does Agent Compute Engine have a public price?
No. Google has not published prices for microVM execution, persistent storage, suspended sessions, or network traffic. It is therefore too early to say whether the service will cost less than other sandboxed or VM-based approaches.
Can an agent retrieve API keys from its own microVM?
The architecture is designed to prevent exactly that. Long-lived API keys, OAuth refresh tokens, and service account keys stay outside the sandbox. An external gateway checks identity and policy before injecting the required credential into an approved outbound request.
How is Agent Compute Engine different from Agent Substrate?
Agent Compute Engine is Google’s coming managed cloud service for isolated agent environments. Agent Substrate is an open, Kubernetes-based runtime for teams that want more control and portability. They share similar ideas, but their availability, operational model, and published performance figures differ.
