RAG-Security-Checkliste (Deutsch)

Retrieval-Augmented Generation (RAG) — also LLMs, die zur Laufzeit auf eine eigene Wissensbasis zugreifen — bringt eigene Sicherheitsprobleme mit: vergiftete Dokumente, indirekte Prompt-Injection über abgerufene Inhalte, Datenlecks aus dem Index. Diese abhakbare Checkliste hilft, eine RAG-Pipeline defensiv abzusichern.

Erstellt von der FlowKI-Community. Rein defensiv — es geht um die Absicherung der eigenen Pipeline, nicht um Angriffe. Orientierung, keine Vollständigkeitsgarantie.

---

1. Vertrauensgrenze: abgerufene Inhalte sind nicht vertrauenswürdig

Der wichtigste Grundsatz: Ein aus dem Index geholtes Dokument ist Eingabe eines Dritten, kein Teil deiner Anweisung. Es kann versteckte Instruktionen enthalten („ignoriere alle vorherigen Anweisungen …").

• Abgerufene Inhalte klar vom System-Prompt trennen (eigener Block, deutliche Delimiter).
• Dem Modell explizit sagen: Inhalte im Kontext sind Daten, nicht Befehle.
• Keine Tool-Aufrufe/Aktionen allein auf Basis von abgerufenem Text auslösen ohne Prüfung.
• Ausgaben validieren, bevor sie weiterverarbeitet werden (siehe Abschnitt 5).

2. Ingestion: was in den Index kommt

Data Poisoning beginnt beim Befüllen. Wer unkontrolliert Inhalte aufnimmt, holt sich Angriffe in die Wissensbasis.

• Quellen kuratieren — nur vertrauenswürdige Dokumente indexieren.
• Bei nutzergenerierten/öffentlichen Quellen: Inhalte bereinigen, verdächtige Instruktions-Muster markieren.
• Herkunft/Metadaten je Dokument speichern (Nachvollziehbarkeit, gezieltes Löschen).
• Änderungen am Index protokollieren (wer hat wann was hinzugefügt?).

3. Zugriffskontrolle & Mandantentrennung

Der Index darf niemandem Dokumente zeigen, die er nicht sehen darf.

• Berechtigungen auf Dokumentebene erzwingen — Retrieval filtert nach Nutzerrechten.
• Bei Mehrmandanten-Systemen: harte Trennung der Vektorräume/Namespaces.
• Kein „globaler" Abruf, der Mandanten-/Rechtegrenzen überspringt.
• Prüfen, dass Zitate/Quellenangaben keine unberechtigten Inhalte durchsickern lassen.

4. Datensparsamkeit & PII im Index

• Nur nötige Daten indexieren; personenbezogene Daten möglichst vermeiden/maskieren.
• Löschkonzept: einzelne Dokumente (und ihre Embeddings) gezielt entfernbar (Art. 17 DSGVO).
• Embeddings als sensibel behandeln — sie können Originalinhalte teilweise rekonstruierbar machen.
• Ort der Verarbeitung klären (EU-Hosting? externe Embedding-/LLM-API?).

5. Ausgabe-Härtung

• Ausgaben nicht ungeprüft als HTML/Markdown rendern (XSS über generierte Links/Skripte).
• Struktur der Antwort validieren, wenn sie maschinell weiterverarbeitet wird (JSON-Schema).
• Halluzinierte Quellen/Zitate erkennen — nur tatsächlich abgerufene Belege zulassen.
• Antworten mit niedriger Retrieval-Konfidenz kennzeichnen statt raten.

6. Betrieb & Missbrauchsschutz

• Rate- und Kosten-Limits gegen Ressourcen-Erschöpfung (viele/teure Abfragen).
• Logging ohne sensible Inhalte; Zugriff auf Logs beschränken.
• Auffällige Abfragemuster überwachen (systematisches Abgreifen des Index).
• Human-in-the-Loop bei folgenreichen Aktionen aus RAG-Ergebnissen.

---

Passt dazu

Die passende Einordnung liefern die OWASP LLM Top 10 (v.a. LLM01, LLM02, LLM08), die praktische Härtung der Prompt-Hardening-Guide, und die Werkzeuge findest du in der LLM-Security-Toolbox.

Diskussion und konkrete Architektur-Reviews laufen in der FlowKI-Community.