💬 NLP

Safeguarding LLM Agents from Misalignment through Provenance Analysis

Das Paper stellt ProvenanceGuard vor, ein auf Provenienz basierendes Framework, das die Erkennung von Fehlsteuerungen (Misalignment) bei LLM-Agenten signifikant verbessert und im Vergleich zu herkömmlichen LLM-as-a-Judge-Baselines die Anzahl falscher Interventionen reduziert, indem es Werkzeugaufrufe gegen nachvollziehbare Belege im Kontext des Agenten verifiziert.

Ursprüngliche Autoren: Yining She, Yiliang Liang, Eunsuk Kang

Veröffentlicht 2026-07-03

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Yining She, Yiliang Liang, Eunsuk Kang

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie stellen einen sehr intelligenten, eifrigen persönlichen Assistenten (einen LLM-Agenten) ein, der Ihnen bei Ihren täglichen Aufgaben helfen soll. Sie sagen ihm: „Bitte frage Daniel nach 30 $.“ Da dieser Assistent mit der realen Welt verbunden ist, kann er tatsächlich E-Mails senden, Geld überweisen oder Dateien ändern.

Das Problem ist, dass dieser Assistent manchmal zu eifrig ist oder etwas missversteht. Anstatt nach Geld zu fragen, könnte er versehentlich Geld an Daniel senden. Oder er könnte eine Rechnung bezahlen, die Sie gar nicht erwähnt haben. Dies wird als Fehlausrichtung (Misalignment) bezeichnet: Der Assistent tut zwar technisch gesehen das, was den Regeln entspricht, aber das, was Sie eigentlich wollten, geht dagegen.

Dieses Paper stellt ein neues Sicherheitssystem namens ProvenanceGuard vor, um diese Fehler zu verhindern, bevor sie passieren. So funktioniert es, einfach erklärt:

Die Kernidee: Der „Spurensuche“-Detektiv

Den Autoren wurde klar, dass bestehende Sicherheitssysteme wie ein Chef sind, der einfach einen zweiten, ebenso verwirrten Assistenten fragt: „Ist das eine gute Idee?“ Dies führt oft zu inkonsistenten Antworten.

Anstattdessen agiert ProvenanceGuard wie ein forensischer Detektiv. Er rät nicht nur, sondern verlangt eine Dokumentationskette (Provenance). Er fragt: „Kannst du mir genau zeigen, an welcher Stelle in unserem Gespräch oder in den Anweisungen du die Beweise gefunden hast, um diese spezifische Aktion auszuführen?“

Wenn der Assistent nicht auf einen bestimmten Satz in Ihrer Anfrage oder eine vorangegangene Tatsache hinweisen kann, die diese Aktion rechtfertigt, blockiert das System sie.

Die drei Arten von Fehlern

Das Paper unterteilt „schlechte Ideen“ in drei Kategorien unter Verwendung einer Detektiv-Checkliste:

Das falsche Werkzeug (Tool-Level):
- Das Szenario: Sie sagen: „Fordere Geld an.“ Der Assistent versucht, ein „Geld senden“-Werkzeug zu verwenden.
- Die Detektiv-Prüfung: „Passt dieses Werkzeug zur Aufgabe?“ Das System prüft die Bedienungsanleitung des Werkzeugs und Ihre Anfrage. Wenn das Werkzeug nicht zur Aufgabenbeschreibung passt, wird es blockiert.
Die falschen Details (Parameter-Level):
- Das Szenario: Sie sagen: „Sende 30 $ an Daniel.“ Der Assistent verwendet das richtige Werkzeug, sendet aber 30 $ an Sarah, weil er den Namen erraten hat.
- Die Detektiv-Prüfung: „Woher hast du den Namen ‚Sarah‘?“ Wenn der Assistent nicht auf eine Tatsache im Gespräch hinweisen kann, die „Sarah“ besagt, sagt das System: „Kein Beweis gefunden. Stopp.“
Die bloße Vermutung (Interpretation-Level):
- Das Szenario: Sie sagen: „Bearbeite diese Anfrage“, ohne zu sagen, wie. Der Assistent entscheidet sich, automatisch eine Rechnung zu bezahlen.
- Die Detektiv-Prüfung: „Gibt es nur einen Weg, dies zu ‚bearbeiten‘?“ Das System erkennt, dass Ihre Anfrage vage war. Da es mehrere Möglichkeiten gibt, „bearbeiten“ zu interpretieren (die Rechnung bezahlen, sie ablehnen oder Sie fragen), trifft der Assistent eine bloße Vermutung. Das System blockiert die Aktion und zwingt den Assistenten stattdessen dazu, Sie um Klärung zu bitten.

