Agent Red Teaming und OWASP LLM01

Warum Agents die Injektionsmathematik ändern

Von Ausgabe zu Aktion

In einem reinen Chatbot ist das Ziel einer Injektion, das Modell dazu zu bringen, etwas zu sagen, was es nicht sagen sollte. Die Auswirkungen hören auf, wenn der Text das Modell verlässt. Wenn das gleiche Modell ein Tool aufrufen kann, kann der injizierte Text zu einem Befehl werden, den das Tool ausführt. Ein Angreifer, der ein Tool zum Lesen von Dateien steuern kann, um eine vertrauliche Datei abzurufen, oder ein Tool zum Senden von E-Mails, um diese Datei weiterzuleiten, hat einen Wortwitz in einen Datenleck verwandelt. Die Schwere hängt daher von dem ab, was das Tool tun kann, und nicht davon, wie clever die Antwort ist.

Tool-Reichweite definiert Blast-Radius

Der Blast-Radius ist die Vereinigung aller Ressourcen, die die Tools des Agents berühren können. Wenn der Agent nur eine schreibgeschützte API zu einem öffentlichen Blog hat, ist der Worst-Case-Szenario das Lecken öffentlicher Informationen. Wenn der Agent ein Tool zum Schreiben in eine Datenbank, ein Tool zum Löschen von Dateien oder ein externes Zahlungsgateway aufrufen kann, kann die gleiche Injektion Datensätze löschen, Konten ändern oder Geld bewegen. Red-Team-Arbeit muss jedes Tool den Datenbeständen, Diensten oder Hardware zuordnen, die es beeinflussen kann, und dann testen, ob eine Injektion diese Vermögenswerte erreichen kann.

Häufige Missverständnisse

- Annahme, dass die Ausgabelänge des Modells den Schaden begrenzt – falsch, da eine kurze Zeichenfolge einen destruktiven Tool-Aufruf auslösen kann. - Glaube, dass die Filterung der Benutzernachricht ausreichend ist – falsch, da Injektionen innerhalb von Tool-Ergebnissen oder System-Prompts ankommen können. - Annahme, dass ein Modell mit wenigen Parametern sicher ist – falsch, wenn dieses Modell mit einer leistungsstarken Tool-Sammlung gepaart wird.

Für einen schnellen Überblick über defensive Codierung siehe die OWASP-Cheat-Sheet zu LLM-Prompt-Injection-Prävention.

Oberflächen, die jenseits des Chat-Fensters zu untersuchen sind

System-Prompt und Konfiguration

Der System-Prompt enthält oft API-Schlüssel, Dienst-URLs oder interne Richtliniensprache. Ein Angreifer, der in diesen Bereich injizieren kann, kann direkte Anmeldeinformationen erhalten oder erfahren, wo er weitere Sondierungen durchführen kann. Überprüfen Sie den Prompt auf statische Geheimnisse und testen Sie, ob sie durch einen Tool-Aufruf echofähig oder exfiltrierbar sind.

Tool-Schemata und Argumentvalidierung

Jedes exponierte Tool definiert ein JSON-Schema für seine Eingaben. Wenn das Schema freie Zeichenfolgen ohne strenge Validierung akzeptiert, kann ein Angreifer Befehle innerhalb dieser Zeichenfolgen einbetten. Zum Beispiel ist ein „run_sql“-Tool, das eine rohe Abfragezeichenfolge akzeptiert, anfällig für SQL-Injection, es sei denn, die Agent-Ebene bereinigt oder parametrisiert die Eingabe. Überprüfen Sie, ob der Agent Typbegrenzungen, Längenbegrenzungen oder Allow-Listen für jedes Argument erzwingt.

RAG-Pipelines (Retrieval-augmented generation)

Wenn der Agent Daten aus externen Quellen abruft – Webseiten, E-Mails, Ticketsysteme – werden diese Daten Teil des Kontexts des Modells. Ein Angreifer, der eine dieser Quellen kontrolliert, kann Anweisungen platzieren, die das Modell später als vertrauenswürdig behandelt. Untersuchen Sie, indem Sie eine bekannte externe Quelle vergiften und beobachten, ob der Agent auf den versteckten Befehl reagiert.

Befehlsweitergabe innerhalb von Tool-Ergebnissen

Einige Designs geben Tool-Ausgaben direkt in den nächsten Modellaufruf zurück, ohne sie erneut zu bereinigen. Wenn ein Tool eine Textzeichenfolge zurückgibt, die einen neuen Befehl enthält, kann das Modell ihn im nächsten Schritt befolgen. Dies erzeugt eine zweistufige Injektion, bei der die erste Stufe harmlos aussehende Daten und die zweite Stufe der böswillige Befehl ist. Testen Sie jeden Tool-Ausgabepfad, um zu sehen, ob der Agent rohe Ergebnisse in den Prompt-Generator zurückspeist.

