GuardAgent: Deterministische Sicherheitsdurchsetzung für LLM-Agenten via Code-Ausführung

Das zentrale Sicherheitsproblem für jeden schreibenden Agenten ist: Wie verhindert man, dass er eine Aktion ausführt, die er niemals ausführen sollte? GuardAgent (Xiang et al., ICML 2025) schlägt einen dedizierten Guardrail-Agenten vor — einen separaten LLM-Agenten, der jede Aktion des Zielagenten vor der Ausführung gegen eine Reihe von Sicherheitsrichtlinien prüft. Für Bean Labs, wo die Frage „Kann der Agent in das Hauptbuch schreiben, ohne die Buchhaltungsregeln zu verletzen?“ nicht verhandelbar ist, steht dieses Paper direkt im Zentrum unserer Forschungsagenda.

Das Paper

GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning von Zhen Xiang und Kollegen der UIUC, Emory und UC Berkeley führt den laut Autoren ersten Allzweck-Guardrail-Agenten für LLM-Systeme ein. Die Kernidee ist einfach: Anstatt Sicherheitsbeschränkungen direkt in den Prompt des Zielagenten einzubetten (wo sie ignoriert oder vergessen werden können), fungiert GuardAgent als unabhängiger Agent, der Aktionen des Zielagenten abfängt und sie gegen festgelegte Richtlinien verifiziert.

Der Mechanismus besteht aus zwei Phasen. Zuerst liest das LLM die Sicherheitsrichtlinie sowie die vorgeschlagene Eingabe oder Ausgabe des Zielagenten und erstellt einen schrittweisen Aktionsplan, der beschreibt, was zu prüfen ist. Zweitens wandelt es diesen Plan in ausführbaren Python-Code um, wobei eine vordefinierte Toolbox aufrufbarer Funktionen genutzt wird. Ein externer Python-Interpreter führt den Code aus und liefert ein deterministisches Ja/Nein-Urteil. Ein Speichermodul speichert vergangene Aufgaben-Tupel (Richtlinie, Plan, Code) und ruft ähnliche frühere Beispiele mittels Levenshtein-Distanz ab, was Few-Shot In-Context Learning ohne zusätzliches Fine-Tuning ermöglicht. Das Paper evaluiert den Ansatz anhand zweier neuer, von den Autoren eingeführter Benchmarks.

Kernideen

• Code-Ausführung schlägt natürlichsprachliche Urteile. Wenn Sicherheitsentscheidungen als Code statt als LLM-Text ausgegeben werden, ist das Ergebnis deterministisch: Die Python-Engine erlaubt oder blockiert, ohne Halluzinationsrisiko im finalen Entscheidungsschritt. Das LLM muss lediglich korrekten Code generieren, nicht die korrekte endgültige Antwort.
• Zwei maßgeschneiderte Benchmarks. EICU-AC (316 Beispiele) testet die Zugriffskontrolle für EHRAgent über eine Datenbank im Gesundheitswesen mit drei Benutzerrollen und zehn Datenbanken. Mind2Web-SC (200 Beispiele) testet sechs Sicherheitsrichtlinien für den Webagenten SeeAct. Beide wurden von den Autoren speziell für dieses Paper erstellt.
• 98,7 % und 90,0 % Label-Genauigkeit (GPT-4) bei EICU-AC bzw. Mind2Web-SC. Entscheidend ist, dass die Genauigkeit der finalen Antwort — ob der Zielagent seine Aufgabe erfüllt, wenn sie erlaubt sein sollte — in beiden Szenarien bei 100 % bleibt.
• Hardcodierte Sicherheitsregeln scheitern kläglich. Die Einbettung von Richtlinien direkt in den System-Prompt des Zielagenten erreicht nur 81,0 % / 77,5 % Genauigkeit in den beiden Benchmarks und führt dazu, dass der Zielagent bei 29,2 % / 71,0 % seiner legitimen Aufgaben scheitert — ein inakzeptabler Kompromiss zwischen Nutzen und Sicherheit.
• LlamaGuard ist hier das falsche Werkzeug. Die Content-Moderation-Baseline erreicht nur etwa 50 % Genauigkeit — was dem Zufall entspricht —, da sie für schädliche Texte konzipiert wurde und nicht für das logische Schlussfolgern darüber, ob eine Agentenaktion eine spezifische Zugriffskontrollregel verletzt.
• Das Entfernen der Toolbox kostet etwa 8 Punkte. Ohne die Bibliothek aufrufbarer Funktionen sinkt GuardAgent bei EICU-AC von 98,7 % auf 90,8 %, obwohl dies teilweise dadurch kompensiert wird, dass benötigte Funktionen autonom definiert werden (68 % der Ausgaben generieren Code auch ohne explizite Anweisung, was die Autoren als Beleg für das Code-Generierungs-Design werten).

Was Bestand hat — und was nicht