Wie das System funktioniert (Die Drei-Stufen-Pipeline)

ProvenanceGuard ist keine einzelne Frage, sondern eine dreistufige Sicherheitskontrolle, die eine Aktion bestehen muss, bevor sie ausgeführt werden kann:

Kontrollpunkt 1 (Das Werkzeug): „Ist dies das richtige Werkzeug für die Aufgabe?“ Wenn nicht, STOPP.
Kontrollpunkt 2 (Die Details): „Hast du einen Beweis für die spezifischen Zahlen oder Namen, die du verwendest?“ Wenn nicht, STOPP.
Kontrollpunkt 3 (Die Interpretation): „Ist dies die einzige logische Vorgehensweise oder gibt es andere Möglichkeiten?“ Wenn es andere Möglichkeiten gibt, geht das System davon aus, dass der Assistent nur rät, und STOPPT, um um Hilfe zu bitten.

Die Ergebnisse: Schlauer und weniger störend

Die Autoren testeten dieses System gegen 10 verschiedene „Gehirn“-Modelle (LLMs) unter Verwendung von zwei verschiedenen Test-Szenarien.

Weniger Fehler: Im Vergleich zur alten Methode (einfach eine zweite KI zu fragen: „Ist das okay?“) fing ProvenanceGuard fast alle schlechten Aktionen ab. In einem Test reduzierte es die Fehlerrate von 43 % auf 2 %.
Weniger störend: Ein Sicherheitssystem, das alles blockiert, ist nutzlos, weil es den Assistenten daran hindert, überhaupt etwas Hilfreiches zu tun. Die Autoren fanden heraus, dass ProvenanceGuard sehr gut darin war, die korrekten Aktionen durchzulassen. Es stand erfolgreichen Aufgaben nicht im Weg, anders als einige andere Methoden, die auch gute Aktionen zu oft blockierten.

Das Fazit

Dieses Paper schlägt vor, dass wir, anstatt zu raten, ob eine KI das Richtige tut, sie dazu verpflichten sollten, es zu beweisen. Indem wir verlangen, dass der Agent eine „Dokumentationskette“ zwischen seiner Aktion und Ihrer tatsächlichen Anfrage nachweist, können wir verhindern, dass er gefährliche, irreversible Fehler macht (wie Geld zu senden oder Dateien zu löschen), ohne dabei die hilfreiche Arbeit zu bremsen, die er eigentlich leisten soll.

Hinweis: Das Paper konzentriert sich strikt auf die Vermeidung dieser spezifischen Arten von Missverständnissen in Software-Agenten. Es beansprucht nicht, alle KI-Sicherheitsfragen zu lösen, noch behandelt es medizinische oder klinische Anwendungen.

Technisches Resümee: Sicherung von LLM-Agenten gegen Fehlausrichtung durch Provenienz-Analyse

Problemstellung

Da sich Large Language Model (LLM)-Agenten von konversationellen Assistenten zu autonomen Systemen entwickeln, die in der Lage sind, irreversible Aktionen auszuführen (z. B. Geld zu überweisen, Dateien zu modifizieren), ist die Sicherstellung, dass ihre Aktionen mit der Absicht des Nutzers übereinstimmen, von entscheidender Bedeutung. Das Paper identifiziert Fehlausrichtung (Misalignment) als ein Phänomen, bei dem die vorgeschlagene Werkzeugaufruf eines Agenten von der Absicht des Nutzers abweicht – nicht notwendigerweise aufgrund böswilliger Absicht, sondern aufgrund von Missverständnissen oder unbegründeten Annahmen über die Anfrage des Nutzers.

