Prompt Injection verstehen: Warum KI-Anwendungen eigene Security-Checks brauchen

Wenn eine klassische Web-Anwendung Eingaben verarbeitet, gilt eine bewährte Regel: Daten sind Daten, Code ist Code, und man hält beides getrennt. SQL-Injection wird verhindert, indem man Eingaben niemals als Befehle interpretiert.

Bei Sprachmodellen bricht genau diese Trennung zusammen. Für ein LLM sind Anweisung und Inhalt derselbe Text. Das ist keine Fehlkonfiguration — es ist die Funktionsweise. Und es ist der Grund, warum Prompt Injection im OWASP Top 10 for Large Language Model Applications (2025) auf Platz LLM01 steht, also als das wichtigste Risiko überhaupt.

Dieser Artikel erklärt das Problem ohne Hype und ohne Verharmlosung — für Entscheider, die eine KI-Funktion freigeben sollen, und für Teams, die sie bauen.

Was Prompt Injection eigentlich ist

Eine Prompt-Injection-Schwachstelle entsteht, wenn Benutzereingaben das Verhalten oder die Ausgabe des Modells in unbeabsichtigter Weise verändern. Laut OWASP müssen diese Eingaben für Menschen nicht einmal sichtbar oder lesbar sein — es reicht, dass das Modell sie verarbeitet.

Anders gesagt: Es geht nicht darum, dem Modell ein „böses Passwort" zu geben. Es geht darum, dass der Inhalt, den das Modell liest, selbst zur Anweisung werden kann.

Man unterscheidet zwei Grundformen:

