Playbook6 Abschnitte · 2 Min. LesezeitVon Dezső Mező.mdLLMPrompt injectionOWASPRAG
Dies ist die gekürzte Fassung des vollständigen Playbooks des Studios. Jede Kategorie unten ist ein wirklich anderer Angriff mit einer wirklich anderen Gegenmaßnahme, und sie als ein Problem zu behandeln ist der Fehler, der immer wiederkehrt.
01Direkte Injection
Jemand tippt eine Anweisung ins Chatfeld, die auf deinen System-Prompt zielt. Die Abwehr ist gut bekannt: System- von Nutzerinhalt trennen, die Anweisungshierarchie explizit markieren, Ablehnungsmuster pflegen. Das Versagen liegt nicht im Nichtwissen, sondern darin, es einmal umzusetzen und nie wieder zu prüfen.
02Indirekte Injection über Dokumente
Die Anweisung steckt in einer Datei, die der Nutzer hochgeladen hat, oder auf einer Seite, die der Agent geholt hat. Der Nutzer hat nie etwas Feindseliges getippt. Alles, was das Modell liest und der Nutzer nicht selbst verfasst hat, muss als nicht vertrauenswürdiger Inhalt gelten, nicht als Anweisung.
03Vergiftung des RAG-Index
Die Nutzlast wird in den Retrieval-Index selbst geschrieben und taucht später bei anderen Nutzern und anderen Fragen auf. Diese Variante überlebt ein Deployment — das macht sie schlimmer als die ersten beiden.
04Missbrauch von Tool-Aufrufen
Die Injection zielt nicht auf die Antwort, sondern auf die Werkzeuge. Die Autorisierung muss an der Werkzeuggrenze sitzen und pro Nutzer geprüft werden — nicht aus einem Gespräch abgeleitet, das der Angreifer mitgeschrieben hat.
05Abfluss über gerenderte Ausgaben
Daten verlassen das System über das, was die Antwort rendert: ein Link, eine Bildquelle, eine Markdown-Referenz auf den Host eines Angreifers. Den Inhalt der Antwort zu prüfen genügt nicht, wenn man sie danach uneingeschränkt rendert.
06In der CI messen
Alle fünf Kategorien gehören in ein Eval-Harness, das bei jeder Änderung läuft — aus demselben Grund wie Unit-Tests. Eine Abwehr, die niemand nachprüft, ist eine Abwehr, die still aufhört zu wirken.
Was bleibt
- Fünf Kategorien, fünf Abwehrmaßnahmen. Ein Bereinigungsfilter deckt eine davon ab.
- Alles, was das Modell liest, der Nutzer aber nicht geschrieben hat, als nicht vertrauenswürdig behandeln.
- Autorisierung an die Werkzeuggrenze legen, pro Nutzer, nicht in den Prompt.
- Einschränken, was die Antwort rendern darf, nicht nur, was sie sagt.
- Alle fünf als Evals in der CI fahren, sonst verrotten die Abwehrmaßnahmen unbemerkt.
Mehr aus dem Lab
Alle Beiträge ansehen
RAG, das keinen falschen Preis nennen kann
Deine tausend Dependencies, auditiert an einem Nachmittag
KI-Sicherheits-Self-Audit
Prompts sind Code: evaluiere sie wie Code
Sollen wir das an Ihrem System ansehen?Gespräch beginnen
