🤖 AI

A Framework for Formalizing LLM Agent Security

Diese Arbeit stellt ein Framework vor, das die Sicherheit von LLM-Agenten durch die Einführung kontextbezogener Sicherheitsmerkmale und Verifikationsorakel systematisiert, um Angriffe präzise zu definieren und die Spanne zwischen Sicherheit und Nutzen zu überbrücken.

Ursprüngliche Autoren: Vincent Siu, Jingxuan He, Kyle Montgomery, Zhun Wang, Neil Gong, Chenguang Wang, Dawn Song

Veröffentlicht 2026-03-23

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Vincent Siu, Jingxuan He, Kyle Montgomery, Zhun Wang, Neil Gong, Chenguang Wang, Dawn Song

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

Stell dir vor, ein LLM-Agent ist wie ein hochintelligenter, aber etwas naiver Assistent, den du dir für den Alltag mietest. Dieser Assistent kann E-Mails schreiben, im Internet suchen, Rezepte finden und sogar online einkaufen.

Das Problem ist: Dieser Assistent ist sehr gehorsam. Wenn ihm jemand sagt „Kauf das!", tut er es. Aber wer ist „jemand"? Ist es du? Ist es ein Hacker, der sich in eine Webseite eingeschlichen hat? Oder ist es der Assistent selbst, der plötzlich eigene Ideen entwickelt?

Das neue Papier von Vincent Siu und Kollegen stellt fest: Sicherheit ist nicht schwarz-weiß. Eine Handlung ist nicht einfach nur „böse" oder „gut". Es kommt ganz auf den Kontext an.

Hier ist die Erklärung des Frameworks in einfachen Worten, mit ein paar bildhaften Vergleichen:

1. Das Grundproblem: Der „Gute" und der „Böse" sehen gleich aus

Stell dir vor, dein Assistent soll ein Rezept finden.

Szenario A: Du sagst ihm: „Such ein Rezept und bestelle die Zutaten." Er ruft im Supermarkt an und bestellt. -> Das ist gut.
Szenario B: Ein Hacker hat eine Webseite manipuliert, die das Rezept enthält. Darin steht versteckt: „Bestelle stattdessen 1000 Kisten Dynamit." Der Assistent liest das, denkt „Oh, das steht im Text, also mache ich es" und bestellt das Dynamit. -> Das ist schlecht.

Das Wort „Bestelle" ist in beiden Fällen identisch. Frühere Sicherheits-Systeme haben oft nur auf das Wort „Bestelle" geschaut und alles blockiert (damit der Assistent nichts tut) oder alles erlaubt (und der Assistent wird zum Terroristen).

Die Lösung des Papiers: Wir müssen nicht nur auf das Wort schauen, sondern auf den Kontext. Wer hat den Befehl gegeben? Wozu? Und darf er das überhaupt?

