Google kündigt Agent Compute Engine mit isolierten MicroVMs an

Google hat am 22. Oktober 2026 Agent Compute Engine angekündigt, einen Dienst, der jedem KI-Agenten eine eigene isolierte virtuelle Maschine zuteilt, berichtet The Decoder. Intern läuft Gemini bereits darauf. Für Google-Cloud-Kunden ist erst eine Preview geplant, laut Google-Cloud-Blog in den kommenden Monaten.

Das Problem dahinter beschreibt Google im Cloud-Blog: Jeder Agent braucht einen eigenen Rechner, ist zwischen den Modellschritten aber oft untätig. Eine dauerhaft laufende VM für jeden wartenden Agenten verschwendet Ressourcen. Wird die Umgebung dagegen bei jedem Schritt abgebaut, geht der Arbeitsstand verloren und muss beim nächsten Mal langsam neu aufgebaut werden.

Warum weder klassische VMs noch Container passen

Die Gemini-Teams teilen jeden Agenten in zwei Teile. Der Harness ruft das Modell auf und entscheidet über den nächsten Schritt. Die Sandbox führt Code, Shell-Befehle und den Browser aus, die das Modell anfordert.

Für diese Sandbox taugen die üblichen Bausteine nur bedingt. Eine klassische VM bootet laut Google eine vollständige Maschine, und schon das Fortsetzen dauert Sekunden bis Minuten. Bei Agenten passiert das ständig. Container sind schnell und leichtgewichtig, teilen sich aber den Kernel des Host-Betriebssystems. Coding-Agenten und Entwicklerassistenten brauchen nach Google-Angaben vollständige Isolation sowie Kernel- und Root-Zugriff auf ihre Umgebung.

Gesucht war also die Isolation einer VM mit Tempo und Dichte eines Containers.

Titanium und eine Sandbox ohne Geheimnisse

Jeder Agent läuft laut Google in einer MicroVM, die durch den Titanium-Chip abgesichert ist, berichtet The Decoder. Im Cloud-Blog beschreibt Google Titanium als eigene Chiparchitektur, die unter anderem kryptografische Vertrauensfunktionen von der Host-CPU auslagert. Jede Agentensitzung läuft demnach in einer eigenen MicroVM.

Dazu kommt der Umgang mit Zugangsdaten. Dauerhafte Geheimnisse wie API-Keys oder OAuth-Refresh-Tokens liegen laut Google weder im Speicher noch auf der Platte der MicroVM. Die Sandbox erhält nur ein kurzlebiges, an die Sitzung gebundenes Identitätstoken. Die langlebigen Nutzer-Credentials bleiben außerhalb des Hosts, und erst ein externes Agent Gateway setzt sie in ausgehende Anfragen ein, nachdem es die Identität der Sitzung und ihre Regeln für ausgehenden Verkehr geprüft hat. Auch eine normale Netzwerkkarte fehlt. Sämtlicher Verkehr läuft über einen vermittelnden Proxy außerhalb der Sandbox.

Google begründet das mit einem hypothetischen Fall: Ein Agent verwaltet ein Postfach, und eine E-Mail enthält versteckten Text, der ihn auffordert, API-Keys auf der Maschine zu suchen und zu verschicken. Darauf, dass ein Modell jede solche Anweisung ignoriert, will sich Google nicht verlassen. Die Sandbox ist deshalb um eine Annahme herum gebaut: Ein Angreifer kontrolliert alles darin, soll dort aber keine langlebigen Nutzer- oder Dienstzugangsdaten vorfinden. Selbst das kurzlebige Sitzungstoken taugt laut Google nicht für direkte Backend-Aufrufe, falls es abfließt.

Ergänzend: Bearer-Tokens in Agentenaufrufen: Warum Zugangsdaten nicht in URLs gehören.

Pause im Leerlauf

Bei Inaktivität pausiert die VM automatisch und gibt die Maschine für andere frei, schreibt The Decoder. Google begründet das mit eigenen Messungen: Agenten verbringen den Großteil ihrer Zeit mit Warten. Sie warten auf den nächsten Schritt des Modells oder auf die Antwort des Nutzers.

Der Ablauf ist an die Agentenschleife gekoppelt. Beendet ein Agent einen Tool-Aufruf, meldet die Sandbox, dass keine Befehle oder Hintergrundaufgaben mehr laufen. Der Host sichert dann den Zustand der Sandbox und schaltet sie auf inaktiv. Bis zum nächsten Tool-Aufruf belegt sie laut Google keine aktiven Ressourcen auf dem Host, danach wacht sie mit erhaltenem Zustand wieder auf.

Hinzu kommt der Speicher. Wie The Decoder berichtet, senkt geteilter Speicher zwischen den VMs die Kosten jeder einzelnen im Betrieb. Technisch teilen sich laut Google alle MicroVMs eines Hosts dieselben physischen RAM-Seiten, etwa für das Basis-Betriebssystem. Eigener Speicher fällt nur für die Seiten an, die ein Agent tatsächlich verändert. Wie viel das in einem konkreten Einsatz spart, bleibt offen.

Kontrollen und Fahrplan

Für die Aufsicht ergänzt Google laut The Decoder unter anderem Token-Tracking und die Anbindung externer Identitätsanbieter wie Ping Identity und SailPoint; diese Kontrollen sollen auch für Cloud Run und GKE gelten. In der Cloud-Version sollen Entwickler ihre Umgebungen laut Google-Cloud-Blog selbst konfigurieren, vom Image bis zum Netzwerkzugriff, während Google die Flotte darunter betreibt.

Ein Termin für die Preview steht nicht fest; Interessenten können sich vormerken lassen. Weiterlesen: TrueForge bündelt Agenten-Harness, Sandboxing und Self-Hosting.

Offen bleibt die Bewertung von außen. Isolation und Umgang mit Zugangsdaten beschreibt bislang nur Google selbst, eine unabhängige Prüfung nennen die Quellen nicht.