Google is putting AI agents in separate virtual machines

Google's most useful AI announcement this morning is not a new model. It is a set of places where the model is not trusted.

At I/O Connect India, Google announced new cybersecurity agents, session protections and payment rules. The most concrete piece is CAPSEM: an open-source runtime that places each AI coding agent in a separate Linux virtual machine.

The idea is simple. If an agent is tricked by a malicious prompt, do not let that agent share the same room as the credentials and systems it could damage.

A smaller room, with one guarded door

CAPSEM's public repository says each session runs in a hardware-isolated VM on macOS or Linux. The root filesystem is read-only. The workspace is temporary. Network traffic cannot go straight to the internet; it passes through a proxy on the host computer, where rules can inspect and block requests. Tool calls through the Model Context Protocol can be checked there too.

Raw credentials stay outside the VM. The agent can ask the host to make an approved connection without receiving the underlying secret.

This does not prevent prompt injection. A poisoned webpage can still persuade an agent to attempt the wrong action. What changes is the consequence: the compromised agent has less to steal, fewer places it can reach and a record of what it tried to do.

That is a stronger security argument than asking the same model to notice that it has been manipulated.

The same rule appears around logins and payments

Google paired CAPSEM with two other efforts that follow the same pattern.

Device Bound Session Credentials, or DBSC, links a web session to a private key held on the user's device. A stolen cookie is less useful on another machine because the attacker cannot prove possession of that key. But Google's description calls DBSC a standard too early: the W3C document is still a First Public Working Draft. It also says plainly that DBSC cannot stop malware already resident on the device from using the active browser session.

The Agentic Payment Protocol, or AP2, draws an even clearer line. Its v0.2 specification says the interface that gets a person's consent must be non-agentic, and that authorization checks must run in deterministic code. The shopping agent can assemble a purchase. Signed mandates and receipts are supposed to prove what the person allowed, what the agent bought and what the payment system accepted.

In each case, the AI proposes or acts inside a limited space. A separate system holds the key, checks the rule or produces the evidence.

Isolation is not immunity

Google says CAPSEM keeps the wider system “fully protected” if an agent is compromised. That is too strong. Virtual machines, proxies, policies and credential brokers all contain software and configuration that can fail.

There is another trade-off. CAPSEM's documentation says its proxy can inspect encrypted traffic and store full request and response bodies in a per-session database. That is valuable for audits. It also creates a sensitive new record of everything the agent saw and sent. Retention, access control and deletion now matter.

The project's status is also unusual. Google announced that it is open-sourcing CAPSEM, and the code sits under the google GitHub organization. The repository itself says it is not an official Google project and is not supported by Google. Readers should treat the architecture as public and testable, not as a security guarantee backed by Google.

The important shift is still real. Agent safety is becoming ordinary computer security: smaller compartments, secrets held elsewhere, narrow permissions and logs that survive the model's explanation of what happened.

The test is no longer whether an agent promises to behave. It is what the surrounding system lets a misbehaving agent do.

---

Source graph: Semble