Klassische Software trennt Code und Daten. LLM-Anwendungen tun das nicht: Anweisungen und Inhalte landen im selben Text, und das Modell entscheidet selbst, was es als Anweisung behandelt. Prompt Injection nutzt genau diese Eigenschaft aus. In der OWASP Top 10 für LLM-Anwendungen steht sie an erster Stelle.
Direkte und indirekte Injection
Bei der direkten Variante schreibt ein Nutzer Anweisungen in seine Eingabe, etwa um Systemvorgaben zu umgehen oder vertrauliche Informationen aus dem Prompt zu entlocken. Gefährlicher ist die indirekte Variante: Die Anweisung steckt in einem Inhalt, den das Modell im Auftrag eines harmlosen Nutzers verarbeitet — einer Webseite, einem PDF, einer E-Mail, einem Dokument im RAG-Index. Das Modell liest den Text und folgt der versteckten Anweisung, ohne dass der Nutzer davon weiss.
Warum das gefährlich wird
Solange ein Modell nur Text ausgibt, ist der Schaden begrenzt. Sobald es über Tool-Calling handeln kann — E-Mails senden, Daten abfragen, Dateien ändern, Zahlungen vorbereiten —, kann eine eingeschleuste Anweisung reale Folgen haben. Ein KI-Agent, der Webseiten liest und gleichzeitig Zugriff auf Kundendaten hat, ist ein klassisches Ziel für Datenabfluss.
Warum es keine vollständige Lösung gibt
Es gibt keinen Filter, der Prompt Injection zuverlässig erkennt, weil Anweisungen in natürlicher Sprache beliebig formuliert werden können. Modelle werden robuster, aber nicht immun. Schutz entsteht deshalb nicht im Prompt, sondern in der Architektur: Man geht davon aus, dass Injection gelingen kann, und begrenzt, was dann passieren darf.
Architekturmassnahmen
Minimale Rechte: Ein Modell erhält nur die Werkzeuge und Daten, die der konkrete Anwendungsfall braucht. Trennung: Inhalte aus nicht vertrauenswürdigen Quellen werden markiert und nicht mit privilegierten Aktionen kombiniert. Bestätigung: Folgenreiche Aktionen brauchen eine Freigabe durch den Menschen. Ausgabekontrolle: Links, Bilder und Daten in Ausgaben werden geprüft, damit keine Informationen über präparierte URLs abfliessen. Mandantengrenzen werden serverseitig durchgesetzt, nicht im Prompt. Ergänzend helfen Guardrails, Protokollierung und Red-Teaming als Teil der Evaluation.
Für Produktteams
Die wichtigste Frage bei jeder LLM-Funktion lautet: Was ist das Schlimmste, das passiert, wenn ein Angreifer den Prompt kontrolliert? Wenn die Antwort inakzeptabel ist, muss die Architektur geändert werden, nicht der Prompt. Unsere Checkliste zur Produktionsreife von LLM-Funktionen behandelt diese Frage als eigenen Schritt.