Google has described an architecture in which each AI agent runs inside its own microVM and the sandbox never holds a credential. In an Agent Compute Engine deep dive by two Google Distinguished Engineers, the company says the platform already powers Gemini, Antigravity and internal evaluation pipelines, with a preview on Google Cloud "targeted" for the coming months. The design is more interesting than the product: it takes the threat model most coding-agent users worry about, an agent that reads hidden instructions and tries to exfiltrate keys, and answers it by making sure there is nothing in the box to steal. If you run Claude Code, Codex or similar agents locally, several of the ideas transfer.
| Question | Short answer |
|---|---|
| Can I use it today? | No. Internal to Google; preview "in the coming months", no pricing or GA date |
| What is the core idea? | Assume an attacker controls everything inside the sandbox, and leave nothing there to use |
| Where do credentials live? | Outside the microVM; an off-node gateway inserts them as requests leave |
| Is it a security guarantee? | It is a vendor design description. The post gives no audit results or benchmarks |
| What can I copy locally? | Secret-free sandboxes, egress policy, harness and sandbox separation, audit trails |
What Google published
The post frames the problem as needing "both the isolation of a VM and the speed and density of a container." Plain containers share the host kernel, which is a poor fit for coding agents that want root and kernel control; traditional VMs boot too slowly for agents that start and stop constantly. Agent Compute Engine (ACE) splits each agent in two:
- The harness, or "brain," calls the model and decides the next step. It runs outside the sandbox.
- The sandbox, or "hands," runs the code, shell commands and browser the model requests.
That separation is the same distinction we describe in our explainer on agent harnesses. Putting the model-calling loop outside the box means a compromised sandbox cannot rewrite the agent's own decision logic or reach its model credentials.
The isolation layers
Google describes several layers. Each session runs in a "dedicated, single-tenant and memory-safe microVM," with CPU side-channel mitigations. Hosts are described as a stateless, immutable appliance running a read-only root filesystem enforced by dm-verity with no persistent local state, with boot integrity verified by Google's Titan silicon before scheduling. Attestation keys stay outside the guest, and the Titanium IPU mediates block storage with instance-bound cryptographic grants. The post also lists automated patching, host intrusion detection, continuous fuzzing, CI/CD vulnerability scanning and regular red-team exercises, without publishing results from any of them.
Guests, Google says, "only execute explicit commands dispatched by the harness and stream output back," which produces "a deterministic audit trail" linking each tool call to sandbox activity. That audit property is worth copying in spirit: if every action has a recorded cause, review stops being guesswork.
No credentials in the sandbox
Google's stated rule is: "Assume an attacker controls everything inside the sandbox, and make sure they find nothing there to use." The motivating example is an agent that reads an email carrying hidden instructions to exfiltrate API keys. Google says it "could not rely on unknown models and system instructions to ignore every malicious user instruction and tool response," so the design removes the prize instead. In its words, a microVM "never holds user credentials, API keys, OAuth refresh tokens, or cloud service account keys in its memory or on its disk."
How does the agent still call anything? The microVM has no standard network interface, default gateway or direct VPC access. Traffic crosses a virtio-vsock boundary to a local unprivileged proxy and on to an external Agent Gateway that "validates request scopes, and enforces strict, policy-driven outbound brokering." Google describes four identities: the user's, a delegated on-behalf-of grant kept in a central authorization service, a short-lived attested SPIFFE-based workload identity that is the only one used for sandbox traffic, and a workforce identity for agents with their own accounts. The workload identity "is not usable to call a backend API directly" if stolen. The gateway evaluates egress and data-loss-prevention policy and inserts the backend credential "as the request leaves the gateway," so the backend sees which agent acted for which user.
This is the strongest defense against the class of attack in our write-up of agentjacking through MCP: prompt injection still happens, but it finds no secrets to read.
Idle handling and cost
Much of the post is about economics. Agents "spend most of their lives waiting," so the sandbox signals when no commands or background tasks are in flight and the host checkpoints it to "zero active resources." Pre-warmed snapshot images are mapped with DAX and copy-on-write clones so VMs share one physical copy of the base system, and snapshot, fork and rewind are supported. Storage has three tiers: ephemeral scratch, read-only shared volumes, and persistent user workspaces on encrypted Hyperdisk. These are efficiency features, not security ones, though fork and rollback also make it cheaper to undo an agent's damage.
Reachability and governance
Google says administrators define reachability through the Agent Gateway and on-demand private network attachments such as Private Service Connect and VPC Service Controls: which VPC endpoints, Workspace APIs or external domains an agent may touch, with "all assets protected by default." Every action respects Cloud IAM and VPC Service Controls perimeters and produces end-to-end audit logs, "without a single enterprise credential ever entering the sandbox." Governance components built on the Gemini platform include an Agent Registry that catalogs plugins, skills, MCP servers and agent-to-agent peers, an Agent Identity vault and broker, and the Agent Gateway for runtime policy enforcement.
The registry is the piece most relevant to anyone worried about untrusted extensions. A catalog of approved skills and MCP servers is the managed-cloud equivalent of reviewing a skill before you install it, a habit we describe in our guide to reviewing MCP servers. Google does not say how entries are vetted, and the post does not describe scanning.
Where the design leaves gaps
Reading the post critically, three limits stand out. First, secret-free sandboxes protect credentials, not data: an agent that can read your repository can still be tricked into sending its contents to an allowed destination, which is why the gateway's data-loss-prevention policy matters and why Google gives no detection numbers. Second, the harness sits outside the sandbox and is therefore the high-value target; the post does not describe how it is protected beyond the general host-hardening list. Third, everything here is a vendor description of an internal system. There is no third-party assessment, no published escape testing and no incident history to weigh. These are reasons to borrow the principles and wait for evidence before relying on the product.
What the press coverage added, and what we could not confirm
The Decoder's summary says Google open-sourced a Kubernetes runtime called Agent Substrate that fits about ten times as many agents per server, and reports suspend and resume under 500 milliseconds in a test with 200,000 agents. In the Google deep dive we read, the term "Agent Substrate" does not appear and there are no benchmark numbers; the post uses only qualitative claims such as "orders of magnitude more living agent microVMs than conventional VMs." The figures may come from another Google announcement we did not find, so treat them as unverified until you see them in a primary source. Likewise, the post describes no threat-model audits or certifications.
What this means if you run AI coding agents
You do not need Google's hardware to apply the pattern. Practical steps for a local setup:
- Take secrets out of the agent's reach. Keep API keys, cloud credentials and tokens out of project directories and shell environments the agent inherits. Use short-lived, scoped credentials where the provider supports them.
- Add an egress control. Route agent traffic through something that can allow or deny destinations, even a simple proxy or firewall rule set. Our write-up of a VM sandbox for coding agents covers an open-source take on this.
- Separate deciding from doing. Where your tooling permits, keep the model-calling process from having the same filesystem rights as the commands it requests.
- Keep a cause-and-effect trail. Record which tool call produced which file change or network request, so you can answer what happened after an injection.
- Remember isolation is not detection. A microVM contains damage; it does not tell you an agent was manipulated. Pair containment with monitoring, as we argue in monitor versus block. The related Perplexity sandbox escape report is a reminder that sandboxes can fail.
What Beam can and cannot do here
Beam is not a microVM and not a kernel sandbox. It runs locally and watches what Claude Code, Codex and similar agents do, flags risky actions such as credential exposure and destructive commands, and can deny through Claude Code and Codex PreToolUse hooks. Secrets Beam sees are redacted before storage, and data stays on your device (how it works, local-first). That is complementary to Google's design: isolation limits what a compromised agent can reach, while hook-based watching tells you what it tried. Beam's deny is hook-based and heuristic, and it fails open when no cached policy is available, so do not treat it as a substitute for a real sandbox. For command-level deny rules, see stopping dangerous Claude Code commands.
Frequently asked questions
What is Google Agent Compute Engine?
It is a compute platform Google says runs large numbers of AI agents, giving each session a dedicated single-tenant microVM while the agent harness that calls the model runs outside the sandbox. It is internal to Google today, with a preview targeted for the coming months.
How does it keep credentials safe?
According to Google, a microVM never holds user credentials, API keys, OAuth refresh tokens or cloud service account keys. Traffic goes through a local proxy to an off-node Agent Gateway that validates scopes and inserts the backend credential as the request leaves the gateway.
Is it available to use now?
No. Google says it powers Gemini, Antigravity and internal pipelines, and is targeted for preview on Google Cloud in the coming months. No pricing or general availability date is given.
Did the press coverage match Google's post?
Partly. The Decoder mentioned an open-sourced Agent Substrate runtime and a sub-500 millisecond resume figure for 200,000 agents; neither appears in the Google deep dive we read, which gives only qualitative density claims. Treat those details as unverified.
What can I copy for local coding agents?
Keep secrets out of places the agent can read, route outbound traffic through a policy point, separate the model-calling harness from execution, and keep an audit trail linking each tool call to its effects.
Does Beam replace a microVM?
No. Beam is not a kernel sandbox. It watches agent actions on your machine, flags risky ones, and can deny them through Claude Code and Codex PreToolUse hooks, so it complements isolation rather than replacing it.
Related reading
- What are agent harnesses?
- A VM sandbox for AI coding agents
- Agent security: monitor versus block
- Agentjacking via MCP
- Google's Agent Compute Engine deep dive
Details reflect Google's published post and press coverage as of October 22, 2026; the product is not yet available and plans may change. Beam is a local prototype; features described are as documented at the time of writing.