Prompt Injection bei Website-Chatbots: Schutz für RAG, Tools und Daten

Ein Website-Chatbot verarbeitet nicht nur harmlose Fragen. Besucher können versuchen, seine Regeln umzuschreiben, interne Anweisungen offenzulegen oder unerlaubte Aktionen auszulösen. Noch schwerer erkennbar sind Befehle, die nicht direkt im Chat stehen, sondern in einer gecrawlten Webseite, einem hochgeladenen Dokument oder einem angebundenen Drittsystem verborgen sind.

Wer Prompt Injection bei Website-Chatbots begrenzen möchte, darf sich deshalb nicht allein auf einen besonders streng formulierten System-Prompt verlassen. Nötig ist eine mehrschichtige Architektur: Eingaben und Quellen werden als nicht vertrauenswürdig behandelt, Berechtigungen technisch eingeschränkt, Ausgaben vor der Weiterverarbeitung geprüft und riskante Aktionen von deterministischem Code oder einem Menschen bestätigt.

Was Prompt Injection bei einem Website-Chatbot bedeutet

OWASP beschreibt Prompt Injection als Eingabe, die das Verhalten oder die Ausgabe eines Sprachmodells unbeabsichtigt verändert. Eine direkte Prompt Injection kommt unmittelbar vom Nutzer, etwa als Aufforderung, vorherige Regeln zu ignorieren. Eine indirekte Prompt Injection steckt dagegen in externen Inhalten, die das System später abruft: Webseiten, Wissensdokumente, E-Mails, Produktdaten oder Dateien.

Diese Unterscheidung ist für Website-Betreiber wichtig. Ein reiner FAQ-Chatbot hat eine kleinere Angriffsfläche als ein System, das laufend Webseiten crawlt, interne Dokumente durchsucht, CRM-Daten liest oder Funktionen ausführen kann. Retrieval-Augmented Generation, kurz RAG, verbessert zwar die fachliche Grundlage von Antworten, beseitigt das Injection-Risiko aber nicht. Auch ein gut gepflegter Quellenbestand kann manipulierte oder missverstandene Anweisungen enthalten.

Risiko nach Funktionen statt nach Modellname bewerten

Die entscheidende Frage lautet nicht nur: „Welches Modell verwenden wir?“, sondern: „Welche Wirkung kann eine manipulierte Antwort entfalten?“ Erstellen Sie eine einfache Funktions- und Datenkarte für den Chatbot:

• Welche öffentlichen und internen Quellen darf er lesen?
• Welche personenbezogenen, vertraulichen oder geschäftskritischen Daten sind erreichbar?
• Kann er nur Text erzeugen oder auch Tickets, Leads, E-Mails, Termine oder Bestellungen anlegen?
• Welche Aktionen verändern externe Systeme?
• Welche Entscheidungen werden automatisch übernommen, ohne dass ein Mensch sie prüft?

Je größer Leserechte, Schreibrechte und Automatisierungsgrad werden, desto wichtiger sind technische Grenzen außerhalb des Modells. Die bestehende Übersicht zu häufigen KI-Chatbot-Fehlern hilft bei der allgemeinen Bestandsaufnahme. Für Prompt Injection müssen Sie zusätzlich Datenflüsse, Vertrauensgrenzen und Aktionsrechte dokumentieren.

Vier Vertrauenszonen klar voneinander trennen

Ein praktisches Sicherheitsmodell unterscheidet vier Zonen, selbst wenn sie technisch in derselben Anwendung verarbeitet werden.

Zone 1: Systemregeln und Richtlinien

Hier stehen Rolle, zulässiger Zweck, Antwortgrenzen und Eskalationsregeln. Diese Regeln geben dem Modell Orientierung, sind aber keine verlässliche Zugriffskontrolle. OWASP warnt ausdrücklich davor, System-Prompts als Geheimnis oder Sicherheitsmechanismus zu behandeln. Zugangsdaten, Verbindungsschlüssel und sensible interne Informationen gehören nicht hinein.

Zone 2: Eingaben von Besuchern

Jede Chatnachricht ist nicht vertrauenswürdig. Begrenzen Sie Länge, Dateitypen und erlaubte Funktionen; normalisieren Sie Eingaben für die technische Verarbeitung und kennzeichnen Sie sie im Prompt klar als Nutzerdaten. Ein Filter kann bekannte Angriffsmuster erkennen, darf aber legitime Fragen nicht pauschal blockieren. Ein Besucher, der in einer Sicherheitsdokumentation nach „ignore previous instructions“ fragt, hat möglicherweise ein berechtigtes Anliegen.

Zone 3: Abgerufene Quellen und RAG-Kontext