Praktische Checkliste

- Extrahieren Sie den System-Prompt und suchen Sie nach hartcodierten Geheimnissen. - Listen Sie alle Tools auf, notieren Sie deren Schema und versuchen Sie, unerwartete Datentypen zu übergeben. - Identifizieren Sie alle externen Datenquellen, die für RAG verwendet werden, und injizieren Sie harmlose Marker, um die Reichweite zu überprüfen. - Erfassen Sie Tool-Ausgaben und speisen Sie sie als neue Eingaben ein, um zu sehen, ob der Agent sie als Befehle behandelt. - Dokumentieren Sie jede Kette, in der eine einzelne Benutzernachricht zu mehreren Tool-Aufrufen führt.

Für einen Vergleich mit klassischen Injektionsverteidigungen bietet die SQL-Injection-Cheat-Sheet nützliche Muster: OWASP A03:2021 – Injection.

Übermäßige Agentenhandlung ist das Begleitrisiko

Was übermäßige Agentenhandlung bedeutet

OWASP listet Excessive Agency unter LLM03 für 2026. Es beschreibt Agenten, die irreversible Aktionen ausführen können - E-Mails senden, Dateien löschen, Code ausführen - ohne eine separate Genehmigungsschritt. Das Risiko wächst, wenn die Autonomie des Modells die Sicherheitsvorkehrungen um seine Tools überholt.

Schwerpunkte für Red-Team-Tests

- Überprüfen Sie, ob destruktive Tools eine explizite Bestätigung durch einen Menschen oder einen separaten Dienst erfordern. - Versuchen Sie, zwei oder mehr Tools miteinander zu verbinden, indem Sie nur modellgenerierte Zwischenoutputs verwenden. - Überprüfen Sie, ob der Agent seine eigenen Berechtigungen erhöhen kann, beispielsweise indem er ein Tool aufruft, das seinen eigenen API-Schlüssel aktualisiert. - Testen Sie timebasierte Trigger: Kann ein verzögerter Toolaufruf verwendet werden, um eine Ratebegrenzung oder ein Sitzungstimeout zu umgehen?

Illustrierende Risikomatrix

Toolkategorie | Typische Berechtigung | Erforderliche Bestätigung | Potenzieller Missbrauch bei Fehlen Dateilesen | Schreibgeschützter Zugriff auf bestimmte Ordner | Keine (Lesen ist normalerweise sicher) | Exfiltration von Protokollen, Quellcode, Konfiguration Dateischreiben | Erstellen oder Überschreiben von Dateien | Ja - Benutzerbestätigung oder signierte Anfrage | Einfügen von Backdoors, Datenkorruption Datenbank schreiben | INSERT/UPDATE/DELETE auf Tabellen | Ja - Transaktionsbestätigung oder MFA | Datenverlust, Finanzbetrug, Berechtigungserhöhung Externer HTTP | Ausgehender Netzwerkzugriff auf beliebige Domänen | Ja - Zulassungsprüfung | Exfiltration von Daten, C2-Signalisierung, SSRF Codeausführung | Willkürliche Shell oder Interpreter | Ja - isolierter Sandbox + Bestätigung | Vollständige Kompromittierung des Hosts, Bereitstellung von Ransomware

Die Tabelle zeigt, warum ein Red-Team jede Zeile überprüfen muss: Wenn die Bestätigungsspalte fehlt, kann der Agent mit einem einzigen vergifteten Eingabe von harmlos zu schädlich werden.

Was ein Prüfbericht enthalten sollte

Wichtige Felder

Ein nützliches Ergebnis benötigt mehr als ein boolesches „Bestanden/Nicht bestanden“. Protokollieren Sie die genaue Benutzereingabe, die die Kette ausgelöst hat, die geordnete Liste der Tools, die der Agent aufgerufen hat, und die endgültige beobachtbare Auswirkung (z. B. eine geschriebene Datei, eine gesendete Netzwerkanfrage, eine geänderte Datenbankzeile). Fügen Sie die rohen Toolargumente hinzu, wie sie gesendet wurden, und die interne Denkspur des Modells, wenn Ihr Framework sie offenlegt.

Schweregrad-Richtlinie

- Niedrig - Leckage öffentlicher Informationen oder eine rückgängig zu machende Zustandsänderung. - Mittel - Zugriff auf interne Daten, die nicht reguliert sind, oder eine rückgängig zu machende Aktion, die einen manuellen Reset erfordert. - Hoch - Änderung regulierter Daten, Finanztransaktion oder Ausführung willkürlichen Codes. - Kritisch - persistenter Backdoor, Datenzerstörung oder Fähigkeit, einen Fuß im Sitz zu behalten, nachdem die Sitzung beendet ist.