Die zentrale architektonische Erkenntnis — dass die Code-Ausführung einen deterministischen Durchsetzungspunkt bietet — ist wirklich nützlich, und die Ablation-Studien sind ehrlich. Der Vergleich mit hardcodierten Sicherheitsregeln ist besonders überzeugend: Er zeigt, dass naive Designs nach dem Motto „einfach Regeln zum Prompt hinzufügen“ den Nutzen des Zielagenten mindern, während sie die Sicherheit dennoch nicht zuverlässig durchsetzen.

Die Evaluierung hat jedoch reale Grenzen. Die beiden Benchmarks sind klein (316 und 200 Beispiele), und da die Autoren beide konstruiert haben, besteht ein offensichtliches Risiko für Overfitting. EICU-AC ist im Wesentlichen eine Zugriffskontrollmatrix (Rolle × Datenbank), was ein strukturiertes, aufzählbares Problem darstellt — genau die Art von Aufgabe, für die Code prädestiniert ist. Mind2Web-SC ist komplexer, und der Wert von 90,0 % ist dort deutlich weniger beeindruckend, als es zunächst scheint: Die Autoren räumen ein, dass Regel 5 (die „Filme, Musik und Videos“ abdeckt) die meisten Fehler verursacht, da sie umfassendes Open-World-Reasoning erfordert. Das ist genau die Art von Regel, mit der ein echter Finanzagent ständig konfrontiert wäre.

Das Speichermodul ruft Demonstrationen anhand von String-Ähnlichkeit ab, was bei wiederkehrenden Richtlinientypen gut funktioniert, bei völlig neuen Richtlinien jedoch an Leistung verlieren wird. Zudem setzt das gesamte Framework einen „vertrauenswürdigen Kontext“ voraus — die Sicherheitsrichtlinien selbst müssen von einem vertrauenswürdigen Administrator bereitgestellt werden. Wenn ein Angreifer die Richtlinien modifizieren kann oder wenn die Toolbox unsichere Funktionen enthält, bietet GuardAgent keinen Schutz. Das Paper modelliert keine adversariellen Richtlinien-Manipulationen. Nachfolgende Arbeiten (ShieldAgent, arXiv:2503.22738; AGrail, arXiv:2502.11448) haben diese Lücken bereits aufgezeigt, wobei ShieldAgent eine durchschnittliche Verbesserung von 11,3 % gegenüber GuardAgent in breiteren Benchmarks meldet.

Warum das für Finanz-KI wichtig ist

Der schreibende Beancount-Agent benötigt mehr als nur einen Sicherheits-Prompt — er braucht einen Mechanismus zur Durchsetzung von Buchhaltungsregeln, der strukturell von dem Agenten getrennt ist, der die Arbeit verrichtet. Die Architektur von GuardAgent lässt sich direkt darauf übertragen: Ein Guard-Agent, der jeden vorgeschlagenen Buchungssatz gegen Buchhaltungsregeln prüft (Soll == Haben, keine Buchungen in gesperrten Zeiträumen, keine Änderung abgeglichener Transaktionen), bevor der Schreibvorgang ausgeführt wird. Die Durchsetzungsebene per Code-Ausführung ist hier besonders attraktiv, da die Arithmetik der doppelten Buchführung genau die Art von strukturierter, aufzählbarer Prüfung ist, die Code zuverlässig handhabt und LLM-Text nicht.

Die ehrliche Einschränkung besteht darin, dass GuardAgent davon ausgeht, dass man alle Sicherheitsrichtlinien im Voraus aufzählen und in eine Toolbox kodieren kann. In produktiven Beancount-Umgebungen sind einige Einschränkungen implizit (sie folgen Ledger-Konventionen, die der Benutzer über Jahre aufgebaut hat) und andere sind dynamisch (Budgets ändern sich, Kontostrukturen werden umstrukturiert). GuardAgent sagt uns nicht, wie wir mit Einschränkungen umgehen sollen, die nicht vordefiniert werden können. Das ist das schwierigere Problem, und es bleibt ungelöst.

Was man als Nächstes lesen sollte

• ShieldAgent (arXiv:2503.22738, ICML 2025) — baut auf GuardAgent auf mit verifizierbarem Schlussfolgern über Sicherheitsrichtlinien und ShieldAgent-Bench (2.000 Beispiele in sechs Web-Umgebungen); berichtet von 11,3 % Verbesserung gegenüber GuardAgent und einer Reduzierung der API-Aufrufe um 64,7 %.
• AGrail (arXiv:2502.11448) — schlägt adaptive Sicherheitsprüfungen vor, die über Agentenaufgaben hinweg übertragbar sind, anstatt Demonstrationen pro Aufgabe zu erfordern; adressiert direkt die Skalierbarkeitsbeschränkung von GuardAgent.
• ToolSafe (arXiv:2601.10156) — proaktive Guardrails auf Schrittebene mit Feedback für Tool-Calling-Agenten; granularer als das Interzeptionsmodell für Ein- und Ausgaben von GuardAgent.