Prompt Injection verhindern: Guardrails für eine echte LLM-App

Bringst du ein LLM-Feature live, das irgendetwas liest, das du nicht vollständig kontrollierst, die Nachricht eines Nutzers, ein Dokument, eine Webseite, die ein Tool geladen hat, öffnest du damit einen Kanal, in den ein Angreifer schreiben kann. Prompt Injection ist Text, der über genau diesen Kanal ankommt und versucht, die Anweisungen des Modells zu kapern, statt die gestellte Frage zu beantworten. Dieser Leitfaden zeigt, wie du Prompt Injection mit Verteidigungen verhinderst, die auch bei echtem Traffic standhalten. Keine davon macht ein Modell vollständig immun dagegen. Verteidigung in mehreren Schichten treibt die Kosten eines Angriffs so weit hoch, dass die meisten Angreifer zu einem leichteren Ziel weiterziehen.

Eine LLM-App funktioniert, indem sie dem Modell einen Prompt übergibt: System-Anweisungen, die dein Team geschrieben hat, plus alles, was die Anfrage sonst noch mitbringt, die Nachricht eines Nutzers, einen Dokumentabsatz, die Ausgabe eines früheren Tool-Aufrufs. Das Modell sagt den nächsten Textabschnitt aus all dem zusammen vorher und liest Anweisungen und abgerufenen Text als einen einzigen durchgehenden Strom von Tokens. Nichts markiert den einen Teil als vertrauenswürdige Anweisung und den anderen als nicht vertrauenswürdige Daten. Prompt Injection ist nicht vertrauenswürdiger Text, der so gestaltet ist, dass er als Anweisung gelesen wird statt als Inhalt, der zusammengefasst oder zu dem eine Frage beantwortet werden soll. Eine Support-E-Mail, die dem lesenden Modell sagt, es solle Kontodetails preisgeben, die es nicht preisgeben sollte. Eine Zeile in einer gescrapten Webseite, die einem Recherche-Agenten sagt, er solle eine Prüfung überspringen, die er eigentlich durchführen sollte. Der Wortlaut ändert sich ständig. Das Muster bleibt gleich: Inhalt, dem das Modell eigentlich nicht gehorchen sollte, wird trotzdem befolgt, weil es keine eingebaute Möglichkeit hat, Anweisung von Daten zu unterscheiden.

Direkte Injection ist der einfachere Fall: Jemand tippt in dein Chat-Interface und versucht, dessen Anweisungen zu überschreiben, indem er das Modell bittet, seinen System-Prompt zu ignorieren oder außerhalb seines Scopes zu antworten. Das überschneidet sich mit Jailbreaking, auch wenn das Ziel ein anderes ist. Jailbreaking zielt meist auf das eigene Safety-Training des Modells. Direkte Injection zielt auf das, was deine App dem Modell konkret aufgetragen hat. Indirekte Injection ist die Variante, die Teams kalt erwischt. Der schädliche Text kommt an, ohne dass die aktuell chattende Person auch nur ein Wort davon geschrieben hat. Er steckt stattdessen in einem Dokument, das dein Assistent zusammenfasst, einer Webseite, die dein Recherche-Agent liest, oder einem Support-Ticket, das dein Triage-Tool verarbeitet. Das Modell kann einen legitimen Absatz nicht von einer eingeschleusten Anweisung unterscheiden, sobald beide nur noch Text im Kontext sind. Indirekte Injection verdient mehr Aufmerksamkeit, als sie normalerweise bekommt. Zu filtern, was ein Nutzer eintippt, fängt davon gar nichts ab, weil der Nutzer den Angriff nie eingetippt hat. Die fragende Person ist oft genauso überrascht wie du.

