Evidence at a glance
Agents Alternate Between Work and Waiting
On October 22, 2026, Google Cloud announced Agent Compute Engine (ACE), a compute service designed to give each AI agent session its own execution environment. Google says ACE already runs Gemini work agents as well as internal evaluation and reinforcement-learning workloads. Customer preview is planned for the coming months, with no specific date announced.
The design addresses more than the speed of running code. Agents work intermittently: they execute a tool call, wait for a model or a user, and then continue. Google describes conventional virtual machines as providing stronger isolation but potentially taking seconds to minutes to start, pause, or resume, while containers are lighter but share the host kernel. Keeping a full VM occupied for every waiting agent can therefore put isolation and resource utilization at odds.
Keep Decisions Outside, Execution Inside
ACE separates an agent into a "brain" and "hands." The orchestration program runs outside the sandbox and decides what to do next, while a microVM inside the sandbox runs code, commands, and browser operations. Each session gets a single-tenant microVM behind a Cloud Hypervisor boundary. This does not mean one physical server per agent: the isolated environments run on Google-managed hosts, which Google says use Titanium IPUs and Titan silicon.
The separation changes the default assumption about compromise. Rather than trusting the code in the sandbox to be safe, the system can treat it as potentially controlled by prompt injection or malicious input, then constrain its capabilities. The orchestrator dispatches explicit operations for the sandbox to execute, putting agent reasoning and code execution on different sides of a trust boundary.
No Credentials Does Not Mean No Access
ACE's security argument is not just to contain dangerous code, but to avoid placing reusable business credentials inside the sandbox. Google says the microVM holds no persistent credentials, OAuth refresh tokens, or cloud service account keys, and cannot access the instance metadata server. It also has no standard network interface, default gateway, or direct VPC access. Requests travel through an isolated local channel to an external Agent Gateway, which checks identity and policy before inserting the required backend credential as the request leaves the gateway.
Google distinguishes four identities for an agent workload: the user identity for the overall task, a delegated identity stored in a central authorization service, a short-lived Agent Workload Identity for sandbox traffic, and the agent's own Agent Workforce Identity. For sandbox network traffic, the workload identity identifies which sandbox sent a request; if exposed, it cannot by itself call a business API. In other words, no credentials does not mean no access. The effective boundary still depends on gateway policy, the scope of delegated authorization, and how the task is designed.
Suspension Is Part of the Design, Not Proof of Performance
When an agent waits, ACE is said to checkpoint its microVM and release active compute resources, then restore it from a snapshot when the next tool call arrives. Pre-warmed snapshots and copy-on-write are intended to reduce duplicated memory use: agents can share unchanged base-system pages, while pages they modify become private. Storage is also divided into disposable scratch overlays, shared read-only volumes, and persistent user workspaces, rather than forcing every kind of state into the same lifecycle.
The public efficiency evidence, however, mainly concerns the open-source sibling project Agent Substrate, not ACE. One Google-reported result gives Substrate 500 activations per second and suspend/resume below 500 milliseconds across 200,000 agents. A separate technical brief cites more than 1,500 activations per second, recovery below 400 milliseconds, and up to 10 times the compute density. The materials do not explain the difference in test conditions, and Google has published no ACE-specific boot time, host density, price, or cost-saving figure. Those numbers should not be projected onto the managed service.
Validate the Permission Boundary Before Betting on the Service
For technical leaders, the most useful lesson is not the slogan "one microVM per agent," but the separation of execution from authorization. If an agent must run untrusted code while accessing enterprise data, teams can first check whether their architecture keeps long-lived credentials out of the sandbox, routes egress through a policy gateway, and grants only the scope needed for each task. The open-source Agent Substrate runs on Kubernetes and can help teams test isolation, identity, and suspend-resume workflows, but it cannot substitute for performance evaluation of ACE as a managed service.
The limits should remain explicit: Google's claims about hardware isolation, releasing resources while idle, and fast recovery are not yet backed by public ACE-specific independent audits or performance data. A microVM alone cannot guarantee agent security. Misconfigured gateway policies, overly broad authorization, or poorly managed persistent workspaces can still create exposure. A prudent sequence is to validate the permission model and failure boundaries, measure recovery latency and cost on real workloads, and then weigh the convenience of a managed service against platform dependence once Google publishes pricing, preview terms, and service-level data.