Googles Zero-Trust-Muster setzt Sicherheitsgrenzen außerhalb des KI-Agenten

Aus einer Bestellung über 149 Dollar soll plötzlich eine Rückzahlung über 10.000 Dollar werden, gefolgt von Python-Code zum Auslesen von Umgebungsvariablen. Google veröffentlichte dafür am 17. August 2026 laut eigenem Developers Blog eine offene Demo mit dem Agent Development Kit (ADK) und Gemini.

Der autonome Support- und Retourenagent dient als Angriffsziel für reale Exploit-Muster. Googles Referenzarchitektur behandelt das Sprachmodell von Beginn an als manipulierbar und verteilt harte Kontrollen auf drei Ebenen außerhalb seines Kontexts. Das ist der Kern von Zero Trust: Vertrauen entsteht nicht durch die Position einer Komponente im System, sondern durch überprüfbare Kontrollen an jedem kritischen Übergang.

Der Prompt darf verlieren

Ein Systemprompt kann dem Agenten eine Erstattung oberhalb eines Grenzwerts verbieten, aber unter einem gezielten Jailbreak bleibt diese Anweisung nur Text in genau dem Kontext, den der Angriff ohnehin schon manipuliert hat. Sie ist keine Sicherheitsgrenze.

Google setzt bei zustandsändernden Datenbankschreibvorgängen deshalb auf eine Kontrolle außerhalb des Modells. Laut Developers Blog muss der konkret handelnde Agent jede solche Operation signieren; die Datenbank prüft die Signatur, bevor sie die Transaktion festschreibt. Damit hängt der Schreibzugriff an einer verifizierbaren Identität und nicht an der Selbstauskunft des Modells.

Diese Trennung ist im produktiven Betrieb der härteste Teil des Musters: Selbst wenn ein Modell eine schädliche Anweisung akzeptiert, bleibt die Datenbank eine eigenständige Instanz mit einem technisch erzwungenen Prüfpunkt. Eine universelle Abwehr belegt die Demo damit nicht. Sie liefert aber eine belastbare Architekturfrage für jeden Agenten mit Schreibrechten: Welche Komponente kann eine Operation noch ablehnen, nachdem das Modell bereits kompromittiert wurde?

Code bleibt in der Sandbox

Die zweite Ebene begrenzt generierten Code. Nach Angaben von Help Net Security läuft er in Googles Beispiel in einer gVisor-Sandbox im User Space, ohne Netzzugriff und mit Limits für Speicher, CPU-Nutzung und Ausführungszeit. Der Schadensradius hängt dadurch nicht allein von der Entscheidung des Agenten ab, sondern zusätzlich von den Fähigkeiten seiner Laufzeitumgebung.

Das ist besonders bei Tool-Nutzung wichtig. Ein Modell kann einen Code-Aufruf für plausibel halten und trotzdem an einer Umgebung scheitern, die Netzwerkzugriffe unterbindet und Ressourcen deckelt. Sandboxing ersetzt keine Prüfung des Aufrufs, fängt aber eine andere Fehlerklasse ab als die Signaturkontrolle an der Datenbank.

Das Gateway prüft vor der Ausführung

Vor Modell und Werkzeugen sitzt die dritte Ebene. Help Net Security beschreibt ein semantisches Gateway, das eingehende Prompts und ausgehende Tool-Aufrufe mit deterministischen Regeln prüft, bevor das Modell gestartet oder eine Datenbankänderung ausgeführt wird. Die Regeln liefern reproduzierbare Entscheidungen an einem Kontrollpunkt außerhalb des Sprachmodells.

Im Zusammenspiel decken die drei Ebenen verschiedene Übergänge ab: Das Gateway filtert Eingaben und Aktionen vor ihrer Ausführung, die Sandbox begrenzt Code, und die Datenbank akzeptiert zustandsändernde Schreibzugriffe erst nach der Signaturprüfung. Keine Ebene trägt den Schutz allein.

Der Aufbau taugt als Mindestmaß für Agenten, die Geld bewegen, produktive Daten ändern oder Code ausführen. Produkt-, Plattform- und Security-Teams sollten für jede dieser Fähigkeiten einen Kontrollpunkt benennen können, der auch bei einem vollständig manipulierten Modell weiter greift. Fehlt dieser Punkt, bleibt die wichtigste Sicherheitsentscheidung beim angreifbaren Teil des Systems.