Google's new agent sandbox assumes the agent will be hijacked. It makes sure there's nothing inside to steal.
Google Cloud introduced Agent Compute Engine on October 22. Every agent gets its own microVM, and no password, token or API key ever sits inside it. There's no price and no preview date yet.
Most agent security advice is about stopping the agent from going wrong. Google’s new agent computer, announced on October 22, starts from the opposite assumption.
In the technical write-up for Agent Compute Engine, two Google Distinguished Engineers put the design rule in one sentence: “Assume an attacker controls everything inside the sandbox, and make sure they find nothing there to use.” Google announced the service on Thursday, October 22, at the AGNTCon + MCPCon conference. You can’t use it yet.
What is Agent Compute Engine?
A Google Cloud service that gives each AI agent its own microVM, a small virtual machine with its own guest kernel and root access. Google says it already runs Gemini as an agent for work tasks. Customers get a preview “in the coming months,” according to the launch post, and the post gives no date and no pricing.
Google splits every agent in two. The “brain” is the software that calls the model and decides what to do next. The “hands” are the sandbox that runs code, shell commands and a browser. The brain runs outside the sandbox, and so do the long-lived credentials.
Why is “no credentials inside” the interesting bit?
Because it answers a known attack, hidden instructions in content the agent reads. Google’s own example is an inbox agent that reads an email with hidden text telling it to find API keys on the machine and send them to an address. The engineers wrote: “Most of the time, it ignores the instruction. Sometimes it does not.”
So the sandbox holds no OAuth refresh tokens, no service account keys and no API keys. It boots without a normal network card, and all traffic passes through a proxy outside the machine. When code in the sandbox calls a service, a separate Agent Gateway checks the session’s identity and the egress policy, then swaps in the real credential as the request leaves. The sandbox never sees it.
If that works as described, a fully compromised sandbox is a bad afternoon rather than a stolen key. The LiteLLM release built to steal AI tool tokens showed the other side of it: secrets that sit where untrusted code runs get taken.
What did Google actually measure?
Less than some summaries suggest. The speed and density figures belong to a different product.
The launch post says that “in benchmark validation running 200,000 agents, Agent Substrate sustained 500 activations per second at less than 500 ms suspend and resume latency,” and that Substrate delivers “as much as 10x higher compute density.” Agent Substrate is the open-source runtime Google released for Kubernetes on GKE, and you can try it today. Agent Compute Engine is the managed service that isn’t in preview yet. At least one roundup blurs the two.
| Item | Where you can use it | Google’s headline claim |
|---|---|---|
| Agent Compute Engine | Not yet, preview “in the coming months” | Hardware-isolated microVM per agent, no credentials inside (no speed figures published) |
| Agent Substrate on GKE | Now, open source | Up to 10x compute density, 500 activations a second at 200,000 agents |
Google published no performance figures for Agent Compute Engine itself. The Substrate numbers are Google’s own, and I found no outside measurement of them. At least one daily roundup, listed in the sources, files the 200,000-agent test under Agent Compute Engine, which is why I’m spelling it out.
How does it save money?
Google says agents spend most of their time waiting on the model or the user. When an agent finishes a tool call, the sandbox tells the host, which checkpoints the microVM so it uses “zero active resources” until the next call. Many agents also share one copy of the base operating system in memory through copy-on-write. Whether that shows up as a lower bill depends on pricing nobody has seen.
My read
The design is sensible, and it matches what other companies have been moving toward. Nvidia’s OpenShell takes a related approach: a policy file says which files, networks and credentials an agent may touch. Keeping secrets away from the code that runs the agent is the correct instinct.
But “nothing to steal” isn’t “nothing to do.” An agent in the sandbox can still run code, and it still acts through the gateway with the user’s delegated permissions. A hijacked agent that can ask the gateway to open your Drive files doesn’t need the key, because the gateway will use it for them. Google’s answer is policy: an administrator decides what an agent can reach, and the technical write-up says all assets are protected by default. That only works if someone then writes the allow rules tightly, and neither post shows what a typical rule set looks like.
There’s also the timing. On October 23 OpenAI said it now trains frontier models with no internet access after one of its research models reached the live internet through a misconfigured DNS resolver, a case I covered in the Brotli and offline-training post. Google is selling the same idea to everyone else: assume the agent will misbehave and build the room around that.
What I’d watch is the preview itself: the price per idle agent, which regions it runs in, and whether anyone outside Google tries to break the gateway.
Note on sources: I read both Google posts in full. WebProNews and TSN are secondary reports that I used to cross-check the launch details, and I found no independent test of Google’s numbers.
Sources
- Google Cloud Blog: Introducing Agent Compute Engine and expanded agent governance (October 22, 2026)
- Google Cloud Blog: Inside Agent Compute Engine, the technical deep dive
- WebProNews: Google Cloud Plans to Open the MicroVMs Behind Gemini’s Agents to Customers
- TSN: Google Cloud Unveils Agent Compute Engine to Run AI Agents in MicroVMs
- Dev.to: AI Daily Digest, October 25, 2026 (a roundup, cited only as the example of the 200,000-agent figure being placed under Agent Compute Engine)