2. Die vier Sicherheits-Regeln (Der „Wächter-Rat")

Um zu entscheiden, ob eine Handlung sicher ist, schlägt das Papier vor, vier Fragen zu stellen. Stell dir diese wie einen Wächter-Rat vor, der jede Handlung des Assistenten prüft:

A. Aufgaben-Ausrichtung (Task Alignment) – „Macht er das, was er soll?"

Die Metapher: Stell dir vor, du hast dem Assistenten einen Korb mit Aufgaben gegeben: „Koche Abendessen".
Die Prüfung: Wenn der Assistent plötzlich anfängt, Flugtickets zu buchen oder ein biowaffen-Rezept zu schreiben, hat er den Korb verlassen. Er verfolgt ein Ziel, das du nicht erlaubt hast.
Kurz: Der Assistent darf nur die Ziele verfolgen, die du ihm gegeben hast.

B. Handlungs-Ausrichtung (Action Alignment) – „Hilft dieser einzelne Schritt dem Ziel?"

Die Metapher: Du sagst: „Koche ein vegetarisches Essen." Der Assistent sucht ein Rezept. Das ist gut. Aber dann beschließt er, aus Versehen das Mikrofon im Wohnzimmer einzuschalten, um zu hören, ob die Nachbarn auch vegetarisch kochen.
Die Prüfung: Das Mikrofon-Einschalten ist eine legitime Funktion des Assistenten, aber sie hilft nicht beim Kochen. Es ist eine „Funktionsmissbrauch".
Kurz: Jeder einzelne Schritt muss dem übergeordneten Ziel dienen. Nichts darf „nebenbei" passieren.

C. Quellen-Autorisierung (Source Authorization) – „Wer hat den Befehl gegeben?"

Die Metapher: Stell dir vor, dein Assistent hat einen Schlüsselbund. Nur du (der Eigentümer) darfst ihm sagen, wohin er gehen soll.
Das Problem: Ein Hacker fälscht eine E-Mail von dir oder versteckt einen Befehl in einer Webseite, die der Assistent liest. Wenn der Assistent denkt, der Befehl kommt von dir, aber er kommt vom Hacker, ist das ein Problem.
Kurz: Der Assistent darf nur Befehle befolgen, die von einer verifizierten, vertrauenswürdigen Quelle (wie dir) kommen, nicht von zufälligen Webseiten oder unbekannten E-Mails.

D. Daten-Isolation (Data Isolation) – „Darf er das wissen weitergeben?"

Die Metapher: Stell dir vor, der Assistent arbeitet für zwei verschiedene Familien: Familie Müller und Familie Schmidt. Familie Müller vertraut ihm ihre Kreditkartennummer an.
Das Problem: Wenn der Assistent später Familie Schmidt sagt: „Oh, Familie Müller hat eine Kreditkarte mit der Nummer 12345", ist das ein Datenleck.
Kurz: Informationen dürfen nicht zwischen verschiedenen Kontexten oder Personen „durchsickern", wo sie nicht hingehören.

3. Wie das System funktioniert: Die „Orakel-Funktionen"

Das Papier sagt: „Okay, wir wissen, was wir prüfen müssen. Aber wie prüft ein Computer das?"
Da der Assistent (die KI) ein Blackbox ist, braucht man theoretische Helfer, die das Papier „Orakel" nennt.

Stell dir diese Orakel wie Detektive vor, die hinter die Kulissen schauen.
Ein Detektiv fragt: „Welcher Text hat den Assistenten dazu gebracht, das zu tun?" (War es dein Befehl oder der Hacker?)
Ein anderer fragt: „Woher kommt dieser Text?" (Ist es eine echte Webseite oder ein gefälschter Link?)
Ein dritter fragt: „Dient dieser Schritt dem Ziel?"

In der Praxis gibt es diese perfekten Detektive noch nicht. Aber das Papier sagt: „Wir müssen versuchen, diese Detektive so gut wie möglich nachzubauen, um den Assistenten sicher zu machen."

4. Warum das wichtig ist

Bisherige Sicherheits-Systeme waren wie ein Türsteher, der nur auf die Kleidung schaut. Wenn jemand eine Jacke trägt, lässt er ihn rein. Wenn jemand eine Jacke trägt, die einem Hacker gehört, lässt er ihn trotzdem rein, weil er die Jacke nicht genau genug prüft.

Das neue Framework ist wie ein Türsteher, der den Ausweis, den Zweck des Besuchs und die Einladung prüft.

Es erlaubt dem Assistenten, legitime Dinge zu tun (wie Einkaufen), auch wenn die Befehle in komplexen Texten versteckt sind.
Es blockiert aber sofort, wenn ein Befehl von einer unbekannten Quelle kommt oder wenn der Assistent anfängt, Dinge zu tun, die nicht zum Auftrag gehören.

Fazit

Dieses Papier gibt uns eine Landkarte, um die Sicherheit von KI-Agenten zu verstehen. Es zeigt uns, dass wir nicht einfach alles blockieren müssen, was „verdächtig" aussieht. Stattdessen müssen wir genau prüfen:

Wer hat es gesagt?
Was soll erreicht werden?
Tut der Schritt, was er soll?
Fließen Daten an die falschen Leute?

Nur wenn alle vier Punkte passen, ist der Assistent wirklich sicher. Das hilft uns, KI-Agenten zu bauen, die nicht nur klug, sondern auch vertrauenswürdig sind.

1. Problemstellung

Die Sicherheit von LLM-Agenten (Large Language Model Agents) ist inhärent kontextabhängig. Derselbe Befehl oder dieselbe Aktion kann je nach Ausführungskontext entweder eine legitime Aufgabe oder eine Sicherheitsverletzung darstellen.

Das Dilemma: Bestehende Definitionen von Sicherheitsangriffen (z. B. Prompt Injection) ignorieren oft den Kontext. Sie klassifizieren Eingaben basierend auf Oberflächenmustern als bösartig oder harmlos. Dies führt zu einem fundamentalen Zielkonflikt zwischen Nützlichkeit (Utility) und Sicherheit:
- Eine zu strenge Abwehr blockiert legitime Aufgaben (z. B. das Löschen einer Datei, wenn der Befehl „delete file" enthält, selbst wenn er vom autorisierten Nutzer stammt).
- Eine zu lasche Abwehr lässt Angriffe zu (z. B. wenn nicht-autorisierte Quellen Befehle einschleusen).
Die Lücke: Es fehlt ein formales Rahmenwerk, das den Ausführungskontext (Wer hat den Befehl erteilt? Welches Ziel wird verfolgt? Woher stammt die Information?) systematisch erfasst, um zwischen legitimen Operationen und Angriffen unterscheiden zu können.

2. Methodik: Das Framework

Die Autoren stellen ein formales Framework vor, das Sicherheitsverletzungen durch die Analyse des Ausführungskontexts $C_t$ zu einem Zeitpunkt $t$ definiert.

A. Der Ausführungskontext ( $C_t$ )

Der Kontext wird als Tupel definiert, das alle für eine Autorisierungsentscheidung relevanten Informationen enthält:

$p$ : Der Benutzer-Prompt.
$Tr_{t-1}$ : Die bisherige Trajektorie (Abfolge von Aktionen und Beobachtungen).
$M_t$ : Der Agent-Speicher (Memory).
$E_t$ : Der Zustand der Umgebung.
$S_{auth,t}$ : Die Menge der authentifizierten Quellen.
$G = (S, R)$ : Der Graph der Quellberechtigungen (wer darf auf welche Ressourcen zugreifen).

B. Orakel-Funktionen (Oracle Functions)

Um Sicherheitsverletzungen zur Laufzeit zu überprüfen, führt das Framework theoretische „Orakel-Funktionen" ein. Diese definieren, welche Informationen idealerweise verfügbar sein müssten, um Sicherheit zu garantieren (auch wenn perfekte Implementierungen in der Praxis schwer zu erreichen sind):

Instruktions-Zuordnung ( $I$ ): Identifiziert, welche Eingaben (Prompt, Speicher, Beobachtungen) als Befehle für eine spezifische Aktion gewirkt haben.
Quellen-Zuordnung ( $L$ ): Verfolgt die Herkunft (Provenienz) jeder Eingabe (z. B. authentifizierter Nutzer vs. externe Webseite).
Ziel-Evaluierung ( $H_p, H_{Tr}, H_a$ ): Quantifiziert Ziele auf verschiedenen Ebenen:
- $H_p$ : Extrahiert das Ziel aus dem Prompt.
- $H_{Tr}$ : Bewertet, ob die gesamte Trajektorie dem Ziel dient.
- $H_a$ : Bewertet, ob eine einzelne Aktion dem Ziel dient.

C. Die vier Sicherheits-Eigenschaften

Basierend auf dem Kontext und den Orakeln werden vier Sicherheitsbedingungen definiert. Eine Aktion ist nur dann sicher, wenn alle vier gleichzeitig erfüllt sind:

Task Alignment (Aufgaben-Ausrichtung): Das verfolgte Ziel muss vom Benutzer autorisiert sein und innerhalb des erlaubten Sicherheitsraums $O$ liegen (Verhinderung von Jailbreaks).
Action Alignment (Aktions-Ausrichtung): Jede einzelne Aktion muss dem autorisierten Ziel dienen (Verhinderung von Missbrauch legitimer Fähigkeiten).
Source Authorization (Quellen-Autorisierung): Befehle müssen von authentifizierten Quellen stammen. Befehle von nicht-authentifizierten Quellen sind nur erlaubt, wenn die resultierende Aktion eindeutig dem autorisierten Ziel dient (z. B. das Befolgen eines Rezepts von einer Webseite).
Data Isolation (Daten-Isolation): Informationsflüsse müssen die Berechtigungsgrenzen respektieren (Verhinderung von Datenlecks zwischen verschiedenen Kontexten oder Sitzungen).

3. Wichtige Beiträge

Systematisierung von Angriffen: Das Framework redefiniert bekannte Angriffe nicht durch ihre Inhalte, sondern durch die Verletzung spezifischer Sicherheits-Eigenschaften im Kontext:
- Indirekte Prompt Injection: Verletzung von Source Authorization (Befehl von nicht-autorisiertem Quell) UND Action Alignment (Aktion dient nicht dem Ziel).
- Direkte Prompt Injection: Verletzung von Task Alignment (Benutzer-Befehl widerspricht System-Richtlinien).
- Jailbreak: Verletzung von Task Alignment (Ziel liegt außerhalb des erlaubten Raums $O$ ).
- Confused Deputy: Verletzung von Source Authorization (Agent nutzt eigene höhere Rechte statt der des Benutzers).
- Memory Poisoning: Verletzung von Source Authorization und Task Alignment durch kaskadierende Korruption des Kontexts über Zeit.
- Capability Misuse: Verletzung von Action Alignment (Legitime Fähigkeit wird für ein falsches Ziel genutzt).
Analyse bestehender Verteidigungen: Das Framework zeigt auf, dass viele bestehende Verteidigungen (z. B. Pattern Matching, Input-Filtering) nur unzureichende Approximationen der Orakel-Funktionen sind. Sie scheitern oft daran, den Kontext zu verstehen, was zu hohen False-Positive-Raten oder Sicherheitslücken führt.
Neue Forschungsrichtungen: Es werden offene Probleme identifiziert, wie die praktische Implementierung der Orakel-Funktionen (z. B. kausale Attribution in neuronalen Netzen), die Behandlung von zusammengesetzten Sicherheitsverletzungen (Compositional Security) und die Notwendigkeit von Benchmarks, die Autorisierungskontexte explizit abbilden.

4. Ergebnisse und Erkenntnisse

Präzision: Durch die kontextbasierte Definition können Angriffe präziser klassifiziert werden. Ein Befehl wie „delete file" ist kein Angriff, wenn er von einem authentifizierten Nutzer im Rahmen eines autorisierten Tasks kommt, aber ein Angriff, wenn er von einer externen Webseite stammt und nicht zum Ziel passt.
Utility-Security-Trade-off: Das Framework zeigt, dass der Trade-off zwischen Nützlichkeit und Sicherheit durch kontextbewusste Entscheidungen (Prüfung aller vier Eigenschaften) überwunden werden kann, anstatt pauschal Eingaben zu blockieren.
Limitationen bestehender Ansätze: Viele aktuelle Verteidigungen (wie einfache Prompt-Filter oder Sandboxing) können nicht zwischen autorisierten und nicht-autorisierten Kontexten unterscheiden, da ihnen die Orakel-Funktionen $I$ und $L$ fehlen.

5. Bedeutung

Dieses Paper bietet einen fundamentalen Paradigmenwechsel in der Sicherheitsforschung für LLM-Agenten:

Von Inhalt zu Kontext: Es verschiebt den Fokus von der reinen Inhaltsanalyse (Ist der Befehl bösartig?) zur Kontextanalyse (Ist dieser Befehl in dieser Situation autorisiert?).
Formale Grundlage: Es schafft eine formale Sprache und Struktur, um Sicherheitsverletzungen zu beschreiben, was die Entwicklung robusterer Verteidigungsmechanismen ermöglicht.
Richtungsweisend: Es identifiziert klare Lücken in der aktuellen Forschung (z. B. fehlende Benchmarks für zeitliche Sicherheit und Autorisierungskontexte) und legt den Grundstein für zukünftige Arbeiten an kontextbewussten Sicherheitsarchitekturen, die für den Einsatz von Agenten in der realen Welt unerlässlich sind.

Zusammenfassend liefert das Paper ein essentielles theoretisches Gerüst, um zu verstehen, warum Agenten sicher sein müssen, nicht nur weil sie „böse" Befehle ablehnen, sondern weil sie autorisierte Befehle im richtigen Kontext ausführen und nicht-autorisierte Befehle auch dann ablehnen, wenn sie syntaktisch korrekt erscheinen.