Zero-Trust-KI-Agenten entwickeln, die Absichten beurteilen, nicht nur Syntax

Dies ist Teil 2 der Serie über Zero-Trust-Agenten. Teil 1 etablierte drei deterministische Kontrollen für autonome Agenten: signierte Datenbankschreibvorgänge mit Cloud KMS, Kernel-Isolation im Userspace mit gVisor und ein Eingabe-/Ausgabe-Gateway, das durch CI-Unit-Tests abgesichert ist.

Diese Kontrollen funktionieren, aber sie haben eine gemeinsame Grenze: Sie erfassen nur Fälle, die Sie im Voraus explizit spezifizieren können. Ein SQL-Parser kann eine sozial konstruierte Rückerstattung nicht von einer legitimen unterscheiden, wenn die Syntax gültig ist. Ein Regex kann den Unterschied zwischen einem physischen USB-Kabel und einer geöffneten Softwarelizenz nicht erkennen. Eine Testsuite mit nur einem Durchlauf kann eine Agentenflotte, die über mehrere Durchläufe hinweg abgeschöpft wird, nicht erkennen.

Teil 2 nimmt denselben Kundensupport- und Retouren-Agenten, der mit dem Agent Development Kit (ADK) erstellt wurde, und verlagert die Sicherheitsprüfungen auf die Plattform, wo sie über Absichten nachdenken und sich an das Verhalten anpassen. Die Verlagerung der Prüfungen auf die Plattform ändert auch, wer sie besitzt: Die Governance wird von einem Plattform- oder Sicherheitsadministrator definiert und verwaltet, getrennt vom Agententwickler, da die Plattform sie außerhalb des Agentencodes durchsetzt.

Von Code-Ebene-Prüfungen zu verwalteter Laufzeit-Governance

Eine Zero-Trust-Laufzeitumgebung geht davon aus, dass jede einzelne Anfrage gültig aussehen und dennoch Teil eines Angriffs sein kann. Anstatt jede Regel im Voraus fest zu codieren, setzt sie drei verwaltete Kontrollen durch – alle angewendet über Agent Gateway, den Laufzeit-Durchsetzungspunkt, der Interaktionen zwischen dem Benutzer, dem Agenten, seinem Modell und seinen Tools abfängt und steuert:

• Model Armor – eine Inline-KI-Firewall, die Prompts und Antworten auf Prompt-Injection, Jailbreaks, bösartige URLs und Datenlecks sensibler Daten überprüft.
• Semantische Governance-Richtlinien – eine auf LLM basierende Richtlinien-Engine in natürlicher Sprache, die jeden vorgeschlagenen Tool-Aufruf vor der Ausführung gegen die Benutzerabsicht und Ihre Geschäftsregeln bewertet.
• Agent-Anomalieerkennung – LLM-gesteuerte Analyse von Agentenprotokollen und Telemetrie, die ungewöhnliches Verhalten innerhalb einer Sitzung kennzeichnet, z. B. eine Rückerstattung, die über viele Durchläufe hinweg abgeschöpft wird.

Jede Kontrolle deckt ab, was die anderen nicht können: Model Armor filtert die Nutzlast, die Richtlinien-Engine denkt über Absichten nach, und die Anomalieerkennung beobachtet das Verhalten im Laufe der Zeit.

Das konkrete Szenario

Der Rückerstattungsagent liest Bestellungen, berechnet Wiederauffüllungsgebühren gegen ein Händlerhauptbuch und zahlt Rückerstattungen aus – wobei calculate_restocking_fee innerhalb von Agent Sandbox, der verwalteten Sandbox der Plattform für modellgenerierten Code, ausgeführt wird. Die Angriffe werden gegen eine einzelne Transaktion ausgeführt, bei der die Aufteilung zwischen physischen und digitalen Gütern (z. B. eine USB-C-Dockingstation für 29 $gegenüber einer digitalen Lizenz für 120$) das ist, worauf die Angriffsmuster abzielen.

Der gesamte Code, die Richtliniendeklarationen und die interaktiven Simulatoren sind in der quelloffenen Begleitdemo verfügbar: zero-trust-agents-2.

Fazit

Das Kernargument der Serie: Schutzmaßnahmen auf Syntaxebene zur Build-Zeit sind notwendig, aber unzureichend, sobald Agenten Ermessensentscheidungen treffen. Die Verlagerung der Governance auf die Plattform – wo eine Richtlinien-Engine auf Absichtsebene und ein verhaltensbeobachtender Anomaliedetektor zwischen dem Agenten und allem, was er tun kann, sitzen – ist der Unterschied zwischen einer Demo und einem einsatzbereiten Agenten. Sie behebt auch das Eigentumsproblem: Der Agententwickler ist nicht länger das Sicherheitsteam.