Auch gecrawlte Inhalte, PDFs und Ergebnisse externer Dienste bleiben Daten, keine Anweisungen. Trennen Sie ihren Inhalt sichtbar vom Steuerkontext, speichern Sie Herkunft und Abrufzeitpunkt und erlauben Sie nur freigegebene Quellen. Der Beitrag zur Aktualität der KI-Chatbot-Wissensbasis zeigt, wie Quelleninventar, Crawl-Kadenz und QA zusammenwirken.

Zone 4: Tools, Aktionen und Ausgaben

Funktionsaufrufe dürfen nicht allein deshalb ausgeführt werden, weil das Modell passenden Text erzeugt. Ein deterministischer Controller prüft Funktionsname, Parameter, Berechtigung, Sitzungskontext und erlaubte Zielsysteme. Modell-Ausgaben, die später als HTML, Markdown, SQL, Dateipfad oder API-Parameter verwendet werden, brauchen die für diesen Kontext passende Validierung und Kodierung.

Least Privilege begrenzt die Auswirkung

Prompt Injection lässt sich nach heutigem Stand nicht mit einer einzelnen Maßnahme zuverlässig ausschließen. Deshalb muss die Anwendung so gebaut sein, dass ein erfolgreicher Manipulationsversuch möglichst wenig bewirken kann. OWASP und Microsoft empfehlen dafür das Prinzip der geringsten Berechtigung.

• Verwenden Sie getrennte technische Identitäten für Lesen und Schreiben.
• Erteilen Sie nur Zugriff auf die Daten, die für den konkreten Chatbot-Zweck nötig sind.
• Begrenzen Sie Funktionen auf kleine, klar definierte Parameter-Schemata.
• Nutzen Sie kurzlebige Berechtigungen, wenn eine Aktion sie überhaupt benötigt.
• Verlangen Sie eine ausdrückliche Bestätigung für riskante oder irreversible Schritte.
• Überlassen Sie Autorisierung niemals dem freien Text des Modells.

Ein Support-Chatbot kann beispielsweise einen Ticketentwurf vorbereiten, sollte aber nicht automatisch beliebige Empfänger, Prioritäten oder interne Zugriffsrechte bestimmen. Ein Lead-Chatbot kann strukturierte Kontaktdaten entgegennehmen, ohne dadurch Leserechte auf das gesamte CRM zu erhalten.

RAG-Quellen prüfen und isolieren

Indirekte Prompt Injection macht die Quellenpipeline zu einem Teil der Sicherheitsarchitektur. Eine manipulierte Seite kann optisch harmlos wirken und dennoch Text enthalten, den ein Modell als Anweisung interpretiert. Bei multimodalen Systemen können auch Bilder oder andere Dateiformate eine Rolle spielen.

Führen Sie deshalb einen Quelleneingang mit Freigaberegeln ein: erlaubte Domains und Dokumentbereiche, nachvollziehbare Eigentümer, Versionierung, Malware- und Dateiprüfung sowie ein Review für neue oder ungewöhnlich veränderte Inhalte. Kennzeichnen Sie abgerufene Passagen im Modellkontext ausdrücklich als untrusted content. Ein Treffer aus der Suche darf Informationen liefern, aber keine Systemregeln oder Werkzeugberechtigungen ändern.

Prüfen Sie außerdem, ob die Antwort wirklich durch die Quellen gedeckt ist. Der Leitfaden zur KI-Chatbot-Antwortqualität mit Golden Set und RAG-Tests beschreibt Groundedness und Quellenabgleich. Diese Qualitätsprüfung ergänzt Sicherheitskontrollen, ersetzt sie aber nicht.

Ein- und Ausgabefilter sind eine Schicht, nicht die ganze Lösung

Spezialisierte Schutzdienste können direkte und indirekte Angriffsversuche erkennen. Microsoft Prompt Shields unterscheidet beispielsweise Angriffe in Nutzereingaben von versteckten Anweisungen in Dokumenten. Google empfiehlt in seiner Sicherheitsleitlinie ebenfalls Schutzmaßnahmen gegen Prompt Injection, enger abgegrenzte Aufgaben, Nutzerkennungen, Mengenbegrenzungen und menschliche Aufsicht bei höherem Risiko.

Solche Filter liefern probabilistische Signale. Planen Sie daher ein abgestuftes Verhalten: blockieren, sicher beantworten, auf einen eng begrenzten Modus wechseln oder an einen Menschen übergeben. Protokollieren Sie die Entscheidungsklasse und technische Version, aber vermeiden Sie unnötige Volltextspeicherung. Bei personenbezogenen Daten gelten zusätzlich die im Beitrag zu KI-Chatbots und DSGVO beschriebenen Prüfbereiche. Dieser Artikel ist keine Rechtsberatung.

Modell-Ausgaben vor der Weiterverarbeitung validieren

Eine sichere Eingabe garantiert keine sichere Ausgabe. OWASP führt unzureichende Ausgabebehandlung als eigenes Risiko: Modelltext kann später in HTML, Skripten, Datenbankabfragen oder Dateipfaden landen. Behandeln Sie deshalb auch jede Modell-Ausgabe zunächst als nicht vertrauenswürdig.

