RAG-Pipelines absichern: Prompt Injection, Datenlecks und Zugriffskontrolle

Die meisten Sicherheitsratgeber für RAG-Systeme hören bei "Prompt-Eingaben säubern" auf. Das ist der uninteressanteste Teil. Produktive RAG-Pipelines haben eine deutlich größere Angriffsfläche: versteckte Anweisungen in abgerufenen Dokumenten, Datenlecks zwischen Mandanten über gemeinsam genutzte Vektordatenbanken, personenbezogene Daten, die in Antworten an unberechtigte Nutzer landen, und Audit-Logs, die nicht rekonstruieren können, wer was gesehen hat. Dieser Artikel beschreibt die Kontrollen, die diese Lücken tatsächlich schließen — die wir bei jeder produktiven RAG-Implementierung umsetzen.

Wer noch an der ersten RAG-Pipeline arbeitet, sollte mit dem Leitfaden für produktive RAG-Architekturen beginnen. Dieser Beitrag setzt voraus, dass eine funktionierende Pipeline existiert, die für sensible Daten, regulierte Branchen oder Multi-Tenant-Deployments gehärtet werden muss.

Das Bedrohungsmodell für RAG-Pipelines

Eine RAG-Pipeline besteht aus fünf Komponenten, die unabhängig voneinander angegriffen werden können: die Ingestion, der Vektor-Store, der Retriever, das LLM und die Antwort-Pipeline. "Das LLM" als Gesamtsystem zu betrachten ist der häufigste Fehler in Sicherheitsreviews.

• Ingestion.Ein Angreifer lädt ein Dokument hoch oder platziert es, in dem versteckte Anweisungen enthalten sind ("Indirect Prompt Injection"). Das Dokument wird zerlegt, eingebettet, gespeichert und irgendwann abgerufen. Das LLM folgt den Anweisungen.
• Vektor-Store. Ein gemeinsam genutzter Store ohne Row-Level Access Control liefert Chunks zurück, die einem anderen Mandanten, einer anderen Abteilung oder einer anderen Vertraulichkeitsstufe gehören.
• Retriever. Suchanfragen geben sensiblen Kontext an externe Embedding-APIs weiter. Query-Logs zeigen, wonach gesucht wird.
• LLM. Generierte Ausgaben enthalten personenbezogene Daten oder Credentials aus dem abgerufenen Kontext. Die Antwort geht an einen unberechtigten Nutzer.
• Antwort-Pipeline. Keine Aufzeichnung darüber, welche Quell-Chunks welche Antwort erzeugt haben. Audit-Logs können die Frage "was hat dieser Nutzer tatsächlich gesehen?" nicht beantworten.

Defense 1: Abgerufene Dokumente als nicht vertrauenswürdige Eingabe behandeln

Das abgerufene Dokument ist der größte blinde Fleck. Teams härten wochenlang das Eingabefeld für Nutzeranfragen und shippen ein System, das jede Anweisung aus einer abgerufenen PDF brav befolgt. In der Realität kommen diese PDFs aus HR-Uploads, kundenseitig eingereichten Tickets, gescrapten Webseiten und E-Mail-Anhängen — jeder dieser Kanäle ist ein Vektor für Indirect Prompt Injection.

Drei Kontrollen, die wirken:

1. Striktes Delimiting. Jeden abgerufenen Chunk in eindeutig gekennzeichnete, maschinenlesbare Trennzeichen einpacken (z. B. <source_doc_N>). Dem Modell explizit sagen, dass Inhalte innerhalb der Trennzeichen Referenzmaterial sind, keine Anweisungen. Das ist keine Garantie — aber es senkt die Erfolgsrate von Injections messbar.
2. Inhaltsklassifizierung vor Speicherung.Bei der Ingestion läuft ein leichtgewichtiger Klassifizierer, der Dokumente mit anweisungsähnlichen Mustern markiert ("ignore previous instructions", "you are now", "system prompt"). Markierte Dokumente landen in einer Review-Queue, nicht im Vektor-Store.
3. Constraints auf Tool-Aufrufe. Wenn das LLM Tool-Aufrufe auslösen kann, werden diese auf eine strikte Allowlist begrenzt und Argumente vor der Ausführung deterministisch validiert. Ein LLM, das keine destruktiven Aktionen auslösen kann, kann auch nicht dazu verleitet werden.

Defense 2: Zugriffskontrolle beim Retrieval erzwingen, nicht danach

Das naive Muster — Top-k abrufen, Ergebnisse danach per ACL filtern — scheitert auf zwei Wegen. Erstens leakt es Daten über Ähnlichkeitsmuster (ein Angreifer kann beobachten, welche Anfragen leere Ergebnisse zurückgeben, und daraus ableiten, was existiert). Zweitens ist es fragil: jeder übersehene Filterpfad gibt den vollständigen Chunk an das LLM weiter, das ihn dann wörtlich wiedergibt.

Beim Retrieval erzwingen. In pgvector bedeutet das eine WHERE-Klausel auf die ACL-Spalte als Teil der Nearest-Neighbor-Anfrage, kein Post-Filter. Row-Level-Security-Policies in Postgres machen das auf Datenbankebene erzwingbar — ein Anwendungsfehler kann die Kontrolle nicht umgehen:

CREATE POLICY tenant_isolation ON document_chunks
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

ALTER TABLE document_chunks ENABLE ROW LEVEL SECURITY;

-- Jede Anfrage automatisch auf den Mandanten des Aufrufers eingeschränkt.
SELECT chunk_text FROM document_chunks
ORDER BY embedding <=> $1
LIMIT 10;

