Google introduces isolated cloud computers for AI agents, with rollout still ahead

Google Cloud introduced Agent Compute Engine on October 22, a service designed to give each AI agent its own isolated cloud computer. The platform separates agents’ working environments from long-lived credentials and pauses idle sandboxes to conserve resources. Rollout is planned in the coming months alongside an updated Agent Gateway, according to SiliconANGLE.

The service hosts the part of an agent that actually does things: running code, issuing commands and operating a browser. Google’s technical explanation separates that sandbox—the agent’s “hands”—from its harness, the software that calls the model and decides what happens next. The harness runs outside the sandbox and sends it explicit commands, keeping orchestration separate from potentially untrusted execution.

Keeping the workspace, not the idle machine

Google describes a gap between two familiar ways of hosting software. Traditional virtual machines offer strong separation and broad operating-system control, but starting, suspending and resuming them takes seconds to minutes. Containers are lighter and faster because they share the host operating system’s core. Some coding agents, however, need both complete isolation and deep control of their environment.

Agents also spend time waiting between steps. Destroying their environment loses working state and forces a rebuild; leaving a dedicated machine running wastes resources. Google says its microVMs—small, hardware-isolated virtual machines—aim to combine virtual-machine isolation with container-like speed and density. Agent Compute Engine detects idle sandboxes, shuts them down and reactivates them when needed.

The lifecycle tools go beyond restarting an agent. Google also describes cloning, snapshots, branching, rewind and rollback, intended to let agent software reuse environments without duplicating resources unnecessarily.

Assume an attacker controls everything inside the sandbox, and make sure they find nothing there to use.

Ramanathan Venkatapathy and Rohit Jnagal, Google Cloud distinguished engineers

Credentials stay outside the sandbox

Google explains its security premise with a malicious-email scenario: an inbox agent encounters hidden instructions to find API keys and send them away. The company says it cannot rely on models or system instructions to reject every malicious instruction. Its response is architectural: keep user credentials, API keys, refresh tokens and cloud service-account keys out of the sandbox.

That does not mean the sandbox has no identity. Each microVM receives a short-lived identity that identifies which sandbox originated a request. Google says that identity cannot directly call a backend application if stolen. Long-lived user credentials remain off-host; Agent Gateway supplies the credentials only after checking the session’s identity and outbound-access policy.

Network access is similarly constrained. MicroVMs have no standard virtual network interface, default gateway or direct access to a customer’s private cloud network. Instead, traffic passes through an isolated communication boundary and intermediary proxies. An external gateway checks the requested scope and applies outbound policies before forwarding it.

Below those controls, Google says Titan chips verify hardware and firmware integrity. The host runs a read-only operating-system filesystem with no persistent local state. Its Titanium infrastructure processor also mediates storage access, using machine-bound cryptographic permissions to prevent a compromised sandbox or host from accessing volumes across customer or node boundaries.

From browser tasks to training environments

Google designed the platform around four workload groups, spanning interactive products and the systems used to develop models:

• Consumer and enterprise agents that run code, use interactive shells or navigate websites on a user’s behalf.
• Software-engineering workspaces with administrator access, compilers and development tools, retained across days or weeks of work.
• Model evaluations and reinforcement-learning pipelines that create and branch thousands of parallel test environments.
• Shared sandbox infrastructure for Google services that need to execute dynamic code and user-driven actions.

The accompanying Agent Gateway update addresses model use and spending. Planned routing will send requests to the model judged most efficient for the task. Token-management controls are intended to track consumption across agents and models, attribute spending and enforce budgets. Those controls govern inference costs—the cost of model responses—rather than the sandbox computing resources Agent Compute Engine manages.