Ein Chatbot, der aus einem festen Skript antwortet, hat kaum eine nennenswerte Angriffsfläche. Kommt Retrieval dazu, ändert sich das schnell. Jedes Dokument, das eine RAG-Pipeline in den Kontext zieht, ein Hilfeartikel, ein hochgeladener Vertrag, ein Live-Suchergebnis aus dem Web, ist Text, den das Modell liest und womöglich danach handelt. Weitest du die Quellen aus, aus denen abgerufen wird, weitest du auch die Stellen aus, an denen jemand eine Anweisung platzieren könnte. Agenten verschärfen die andere Hälfte des Problems: die Konsequenzen. Ein Chatbot, der zu einem nicht autorisierten Thema verleitet wird, verschwendet ein Gespräch. Ein Agent, der ausgetrickst wird, während er ein Tool hält, das E-Mails verschickt, in eine Datenbank schreibt oder eine Zahlungs-API aufruft, kann nach der Anweisung handeln, die er fälschlich für legitim gehalten hat. Das Modell tut genau das, was sein Kontext ihm sagt, und der Kontext ist es, der kompromittiert wurde. Die meisten nützlichen LLM-Features brauchen Retrieval, Tool-Zugriff oder beides. Die eigentliche Aufgabe besteht darin, jede abgerufene Passage und jeden Tool-Aufruf als Stelle zu behandeln, die ein Angreifer erreichen könnte.

Frag fünf Anbieter, wie man Prompt Injection verhindert, und du bekommst fünf Produkte zum Kaufen. Keines davon löst das Problem allein. Was in der Praxis standhält, ist, Verteidigungen zu schichten, sodass kein einzelner Ausfall einem Angreifer das gewünschte Ergebnis liefert. Fang mit der schwächsten Schicht an: der Instruction Hierarchy, also den System-Prompt so zu formulieren, dass er bestimmte Inhalte als Daten behandelt und darin vergrabene Anweisungen ignoriert. Das hilft gegen beiläufige Versuche, und es ist auch die Schicht, um die Angreifer am leichtesten herumkommen. Behandle sie als Bremsschwelle. Mehr nicht. Input- und Output-Filtering sitzen eine Stufe höher: ein Klassifizierer, der Inhalte markiert, die wie eine Anweisung aussehen, oder Ausgaben, die wie ein Leak aussehen. Das fängt bekannte Muster ab und stoppt nachlässige Versuche. Ein entschlossener Angreifer formuliert um, kodiert oder zerlegt die Payload, bis etwas durchrutscht. Die beiden Schichten, die wirklich etwas am Ergebnis ändern, wenn die ersten beiden versagen: wen und was das Modell berühren kann, und wie du mit dem umgehst, was am anderen Ende herauskommt.

Least-Privilege-Zugriff ist die Verteidigung, die sich auch dann noch auszahlt, wenn jede andere Schicht versagt. Gib dem Modell, und jedem Tool, das es aufruft, nur die Berechtigungen und Daten, die es für die jeweilige Aufgabe braucht. Ein Support-Agent, der Abrechnungsfragen beantwortet, braucht keinen Schreibzugriff auf die Abrechnungsdatenbank. Ein Dokumenten-Zusammenfasser braucht kein Tool, das E-Mails verschickt. Rutscht eine Injection durch jeden Filter, bleibt der Schaden klein, weil nichts Gefährliches in Reichweite liegt. Scope API-Keys und Tool-Berechtigungen pro Aufgabe statt pro App. Trenne die Credentials, die ein Zusammenfassungs-Feature nutzt, von denen eines Abrechnungs-Features. Isoliere Daten pro Mandant, sodass die Dokumente eines Kunden niemals die Frage eines anderen beantworten können. Wie eng die Reichweite des Modells gehalten wird, entscheidet, ob dich eine Injection jemals etwas kostet.

