# 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](https://flowki-club.de). 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](https://flowki-club.de/freebies/owasp-llm-top10)
(v.a. LLM01, LLM02, LLM08), die praktische Härtung der
[Prompt-Hardening-Guide](https://flowki-club.de/freebies/prompt-hardening), und die
Werkzeuge findest du in der
[LLM-Security-Toolbox](https://flowki-club.de/freebies/llm-security-toolbox).

Diskussion und konkrete Architektur-Reviews laufen in der
[FlowKI-Community](https://flowki-club.de/community).