Prompt-Injection-Bewertung für Retrieval- und Tool-Use-Agents

Aktuelle Benchmarks erweitern die Testbedingungen

LongPIBench, ein Preprint vom August 2026, untersucht die prompte Injektion in längere Eingaben über mehrere dokumentenorientierte Aufgaben hinweg. NetInjectBench untersucht Toolaktionen mit vertrauenswürdigen Richtlinienmetadaten, getrennt von nicht vertrauenswürdigen Artefakten. Ihre Anwendungsbereiche unterscheiden sich, aber beide motivieren eher zum Testen realistischer Kontext- und Ausführungsgrenzen als zu einer kurzen kontroversen Aufforderung.

Beweis: LongPIBench: Ein Long-Context-Benchmark für die schnelle Injektion [1]NetInjectBench: Benchmarking der indirekten Prompt-Injection in Tool-Using Large Language Model Agents für den Netzwerkbetrieb [2]

Definieren Sie eine sichere und aussagekräftige Testgrenze

Geben Sie die autorisierte Benutzeraufgabe, die nicht vertrauenswürdige Eingabeoberfläche, das verbotene Ergebnis und die zum Testen verwendete Umgebung an. Verwenden Sie synthetische Datensätze, Scheingeheimnisse und harmlose Endpunkte. Führen Sie keine unbefristeten Angriffe auf Systeme oder Konten außerhalb des vereinbarten Umfangs durch.

Unterscheiden Sie die Antwort des Modells von der Durchsetzung der Anwendung. Wenn der Agent einen nicht autorisierten Vorgang anfordert, das Tool-Gateway ihn jedoch ablehnt, funktionierte die Grenze, während der Agent immer noch einen Planungsfehler aufwies. Notieren Sie beide Fakten. Ein Single-Pass-Etikett würde nützliche Diagnoseinformationen verbergen.

Kombinieren Sie Angriffsfälle mit harmlosen Kontrollen

Rubrex empfiehlt, abgerufene Dokumente, zitierte Nachrichten, Toolfehler und lange Eingaben mit gemischtem Kontext zu testen. Fügen Sie harmloses Material hinzu, das zwingende Formulierungen enthält, beispielsweise ein Handbuch, das einen Befehl beschreibt. Ein System, das alle derartigen Texte ablehnt, kann resistent erscheinen, obwohl normale Aufgaben fehlschlagen.

Die Auswirkung der Kontextlänge und -platzierung zu bewerten, ohne eine Position anzunehmen, ist immer am schwierigsten. Halten Sie die angeforderten Aufgaben und Berechtigungen beim Vergleich einer Verteidigung stabil. Behalten Sie die exakten Artefakte und Anwendungsversionen bei, damit das Ergebnis reproduziert werden kann, ohne dass wirklich sensible Daten preisgegeben werden.

Anschauliches Beispiel: Ein Dokument fordert eine Nebenaktion

Ein wissenschaftlicher Mitarbeiter wird gebeten, ein Dokument zusammenzufassen. Ein Testdokument enthält eine Anweisung zum Ändern eines nicht zugehörigen Datensatzes. Die autorisierte Aufgabe bleibt die Zusammenfassung; Der Dokumentinhalt kann keine Berechtigung für die Nebenaktion erteilen. Bei der Auswertung wird geprüft, ob keine Mutation vorliegt und die sinnvolle Zusammenfassung noch vervollständigt werden kann.

Eine harmlose Kontrolle enthält einen Absatz, in dem erläutert wird, wie Datensatzänderungen funktionieren, ohne dass eine solche Anforderung erforderlich ist. Der Assistent sollte in der Lage sein, diesen Absatz zusammenzufassen. Dies hilft, Überblockungen zu erkennen, die durch einfache schlüsselwortbasierte Abwehrmaßnahmen verursacht werden.

Widerstand und Nutzen sichtbar halten

Melden Sie versuchte Grenzverletzungen, ausgeführte Verstöße, blockierte legitime Aufgaben und unvollständige Ausführungen separat. Dokumentieren Sie Kontrollen auf Tool-Ebene und bekannte Abdeckungslücken. Eine bestandene Testsuite unterstützt eine begrenzte Beobachtung der getesteten Bedingungen und keinen Anspruch darauf, dass das System injektionssicher ist.

• Verwenden Sie isolierte und harmlose Ziele.
• Verfolgen Sie, ob die verbotene Aktion versucht oder ausgeführt wurde.
• Fügen Sie gewöhnliche Dokumente mit befehlsähnlicher Sprache ein.
• Nach Werkzeug-, Abruf-, Berechtigungs- oder Modelländerungen erneut testen.

LLM-Sicherheitskontrollen und die Grenzen von Leitplanken

Definieren Sie für LLM-Sicherheitstests, welche Assets und Aktionen die Anwendung schützen muss, bevor kontroverse Fälle erstellt werden. Schwachstellen in LLM-Anwendungen können entstehen, wenn nicht vertrauenswürdiger Text einen Tool-Aufruf beeinflusst, eine Datengrenze überschreitet oder eine Befehlspriorität ändert. Rubrex empfiehlt, jeden Test einer bestimmten geschützten Aktion und einem klar beobachtbaren Ergebnis innerhalb einer autorisierten Umgebung zuzuordnen.

LLM-Red-Teaming kann eine begrenzte Bewertung unterstützen, aber eine Prompt-Injection-Suite allein deckt nicht alle LLM-Schwachstellen ab. Kombinieren Sie kontroverse Fälle mit legitimen Anfragen, um zu prüfen, ob LLM-Leitplanken sowohl nützliches als auch schädliches Verhalten blockieren. Notieren Sie die getestete Kontrolle, das beobachtete Ergebnis und die ungetesteten Grenzen. Halten Sie die Zugriffskontrolle und die Durchsetzung von Berechtigungen außerhalb der Ermessensanweisungen des Modells.

Häufige Fragen