Alles, was ein Modell ausgibt, verdient dasselbe Misstrauen wie Text, den ein Fremder irgendwo im Netz getippt hat. In gewissem Sinn kann es genau das sein: die Worte eines Fremden, gewaschen durch dein Modell. Diese Ausgabe ungefiltert direkt in eine Webseite zu rendern, kann aus einer erfolgreichen Injection ein gespeichertes Skript machen, das jeden Besucher nach dem ersten trifft. Sie in eine Datenbankabfrage oder einen Shell-Befehl zu geben, macht aus einem Sprachproblem ein Code-Execution-Problem. Human-in-the-loop schließt die Lücke, die kein Filtering allein schließen kann. Alles Folgenreiche, Geld bewegen, einen Datensatz löschen, jemandem außerhalb deines Unternehmens eine E-Mail schicken, eine Berechtigung ändern, sollte anhalten, bis eine Person das bestätigt, egal wie selbstsicher das Modell klingt. Ein erfolgreich manipuliertes Modell klingt exakt so selbstsicher wie ein legitimes. Selbstsicherheit war nie das Signal, dem man trauen sollte.

Verteidigungen gegen Prompt Injection zu testen sieht anders aus als ein normales Feature zu testen. Das Ergebnis ist ein Maß an Widerstandsfähigkeit, eher eine Skala als ein Häkchen. Die einzig wirklich funktionierende Methode ist Red-Teaming der eigenen App: die Angriffe versuchen, die ein Außenstehender versuchen würde, bevor es jemand anderes tut. Deck beide Seiten ab. Probiere direkte Versuche über das Chat-Interface, indem du das Modell bittest, seine Anweisungen zu ignorieren oder seinen System-Prompt preiszugeben. Probiere dann indirekte Versuche: platziere eine Anweisung in einem Dokument, das deine App realistischerweise einlesen würde, und schau, ob das Modell ihr folgt. Ein kleines, gegnerisch gedachtes Testset findet mehr als ein viel größeres Set aus normalen Nutzungsfragen. Lass das vor dem Launch laufen, und danach jedes Mal erneut, wenn sich der System-Prompt oder eine Datenquelle ändert, dieselbe Disziplin, die unser Leitfaden zu LLM Evaluation Metriken fürs Regressionstesting beschreibt. Wer die Verteidigung geschrieben hat, ist meistens die schlechteste Person, um sie zu testen. Hol dir eine Kollegin oder einen Kollegen dazu, die zwanzig Minuten damit verbringen, sie zu knacken.

Ein Gründer, der schnell shippt, braucht am ersten Tag keine Guardrails in Enterprise-Tiefe. Eine realistische Baseline für die MVP-Phase deckt vier Dinge ab:

• Jede Tool- und Datenverbindung auf die knappstmöglichen Berechtigungen scopen
• Allen abgerufenen Inhalt und jede Modellausgabe standardmäßig als nicht vertrauenswürdig behandeln
• Bei allem Folgenreichen eine Bestätigung durch eine Person verlangen, bevor es ausgeführt wird
• Genug Aktivität loggen, damit ein ungewöhnliches Muster auffällt

Plane das von Anfang an ins Budget ein. Guardrail-Arbeit ist Teil des Features selbst. Sie auszulassen, zeigt sich später als Support-Ticket oder Schlimmeres. Unser Leitfaden zu den Kosten der KI-App-Entwicklung rechnet vor, was das zu einem Build hinzufügt. Die Verteidigung gegen Prompt Injection ist ein Baustein eines größeren Sicherheitsbilds. Unser Leitfaden zu Sicherheit und Skalierbarkeit in der MVP-Entwicklung deckt den Rest ab. Kein Setup hier macht ein LLM-Feature immun gegen einen entschlossenen Angreifer. Eine mehrschichtige Baseline, die mit dem Feature mitwächst, sorgt dafür, dass ein realistischer Angreifer mehr Aufwand hat, als sich lohnt. Wenn du Guardrails für ein Feature mit echten Nutzerdaten scopst, sprich mit unserem Team für KI-Integration, und wir dimensionieren die Verteidigung passend dazu.