Fordern Sie für automatisierte Abläufe ein enges strukturiertes Format an und validieren Sie es gegen ein Schema. Nutzen Sie Positivlisten für Funktionsnamen und Zielsysteme. Kodieren Sie sichtbaren Text für den jeweiligen Ausgabekontext. Verwerfen Sie unerwartete Felder, externe URLs und Parameter außerhalb erlaubter Werte. Sensible Daten sollten vor der Anzeige oder Übertragung nochmals durch eine eigene Richtlinienprüfung laufen.

Prompt Injection mit einem Sicherheitstestset prüfen

Ergänzen Sie das fachliche Golden Set um adversariale Testfälle. Die Tests müssen das tatsächliche Produktionssystem einschließlich Retrieval, Tools und Berechtigungslogik prüfen, nicht nur das Basismodell. Ein nützliches Set enthält:

• direkte Versuche, Regeln zu ersetzen oder interne Anweisungen abzufragen;
• mehrsprachige, kodierte und über mehrere Nachrichten verteilte Varianten;
• harmlose Fachfragen, die ähnliche Schlüsselwörter enthalten und nicht fälschlich blockiert werden dürfen;
• manipulierte Passagen in einer Test-Wissensquelle;
• unerlaubte Funktionsnamen, zusätzliche Parameter und fremde Zieladressen;
• Versuche, vertrauliche Daten oder vorherige Sitzungsinhalte auszugeben;
• Tests für HTML-, Markdown- und Linkausgaben;
• Abbruch-, Handoff- und Bestätigungswege bei riskanten Aktionen.

Messen Sie nicht nur, ob ein Filter anschlägt. Prüfen Sie das Endergebnis: Wurde eine unerlaubte Aktion verhindert? Blieben vertrauliche Daten geschützt? Hat eine legitime Anfrage weiterhin funktioniert? Wurde ein auffälliger Fall nachvollziehbar protokolliert?

Praktischer Einführungsplan für Website-Teams

1. Umfang erfassen: Datenquellen, Tools, Schreibrechte und externe Ziele dokumentieren.
2. Vertrauenszonen trennen: Systemregeln, Nutzereingaben, RAG-Inhalte und Aktionsausgaben technisch kennzeichnen.
3. Rechte reduzieren: ungenutzte Zugriffe entfernen und Schreibaktionen in kleine Funktionen zerlegen.
4. Validierung ergänzen: Eingabegrenzen, strukturierte Ausgaben, Positivlisten und kontextspezifische Kodierung einführen.
5. Bestätigung festlegen: riskante Aktionen und sensible Datenflüsse mit Human-in-the-Loop absichern.
6. Testset ausführen: direkte, indirekte und legitime Kontrollfälle vor jedem relevanten Release prüfen.
7. Betrieb beobachten: Filterereignisse, verweigerte Aktionen, ungewöhnliche Quellenänderungen und Fehlalarme regelmäßig reviewen.

Checkliste: Prompt-Injection-Schutz

• Der System-Prompt enthält keine Secrets und ersetzt keine Autorisierung.
• Nutzertexte und externe Quellen gelten standardmäßig als nicht vertrauenswürdig.
• RAG-Quellen besitzen Freigabe, Herkunft, Version und verantwortliche Eigentümer.
• Tools folgen Least Privilege und akzeptieren nur validierte Parameter.
• Riskante Aktionen benötigen eine nachvollziehbare Bestätigung.
• Modell-Ausgaben werden vor HTML, API, CRM oder anderen Zielsystemen geprüft.
• Sicherheitsfilter werden mit False Positives und False Negatives bewertet.
• Direkte und indirekte Angriffstests laufen regelmäßig und nach Änderungen.

Fazit

Prompt Injection ist kein reines Prompt-Engineering-Problem. Für Website-Chatbots entsteht belastbarer Schutz erst, wenn die Anwendung Eingaben, Quellen, Ausgaben und Aktionen als getrennte Vertrauenszonen behandelt. Filter können Angriffe erkennen, doch Least Privilege, deterministische Validierung und menschliche Bestätigung begrenzen ihre mögliche Wirkung.

Beginnen Sie mit der Funktions- und Datenkarte Ihres Chatbots. Entfernen Sie unnötige Rechte, isolieren Sie RAG-Inhalte und testen Sie den kompletten Weg bis zur externen Aktion. So bleibt der Chatbot nützlich, ohne dass freier Modelltext über Berechtigungen oder geschäftskritische Änderungen entscheidet.

Quellen

• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Microsoft Learn: Defend against indirect prompt injection attacks
• Microsoft Learn: Prompt Shields in Azure AI Content Safety
• Google AI for Developers: Safety and factuality guidance