Google AX isoliert KI-Agenten in Kubernetes

AX trennt den Agenten vom Cluster

Für mich ist an AX nicht Kubernetes selbst entscheidend, sondern der Versuch, die Ausführung potenziell nicht vertrauenswürdigen Agenten-Codes zu einer eigenständigen Infrastrukturinstanz zu machen. Im offiziellen Google-Repository wird das Projekt als deklarative Runtime beschrieben, die Tasks isoliert, Workspaces anbindet, ausgehende Netzwerkverbindungen begrenzt und Agenten-Workloads im Cluster skaliert.

Stand September 2026 wurde AX, kurz für Agent Executor, unter der Apache-2.0-Lizenz veröffentlicht. Seine zentralen Primitive verdeutlichen das Ausführungsmodell: Task startet eine Agentenaufgabe, Workspace liefert Dateikontext oder ein Repository, Gateway definiert den externen Zugriff und Model konfiguriert Modellanbieter und Zugangsdaten.

Damit ist AX mehr als ein Kubernetes Job mit Container. Es ist für langlebige, zustandsbehaftete Agentenprozesse konzipiert, die einen verwalteten Arbeitskontext und eine klare Netzwerkgrenze benötigen. Genau diese Details geraten meist außer Kontrolle, sobald ein Agent Dateien schreiben, Code ausführen und externe Systeme ansprechen darf.

AX ist jedoch nicht eigenständig. Die Repository-Dokumentation nennt als Voraussetzungen einen Kubernetes-Cluster, den Image-Builder ko, eine für den Cluster erreichbare Container-Registry sowie die Agent Substrate Control API. Ein wesentlicher Teil der tatsächlichen Ausführung liegt in Agent Substrate, während AX die deklarative Verwaltung und Orchestrierung übernimmt.

Google bezeichnet AX als Hochleistungs-Orchestrator, der für Milliarden autonomer Agenten-Workloads pro Cluster ausgelegt sei. Das klingt ambitioniert, doch die verfügbaren Materialien enthalten keine offizielle öffentliche Suite reproduzierbarer Benchmarks. Vorerst ist das ein Architekturziel und keine Kennzahl, auf die ich eine Kapazitätsplanung stützen würde.

Isolation wird Teil des Agentenmodells

AX verändert einen wichtigen Punkt: Die Sicherheit eines Agenten wird nicht durch eine Sammlung von Vereinbarungen innerhalb der Anwendung definiert, sondern durch eigenständige Infrastruktur-Objekte. Netzwerk, Workspace, Modell und ausführbare Aufgabe erhalten explizite Grenzen, die sich über einen Kubernetes-ähnlichen Prozess beschreiben und kontrollieren lassen.

Am meisten profitieren Plattformen, auf denen verschiedene Agenten mit nicht vertrauenswürdigem Code oder unterschiedlichen Zugriffsrechten gleichzeitig laufen. Für eine kleine Installation kann die Einstiegshürde hoch sein: Neben Kubernetes müssen Teams eine Registry, Image-Builds und eine separate Agent-Substrate-Schicht betreiben.

Ich würde zuerst nicht den behaupteten Maßstab prüfen, sondern die Belastbarkeit der Grenzen: das Umgehen des Netzwerk-Gateways, den Umgang mit Modellzugangsdaten, die Wiederherstellung langer Tasks und das Verhalten bei Ausfällen der Steuerungsebene. Die Idee hinter AX ist solide, doch ihr Wert hängt weniger von der Zahl gestarteter Agenten ab als davon, wie zuverlässig ein defekter Agent auf seine eigene Sandbox begrenzt bleibt.

Zuvor haben wir erläutert, wie sich ein selbst gehosteter autonomer KI-Agent mit sicheren DevOps-Kontrollen und kontinuierlichem Betrieb bereitstellen lässt. Die Google-AX-Sandbox erweitert diese Diskussion um Kubernetes-Isolierung für Agenten-Workloads.