Google AX Orchestrator v0.3.0: Agenten sicher betreiben

Google AX Orchestrator v0.3.0 ist da: drei Dienste, Task-State in Redis, Sandbox und Egress-Allowlist als YAML. Was davon sicherheitsrelevant ist.

Der Google AX Orchestrator ist in Version 0.3.0 erschienen – am 20. September 2026 als Release-Tag auf GitHub. Auf Hacker News sammelte die Einreichung 628 Punkte. AX steht für „Agent Executor” und ist bewusst wie kubectl gebaut: Wer Kubernetes kennt, dem werde sich ax vertraut anfühlen, schreibt Google im README. Der Code liegt unter Apache-2.0 vor, ist in Go geschrieben und kam am 22. September 2026 auf rund 5.900 GitHub-Sterne.

Was der Google AX Orchestrator in v0.3.0 ändert

Die auffälligste Änderung steckt unter der Haube. AX besteht jetzt aus drei getrennten Diensten – und der Vergleich der Repository-Stände zeigt, wie frisch das ist: Bei Version 0.2.3 lag unter cmd/ noch ein einziges Binary, bei v0.3.0 sind es vier. ax-server ist die zustandslose gRPC-API, ax-controller ein horizontal skalierbarer Pool von Reconciliation-Workern, ax-task-runner führt die Aufgabe im Sandkasten aus. Dazu kommt das CLI ax.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

Der zweite Umbau betrifft den Zustandsspeicher. Der naheliegende Kubernetes-Weg – jede Aufgabe als Custom Resource – kam für Google nicht infrage, und die Begründung steht offen im Design-Dokument: Millionen kurzlebiger Tasks als CRDs würden etcd überfordern, Stichworte Speichergrenzen im einstelligen Gigabyte-Bereich, Schreibraten-Engpässe und eine degradierende Control Plane. AX hält seinen Zustand deshalb in Redis und nutzt Redis Streams als Arbeitsschlange zwischen API-Server und Controllern.

Vier Primitive, ein YAML

Alles wird über Manifeste der API-Gruppe ax.io/v1alpha1 beschrieben. Vier Objekte tragen das Konzept:

Task – die kleinste isolierte Ausführungseinheit. Sie nennt Container-Image, Kommando, Ressourcenanforderungen und -limits sowie Verweise auf Gateway und Workspaces. Absichtlich klein gehalten: billig zu erzeugen, zu isolieren, zu pausieren und wegzuwerfen. Ein Agent baut sich daraus bei Bedarf einen ganzen Aufgabenbaum.
Workspace – nimmt dem Agenten die Startvorbereitung ab. Repositories in der richtigen Revision, MCP-Server und Skill-Pakete werden einmal deklariert und danach von beliebig vielen Tasks eingebunden, bevor das Kommando startet.
Gateway – die Netzgrenze. Ausgehender Verkehr ist nur zu Hosts und Ports erlaubt, die ausdrücklich auf der Allowlist stehen.
Model – bestimmt, welches Sprachmodell die Plattform selbst nutzt; die Zugangsdaten kommen aus einem Kubernetes-Secret.

Dazu kommen Bedienbefehle, die man bei Agenten-Frameworks selten sieht: ax suspend und ax resume halten einen untätigen Agenten an und setzen ihn an derselben Stelle fort, ax ssh öffnet eine Shell in der laufenden Sandbox. Die eigentliche Isolation liefert Agent Substrate als Unterbau.

Was das für dich bedeutet

Die Schlagzeilen-Zahl – „Milliarden Agenten-Workloads pro Cluster” – ist für die meisten Leser irrelevant. Interessant ist etwas anderes, und zwar aus Sicherheitssicht: Mit dem Gateway-Objekt wird die Egress-Kontrolle eines Agenten zu einer Datei, die im Git liegt, reviewt und versioniert wird. Genau das fehlt in den meisten Agenten-Setups, die mir begegnen. Dort läuft der Agent in einem Container mit vollem Internetzugang, weil sonst angeblich nichts funktioniert.

Warum das zählt, haben die vergangenen Wochen vorgeführt. Als Modelle von Google, OpenAI, Anthropic und Meta bei Sicherheitstests des Prüfdienstleisters Irregular an echte Fremdsysteme gerieten, lag das nicht an einer fehlenden Anweisung, sondern daran, dass die Testumgebung versehentlich Internetzugang hatte. Eine fehlende technische Grenze also. Ein Agent ist eine hochprivilegierte Identität mit Zugangsdaten und Netzwerkzugriff – und Identitäten begrenzt man per Policy, nicht per Prompt. Dass Isolation, Ressourcenlimit und Allowlist hier zu erstklassigen Objekten werden, ist die eigentliche Nachricht dieses Releases. Wie schnell agentische Werkzeuge ihre eigenen Schutzmechanismen umgehen, habe ich zuletzt am Fall Plugin4Shell beschrieben.

Zwei Haken bleiben. Den ersten nennt Google selbst: Im README steht eine Warnung, dass Kernkonzepte, Protokolle und Spezifikationen noch aktiv überarbeitet werden und größere Breaking Changes vor einem stabilen Release wahrscheinlich sind. Der Versionsverlauf bestätigt das – v0.1.0 im Mai, v0.3.0 im September. Der zweite Haken ist der Einstiegspreis: AX setzt einen Kubernetes-Cluster und eine erreichbare Agent-Substrate-Control-API voraus, dazu ein Build-Werkzeug und eine eigene Container-Registry. Modellwahl und Egress-Regeln bestimmst du selbst, die Betriebslast der Control Plane aber auch.

Drei sinnvolle nächste Schritte

Nicht in Produktion nehmen. Bei einer v1alpha1-API mit angekündigten Breaking Changes ist ein Testcluster der richtige Ort. Version explizit pinnen.
Die Allowlist als Übung nutzen. Lege einen Task mit einem Gateway an, das nur den Modell-Endpunkt erlaubt, und schau zu, was bricht. Die Liste der Hosts, die dein Agent zusätzlich verlangt, ist seine reale Angriffsfläche – notiere sie, auch wenn du AX nie produktiv einsetzt.
Prinzip übertragen. Sandbox, Ressourcenlimit, Egress-Allowlist und zentrale Modellkonfiguration lassen sich auch ohne AX umsetzen. Wer lieber lokal und ohne Cloud-Abhängigkeit arbeitet, findet die Hardwareseite in meinem Überblick zu Hardware für lokale KI und LLMs 2026.

Quellen

Dranbleiben

Diese Analysen als Newsletter

Ein Mal pro Woche Klartext zu KI, Security & Crypto – direkt in dein Postfach.

Jetzt anmelden

Google AX Orchestrator v0.3.0: Sandbox und Egress-Allowlist für KI-Agenten