Bestehende Runtime-Guardrails verlassen sich oft auf ein „LLM-as-a-judge“-Paradigma, bei dem ein einzelner LLM-Prompt bewertet, ob eine Aktion zulässig ist. Die Autoren argumentieren, dass dieser Ansatz einen systematischen Rahmen für das Denken über Ausrichtung vermissen lässt, was zu inkonsistenten Urteilen, subjektiven Begründungen und Schwierigkeiten bei der Auditierung führt. Zudem begrenzen traditionelle Sicherheitsmaßnahmen wie Sandboxing die Konsequenzen, anstatt die ursprüngliche fehlgerichtete Aktion zu verhindern, und Post-hoc-Verifizierung kann irreversible Werkzeugaufrufe nicht rückgängig machen.

Methodik

1. Konzeptioneller Rahmen: Provenienz-basierte Guardrails

Motiviert durch die Provenienz-Analyse (die Untersuchung der Herkunft und der Ableitungsgeschichte eines Artefakts), schlagen die Autoren einen Rahmen vor, in dem eine Aktion nur dann als ausgerichtet gilt, wenn sie durch nachvollziehbare Belege innerhalb des Kontextes des Agenten gestützt wird. Der Kontext umfasst die Nutzeranfrage ( $q$ ), die Werkzeugdokumentation ( $d$ ) und die Interaktionshistorie ( $h$ ).

Das Framework formalisiert die Erkennung von Fehlausrichtung, indem es diese in drei distinkte Typen kategorisiert, die jeweils einer Schwäche beim Aufbau spezifischer Provenienz-Relationen entsprechen:

Werkzeug-Ebene (Tool-Level) Fehlausrichtung: Der Agent wählt ein Werkzeug, das irrelevant für die Aufgabe ist.
- Provenienz-Prüfung: Besitzt das ausgewählte Werkzeug ( $t$ ) eine Dokumentation ( $d_t$ ), die RelevantTo einer Teilaufgabe ( $s$ ) ist, welche wiederum ContributesTo der Nutzeranfrage ( $q$ ) beiträgt?
Parameter-Ebene (Parameter-Level) Fehlausrichtung: Der Agent wählt das korrekte Werkzeug, weist ihm jedoch Parameter zu, die nicht im Kontext fundiert sind.
- Provenienz-Prüfung: Kann die Parameterzuweisung ( $a$ ) aus faktischen Belegen ( $e$ ) abgeleitet werden (DerivedFrom), die in der Anfrage oder Historie erscheinen? Zudem: Kann das instanziierte Werkzeug ( $t$ mit $a$ ) die Teilaufgabe ( $s$ ) adressieren (CanAddress)?
- Hinweis: Das Framework unterscheidet zwischen ableitbaren Parametern (die eine Provenienz erfordern) und generativen Parametern (z. B. das Entwerfen eines E-Mail-Textkörpers), die keine direkte Provenienz-Verfolgung erfordern.
Interpretations-Ebene (Interpretation-Level) Fehlausrichtung: Der Agent löst eine unterbestimmte Anfrage auf, indem er willkürlich eine Interpretation festlegt, wenn mehrere plausible Interpretationen existieren.
- Provenienz-Prüfung: Ist die vorgeschlagene Aktion die einzige zur Provenienz zulässige Kandidatin gegeben den Kontext? Wenn mehrere distinkte Aktionen durch den Kontext gestützt werden, ist die Anfrage unterbestimmt, und das Festlegen auf eine davon ohne Klärung stellt eine Fehlausrichtung dar.

2. Implementierung: ProvenanceGuard

Die Autoren implementieren diesen Rahmen als ProvenanceGuard, eine mehrstufige Runtime-Pipeline, die Werkzeugaufrufe vor der Ausführung abfängt. Im Gegensatz zu einem einstufigen „LLM-as-a-judge“ zerlegt ProvenanceGuard die Entscheidung in drei sequentielle Stufen:

Stufe I (Werkzeug-Ebene): Filtert nach umweltverändernden Werkzeugen und verifiziert, ob das ausgewählte Werkzeug relevant für den aktuellen Teilaufgabenplan des Agenten ist.
Stufe II (Parameter-Ebene): Identifiziert, welche Parameter ableitbar sind, und verifiziert, ob deren Werte auf den Kontext zurückgeführt werden können und ob sie das Werkzeug korrekt für die Teilaufgabe instanziieren.
Stufe III (Interpretations-Ebene): Fragt das LLM (ohne die gewählte Aktion des Agenten preiszugeben, um Bias zu vermeiden), ob es andere zur Provenienz zulässige Aktionen gibt. Wenn mehrere existieren, wird die Aktion blockiert, da sie auf einer unbegründeten Annahme beruht.