Für Dokument-spezifische ACLs (nicht nur Mandant) eine allowed_principals-Spalte als Array hinzufügen und mit @> filtern. Die Kosten sind im Skalierungsfall vernachlässigbar, das Sicherheitsmodell ist erzwingbar und auditierbar.

Defense 3: Embeddings sind Daten, keine Hashes

Embeddings sind keine Hashes. Aktuelle Forschung hat praktikable Inversion-Angriffe gegen gängige Embedding-Modelle gezeigt — ein geleakter Embedding-Vektor kann eine plausible Version des Ausgangstexts rekonstruieren. Embeddings sollten dieselbe Schutzklasse haben wie die zugrunde liegenden Dokumente.

• Embeddings im Ruhezustand verschlüsseln. In Postgres mit pgcrypto oder Application-Layer-Verschlüsselung für Vektor-Spalten mit sensiblen Korpora.
• Lesezugriff auf den Vektor-Store auf den Retrieval-Service beschränken. Keine direkten Nutzer-Anfragen an die Vektor-Tabelle.
• Embedding-Modelle für sensible Korpora rotieren — Inversion-Angriffe sind modell-spezifisch.

Defense 4: PII bei der Ingestion redacten, nicht bei der Antwort

Nachträgliche PII-Redaction auf der generierten Antwort ist eine Notlösung. Sie versagt bei Paraphrasierung, sie versagt bei Übersetzung, und sie versagt, wenn der Nutzer die Antwort in ein System-Log kopiert. Das verteidigbare Muster ist Redaction bei der Ingestion, vor dem Embedding.

Eine Pipeline mit Microsoft Presidio oder einem äquivalenten NER-Modell läuft über jeden eingelesenen Chunk und ersetzt erkannte PII durch Tokens. Die Original-PII und ihr Token werden in einer getrennten, zugriffsgeschützten Tabelle gespeichert. Wenn ein berechtigter Nutzer eine Anfrage stellt, holt der Retriever die redacteten Chunks, das LLM erzeugt eine redactete Antwort, und ein finaler De-Tokenization-Schritt ersetzt Tokens nur für Nutzer durch echte PII, deren ACL das erlaubt.

Dieses Muster hat einen großen Nebeneffekt: das redactete Korpus kann für Evaluation, Debugging und ML-Training genutzt werden, ohne echte Daten preiszugeben.

Defense 5: Jeden Retrieval-Vorgang mit Chunk-Attribution loggen

Die schwierigste Compliance-Frage für RAG-Systeme lautet: "Was hat dieser Nutzer tatsächlich gesehen?" Ohne pro-Anfrage Chunk-Logging lautet die Antwort "wir wissen es nicht" — und diese Antwort scheitert in Audits gegen DSGVO, HIPAA und SOC 2 gleichermaßen.

Das Minimum-Audit-Record pro Anfrage:

• Nutzer / Service-Principal
• Anfragetext (oder Hash, wenn die Anfrage selbst sensibel ist)
• Abgerufene Chunk-IDs mit ihren Quelldokument-IDs
• LLM-Modell + Version + Hash des System-Prompts
• ID der erzeugten Antwort (nicht die vollständige Antwort — getrennt mit Aufbewahrungsrichtlinie speichern)
• Zeitstempel und Request-ID

Den Audit-Log in einem Append-Only-Store ablegen (Postgres mit REVOKE DELETE oder einem dedizierten Append-Only-Log-Service). Ziel: eine forensische Untersuchung sechs Monate später kann exakt rekonstruieren, welchen Kontext das LLM gesehen hat, als es eine bestimmte Antwort erzeugt hat.

Was ist mit Prompt-Injection-Detection?

Kommerzielle "Prompt-Injection-Firewalls" existieren. Sie helfen als Defense in Depth, sind aber keine Primärkontrolle. Jeder veröffentlichte Detektor hat innerhalb von Wochen nach Release einen dokumentierten Bypass. Auf die fünf oben genannten Kontrollen setzen, Injection-Detection als zusätzliche Schicht behandeln, und niemals eine Sicherheitsentscheidung auf Basis von "der Detektor hat das nicht markiert" treffen.

Mapping auf Compliance-Frameworks

Die Mindestschwelle für produktive RAG-Pipelines

Eine RAG-Pipeline ist bereit für sensible Produktivnutzung, wenn sie diese fünf Fragen mit Evidenz beantworten kann:

1. Wenn ein Angreifer ein bösartiges Dokument einschleust — was stoppt es?
2. Wenn ein Nutzer ohne Berechtigung ein Thema abfragt — was verhindert das Leak?
3. Wenn der Embedding-Store exfiltriert wird — wie groß ist der Schaden?
4. Wenn ein Nutzer PII erhält, die er nicht erhalten sollte — wie wird das erkannt?
5. Für jede vergangene Antwort: kann rekonstruiert werden, was das LLM gesehen hat?

Wenn eine dieser Antworten lautet "wir vertrauen darauf, dass das LLM das Richtige tut", ist die Pipeline nicht produktionsreif — unabhängig davon, wie gut die Demo aussah.

Sicherheitsreview für Ihre RAG-Pipeline?

Wer ein RAG-System mit sensiblen Daten, regulierten Workloads oder Multi-Tenant-Grenzen betreibt, kann die größten Lücken typischerweise in einer Woche durch ein gezieltes Sicherheitsreview schließen. Wir führen diese Reviews gegen das oben beschriebene Bedrohungsmodell durch, liefern einen priorisierten Maßnahmenplan und übergeben ein Regelwerk, das das Team bei der nächsten Implementierung wiederverwenden kann. Erstgespräch vereinbaren.

Weiterführend: der Leitfaden für produktive RAG-Architekturen, die EU AI Act Compliance für KI-Entwickler und warum 90 % der KI-Projekte vor der Produktion scheitern.