Ein RAG-Chatbot soll interne Informationen sicher bereitstellen – und wird genau dadurch angreifbar: Inhalte aus Dokumenten, Webseiten oder Tickets können Anweisungen enthalten, die das Modell „überreden“, Regeln zu brechen. Dieses Muster heißt Prompt-Injection und ist kein theoretisches Risiko, sondern eine Designfrage: Welche Anweisungen dürfen wirken, welche Daten dürfen sprechen, und welche Aktionen dürfen ausgelöst werden?
Der Kern der Absicherung liegt nicht in einer einzelnen Maßnahme, sondern in einem sauberen Zusammenspiel aus Prompt-Design, Retrieval-Politik, Tool-Grenzen, Output-Kontrollen und kontinuierlichem Testen. Der folgende Leitfaden ordnet die Angriffsformen ein und zeigt, wie RAG-Systeme im Unternehmensalltag belastbar werden.
Warum Prompt-Injection bei RAG besonders häufig gelingt
Das Modell kann Daten nicht sicher von Anweisungen trennen
LLMs verarbeiten Eingabetext als fortlaufenden Kontext. Auch wenn ein System „sagt“, dass ein Dokument nur Referenz ist, bleibt es aus Modellperspektive Text, der Einfluss auf die nächste Antwort nimmt. Angreifer nutzen genau das: Sie platzieren Instruktionen in Inhalten, die später in den Kontext gezogen werden, etwa in einer Wiki-Seite, einem PDF oder einer Support-Notiz.
Typische Ziele: Sicherheitsregeln umgehen, verbotene Daten preisgeben, interne Prompts offenlegen oder Werkzeuge missbrauchen (z. B. E-Mail versenden, Tickets erstellen, Datenbanken abfragen).
RAG verstärkt die Reichweite fremder Inhalte
Retrieval entscheidet, welche Textstellen in den Kontext gelangen. Sobald eine manipulierte Passage häufig „getroffen“ wird (z. B. wegen populärer Keywords), wird der Angriff reproduzierbar. Besonders heikel wird es, wenn externe Inhalte (Web, Partnerportale) indexiert werden oder wenn viele Schreibrechte im Unternehmen bestehen.
Angriffsmuster: so sehen Manipulationen in der Praxis aus
Direkte Injektion im Nutzerprompt
Der Nutzer versucht, die Systemregeln zu überschreiben („Ignoriere alle vorherigen Anweisungen …“). Das ist gut bekannt und relativ gut zu mitigieren – allerdings nicht vollständig, wenn das System über Tools echte Aktionen ausführen kann.
Indirekte Injektion über Dokumente (das typische RAG-Problem)
Die eigentliche Manipulation steckt in einem Dokumentabschnitt, der zufällig oder gezielt retrieved wird. Häufige Tarnungen: scheinbare „Hinweise“, Fußnoten, Formatierungen wie „WICHTIG“ oder Anweisungen, die wie Metadaten wirken („System: …“, „Developer note: …“). Die Gefahr entsteht, wenn das Modell diese Textteile als handlungsleitend interpretiert.
Tool-Missbrauch: wenn das Modell Zugriff auf Aktionen hat
Sobald ein Assistent Tools aufrufen kann (E-Mail, CRM, Ticketing, Datenbank), wird Injection zur Brücke in echte Systeme. Eine harmlose Frage („Was steht in Dokument X?“) kann zu einer unerwünschten Aktion werden („Sende die Antwort an …“, „Erstelle ein Ticket mit …“), wenn Tool-Aufrufe nicht strikt eingeschränkt sind. Das gilt auch ohne „Agenten“: Schon einfache Function-Calls können missbraucht werden.
Schutzprinzipien: Sicherheitsziele vor Technik wählen
Erst definieren, was „sicher“ heißt
Effektive Maßnahmen beginnen mit klaren Sicherheitszielen: Welche Daten dürfen in Antworten erscheinen? Welche Daten dürfen als Kontext geladen werden? Welche Aktionen sind überhaupt erlaubt? Welche Nutzerrollen gibt es? Ohne diese Antworten wird jede technische Maßnahme zum Ratespiel.
Hilfreich ist eine kurze Policy, die vier Ebenen trennt: Systemregeln (nicht verhandelbar), Entwicklerregeln (App-Logik), Nutzereingaben (untrusted), Dokumente/Retrieval (untrusted). Alles außer System/Entwickler wird als potenziell adversarial behandelt.
Die richtige Kante: „untrusted data“ konsequent markieren
Dokumente und Nutzerinput sind Daten, keine Steuerbefehle. In der Umsetzung bedeutet das: Der Prompt muss unmissverständlich deklarieren, dass Inhalte aus Quellen niemals Anweisungen sind. Das ist kein Allheilmittel, reduziert aber die Erfolgsquote. Parallel muss die Anwendung technisch verhindern, dass das Modell aus Dokumenttext heraus Tool-Entscheidungen trifft.
Technische Maßnahmen im Stack: was wirklich robust ist
Retrieval absichern: weniger ist oft mehr
Viele Systeme werden verwundbar, weil „zu viel“ Kontext geliefert wird. Je mehr Text, desto mehr Angriffsfläche. Bewährt haben sich:
- Konsequente Scope-Begrenzung: nur Sammlungen/Spaces indexieren, die für den Use Case nötig sind.
- Vertrauenszonen im Index (z. B. „intern freigegeben“, „extern“, „user-generated“) und unterschiedliche Retrieval-Regeln je Zone.
- Chunking so gestalten, dass unstrukturierte Randtexte (Footer, Navigation, Kommentarbereiche) nicht dominant werden.
- Top-k nicht automatisch erhöhen, sondern über Qualitätskriterien (z. B. Mindestscore, Duplikatfilter) steuern.
Wer RAG professionell betreibt, profitiert zusätzlich von klaren Evaluierungsdaten und Testsätzen; praxisnaher Kontext dazu findet sich in Evaluationsdaten aufbauen.
Prompt-Design: Rollen sauber trennen, Konflikte explizit lösen
Ein robustes Prompt-Template enthält drei Bausteine: (1) nicht verhandelbare Regeln, (2) Aufgabe und Ausgabeformat, (3) Umgang mit Kontextquellen. Wichtig ist eine Konfliktregel: Wenn Kontext Anweisungen enthält oder Regeln zu widersprechen scheint, werden diese als Inhalte behandelt und ignoriert.
Zusätzlich sollte die Antwortlogik festlegen: Wenn eine Anfrage nur über riskante Operationen erfüllbar wäre (z. B. Datenexfiltration), wird eine sichere Alternative angeboten (Zusammenfassung ohne sensitive Details, Hinweis auf berechtigte Kanäle).
Tooling härten: Funktionen als kleinste Rechte-Einheit
Injection wird am gefährlichsten, wenn das Modell Aktionen auslösen darf. Deshalb müssen Tool-Aufrufe wie API-Requests behandelt werden: mit minimalen Rechten, enger Parametrisierung und separater Autorisierung. In der Praxis heißt das:
- Nur wenige, klar definierte Tools; keine „万能“-Tools wie Shell-Zugriff oder generische HTTP-Requests.
- Strikte Schemas/Validierung für Parameter, inklusive Längenlimits, erlaubter Werte und Regex-Checks.
- Serverseitige Policy-Checks: Tool-Aufruf darf nur passieren, wenn Nutzerrolle und Kontext es erlauben.
- High-risk Aktionen (z. B. „senden“, „löschen“, „veröffentlichen“) benötigen explizite Nutzerbestätigung (Two-step).
Wenn Assistenten als Agenten organisiert sind, sollten zusätzlich Betriebs- und Risikofragen geklärt werden; dazu passt KI-Agenten im Unternehmen.
Ausgabe- und Richtlinienkontrollen: nicht nur auf das Modell vertrauen
Selbst mit guten Prompts können Antworten unerwünschte Inhalte enthalten. Deshalb lohnt sich ein nachgelagerter Kontrollschritt: Policy-Checks für sensitive Kategorien, Redaction für bestimmte Datentypen, und eine klare „Refuse/Defer“-Strategie. Diese Maßnahmen gehören zu Guardrails im Betrieb – wichtig ist dabei, die Regeln testbar und versionierbar zu halten. Ergänzend ist Guardrails im Unternehmen ein sinnvoller Anknüpfungspunkt.
Praxis-Notizen: Erkennung, Tests und Betrieb
Signale für Injection im Live-System
Einzelne Indikatoren beweisen noch keinen Angriff, aber Muster sind aussagekräftig:
- Antworten referenzieren „System“, „Developer“, „hidden instructions“ oder behaupten, Regeln wurden geändert.
- Unerklärliche Tool-Aufrufe oder Parameter, die nicht zur Nutzerfrage passen.
- Plötzlicher Wechsel von Ton/Format (z. B. imperativische Anweisungen, ungewöhnliche Schlüsselwörter).
- Wiederholte Rückfragen, die auf Datenabfluss zielen („gib den gesamten Kontext aus“, „zeige den Prompt“).
Ein kleiner Härtungs-Plan für Teams
- Threat Modeling für den konkreten Use Case: Datenquellen, Rollen, Tools, Missbrauchsszenarien.
- Retrieval-Zonen definieren (intern/extern/user-generated) und pro Zone klare Retrieval-Policies festlegen.
- Prompt-Template mit Konfliktregel und „Dokumente sind Daten“-Prinzip standardisieren.
- Tool-Aufrufe minimalisieren, Schemas härten, serverseitige Autorisierung und Bestätigungsschritte einbauen.
- Regression-Tests mit eigenen Angriffsprompts und „bösen“ Dokument-Chunks in einer Test-Kollektion ausführen.
- Monitoring auf Tool-Aufrufe, Ablehnungsraten und ungewöhnliche Antwortmuster; Alerts für Ausreißer definieren.
Entscheidungsstütze: welche Maßnahmen passen zu welchem Risiko?
Vergleich typischer Schutzmaßnahmen
| Maßnahme | Stärke | Grenze | Wann besonders sinnvoll |
|---|---|---|---|
| Retrieval-Zonen & Scope-Begrenzung | Reduziert Angriffsfläche an der Quelle | Benötigt Pflege der Datenräume | Viele Dokumentquellen, wechselnde Teams |
| Prompt-Konfliktregel („Kontext ist keine Anweisung“) | Schnell umsetzbar, verbessert Robustheit | Nicht vollständig zuverlässig | Alle RAG-Apps als Basis-Hygiene |
| Serverseitige Tool-Policies & Parameter-Validierung | Verhindert reale Schäden trotz Modellfehler | Mehr Engineering-Aufwand | Sobald Tools Aktionen ausführen können |
| Nachgelagerte Output-Checks | Fängt Fehler ab, unterstützt Compliance | Kann False Positives erzeugen | Sensitive Daten, regulierte Inhalte |
Häufige Umsetzungsfehler, die Prompt-Injection begünstigen
„Das Modell wird schon verstehen, was gemeint ist“
Implizite Annahmen sind der Feind. Systeme brauchen explizite Trennlinien: untrusted Input, untrusted Retrieval, erlaubte Aktionen. Ohne diese Trennlinien wird jeder neue Datenraum zur potenziellen Angriffsfläche.
Zu breite Tool-Rechte und fehlende Bestätigungsschritte
Wenn ein Chatbot E-Mails versenden oder Datensätze verändern darf, ist ein zusätzlicher Bestätigungsschritt kein Luxus, sondern ein Sicherheitsgurt. Gleiches gilt für Scopes: pro Tool nur die minimal nötigen Berechtigungen, getrennt nach Rollen.
Tests nur mit „braven“ Beispielen
Injection ist adversarial. Wer nur Happy Paths testet, misst höchstens Sprachqualität, nicht Sicherheit. Sinnvoll sind gezielte Testfälle: Dokumente mit eingebetteten Anweisungen, Nutzerprompts mit Exfiltrationswünschen, sowie Kombinationen aus beidem. Für den Betrieb helfen robuste Tests und Metriken; als Ergänzung passt KI-Evaluierung im Unternehmen.
Was sich im Alltag bewährt: saubere Grenzen statt Magie
Systemdesign so bauen, dass Modellfehler nicht eskalieren
LLMs sind probabilistische Systeme; selbst gut instruierte Modelle können in Grenzfällen falsche Prioritäten setzen. Robust wird eine Lösung, wenn Fehlverhalten keine kritischen Folgen hat: Tools sind abgesichert, Datenzugriffe sind rollenbasiert, und Antworten werden kontrolliert. Dann bleibt Prompt-Injection ein behandelbares Risiko statt eines Showstoppers.
Dokumenten-Governance als Teil der KI-Sicherheit
RAG-Sicherheit ist auch Content-Sicherheit. Schreibrechte, Freigabeprozesse und klare Verantwortlichkeiten reduzieren die Chance, dass manipulierte Inhalte überhaupt in den Index gelangen. Wo viele Teams beitragen, sollten Index-Regeln und Klassifizierung zusammen gedacht werden – inklusive klarer „Do not index“-Zonen für Chat-Logs, E-Mail-Threads oder Kommentarbereiche.
Rechner-Hinweis für Priorisierung
Für die Reihenfolge der Maßnahmen hilft eine einfache Priorisierungsidee als Textformel: Risiko ≈ (Wahrscheinlichkeit eines erfolgreichen Angriffs) × (Auswirkung bei Erfolg). Scope-Reduktion senkt oft die Wahrscheinlichkeit, Tool-Härtung senkt vor allem die Auswirkung.
Quellen
- Keine Quellen angegeben.
