Google's Agent Compute Engine keeps credentials out of agent sandboxes

Google Cloud published an engineering deep dive on 22 October 2026 describing Agent Compute Engine, a new service that gives every AI agent its own hardware-isolated microVM. Google says it already runs Gemini's cloud agents, Gemini for business, its Antigravity coding product and internal evaluation pipelines, and that it is targeted for preview on Google Cloud "in the coming months".

The sandbox holds nothing worth stealing

Google's design rule, in its words, is to "assume an attacker controls everything inside the sandbox, and make sure they find nothing there to use." It says a microVM never holds user credentials, API keys, OAuth refresh tokens or cloud service-account keys in memory or on disk, and has no standard network interface. Traffic leaves through a mediated proxy.

When code in the sandbox makes an outbound request, Google says an off-node Agent Gateway checks the user's delegation, the agent's identity and the node's attested identity, applies egress and data-loss-prevention policy, then inserts the real credential "in-flight" as the request leaves. The sandbox only ever holds a short-lived workload identity based on the SPIFFE standard, which Google says is not usable to call a backend directly if stolen.

Google also separates the harness, which calls the model and decides what to do, from the sandbox that runs the code. It says this gives an audit trail tying every tool call to the compute activity it caused.

Idle agents are the cost lever

Google reports that when it measured typical agent sessions, agents spent most of their lives waiting for the model or the user. Its service detects when a tool call finishes and checkpoints the sandbox, so an idle agent uses what Google calls zero active host resources and resumes on the next step. Identical base images share memory pages across agents on a host.

The Decoder, reporting Google's separate launch post, says Google claims ten times as many agents per server and under 500 milliseconds to suspend and resume in a test with 200,000 agents. I could not verify those figures against Google's launch post, and they are Google's own tests.

Governance controls on top

Google describes four identities per action: the user, a delegated on-behalf-of grant that lives only in a central authorisation service, the sandbox's workload identity, and an agent workforce identity. It says access to private networks and Workspace is governed by administrator policy through Private Service Connect and VPC Service Controls. The Decoder reports token tracking, model routing and support for identity providers such as Ping Identity and SailPoint.

What the post leaves out

There is no price, no region list, no preview date and no independent test. The security claims are architecture descriptions from the vendor, not audits. The service is also tied to Google's own gateway and identity stack.

What to do

• Ask every agent vendor, including your own platform team, where an agent's credentials live while it runs; "inside the sandbox" is the answer to design away.
• Measure how much of your agents' session time is spent waiting before you size compute, since Google's cost case rests on that ratio.
• Register interest via Google if you run agents on Google Cloud, but wait for published pricing and a preview before planning around it.