# Google Agent Compute Engine separates agent execution from credentials > Google detailed the microVMs, credential gateway and saved state behind Agent Compute Engine. It powers internal agents; an external preview is still ahead. By BIGCHANGE.AI Editorial Published: 2026-10-24T07:30:38.731Z Updated: 2026-10-24T07:30:38.731Z Canonical: https://bigchange.ai/blog/google-agent-compute-engine-microvm-identity-preview ![Conceptual charcoal illustration of a blank computer inside a clear enclosure, with a separate closed key safe beside it.](https://bigchange.ai/api/media/file/google-agent-compute-engine-isolated-execution-hero-v2.png) AI-generated conceptual illustration by BIG CHANGE; no actual Google facility, Agent Compute Engine machine, credential, customer deployment or verified security outcome is depicted. Google has described the infrastructure behind agents that run code and use connected resources in its own products. [Agent Compute Engine](https://cloud.google.com/blog/topics/ai-infrastructure/introducing-agent-compute-engine-and-expanded-agent-governance), announced on October 22, gives an agent a dedicated microVM for execution. Google says it already powers Gemini and other internal workloads. Developers outside Google are being asked to [register interest](https://cloud.google.com/blog/topics/ai-infrastructure/agent-compute-engine-deep-dive/) for a preview targeted in the coming months. The design separates the program that decides an agent's next step from the computer that carries it out. It also keeps long-lived user and service credentials outside that computer. Those choices matter to teams considering agents that need a shell, browser, saved workspace and access to company data, although Google's account does not establish how the eventual customer service will perform in independent use. ## The big change - **What changed:** Google has put a name and architecture behind the computers used by its agents: dedicated, hardware-isolated microVMs with separate orchestration, mediated network access and saved workspaces. The external service remains a future preview. - **Why it matters:** An agent can execute untrusted code while its authorization to reach a document or internal service is checked outside the guest. That gives administrators a place to set access policy, while leaving the model's decisions and the policy configuration to be evaluated separately. - **What to watch:** The preview's actual interface, access terms and pricing will determine whether outside teams can use these boundaries for their own agents. Google has not published those details in the announcement or deep dive. ## One agent, two different components In [Google's technical account](https://cloud.google.com/blog/topics/ai-infrastructure/agent-compute-engine-deep-dive/), the *harness* calls the model and decides what to do next. The *sandbox* runs the requested code, shell commands or browser. Google says its product teams write and trust their own harnesses; Agent Compute Engine supplies the execution environment. This distinction keeps a developer's orchestration logic outside the guest where model-directed code runs. Each session gets a dedicated microVM with its own guest kernel. Google describes this as a hardware isolation boundary, unlike a container that shares the host kernel. The company says the guest has no ordinary network interface, default gateway or direct VPC access. Traffic crosses a `virtio-vsock` boundary to a local mediation proxy and then an external gateway, where policy governs outbound requests. That path is central to the security design: isolating code on a guest machine alone would not decide which company resources it may contact. ## Credentials are brokered beyond the guest Google's account distinguishes the user who initiated a task, the user's delegated authorization, the short-lived identity assigned to the microVM, and an agent identity that can have its own resources. The guest uses a session-scoped workload identity to identify its outbound traffic. Long-lived user grants and backend credentials stay outside it. According to Google, Agent Gateway checks the user delegation, agent and node identities and applicable egress policy before adding the credential required by a destination service. That design narrows what an attacker could take directly from a compromised guest, according to Google. It does not mean the agent has no identity or that a permitted request cannot cause harm. Google itself describes malicious instructions in content an agent reads as a design concern. The gateway's permissions, the harness's choices and the destination service still determine what an authorized agent can do. These are architectural claims from the provider, not the result of an independent security assessment of Agent Compute Engine. For enterprise access, Google describes administrator-defined reachability to approved Workspace APIs, private VPC endpoints and external domains through Agent Gateway. It says requests are checked against delegated authority and policy outside the sandbox. Teams evaluating the future service will need the released controls and documentation to judge how those rules are configured and audited in their own environments. ## Saved work without an always-running machine Agents often wait for a model response or a user. Google says its runtime detects when a tool call ends and no background task remains, then checkpoints the microVM and returns its active resources to the host. It can restore the session for the next command. Google also describes shared, prewarmed base images and copy-on-write memory pages to reduce duplicate use of physical memory. The post offers architectural explanation, but no customer price or independently verified speed and density comparison for Agent Compute Engine. Persistence has a separate storage boundary. Google divides data into disposable scratch space, shared read-only assets such as toolchains, and durable user workspaces containing saved work and artifacts. Its [launch announcement](https://cloud.google.com/blog/topics/ai-infrastructure/introducing-agent-compute-engine-and-expanded-agent-governance) says Hyperdisk underpins persistent execution workspaces. Keeping that state across sessions can avoid rebuilding an environment after every pause; it also makes retention and access to saved work a question for the eventual customer controls. ## Internal use now, external preview later Google says Agent Compute Engine powers Gemini, Antigravity and internal evaluation and reinforcement-learning workloads. The October 22 announcement says the service will be available to outside developers in preview in the coming months; the [deep dive](https://cloud.google.com/blog/topics/ai-infrastructure/agent-compute-engine-deep-dive/) repeats that target. Neither supplies a firm date, public setup procedure, supported image or API specification, regions, eligibility rules or Agent Compute Engine price. Its published architecture is useful for evaluating the proposed boundaries today, while implementation planning must wait for actual preview terms and documentation. This is a separate infrastructure disclosure from Google's earlier [Gemini Agent announcement for enterprise work](https://bigchange.ai/blog/google-gemini-agent-work-enterprise-controls-launch). The earlier story covered the work-agent offering and controls; this one explains the runtime Google says underlies agent execution. ## Sources & further reading - [Google Cloud: Introducing Agent Compute Engine and expanded agent governance](https://cloud.google.com/blog/topics/ai-infrastructure/introducing-agent-compute-engine-and-expanded-agent-governance): October 22 announcement. It establishes Google's stated internal use and the target of an external preview in the coming months; it does not provide customer pricing or a release date. - [Google Cloud: Inside Agent Compute Engine](https://cloud.google.com/blog/topics/ai-infrastructure/agent-compute-engine-deep-dive/): Google's architecture account for the harness, microVM, credential broker, network path and persistent state. These are provider descriptions, without an independent security or performance test. - [Google Cloud documentation: Agent Identity overview](https://docs.cloud.google.com/iam/docs/agent-identity-overview): background on Google's agent identity and credential management services. The documented service family does not establish that Agent Compute Engine is already open for customer deployment. ## Sources - [Google Cloud: Introducing Agent Compute Engine and expanded agent governance](https://cloud.google.com/blog/topics/ai-infrastructure/introducing-agent-compute-engine-and-expanded-agent-governance) — Original announcement for internal use, service architecture and external preview target. Provider claims, not an independent deployment or benchmark test. - [Google Cloud: Inside Agent Compute Engine](https://cloud.google.com/blog/topics/ai-infrastructure/agent-compute-engine-deep-dive/) — Detailed provider architecture account. The trailing-slash URL rendered October 22 while no-slash rendered October 23 in the same review; reason unresolved. No independent security or performance test. - [Google Cloud documentation: Agent Identity overview](https://docs.cloud.google.com/iam/docs/agent-identity-overview) — Context on identity and credential management; not an Agent Compute Engine availability statement.