Google built tiny computers for its work agents. The decisive feature is where it keeps the keys

An assistant that writes an answer is mostly a software conversation. An assistant that edits spreadsheets, runs scripts, opens websites and retrieves corporate files is a small computer operator. It needs somewhere to execute tasks, somewhere to store temporary work and, most importantly, a defensible limit on what it can touch.[1]

Google Cloud's October 22 announcement of Agent Compute Engine makes that distinction tangible. Instead of placing all agents inside a generic shared application process, the service gives individual work agents a micro-virtual machine, or microVM. Each has its own guest operating-system kernel and isolated execution context. Google says this infrastructure already supports Gemini's work-oriented agents; customers are promised a preview in the coming months, not immediate general availability.[1]

The most consequential design choice is not simply that the guest boots quickly. It is that valuable credentials remain outside the environment in which an AI agent may execute unfamiliar code. The microVM receives a short-lived identity; controlled gateway services can attach authorized credentials when an external request leaves the guest. An injected instruction or compromised script inside the agent should therefore have a harder time simply reading long-lived service secrets from the filesystem.

Separate the workshop from the keys

Imagine asking a company agent to inspect an uploaded sales workbook and write a report. It may need to execute code, read formulas, generate charts and then post a result to a company drive. The workbook is a lower-trust input: cells, macros or associated documents may contain unexpected instructions or hostile content. Giving that execution environment a standing, unrestricted drive credential would allow one mistake to become a much larger compromise.[1]

In Google's design, the microVM is the workshop. The identity, network policy and gateway are the locked doorway. The agent can perform permitted computation, while attempts to reach outside services pass through a component positioned to authorize, observe or deny them. The company's technical description pairs Cloud Hypervisor boundaries with Titanium offload infrastructure and cryptographically verified agent identities. Those are specific engineering controls, not proof that every future customer configuration will be safe.

There is an important difference between keeping a secret inaccessible and preventing a damaging action. If the gateway legitimately permits an agent to delete a file, a malicious document may still persuade the agent to request deletion through that authorized channel. Hardware isolation contains certain kinds of compromise; careful permissions, audit trails, policy checks and, for consequential work, human confirmation remain necessary.

The strange economics of a thinking computer

A conventional server tends to run continuously. An AI work agent is bursty: it thinks, runs a tool, waits for a response, pauses for a person, then resumes. Charging for a permanently active machine during that idle time would make many agent workflows unnecessarily expensive. Google says its architecture can snapshot or suspend idle microVMs and resume them rapidly, using copy-on-write memory sharing to keep many agents economical on common physical infrastructure.[1]

Persistence is the second complication. Each agent may need to come back tomorrow with its files, browser state or programming environment intact. Google describes per-agent Hyperdisk storage so the workspace can outlive an individual burst of computation. Here the challenge is to combine continuity of useful context with credentials that should not remain permanently accessible inside the guest.

The company is also expanding governance across environments, adding Agent Gateway, Registry, Identity and OpenTelemetry-compatible observability. That matters because an enterprise rarely operates a fleet with just one vendor, one runtime and one model. A registry of approved agents and tools, enforceable network policy and traceable actions may become a much more important control plane than a dashboard showing how many prompts were sent.

A product announcement, not an audited safety guarantee

The evidence currently public is Google's product and technical description. It explains architectural intentions and some use inside Gemini, but it is not a comparative, independent penetration test against every alternative sandbox. Customers cannot yet treat the announced future preview as a fully deployed service available to all. Nor does the design automatically fix errors in AI reasoning or protect data from every misconfigured access policy.[1]

Still, the direction is revealing. Once AI systems acquire the ability to act, 'which model?' is only one architectural question. The others are 'which computer?', 'whose identity?', 'what can leave the boundary?' and 'what happens if the task goes wrong?' A tiny machine per agent is a useful answer to the first two, provided the keys really stay on the other side of the door.

Report an error or suggest a correction