Stand: 28. September 2026
Retrieval-Augmented Generation, kurz RAG, ist 2026 zu einer Standardarchitektur für Unternehmens-KI geworden. Statt sich ausschließlich auf das im Modell gelernte Wissen zu verlassen, durchsucht eine RAG-Anwendung interne Datenquellen, wählt relevante Inhalte aus und übergibt sie dem Sprachmodell als Kontext. So können Unternehmen Chatbots und Assistenten mit SharePoint, Confluence, Dokumentenablagen, Ticketsystemen, CRM-Daten oder technischen Wissensdatenbanken verbinden.
Der Vorteil ist offensichtlich: Antworten werden aktueller, spezifischer und näher an den realen Unternehmensdaten. Aber genau diese Datenverbindung erzeugt eine neue Angriffsfläche. OWASP behandelt RAG inzwischen als eigenen Security-Bereich und warnt davor, RAG als bloße „Halluzinationslösung“ zu sehen. Tatsächlich verteilt RAG das Risiko über eine komplette Pipeline: Ingestion, Dokumentverarbeitung, Embeddings, Vector Database, Retrieval, Prompt-Kontext, Modellausgabe und mögliche nachgelagerte Aktionen.
Warum RAG-Sicherheit mehr ist als LLM-Sicherheit
Bei einem klassischen Chatbot ohne Unternehmensdaten besteht das Hauptrisiko häufig in falschen Antworten, Prompt Injection oder Datenschutzproblemen. Ein RAG-System kommt dagegen mit dauerhaft gespeicherten Unternehmensinformationen in Berührung. Sobald Dokumente in Chunks zerlegt, eingebettet und in einem Vektorspeicher abgelegt werden, entsteht eine neue Datenrepräsentation mit eigenen Zugriffs- und Lebenszyklusfragen.
Viele Teams konzentrieren sich auf das Modell und übersehen den Datenpfad. Ein sicherer LLM-Provider schützt nicht automatisch vor einem falsch konfigurierten Vektorindex. Ein sauberer Login verhindert nicht automatisch, dass ein Benutzer semantisch ähnliche Chunks aus einer Abteilung erhält, für die er im Originalsystem keine Berechtigung besitzt. Genau hier entstehen die gefährlichsten Enterprise-RAG-Fehler.
Die wichtigsten Risiken in produktiven RAG-Systemen
1. Document Poisoning
Beim Document Poisoning gelangt manipuliertes Material in die Wissensbasis. Das kann absichtlich hochgeladen werden oder über externe Quellen, automatisierte Connectoren und kompromittierte Dokumentenablagen erfolgen. Enthält ein Dokument versteckte Anweisungen, kann ein Modell diese später beim Retrieval in seinen Kontext übernehmen. Das Problem ist besonders kritisch, wenn das RAG-System mit Agenten oder Tools verbunden ist.
Die zentrale Regel lautet: Abgerufener Inhalt ist Datenmaterial, keine vertrauenswürdige Systemanweisung. Unternehmen sollten zwischen Instruction Layer und Knowledge Layer strikt trennen und eingehende Dokumente auf aktive Inhalte, eingebettete Skripte, verdächtige Instruktionen und ungewöhnliche Formatierungen prüfen.
2. Verlust von Zugriffsrechten beim Chunking
OWASP bezeichnet Access-Control-Inheritance als eines der häufigsten Compliance-Probleme in Enterprise-RAG. Ein vertrauliches Dokument kann im Originalsystem korrekt geschützt sein. Wird es jedoch in 200 Chunks zerlegt und ohne Rollen-, Tenant- oder Klassifikationsmetadaten in einer gemeinsamen Vector Database gespeichert, gehen diese Grenzen verloren.
Die Berechtigung muss deshalb bis auf Chunk-Ebene mitgeführt werden. Nicht nur das Dokument selbst, sondern jeder abgeleitete Datensatz benötigt Informationen darüber, wem er gehört, welche Rollen ihn lesen dürfen und welcher Mandant zuständig ist. Noch wichtiger: Diese Regeln müssen vor oder während des Retrievals greifen, nicht erst nachdem unberechtigte Ergebnisse bereits abgerufen wurden.
3. Vector Database als neues Hochwertziel
Viele Vector Databases wurden ursprünglich für Performance und Ähnlichkeitssuche entwickelt, nicht als primäres Security-System. Ein kompromittierter Index kann beeinflussen, welche Inhalte für bestimmte Fragen gefunden werden. Ein Angreifer muss dann nicht einmal das Originaldokument verändern. Er kann versuchen, Chunks, Metadaten oder Embeddings direkt zu manipulieren.
Schreibzugriff auf den Index sollte deshalb ausschließlich über kontrollierte Ingestion-Pipelines möglich sein. Produktive Anwendungen und Agenten benötigen normalerweise keinen direkten Write-Zugriff. Zusätzlich sind Integritätsprüfungen, Backups, Versionierung und getrennte Umgebungen sinnvoll.
4. Embedding- und Metadaten-Leakage
Embeddings sind keine harmlosen Zufallszahlen. Sie repräsentieren semantische Eigenschaften der zugrunde liegenden Inhalte. Je nach Modell und Zugriffsmöglichkeit können daraus sensible Informationen abgeleitet oder Ähnlichkeitsbeziehungen analysiert werden. Deshalb gehören Embeddings in dieselbe Schutzklasse wie die Daten, aus denen sie erzeugt wurden.
Ein häufiger Fehler ist, den Dokumentenspeicher streng zu schützen, den Vector Store aber als technische Nebenkomponente mit schwächeren Kontrollen zu behandeln. Verschlüsselung, Authentifizierung, Netzwerksegmentierung, Mandantentrennung und Backup-Schutz müssen auch dort gelten.
5. Stale Permissions
Berechtigungen ändern sich laufend: Mitarbeiter wechseln Abteilungen, Projekte enden, externe Partner verlieren Zugriff oder ein vertrauliches Dokument wird nachträglich höher klassifiziert. Wenn RAG-Indizes nicht mit diesen Änderungen synchronisiert werden, kann ein Benutzer Inhalte weiterhin über die KI abrufen, obwohl er im Quellsystem keinen Zugriff mehr hat.
Deshalb braucht jede RAG-Plattform einen klaren Synchronisationsmechanismus für Änderungen und Löschungen. „Einmal ingestiert“ darf nicht „für immer verfügbar“ bedeuten.
6. Datenlöschung und Right to be Forgotten
Das Löschen eines Dokuments aus SharePoint oder einem DMS entfernt nicht automatisch alle Chunks, Embeddings, Caches und abgeleiteten Metadaten. Für Datenschutz und Records Management muss nachvollziehbar sein, wo eine Information im RAG-System weiterlebt. Unternehmen brauchen deshalb eine Löschkette, die Quelle, Index, Cache und gegebenenfalls Conversation Memory umfasst.
7. Cross-Tenant Retrieval
Bei SaaS- oder Multi-Tenant-Architekturen ist eine gemeinsame semantische Suche besonders riskant. Eine falsch gesetzte Filterbedingung kann Inhalte aus einem anderen Mandanten sichtbar machen. Tenant-Isolation sollte nicht nur als Query-Parameter existieren, sondern möglichst architektonisch abgesichert sein – etwa durch getrennte Namespaces, getrennte Indizes oder starke serverseitige Policies.
Sicheres RAG beginnt bereits bei der Datenaufnahme
Die Ingestion-Pipeline ist der erste Kontrollpunkt. Jeder Connector sollte inventarisiert und technisch authentifiziert sein. Dokumente sollten auf Quelle, Owner, Klassifikation, Mandant, Zugriffsrechte und Zeitpunkt der letzten Änderung geprüft werden. Externe oder benutzerhochgeladene Inhalte brauchen höhere Vertrauensprüfungen als kuratierte interne Dokumente.
Darüber hinaus sollte die Pipeline dokumentieren, welches Embedding-Modell verwendet wurde. Ein Modellwechsel kann Suchergebnisse verändern und eine Neuindizierung erforderlich machen. Unternehmen, die verschiedene Embedding-Modelle parallel betreiben, benötigen eine klare Versionierung.
Retrieval darf Berechtigungen nicht umgehen
Der vielleicht wichtigste Architekturgrundsatz lautet: Ein Benutzer darf über semantische Suche niemals mehr sehen als über das Quellsystem. Dazu muss der Retrieval-Service die effektiven Rechte des aktuellen Benutzers kennen. Bei sensiblen Daten sollte ein Pre-Retrieval-Filter verhindern, dass nicht erlaubte Chunks überhaupt in die Ähnlichkeitssuche einbezogen werden.
Post-Retrieval-Filtering ist schwächer, weil das System zuerst Treffer aus einem größeren Datenraum erzeugt und sie anschließend verwirft. Selbst wenn der Text nicht angezeigt wird, können Rankings, Scores oder Seiteneffekte Informationen preisgeben. Deshalb empfiehlt OWASP ausdrücklich, Zugriffskontrollen möglichst vor der eigentlichen Retrieval-Phase anzuwenden.
Prompt Injection in RAG richtig behandeln
Prompt Injection wird bei RAG besonders gefährlich, weil die Angreiferanweisung nicht direkt vom Benutzer kommen muss. Sie kann in einem PDF, Ticket, Wiki-Artikel oder Quellcode-Kommentar stecken. Sobald dieses Material abgerufen wird, landet es in derselben Kontextumgebung wie legitime Anweisungen.
Ein robustes System sollte deshalb Systeminstruktionen technisch priorisieren, retrieved content als untrusted markieren, Tool-Ausführung separat autorisieren und sicherheitskritische Aktionen niemals allein aus dem Inhalt eines abgerufenen Dokuments ableiten. Zusätzliche Output-Checks und Policy Engines können verhindern, dass ein kompromittierter Retrieval-Kontext unmittelbar zu einer schädlichen Aktion führt.
RAG Security Monitoring
Security Operations sollten nicht nur Anmeldeversuche überwachen, sondern auch Retrieval-Muster. Auffällig sind beispielsweise massenhafte semantische Abfragen, ungewöhnlich breite Suchräume, wiederholte Fragen nach sensiblen Begriffen, plötzliche Veränderungen der Retrieval-Verteilung oder auffällige Schreibvorgänge im Vector Store.
Zusätzlich lohnt sich ein Index-Integrity-Monitoring. Prüfsummen, Versionen und kontrollierte Deployment-Prozesse helfen dabei, unerwartete Änderungen sichtbar zu machen. Besonders in regulierten Umgebungen sollte nachvollziehbar sein, welche Dokumentversion zu welcher Zeit Teil des RAG-Korpus war.
Ein sinnvolles Security-Modell für Enterprise RAG
Datenebene
Quellsysteme, Dokumente, Chunks, Embeddings und Metadaten werden nach Sensitivität klassifiziert. Rechte werden aus dem Ursprung übernommen und über den gesamten Lebenszyklus synchronisiert.
Identitätsebene
Benutzeridentität und technische Identität des RAG-Dienstes bleiben getrennt. Der Retrieval-Service entscheidet auf Basis des echten Benutzerkontexts, welche Daten sichtbar sind.
Retrieval-Ebene
Mandant, Rolle und Klassifikation werden serverseitig gefiltert. Nicht autorisierte Inhalte gelangen gar nicht erst in den Kontext des Modells.
LLM-Ebene
Retrieved Content wird als untrusted behandelt. System- und Sicherheitsregeln stehen außerhalb der Wissensdaten. Sensible Ausgaben werden geprüft und gegebenenfalls maskiert.
Agenten-Ebene
Wenn das RAG-System Tools auslösen kann, benötigt jede Aktion eine eigene Autorisierung. Lesen und Ausführen sind zwei verschiedene Vertrauensstufen.
RAG Security Checkliste
Quellen: Sind alle Connectoren bekannt, genehmigt und technisch authentifiziert?
Provenance: Kann jeder Chunk auf sein Ursprungsdokument zurückgeführt werden?
ACL: Werden Berechtigungen auf Chunk-Ebene gespeichert und beim Retrieval durchgesetzt?
Mandantentrennung: Sind Daten verschiedener Kunden oder Abteilungen sauber getrennt?
Index Write Access: Darf nur die Ingestion-Pipeline schreiben?
Encryption: Sind Vector Store, Backups und Netzwerkverbindungen geschützt?
Deletion: Werden gelöschte oder gesperrte Dokumente vollständig aus Chunks, Embeddings und Caches entfernt?
Poisoning: Werden neue Dokumente auf riskante Inhalte geprüft?
Monitoring: Werden ungewöhnliche Retrieval-Muster und Indexänderungen erkannt?
Agenten: Können abgerufene Dokumente niemals direkt privilegierte Aktionen autorisieren?
Warum RAG Red Teaming notwendig ist
Normale Funktionstests zeigen meist nur, ob die KI gute Antworten gibt. Security-Tests müssen dagegen absichtlich versuchen, Grenzen zu überschreiten: Kann ein Benutzer Inhalte anderer Rollen finden? Funktionieren neue ACLs sofort? Was passiert mit gelöschten Dokumenten? Können manipulierte Dateien Tool-Aufrufe beeinflussen? Lassen sich sensible Informationen über indirekte Fragen rekonstruieren?
Ein gutes RAG-Red-Team prüft also nicht nur Prompt Injection, sondern den gesamten Datenfluss. Genau darin unterscheidet sich RAG Security von klassischer Web-Security und von reinem LLM-Safety-Testing.
Fazit
RAG ist eine der wertvollsten Enterprise-AI-Architekturen, weil sie Sprachmodelle mit realem Unternehmenswissen verbindet. Gleichzeitig macht genau diese Verbindung interne Daten zu einem aktiven Teil der KI-Angriffsfläche. Wer 2026 produktive RAG-Systeme betreibt, muss Berechtigungen, Provenance, Index-Integrität, Löschung, Mandantentrennung und Prompt-Injection-Schutz gemeinsam betrachten. Die wichtigste Regel bleibt dabei überraschend einfach: Die KI darf über Retrieval niemals mehr Daten sehen als der aktuelle Benutzer im Originalsystem.
Weiterführende Quellen
OWASP: Retrieval-Augmented Generation Security Cheat Sheet
NIST AI Risk Management Framework
Titelbild: Kevin Ache / Unsplash
Autor: Salman Dolatpanah Gortlar