„Securely running autonomous agents is fundamentally an infrastructure challenge.“ Mit diesem Satz eröffnen Nirav Mehta, Michael Bachman und Kevin Hutchins ihre Ankündigung. Er klingt dramatischer, als er ist. Dahinter steht eine Beobachtung, die jedes Team macht, das KI-Agenten von der Demo in den Dauerbetrieb bringt: Das Modell ist selten das Problem, die Umgebung drumherum ist es.
Der Wechsel von einzelnen Prompt-Antworten zu interaktiven Agenten verändert, was die Recheninfrastruktur leisten muss. Google hat auf der AGNTCon + MCPCon reagiert und die Agent Compute Engine vorgestellt, einen Compute-Dienst für agentische Workloads, der Gemini intern schon für Arbeitsschritte antreibt. Verfügbar sein soll er in den kommenden Monaten als Preview, mit einer hardware-isolierten Laufzeitumgebung. Dazu kommt ein Ausbau der Governance-Funktionen, mit denen sich Agenten über verschiedene Umgebungen hinweg steuern und prüfen lassen.
Am besten lässt sich das mit einem Gebäude voller einzelner Werkstätten beschreiben. Jeder Agent bekommt seine eigene, abgeschlossene Werkstatt mit eigenem Schloss, eigenem Ausweis und eigenem Lager. Ist er fertig, wird die Werkstatt nicht abgerissen, sondern eingemottet, und der Platz im Gebäude steht in der Zwischenzeit anderen zur Verfügung. Genau diese Idee steckt in der Agent Compute Engine, und sie erklärt fast jede technische Entscheidung der Ankündigung.
Warum klassische Server für KI-Agenten schlecht passen
Herkömmliche Compute-Primitive sind für Standardlasten hervorragend geeignet, aber sie wurden nicht für die Eigenheiten von KI-Agenten entworfen. Ein Agent schreibt und führt Code aus, ruft Werkzeuge auf, steuert Browser, orchestriert Unternehmensabläufe und wiederholt das in schneller Folge. Die Lebensdauer eines Agenten ist sprunghaft: starten, rechnen, pausieren, weiterrechnen. Ein Container, der für eine Anfrage hochgefahren wird und dann untätig herumsteht, passt schlecht zu diesem Muster.
Google beschreibt die eigene Last als groß und stark schwankend. Dort liegt das Problem: Wenn ein Agenten-Durchlauf oder ein Auswertungslauf auf Sekunden beim Hochfahren wartet, wird jede Iteration teuer. In der Werkstatt-Analogie wäre das ein Raum, dessen Tür erst mehrere Minuten entriegelt werden muss, obwohl der Handwerker nur zwanzig Sekunden darin arbeitet. Die Agent Compute Engine setzt deshalb nicht bei der Rechenleistung an, sondern beim Lebenszyklus.
MicroVMs, Copy-on-Write und das Pausieren im Denkmodus
Das Kernstück sind MicroVMs, die sehr schnell starten. Damit sich viele Agenten eine physische Maschine teilen können, ohne dass die Kosten explodieren, nutzt der Dienst Copy-on-Write-Speicherfreigabe: Mehrere Agenten laufen auf demselben Betriebssystem-Template, teilen sich also den Bauplan, aber nicht ihre Möbel. Dazu kommt schnelles Einfrieren und Wiederherstellen über Checkpoints, sodass untätige MicroVMs keinen aktiven Platz mehr belegen.
Aufschlussreich ist der Übergang, den Google beschreibt. Beendet ein Agent einen Werkzeugaufruf und wechselt in die Denkphase des agentischen Kreislaufs, meldet die MicroVM ihre Untätigkeit. Der Host verschiebt sie vom aktiven in den ruhenden Zustand und sichert den Speicherstand. Wartet ein Agent auf einen Menschen oder ein externes System, läuft die Uhr also nicht weiter. Das ist der Unterschied zwischen einer Werkstatt, die abgebaut wird, und einer, die nur abgedeckt wird.
Für Dauerhaftigkeit bekommt jede MicroVM eine eigene Hyperdisk. Damit überleben Arbeitsstände und Kontext eines Agenten mehrere lange Sitzungen hinweg, und Unternehmensdaten lassen sich nutzen, ohne sie vorher zu verschieben. Weil die Agent Compute Engine direkt in Googles Cloud- und Identitätsgefüge eingewoben ist, gilt für die Anbindung an Unternehmenssysteme dasselbe Sicherheits- und Identitätsmodell wie für die MicroVM selbst, inklusive Nachvollziehbarkeit.
Sicherheit als Bauprinzip: Titanium, Hypervisor-Grenze und eigene Identität
Der Dienst läuft auf Titanium, Googles ausgelagerter Infrastructure Processing Unit, und liefert damit eine im Silizium verwurzelte Verteidigung in der Tiefe. Die Isolation entsteht über eine hardwaregetrennte Cloud-Hypervisor-Grenze mit eigenem Gast-Kernel und eigenem Root-Zugang. Jede MicroVM führt die Identität ihres Agenten mit kurzlebigen Zugangsdaten, besitzt eine kryptografisch verifizierte ID, und Dienstanmeldedaten werden beim ausgehenden Verkehr außerhalb der MicroVM injiziert.
Das dient nicht nur der Hygiene. Sobald Agenten fremden oder feindlichen Code ausführen, wird aus einer harmlosen Prompt-Injection im schlechten Fall eine Codeausführung mit Zugriff auf Unternehmensdaten. Wer KI-Agenten produktiv einsetzt, braucht deshalb eine Laufzeitumgebung, die dem Agenten selbst nicht vertraut. Zusammen mit dem Agent Gateway entstehen Beobachtbarkeit, Richtlinienprüfung und Sicherheitsbewertung an einer zentralen Stelle statt in jedem Agenten einzeln.
Agent Substrate: derselbe Ansatz für Kubernetes und Multi-Cloud
Für Plattformteams, die bereits auf Kubernetes standardisiert haben oder Portabilität über mehrere Clouds brauchen, gibt es Agent Substrate auf Google Kubernetes Engine. Die Laufzeit ist quelloffen, folgt einer Zero-Trust-Architektur und trennt die Ausführung des Agenten sauber von der Verwaltung der Maschine. Wird ein Agent untätig, sichert das System seinen aktiven Speicher und gibt den Rechner an den Pool zurück; sobald er wieder gebraucht wird, läuft er weiter.
Google nennt konkrete Zahlen: bis zu zehnfache Rechendichte gegenüber klassischem Compute bei voller Kernel-Isolation, und in einem Benchmark mit 200.000 Agenten wurden 500 Aktivierungen pro Sekunde bei weniger als 500 Millisekunden für Aussetzen und Fortsetzen erreicht. Jede Sandbox nutzt wahlweise MicroVMs oder gVisor, jeder Agent erhält eine eigene kryptografisch sichere Identität, und Egress-Proxys setzen feingranulare Netzwerkrichtlinien durch. Das läuft auf jedem Kubernetes-Cluster und mit gängigen Agenten-Frameworks, ausdrücklich genannt werden Claude Code, OpenClaw und Hermes; Filestore-Volumes liefern einen gemeinsamen Arbeitsbereich für Multi-Agenten-Abläufe.
Hervé Bizira, Chief Business Officer von Nous Research, sagt dazu, sein Unternehmen habe Hermes Enterprise gebaut, damit Kunden in ihre bestehende Infrastruktur deployen können, inklusive Isolation pro Agent und erweiterbarer Zugriffskontrolle. Agent Substrate löse beides auf der Plattformebene und schone dabei Rechenressourcen, so Bizira weiter. Die Erfahrung gebe Vertrauen, dass die Architektur mit wachsenden Agentenlasten mitskaliert.
Governance: Pförtner, Verzeichnis und Ausweis für Agentenflotten
Der zweite Teil der Ankündigung betrifft nicht die Werkstatt, sondern das Gebäudemanagement. Google beschreibt drei Herausforderungen: nicht-deterministische Interaktionspfade zwischen Agenten, Werkzeugen, Modellen und Daten absichern, eine Haltung der Standard-Ablehnung mit minimalen Rechten über verteilte Laufzeiten hinweg durchhalten und asynchrone Agentenaktionen nachvollziehbar prüfen. Ohne diese Kontrolle entstehen Schatten-KI, Datenabfluss und Aktionen, die sich im Nachhinein kaum zuordnen lassen.
Vier Bausteine bilden das Fundament. Das Agent Gateway fungiert als Fluglotse für allen Verkehr von Clients zu Agenten und von Agenten zu allem anderen, inklusive Schutz sensibler Daten und eigener Richtlinien. Die Agent Registry ist das Verzeichnis aller freigegebenen Agenten, Werkzeuge, MCP-Server, Skills, Modelle und Endpunkte und regelt den Laufzeitzugriff über angewandte Richtlinien. Die Agent Identity vergibt nach dem offenen SPIFFE-Standard eine eindeutige sichere ID pro Agent, und die Beobachtbarkeit liefert OpenTelemetry-konforme Telemetrie für jeden Modellaufruf, jede Werkzeugnutzung und jeden Sprung zwischen Agenten.
Neu ist die Reichweite. Die Governance erstreckt sich künftig über Agent Runtime, Cloud Run, Agent Sandboxes, GKE und die Agent Compute Engine, dazu kommen leichtgewichtige Envoy-basierte Durchsetzungspunkte für Multi-Cloud- und Hybrid-Umgebungen und eine Absicherung lokaler Coding-Agenten wie Claude Code oder Antigravity CLI auf verwalteten Geräten. Ergänzend kündigt Google feinere Token- und Kostenkontrolle, Modell-Routing zur Steuerung von Ausgaben und Leistung, erweiterbare Richtlinien über Service-Extension-Bindings sowie Partneranbindungen über Ping Identity, SailPoint und Saviynt an. Express Link für Cloud Run soll Agenten befähigen, ihren Bedarf zu erklären, und die authentifizierte Verbindung gleich mitliefern.
Was das für den Betrieb eigener Agenten bedeutet
Bei L’Oréal beschreibt Alexandre Frizzo, AI Lead Engineer, das Ziel, agentische KI den eigenen Teams in die Hand zu geben und über eine Beauty-Tech-Agentic-Plattform in den Arbeitsalltag zu bringen. Die Governance von Google Cloud liefere die Grundlage, um dieses Vorhaben mit Zuversicht zu skalieren, weil Identität, Richtlinien und Beobachtbarkeit über Laufzeiten wie Cloud Run hinweg vereinheitlicht würden. Entwickler könnten schneller arbeiten, während die Kontrolle darüber erhalten bleibe, worauf jeder Agent zugreifen darf.
Wer eigene Agenten baut, muss sich damit andere Fragen stellen. Nicht mehr das Modell entscheidet über den Erfolg, sondern ob die Laufzeitumgebung mithält: Gibt es eine Identität pro Agent statt eines geteilten Kontos, überleben Arbeitsstände eine Unterbrechung, kostet ein wartender Agent Geld, und existiert ein auditierbarer Pfad für jede Aktion. Wer heute KI-Agenten skalieren will, sollte diese Punkte genauso verhandeln wie Rechenleistung und Preis. Die Agent Compute Engine für eigene Agenten ist dabei nur ein Teil der Antwort.
Zur Einordnung: Vieles davon steht als Preview in den kommenden Monaten an, nicht als sofort verfügbares Produkt. Preview heißt in dieser Branche meist: funktioniert, aber die Kanten sind noch sichtbar. Interessant bleibt der offene Teil, Agent Substrate auf Kubernetes, weil er die Bindung an einen Anbieter verringert und den Ansatz für andere Umgebungen nachvollziehbar macht. Unspektakulär und richtig ist der Kern der Ankündigung: Sichere Ausführung autonomer KI-Agenten ist ein Infrastrukturproblem, das sich nicht nachträglich mit einer Schicht Richtlinien über einem gewachsenen System lösen lässt.
Quelle: cloud.google.com
