Schutz vor Prompt Injection
Es gibt keine Einstellung, die Prompt Injection abschaltet. OWASP hält fest, dass eine vollständige Verhinderung wegen des stochastischen Charakters generativer Modelle unklar bleibt, auch mit RAG oder Fine-Tuning, und das BSI stuft indirekte Prompt Injections als intrinsische Schwachstelle anwendungsintegrierter Sprachmodelle ein.12 Wirksam ist deshalb ausschließlich gestaffelte Absicherung, bei der jede Schicht davon ausgeht, dass die vorherige versagt. Der praktische Leitsatz lautet: Ein Sprachmodell ist kein Sicherheitskontrollpunkt. Wenn eine Aktion Schaden anrichten kann, muss sie außerhalb des Modells autorisiert werden.
Daraus folgt eine Rangfolge, die den Aufbau dieses Clusters bestimmt. Am stärksten wirken Maßnahmen, die unabhängig vom Inhalt des Kontextfensters greifen: begrenzte Rechte, getrennter Kontrollfluss, geschlossene Rückkanäle, menschliche Freigaben. Erkennung und Filterung kommen danach, weil sie eine Formulierung sperren und nicht die Absicht. Beide Ebenen sind nötig, aber die Reihenfolge entscheidet, ob eine Architektur trägt.
Die Seiten dieses Clusters
Prompt Injection erkennen Welche Signale in Eingaben, Kontext und Ausgaben auf einen Angriff hindeuten, und warum Erkennung immer eine nachlaufende Maßnahme bleibt.
Guardrails richtig einsetzen Wofür vorgelagerte Prüfschichten taugen, wo ihre Fehlerraten liegen und warum sie eine Architekturentscheidung nicht ersetzen.
Eingabeprüfung und Normalisierung Unsichtbare Unicode-Zeichen, Homoglyphen und Kodierungen entfernen, bevor Text in den Kontext gelangt.
Sichere Verarbeitung von Modellausgaben Ausgaben wie Nutzereingaben behandeln: validieren, escapen, parametrisieren. OWASP führt das Versäumnis als eigenes Risiko LLM05.3
Spotlighting: Daten von Anweisungen trennen Abgerufene Inhalte unverwechselbar als Daten markieren, statt sie in den Anweisungstext einzuschmelzen.4
Instruktions-Hierarchie Antrainierte Rangfolge von System-, Nutzer- und Datenanweisungen, die die Robustheit messbar erhöht, das Problem aber nicht aufhebt.5
Least Privilege für KI-Agenten Jedes Werkzeug, jede Berechtigung und jeder Datenzugriff nur so weit, wie die Aufgabe es erzwingt.6
Dual-LLM-Muster und CaMeL Architektonische Trennung von privilegiertem und isoliertem Modell. CaMeL löste im AgentDojo-Benchmark 77 Prozent der Aufgaben mit beweisbarer Sicherheitseigenschaft, gegenüber 84 Prozent ungeschützt.78
Die tödliche Trias vermeiden Private Daten, fremde Inhalte und ein Außenkanal gehören nicht in dieselbe Sitzung.9
RAG-Pipelines absichern Kuratierte Quellen, Herkunftsprüfung und Rechtedurchsetzung bis auf Chunk-Ebene.
KI-Agenten absichern Policy-Prüfung vor jedem Werkzeugaufruf, Herkunftskennzeichnung über die Agentenkette, keine Vollzugriffs-Identität.
LLM-Penetrationstest und Red Teaming Systematisch adversarial testen, mit Werkzeugen aus dem Tool-Verzeichnis und wiederholbaren Testfällen statt Stichproben.
Checkliste: 20 Punkte vor dem Produktivgang Abnahmefähige Liste für den Gang in den Betrieb, angelehnt an die Härtungs-Checkliste des BSI.10
Prompt Injection im Unternehmen: Governance und Compliance Zuständigkeiten, Freigabeprozesse und die Einordnung in bestehende Rahmenwerke.
Was nicht funktioniert
Drei Ansätze halten sich hartnäckig und tragen nicht. Ein besserer System-Prompt ist selbst nur Text im selben Eingabekanal, er kann Priorität nahelegen, aber nicht erzwingen. Eine Sperrliste verdächtiger Formulierungen sperrt Wortlaute, während automatisierte Verfahren beliebig viele Varianten erzeugen. Und ein zweites Sprachmodell als Prüfer verschiebt das Problem nur, weil auch der Prüfer den Angriffstext lesen muss.
Was bleibt, ist unbequemer und belastbarer: weniger Rechte, klare Vertrauensgrenzen, deterministische Prüfungen außerhalb des Modells und eine menschliche Freigabe dort, wo eine Aktion nicht rückgängig zu machen ist.
Passende Einstiegspunkte je nach System: Angriffsvektoren für die Bestandsaufnahme, OWASP LLM Top 10 für die Risiko-Systematik, Werkzeuge für die Umsetzung.
Maßnahmen im Einzelnen 14
-
Prompt Injection erkennen
Erkennung senkt die Erfolgsquote von Angriffen, kann Prompt Injection aber nicht ausschließen. Jedes Erkennungsverfahren entscheidet über natürliche Sprache — und dieselbe Anweisung lässt sich beliebig oft umformulieren. Erkennung gehört deshalb als eine Schicht in eine gestaffelte Absicherung, nie als deren Kern.
-
Guardrails richtig einsetzen
Ein Guardrail ist eine Prüfschicht vor oder hinter dem Sprachmodell: Sie bewertet Eingaben, abgerufene Inhalte oder Ausgaben und blockiert, was gegen die Vorgaben verstößt. Guardrails verschieben Wahrscheinlichkeiten — sie sind kein Zugriffsschutz und keine Autorisierung.
-
Eingabeprüfung und Normalisierung
Eingabeprüfung bei Sprachmodellen ist etwas anderes als klassische Validierung: Es gibt kein gültiges Format, gegen das man prüfen könnte, denn die Eingabe ist Freitext. Sinnvoll und wirksam ist deshalb vor allem Normalisierung — das Entfernen von Zeichen und Kodierungen, deren einziger Zweck die Verschleierung ist.
-
Sichere Verarbeitung von Modellausgaben
Die Ausgabe eines Sprachmodells ist eine nicht vertrauenswürdige Eingabe für alles, was danach kommt: für die Darstellung im Browser, für die Datenbank, für die Shell, für den nächsten Agenten. OWASP führt den unsachgemäßen Umgang damit als eigenes Risiko (LLM05).
-
Spotlighting: Daten von Anweisungen trennen
Spotlighting bezeichnet Verfahren, die Fremddaten im Prompt sichtbar von Anweisungen abgrenzen — durch klare Trennzeichen, durch Markierung jedes Datentokens oder durch Kodierung des Datenteils. Microsoft-Forschende beschrieben die Familie 2024 und wiesen für die untersuchten Verfahren deutliche Rückgänge der Angriffserfolgsquote nach.
-
Instruktions-Hierarchie
Die Instruktions-Hierarchie ist der Versuch, einem Modell antrainiert beizubringen, welchen Anweisungen es mehr Gewicht geben soll: System vor Nutzer vor Daten. Ein OpenAI-Forschungsteam um Eric Wallace zeigte 2024, dass dieser Ansatz die Robustheit deutlich erhöht — auch gegen im Training nicht gesehene Angriffsarten.
-
Least Privilege für KI-Agenten
Eine Aktion, die ein System nicht ausführen darf, kann auch eine erfolgreiche Prompt Injection nicht auslösen. Least Privilege ist damit die einzige Maßnahme, die unabhängig von der Qualität des Modells und der Filter wirkt — und die einzige, die eine harte Grenze zieht statt einer Wahrscheinlichkeit.
-
Dual-LLM-Muster und CaMeL
Auf Architekturebene setzt die Forschung darauf, nicht vertrauenswürdige Inhalte gar nicht erst über den Kontrollfluss entscheiden zu lassen. Simon Willisons Dual-LLM-Muster trennt dazu ein privilegiertes Modell, das Werkzeuge aufruft, von einem isolierten Modell, das ausschließlich verdächtige Daten verarbeitet.
-
Die tödliche Trias vermeiden
Simon Willison fasste 2025 unter dem Begriff „lethal trifecta" zusammen, wann eine LLM-Anwendung gefährlich wird: wenn sie Zugriff auf private Daten hat, nicht vertrauenswürdige Inhalte verarbeitet und zugleich nach außen kommunizieren kann. Fehlt eine der drei Eigenschaften, wird aus einer Injektion kein Datenabfluss.
-
RAG-Pipelines absichern
Eine RAG-Pipeline ist eine Kette aus Import, Zerlegung, Einbettung, Suche und Antwortgenerierung. Jeder Schritt ist ein Prüfpunkt — und der Import ist der wichtigste, weil ein einmal indexierter Eintrag bei jeder passenden Frage erneut wirkt.
-
KI-Agenten absichern
Ein Agent ist genau so sicher wie die Menge der Aktionen, die er ohne Rückfrage ausführen darf. Absicherung bedeutet deshalb zuerst Entwurfsarbeit — Werkzeugauswahl, Freigabepunkte, Ausführungsumgebung — und erst danach Filterarbeit.
-
LLM-Penetrationstest und Red Teaming
Ein LLM-Penetrationstest prüft nicht das Modell, sondern die Anwendung: Welche Rechte hat sie, welche Daten erreicht sie, was passiert, wenn ein Fremdinhalt eine Anweisung enthält? Ein bestandener Testlauf belegt die Abwesenheit der geprüften Schwächen zum Prüfzeitpunkt — nicht Sicherheit.
-
Checkliste: 20 Punkte vor dem Produktivgang
Diese Checkliste fasst die Maßnahmen zusammen, die sich aus den OWASP-Empfehlungen zu LLM01 und der BSI-Handreichung zu Evasion Attacks ableiten. Sie ersetzt keine Risikoanalyse, macht aber sichtbar, welche Fragen vor einem Produktivgang beantwortet sein sollten.
-
Prompt Injection im Unternehmen: Governance und Compliance
Prompt Injection ist kein Produktfehler, den eine Abteilung beheben kann, sondern eine Eigenschaft der eingesetzten Technologie. Organisationen brauchen deshalb keine einmalige Maßnahme, sondern eine Zuständigkeit: Wer entscheidet, welche Daten ein Assistent sehen darf und welche Aktionen ohne Freigabe laufen?
Quellen
- OWASP GenAI Security Project: LLM01:2025 Prompt Injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/ ↩
- BSI: Indirect Prompt Injections. Intrinsische Schwachstelle in anwendungsintegrierten KI-Sprachmodellen, Cyber-Sicherheitswarnung 2023. https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2023/2023-249034-1032_csw.html ↩
- OWASP GenAI Security Project: LLM05:2025 Improper Output Handling. https://genai.owasp.org/llmrisk/llm052025-improper-output-handling/ ↩
- Hines, Lopez, Hall, Zarfati, Zunger, Kiciman: Defending Against Indirect Prompt Injection Attacks With Spotlighting, arXiv:2403.14720. https://arxiv.org/abs/2403.14720 ↩
- Wallace, Xiao, Leike, Weng, Heidecke, Beutel: The Instruction Hierarchy, arXiv:2404.13208. https://arxiv.org/abs/2404.13208 ↩
- OWASP GenAI Security Project: LLM06:2025 Excessive Agency. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ ↩
- Simon Willison: The Dual LLM pattern for building AI assistants that can resist prompt injection, 25.04.2023. https://simonwillison.net/2023/Apr/25/dual-llm-pattern/ ↩
- Debenedetti, Shumailov, Fan, Hayes, Carlini et al.: Defeating Prompt Injections by Design (CaMeL), arXiv:2503.18813. https://arxiv.org/abs/2503.18813 ↩
- Simon Willison: The lethal trifecta for AI agents, 16.06.2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ ↩
- BSI: Evasion Attacks on LLMs, Countermeasures and Checklist, 10.11.2025. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/Evasion_Attacks_on_LLMs-Checklist.pdf ↩