Priorisieren Sie die Behebung von Fehlern mit hoher und kritischer Schwere zuerst; geringfügige Mängel können in einem späteren Hartungs-Sprint behoben werden.

Handhabbare Hinweise zur Behebung

- Fügen Sie eine schemabasierte Validierung hinzu, die Zeichenfolgen ablehnt, die SQL-Schlüsselwörter oder Shell-Metazeichen enthalten. - Schließen Sie destruktive Tools in einen Microservice ein, der ein signiertes Genehmigungstoken erfordert. - Implementieren Sie eine Zulassungsliste für ausgehende HTTP-Anrufe und protokollieren Sie jeden versuchten Verbindungsaufbau. - Sanitisieren Sie die Ausgaben von Tools, bevor sie in die Modellprompt wieder eingesetzt werden - entfernen oder maskieren Sie jeden Inhalt, der wie eine Anweisung aussieht. - Verwenden Sie eine schreibgeschützte Replikation für jedes Datenbankabfrage-Tool, es sei denn, ein Schreiben ist explizit erforderlich.

Red-Teaming ist kein Ersatz für Designkontrollen

Warum Tests Ergänzungen und keine Ersetzungen von Sicherheitsvorkehrungen sind

Red-Team-Arbeit entdeckt Lücken, die bereits in der Implementierung bestehen. Es bietet keine Garantien, die durch eine minimalistische Tool-Design, Bestätigungstore oder Netzwerksegmentierung entstehen. Behandeln Sie jeden Test als Validierungsschritt: Wenn die Kontrollen die eingeschleuste Kette stoppen, haben Sie den Beweis, dass sie funktionieren; wenn sie nicht funktionieren, haben Sie einen konkreten Fehler zu beheben.

Kontrollen, die priorisiert werden sollten

- Führen Sie jedes Tool unter einem dedizierten OS-Benutzer mit dem minimalen Satz an Dateisystemfunktionen aus. - Erfordern Sie einen separaten Genehmigungsdienst für jeden Aufruf, der den Zustand ändern kann, protokollieren Sie die Entscheidung und erzwingen Sie ein Timeout. - Wenden Sie Netzwerkrichtlinien an, die ausgehende Verbindungen auf bekannte interne Dienste und eine kurze Liste externer APIs beschränken. - Verschlüsseln Sie Geheimnisse im Ruhezustand und platzieren Sie sie niemals im Systemprompt; verwenden Sie stattdessen einen Vault-Dienst. - Protokollieren Sie jeden Tool-Aufruf mit Benutzer-ID, Timestamp, Eingabehash und Ausgabehash für die forensische Überprüfung.

Wenn diese Kontrollen vorhanden sind, ändern sich die Ergebnisse des Red-Teams von „Wir haben einen Weg gefunden, es zu brechen“ zu „Wir haben X versucht und die Kontrollen haben es blockiert“, was ein stärkeres Signal für Sicherheitsreife ist.

Was dies NICHT ist

Keine Garantie für Vollständigkeit

Dieser Leitfaden verspricht nicht, dass das Befolgen der Schritte jeden möglichen Einschleusversuch abfängt. Neue Techniken, Zero-Day-Tool-Schwachstellen oder nicht offengelegte Agentenfunktionen können die hier beschriebenen Überprüfungen umgehen.

Keine 100-%-Lösung

Die Anwendung der Minderungsmaßnahmen reduziert das Risiko, eliminiert es aber nicht. Verteidigung in der Tiefe erfordert eine kontinuierliche Überwachung, regelmäßige Überprüfungen der Tool-Kette und Updates, wenn neue OWASP-Veröffentlichungen erscheinen.

Falsche Behauptung, nie zu verpassen

Keine Red-Team-Methode kann behaupten, nie eine Schwachstelle zu verpassen. Das Ziel ist es, die Kosten für einen Angreifer zu erhöhen und eine erfolgreiche Ausnutzung bemerkbar und nachverfolgbar zu machen.

Kein Ersatz für sicheres Coden

Die Empfehlungen gehen davon aus, dass Sie bereits grundlegende sichere Codierungspraktiken befolgen – Eingabevalidierung, Ausgabeencoding und das Prinzip der geringsten Rechte. Sie fügen agentenspezifische Schichten auf diese Grundlage hinzu.

Referenzen

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://genai.owasp.org/llmrisk/llm01-prompt-injection - https://owasp.org/Top10/2021/A03_2021-Injection

Verwandte Artikel

- Tool-Missbrauchstests für LLM-Agents - Erforschen Sie die vollständige AI-Micro-SaaS-Themenmatrix →