On October 22, 2026, Google Cloud announced Agent Compute Engine, a managed sandbox that runs each AI agent in a microVM (a small virtual machine with its own kernel) and keeps backend credentials outside the agent’s environment, and said its agent governance will extend to other clouds and to local coding agents. The sandbox design is documented in detail, and Google says Gemini already runs on it. Cross-cloud governance is still coming soon, so buyers should test whether Google’s policies behave the same way on runtimes Google doesn’t own.
What is Covered in this Article
- What Google announced at AGNTCon + MCPCon on October 22, 2026, and which parts are available now.
- What Google’s documentation says about governing agents that run on other clouds, and how that compares with Microsoft Agent 365.
- How Agent Compute Engine keeps backend credentials outside an agent’s sandbox, and what that leaves to policy.
- How AWS, Microsoft, Docker, and Cloudflare already isolate agents and handle their credentials.
- What platform teams, security teams, Google, and cross-platform governance vendors should do next.
The News: On October 22, 2026, at AGNTCon + MCPCon, Google Cloud announced Agent Compute Engine, a service that gives each AI agent its own hardware-isolated microVM to run code, shell commands, and a browser. User and backend service credentials never enter the microVM; it holds only a short-lived workload identity. Agent Gateway adds the backend credentials to outbound requests after checking the user, agent, and node identities. The service checkpoints idle agents while they wait on the model, persists workspaces on Hyperdisk, and lets teams fork an environment into parallel copies. Google says the service already runs Gemini, Antigravity, and its evaluation and reinforcement learning pipelines.
Google paired it with Agent Substrate, the open-source Kubernetes runtime it announced on September 15, 2026, which isolates agents using gVisor or microVMs, injects credentials outside the sandbox, and works with any agent framework. Google also said its gateway, registry, identity, and OpenTelemetry-based observability tools will govern agents on other clouds and on-premises clusters, and coding agents such as Claude Code on managed devices.
Of the two execution offerings, only Agent Substrate is available now, on Google Kubernetes Engine (GKE) “for evaluation and non-production use,” with production support by allowlist. Agent Compute Engine reaches preview “in the coming months,” cross-cloud and local-agent governance are “in preview soon,” and five gateway additions, including token and cost controls and model routing, are due in preview this quarter. Google’s blog lists GKE and Cloud Run as governed runtimes, while its Agent Gateway documentation lists both as coming soon. Google detailed the launch in its October 22 announcement.
Google Agent Compute Engine Puts Cross-Cloud Governance to a Parity Test
Analyst Take: Google Agent Compute Engine gives Google Cloud a place to run agents, and the governance tools announced alongside it would let Google govern agents it doesn’t run itself. Google says it is extending governance “to support agents wherever they operate,” and its documentation names Amazon EKS, Azure AKS, and Red Hat OpenShift.
That goes further than Microsoft Agent 365 does today. Its connected-platforms feature syncs agents from Amazon Bedrock and Google Vertex AI, and Microsoft calls those connections “read-only by design.” Google proposes running its own policy gateway within an AWS or Azure customer’s cluster.
It puts Google in the position Kong took when it announced Volcano on September 30, 2026, as a host that also wants to referee. The same test applies here: whether a policy produces the same decision on a runtime Google doesn’t own. Google hasn’t shown that yet.
Google Wants a Policy Seat in Rivals’ Clouds
For agents on rivals’ clouds, “Google Cloud hosts the management plane,” where identities, registry entries, and policies are defined, and checks such as Model Armor, Google’s prompt and response screening service, call out to Google Cloud.
Our July AI Stack report placed Google in a vertical integration archetype, a bet that “integration depth and unified governance outweigh demand for layer-by-layer substitutability.” The October 22 launch revises that placement because Google kept the unified governance and opened its execution layer to other vendors’ harnesses; Agent Substrate names Claude Code, OpenClaw, and Hermes. A harness is the software that calls the model and picks the next step.
Google still runs Antigravity, its own harness, on Agent Compute Engine. The launch matches what we found after OpenAI’s DevDay, where OpenAI supplies the harness and model while “the hyperscaler keeps the control plane and the customer’s cloud commitment.” It also answers the question posed by Futurum Research in May about whether Google’s governance pieces would “mature into a unified agent governance surface.”
Google has given software away to win a market before. It released Kubernetes 1.0 on July 21, 2015, and announced it would donate the project to the forthcoming Cloud Native Computing Foundation (CNCF). In our view, Agent Substrate repeats the open-source part of that move, but Google hasn’t given its governance layer to a foundation.
Google’s Cross-Cloud Agent Governance Is Still a Plan
The standard Google set is governance for agents “wherever they operate.” The Agent Gateway documentation, as of October 28, says the gateway “is currently available for agents running on Gemini Enterprise Agent Platform.”
The cross-cloud design would enforce policy inside the customer’s own cluster. It would deploy an Envoy-based gateway there and identify each agent with SPIFFE, an open standard for workload identity. Google says, “Agent traffic stays in your environment.”
The policies live in Google’s management plane, and nothing Google has published says how enforcement behaves on EKS when that management plane can’t be reached, or which policies work the same way off Google Cloud.
In June, Fernando Montenegro argued that “no hyperscaler has the incentive to aggregate governance across competitors’ platforms.” Microsoft is aggregating anyway, and Google plans to. Each keeps the registry in its own cloud service, as his incentive argument predicts. His argument doesn’t settle whether Google’s policy behaves the same on a rival’s cloud as on its own.
Every control plane an enterprise adopts before the market settles adds integration debt, and one that covers only part of the estate can add debt without retiring any. In The Futurum Group’s 2H 2026 Software Lifecycle Engineering Global Enterprise Decision Maker Survey (n=839, fielded June 2026), integration complexity (40%) and tool sprawl and vendor proliferation (39%) were the top blockers organizations ranked in software lifecycle engineering.
Until Google shows the same policy produces the same decision everywhere it claims to govern, its gateway adds to that integration burden.
Google Agent Compute Engine Keeps Keys Out, Which Makes Gateway Policy the Control That Matters
Agent Compute Engine’s sandbox is built to hold no user or backend credentials. Google’s engineering deep dive states the rule: “Assume an attacker controls everything inside the sandbox, and make sure they find nothing there to use.” A prompt injection that tells an agent to collect API keys finds none.
That prevents a compromised sandbox from extracting the user and backend credentials held outside it. A manipulated agent can still ask the gateway for an action it is allowed to take, such as sending a document to an approved destination, and an agent allowed to update a record can update the wrong one. Rolling back the sandbox doesn’t repair a wrong action, because restoring it can’t recall an email already sent or a change already committed to another system.
According to Google, the gateway evaluates “fine-grained egress and data-loss-prevention policies,” and for Model Context Protocol (MCP) traffic it “inspects JSON-RPC requests to extract tool names and method attributes.” Checking a request’s values, such as the recipient or repository, falls to custom authorization extensions that inspect full payloads, which the gateway documentation lists as coming soon.
That is the confused-deputy problem, in which a program with legitimate authority is tricked into misusing it. A June 2026 arXiv preprint by David Mellafe Zuvic audited LangChain, LlamaIndex, and the Stripe Agent Toolkit and found that all three gate which tools an agent may call, but none check the argument values of each call by default.
The security boundary is now policy, and writing it is platform engineering work. Platform engineers write the egress and data-loss rules. Security teams review them and test them with injected instructions.
Google Enters a Sandbox Field AWS and Microsoft Already Ship In
Google is an entrant here, not the inventor. In AWS‘s Amazon Bedrock AgentCore, generally available since October 2025, each session “receives its own dedicated microVM.” Microsoft‘s Foundry Hosted Agents have run “in per-session VM-isolated sandboxes” since July 2026, and Docker keeps proxy-managed credentials on the host, while Cloudflare can inject credentials through outbound Workers that run outside the sandbox.
What Google adds is checkpointing triggered when the agent is waiting on the model, forking one environment into what Google says can be thousands of copies for evaluation, and an open-source Kubernetes runtime with credential injection built in. None of it says how an agent’s authority is declared and carried between runtimes, the problem Docker’s Sandbox Kit specification takes on.
Pilot Substrate Now and Make Google Prove Parity Before Consolidating
- Platform engineering teams: pilot Agent Substrate on a non-production GKE cluster, the one piece available today, and write an egress policy for one real workflow in its built-in egress gateway. Send the agent an injected instruction targeting an approved destination and record what the gateway blocks.
- Security teams: before any cross-cloud commitment, get Google’s answers in writing: which policies behave the same on EKS or AKS as on GKE, and which request-value checks are built in and which need a custom extension.
- Google: publish a parity matrix for the cross-cloud Agent Gateway before its preview opens, and give Agent Substrate a foundation home, as it did for Kubernetes in 2015.
- Kong, MuleSoft, and other cross-platform governance vendors: Google’s claim makes runtime parity a buying criterion. Publish your own parity results across AWS, Azure, and Google Cloud before Google publishes its own.
Why CIOs Need Cross-Cloud Agent Governance De-Risked Before They Buy
The sandbox is a platform engineering decision. The cross-cloud governance claim is a procurement one, and it lands on the CIO and the chief information security officer (CISO), not the platform team. Google is asking enterprises to let a competitor’s policy gateway run inside their AWS or Azure clusters and adjudicate agent traffic there. That is a buy, build, or partner call about who referees agents across an estate no single vendor owns, and the answer sets integration and audit exposure for the next two years.
For the buyer, the exposure is control plane debt. A governance layer that covers agents on Gemini Enterprise Agent Platform today and promises the rest adds integration surface and cost without retiring any of the tools already in place. Google has not published what the gateway costs to run across clouds, how it prices checkpointed idle sessions, or what enforcement does when its management plane is unreachable from a rival’s cloud. Until it does, treat cross-cloud parity as a gate on the purchase rather than a line on a roadmap. Keep the registry, the policy model, and the egress decision as criteria you can move between vendors, and make any consolidation wait for evidence that the same policy produces the same decision on a cloud Google does not run.
See the full launch post and its governance roadmap on the Google Cloud website.
What to Watch
- Whether the cross-cloud Agent Gateway preview documents how enforcement behaves on EKS or AKS when Google’s management plane is unreachable.
- Whether Google moves Agent Substrate, or any part of its governance layer, into a neutral foundation such as the CNCF before the Agent Compute Engine preview opens.
- Whether Agent Substrate or the Kubernetes Agent Sandbox project enforces Docker’s Sandbox Kit specification, which Docker is bringing to the CNCF.
- Whether Microsoft moves Agent 365 from syncing agents on Google Cloud to enforcing policy on them, whether AWS follows, and whether Kong and MuleSoft can still sell cross-platform governance once all three hyperscalers claim it.
- Whether the Agent Compute Engine preview names an external customer and publishes pricing for checkpointed idle sessions.
Sources
1. Introducing Agent Compute Engine and expanded agent governance
2. With Kong Volcano, Kong Hosts the Agents It Governs
3. Docker Reruns the Container Playbook, This Time for Cloud Sandbox Kit
4. OpenAI Moves Up the Stack and Competes With the Platforms It Powers
5. Google I/O: Did Google Just Ship the Full AI Stack?
Declaration of generative AI and AI-assisted technologies in the writing process: This content has been generated with the support of artificial intelligence technologies. Due to the fast pace of content creation and the continuous evolution of data and information, The Futurum Group and its analysts strive to ensure the accuracy and factual integrity of the information presented. However, the opinions and interpretations expressed in this content reflect those of the individual author/analyst. The Futurum Group makes no guarantees regarding the completeness, accuracy, or reliability of any information contained herein. Readers are encouraged to verify facts independently and consult relevant sources for further clarification.
Disclosure: Futurum is a research and advisory firm that engages or has engaged in research, analysis, and advisory services with many technology companies, including those mentioned in this article. The author does not hold any equity positions with any company mentioned in this article.
Analysis and opinions expressed herein are specific to the analyst individually and data and other information that might have been provided for validation, not those of Futurum as a whole.
Read the full Futurum Group Disclosure.
Other Insights from Futurum:
Enterprises Embrace Open Weights but Infrastructure Sellers Profit…
Google Cloud Marketplace: Can It Become Gemini’s Front Door to the…
How Apple Could Break Amazon and Google’s Hold On The Smart Home…
Author Information
Vikram Rathnam is Research Director, Software Lifecycle Engineering at The Futurum Group. His research examines how software is built, tested, secured, and operated as AI agents move from assisting developers to doing the work. His coverage includes observability, platform engineering, and the control planes that govern agents. Before joining Futurum, he spent 24 years on the vendor side: ten in engineering at Silicon Labs and fourteen in product and partner strategy, with roles at Cisco, Secureworks, Dell, and CMIT Solutions. Across those roles, he managed B2B cybersecurity, IoT, and AI products, with partner and channel ecosystems as the common thread. At CMIT Solutions, he led product strategy across a franchise network of 180 locations. He reads a vendor’s roadmap as someone who has had to ship one and take it to market.
Mitch Ashley is VP and Practice Lead for the CIO & Technology Buyers and Software Lifecycle Engineering practices at The Futurum Group. A multi-time CIO and CTO with 30+ years leading technical organizations, Mitch built and operated production systems spanning cybersecurity for the U.S. Department of Defense, PKI services for the broadband and 5G industries, SaaS platforms, large-scale telecom and banking systems, and a national broadband network. His work with AI began early, developing expert systems that diagnosed and repaired complex mainframe environments. That operator foundation grounds his analysis in operational consequence, covering the technology buyer's world of software engineering, cybersecurity, DevOps, cloud, and AI.