Das System nutzt ein LLM, um die spezifischen Provenienz-Relationen (z. B. RelevantTo, DerivedFrom) zu bewerten, strukturiert jedoch den Denkprozess expliziter und auditierbarer als einen ganzheitlichen Prompt.

Zentrale Beiträge

Taxonomie der Fehlausrichtung: Eine formale Unterscheidung zwischen Fehlausrichtungen auf Werkzeug-, Parameter- und Interpretationsebene.
Provenienz-basierter Rahmen: Ein konzeptionelles Modell, das die Prüfung der Ausrichtung als Bestimmung definiert, ob Werkzeugaufrufe auf nachvollziehbaren Belegen basieren, formalisiert durch spezifische binäre Relationen.
ProvenanceGuard: Eine Multi-Stage-Pipeline-Implementierung des Rahmens, die als Runtime-Guardrail operiert.
Benchmarking: Evaluierung über zwei Benchmarks (Agent-SafetyBench und WorkBench) und 10 Backbone-LLMs, einschließlich einer manuell annotierten Teilmenge von Agent-SafetyBench-Traces.

Experimentelle Ergebnisse

Die Autoren evaluierten ProvenanceGuard gegenüber einem DirectPrompt Baseline (Standard LLM-as-a-judge) und einem Single-step Provenance Prompt (ProvePrompt, welches die Konzepte des Rahmens in einem einzigen Durchgang nutzt).

Erkennung von Fehlausrichtung (Error Rate):
- Auf Agent-SafetyBench (fokussiert auf Unterbestimmtheit) reduzierte ProvenanceGuard die Fehlerrate bei fehlgerichteten Traces von 42,9 % (Baseline) auf 1,8 %.
- Auf WorkBench sank die Fehlerrate von 32,1 % auf 17,3 %.
- Das mehrstufige Design (ProvenanceGuard) übertraf konsistent die einstufige Variante (ProvePrompt), insbesondere auf Agent-SafetyBench, was den Wert der Dekomposition des Denkprozesses unterstreicht.
Interventionskosten (Falsch-Positive/Unnötige Interventionen):
- Auf Agent-SafetyBench (ausgerichtete Traces) führte ProvenanceGuard nicht zu einer statistisch signifikanten Erhöhung unnötiger Interventionen im Vergleich zur Baseline.
- Auf WorkBench (aufgabenerfolgreiche Traces) reduzierte ProvenanceGuard die Interventionsrate signifikant von 30,5 % (Baseline) auf 12,8 %, was zeigt, dass es präziser ist als die Baseline darin, korrekte Aktionen passieren zu lassen.

Signifikanz und Behauptungen

Das Paper behauptet, dass strukturiertes, provenienz-basiertes Denken eine effektive und praktische Grundlage für die Sicherung von LLM-Agenten bietet. Die Signifikanz liegt in:

Systematisches Denken: Der Übergung weg von subjektiven, ganzheitlichen Urteilen hin zu einem Rahmen, der auf expliziten, auditierbaren Abhängigkeitsverknüpfungen zwischen Aktionen und Kontext basiert.
Umgang mit Unterbestimmtheit: Das Framework adressiert spezifisch das Risiko, dass Agenten bei unterbestimmten Anfragen unbegründete Annahmen treffen – eine häufige Ursache für Fehlausrichtung, die Standard-Sicherheitsfilter oft übersehen.
Ausgewogene Performance: Der mehrstufige Ansatz erreicht eine hohe Erkennungsgenauigkeit für fehlgerichtete Aktionen, ohne dabei prohibitive Kosten in Form des Blockierens valider, erfolgreicher Agenten-Aufgaben zu verursachen.

Die Autoren kommen zu dem Schluss, dass das Framework zwar keine Fehlausrichtung in rein generativen Parametern (wie freier Textgenerierung) erkennen kann und auf dem eigenen Plan des Agenten basiert (der theoretisch ebenfalls fehlgerichtet sein könnte), aber einen robusten Mechanismus zur Verhinderung irreversibler, kontextfremder Aktionen in agentischen Systemen bietet.