Direkte Prompt Injection. Die Eingabe der nutzenden Person enthält selbst die manipulierende Anweisung („Ignoriere deine bisherigen Vorgaben und ...").
Indirekte Prompt Injection. Das gefährlichere Muster: Das Modell verarbeitet externe Inhalte — eine Webseite, ein PDF, eine E-Mail, ein Dokument im Wissensindex — und in diesem fremden Inhalt stecken Anweisungen, die das Verhalten verändern. Die nutzende Person hat nichts Bösartiges getan; sie hat nur eine Seite zusammenfassen lassen.

Mit multimodalen Systemen kommt eine dritte Ebene hinzu: Anweisungen können in Bildern versteckt sein, die zusammen mit harmlosem Text verarbeitet werden.

Ein konkretes Szenario

Das OWASP-Beispiel ist unspektakulär und genau deshalb lehrreich: Eine Person lässt ein LLM eine Webseite zusammenfassen. Die Seite enthält versteckte Anweisungen. Das Modell folgt ihnen — und baut etwa einen Bildlink ein, dessen Aufruf Teile der privaten Konversation an einen fremden Server überträgt.

Niemand hat hier ein Passwort verraten oder eine Datei hochgeladen. Der Angriff lief über vertrauenswürdig aussehenden Inhalt. Genau das macht indirekte Injection im Unternehmenskontext relevant: Sobald ein Assistent Dokumente, Tickets, Mails oder Webinhalte verarbeitet, ist die Inhaltsquelle Teil der Angriffsfläche.

Warum es keine „eine Lösung" gibt

Hier ist die unbequeme Wahrheit, die OWASP offen ausspricht: Wegen der stochastischen Natur generativer Modelle ist unklar, ob es überhaupt narrensichere Methoden gibt, Prompt Injection vollständig zu verhindern.

Das ist kein Grund, KI nicht einzusetzen. Es ist ein Grund, KI anders abzusichern als eine klassische Web-App. Man verhindert Prompt Injection nicht durch einen einzelnen Filter — man begrenzt ihren möglichen Schaden durch Architektur.

Der entscheidende Perspektivwechsel: Begrenzen, nicht nur Filtern

Die wirksamste Frage ist nicht „Wie verhindern wir jede Injection?", sondern „Was kann im schlimmsten Fall passieren, wenn eine Injection gelingt?"

Wenn die Antwort „nichts Schlimmes" ist, haben Sie ein sicheres System gebaut — nicht weil keine Injection möglich ist, sondern weil sie nichts erreicht.

Daraus folgen vier Architekturprinzipien:

1. Minimale Rechte für das Modell

Das Modell sollte nur auf das zugreifen können, was die konkrete Aufgabe braucht. Ein Zusammenfassungsassistent braucht keinen Schreibzugriff auf das ERP. Wenn das Modell wenig darf, kann eine erfolgreiche Injection wenig anrichten.

2. Tool-Isolation und menschliche Freigabe bei Wirkung

Solange das Modell nur Text erzeugt, ist der Schaden begrenzt. Gefährlich wird es, wenn die Ausgabe automatisch eine Aktion auslöst — eine Mail sendet, einen Datensatz ändert, eine Zahlung anstößt. Genau an dieser Stelle gehört ein Mensch in die Schleife. Wirkungsvolle Aktionen brauchen Freigabe, nicht Automatik.

3. Nicht vertrauenswürdige Inhalte als nicht vertrauenswürdig behandeln

Externer Inhalt — Web, eingehende Mail, hochgeladene Datei, fremdes Dokument — ist potenziell Anweisung, nicht nur Information. Solche Quellen sollten erkennbar getrennt, eingegrenzt und nicht mit erhöhten Rechten verarbeitet werden.

4. Sichtbarkeit und Protokoll

Welche Quellen flossen in eine Antwort? Was wurde vorgeschlagen? Was wurde freigegeben? Ohne diese Spur bemerkt man eine erfolgreiche Injection erst, wenn der Schaden sichtbar ist. Nachvollziehbarkeit ist hier eine Sicherheitsfunktion, kein Komfort.

Was das für die Praxis im Mittelstand heißt

Sie brauchen kein Forschungsteam. Sie brauchen vor dem Go-Live eines KI-Features eine ehrliche Antwort auf fünf Fragen:

Verarbeitet das Feature fremde Inhalte (Web, Mail, Upload, Wissensindex)?
Welche Rechte hat das Modell — und sind sie auf die Aufgabe minimiert?
Kann die Ausgabe automatisch eine Aktion auslösen, oder steht ein Mensch dazwischen?
Werden nicht vertrauenswürdige Quellen anders behandelt als interne, geprüfte?
Gibt es ein Protokoll, mit dem ein Vorfall überhaupt erkennbar wäre?

Diese fünf Fragen ersetzen kein Security-Audit. Aber sie trennen ein verantwortbares KI-Feature von einem, das man besser nicht produktiv schaltet.

Auch der Lagebericht des BSI zur IT-Sicherheit ordnet KI-Anwendungen als eigene, wachsende Angriffsfläche ein — nicht als Sonderfall klassischer Web-Sicherheit. Das deckt sich mit dem OWASP-Befund: LLM-Sicherheit ist eine eigene Disziplin, kein Anhängsel.

Häufige Fragen

Reicht ein Eingabefilter gegen „ignoriere deine Anweisungen"? Nein. Filter fangen bekannte Muster, nicht die stochastische Natur des Problems oder versteckte indirekte Injection. Filter sind eine Schicht, keine Lösung.

Ist Prompt Injection nur bei Chatbots ein Thema? Nein. Sie ist überall relevant, wo ein Modell Inhalte verarbeitet, die es nicht selbst kontrolliert — Zusammenfassung, RAG-Wissensassistent, Dokumentenverarbeitung, Agenten.

Heißt das, wir sollten keine KI einsetzen? Im Gegenteil. Es heißt, KI mit begrenzten Rechten, menschlicher Freigabe bei Wirkung und Protokollierung einzusetzen — genau das Designprinzip, das wir auch in unseren Artikeln zu kontrollierten Piloten und Wissensassistenten vertreten.

Wer sollte diese Bewertung machen? Niemand allein. Fachbereich (was darf das Feature?), Entwicklung (welche Rechte, welche Tools?) und idealerweise eine Security-Sicht — vor dem Go-Live, nicht danach.

Fazit

Prompt Injection steht aus gutem Grund auf Platz eins der OWASP-LLM-Risiken: Sie folgt aus der Funktionsweise von Sprachmodellen und lässt sich nicht durch einen Filter wegkonfigurieren. Der belastbare Umgang besteht nicht darin, jede Injection zu verhindern, sondern ihren möglichen Schaden durch minimale Rechte, Tool-Isolation, menschliche Freigabe und Nachvollziehbarkeit zu begrenzen.

KI-Anwendungen brauchen eigene Security-Checks — weil sie eine eigene Angriffsfläche haben. Das ist kein Argument gegen KI. Es ist die Bedingung, sie verantwortbar produktiv zu setzen.

Nächster Schritt

Sie planen ein KI-Feature, das fremde Inhalte verarbeitet oder Aktionen auslösen kann? Lassen Sie die fünf Fragen vor dem Go-Live beantworten. Sprechen Sie mit uns über einen kontrollierten KI-Piloten mit Security-by-Design — oder starten Sie mit einem AI-Readiness-Check, der das Risiko von Anfang an einordnet.

Quellen

OWASP, Top 10 for LLM Applications (2025) — LLM01:2025 Prompt Injection — genai.owasp.org
OWASP, Top 10 for Large Language Model Applications — owasp.org
NIST, Generative AI Profile for the AI RMF — nist.gov
BSI, Die Lage der IT-Sicherheit in Deutschland — bsi.bund.de