WISSEN > KI ARCHITEKTUR > RAG BERECHTIGUNGEN
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Was ein RAG-System findet, darf es nicht immer zeigen
Wie Authorization vom Quellsystem bis in den LLM-Kontext erhalten bleibt
Das sollten Sie mitnehmen:
- Die Anmeldung an der RAG-Anwendung ist keine Zugriffskontrolle.
Authentication stellt die Identität fest, Authorization entscheidet über die verwendbaren Daten.
- Berechtigungen müssen Ingestion und Chunking überstehen.
Verliert ein Chunk den Bezug zur Zugriffskontrolle seines Quelldokuments, entsteht im Index ein neues Zugriffsmodell.
- Nicht autorisierte Inhalte gehören vor das Retrieval-Ergebnis, nicht hinter die LLM-Antwort.
Ein nachgelagerter Ausgabefilter ersetzt keine Zugriffskontrolle auf den Generierungskontext.
- Aktualität ist eine Sicherheitseigenschaft.
Zwischen einer entzogenen Berechtigung im Quellsystem und ihrer Wirksamkeit im Index liegt ein messbares Zeitfenster.
- Nicht entscheidbare Autorisierung muss zum Ausschluss führen.
Fällt die Gruppenauflösung aus, darf das Ergebnis nicht die Auslieferung der betroffenen Inhalte sein.
Warum RAG ein zusätzliches Berechtigungsproblem erzeugt
Inhaltsverzeichnis
- Warum RAG ein zusätzliches Berechtigungsproblem erzeugt
- Authentication, Authorization und Retrieval sind drei getrennte Entscheidungen
- Berechtigungen müssen Ingestion und Chunking überstehen
- Authorization gehört in den Retrieval-Pfad
- Die übergebene Identität muss vertrauenswürdig sein — und sie ist nicht die des Dienstes
- Gruppen entscheiden über den Zugriff, ihre Auflösung über die Aktualität
- Aktualität ist eine sicherheitsrelevante Architektureigenschaft
- Die Trust Boundary endet nicht beim Retrieval
- Mehrere Datenquellen verschärfen das Identity-Problem
- Nicht entscheidbare Autorisierung muss zum Ausschluss führen
- Typische Fehlerbilder bei RAG-Berechtigungen
- Architekturfragen vor der Einführung eines Enterprise-RAG-Systems
- Fazit
- Quellen
Bei einem klassischen Dateizugriff ist der Zusammenhang zwischen Anforderung und Prüfung unmittelbar. Ein Benutzer fordert eine Ressource an, das jeweilige System prüft anhand einer Access Control List, einer Rolle oder einer Policy, ob der Zugriff zulässig ist, und liefert die Datei aus oder verweigert sie. Prüfstelle und Datenhaltung liegen im selben System, und die Entscheidung fällt zum Zeitpunkt des Zugriffs.
RAG verändert diesen Datenpfad grundlegend. Ein Ingestion-Prozess greift zunächst auf eine große Anzahl von Dokumenten zu, die aus Dateisystemen, Object Storage, Collaboration-Plattformen oder Datenbanken stammen können. Die Inhalte werden extrahiert, normalisiert, in Chunks zerlegt und für die semantische Suche indexiert. Der spätere Benutzer greift damit nicht mehr auf das ursprüngliche Dokument in seinem ursprünglichen System zu, sondern auf eine abgeleitete Repräsentation in einem neuen System: Über die RAG-Anwendung erreicht seine Anfrage das Retrieval-System, dieses liefert Chunks an das Sprachmodell, und das Modell erzeugt daraus eine Antwort.
Damit entsteht eine Architekturfrage, die vor der Auswahl von Embedding-Modell und Vektordatenbank beantwortet werden muss: An welcher Stelle wird überprüft, ob dieser konkrete Benutzer den gefundenen Chunk überhaupt sehen darf?
Der Zugriff der RAG-Infrastruktur auf die Datenquelle beantwortet diese Frage nicht. Ein Ingestion-Service kann technisch berechtigt sein, Millionen Dokumente zu lesen, ohne dass ein einzelner Benutzer der Anwendung auch nur einen Bruchteil dieser Rechte besitzt. Die OWASP Top 10 for LLM Applications führen diesen Problembereich seit der Ausgabe 2025 als eigene Risikokategorie: Unzureichende oder fehlausgerichtete Zugriffskontrollen können dazu führen, dass Embeddings mit sensiblen Informationen unberechtigt abgerufen werden, und in Umgebungen, in denen mehrere Benutzerklassen dieselbe Vektordatenbank teilen, besteht das Risiko eines Kontext-Leakage zwischen Benutzern.
[BILD] Gegenüberstellung des klassischen Dateizugriffspfads und des RAG-Datenpfads, mit Markierung der jeweiligen Position der Autorisierungsentscheidung.
Warum RAG ein zusätzliches Berechtigungsproblem erzeugt
Bei einem klassischen Dateizugriff ist der Zusammenhang zwischen Anforderung und Prüfung unmittelbar. Ein Benutzer fordert eine Ressource an, das jeweilige System prüft anhand einer Access Control List, einer Rolle oder einer Policy, ob der Zugriff zulässig ist, und liefert die Datei aus oder verweigert sie. Prüfstelle und Datenhaltung liegen im selben System, und die Entscheidung fällt zum Zeitpunkt des Zugriffs.
RAG verändert diesen Datenpfad grundlegend. Ein Ingestion-Prozess greift zunächst auf eine große Anzahl von Dokumenten zu, die aus Dateisystemen, Object Storage, Collaboration-Plattformen oder Datenbanken stammen können. Die Inhalte werden extrahiert, normalisiert, in Chunks zerlegt und für die semantische Suche indexiert. Der spätere Benutzer greift damit nicht mehr auf das ursprüngliche Dokument in seinem ursprünglichen System zu, sondern auf eine abgeleitete Repräsentation in einem neuen System: Über die RAG-Anwendung erreicht seine Anfrage das Retrieval-System, dieses liefert Chunks an das Sprachmodell, und das Modell erzeugt daraus eine Antwort.
Damit entsteht eine Architekturfrage, die vor der Auswahl von Embedding-Modell und Vektordatenbank beantwortet werden muss: An welcher Stelle wird überprüft, ob dieser konkrete Benutzer den gefundenen Chunk überhaupt sehen darf?
Der Zugriff der RAG-Infrastruktur auf die Datenquelle beantwortet diese Frage nicht. Ein Ingestion-Service kann technisch berechtigt sein, Millionen Dokumente zu lesen, ohne dass ein einzelner Benutzer der Anwendung auch nur einen Bruchteil dieser Rechte besitzt. Die OWASP Top 10 for LLM Applications führen diesen Problembereich seit der Ausgabe 2025 als eigene Risikokategorie: Unzureichende oder fehlausgerichtete Zugriffskontrollen können dazu führen, dass Embeddings mit sensiblen Informationen unberechtigt abgerufen werden, und in Umgebungen, in denen mehrere Benutzerklassen dieselbe Vektordatenbank teilen, besteht das Risiko eines Kontext-Leakage zwischen Benutzern.
[BILD] Gegenüberstellung des klassischen Dateizugriffspfads und des RAG-Datenpfads, mit Markierung der jeweiligen Position der Autorisierungsentscheidung.
Authentication, Authorization und Retrieval sind drei getrennte Entscheidungen
Für die Sicherheitsarchitektur eines RAG-Systems müssen mindestens drei Vorgänge auseinandergehalten werden, die in der Praxis regelmäßig vermischt werden.
Authentication beantwortet die Frage, wer die Anfrage stellt. Das geschieht typischerweise über einen Identity Provider und ein daraus abgeleitetes Benutzer- oder Service-Token. Authorization beantwortet die davon unabhängige Frage, ob diese Identität auf die angeforderte Ressource zugreifen darf. Retrieval schließlich beantwortet eine rein inhaltliche Frage, nämlich welche Informationen zu einer Anfrage semantisch passen.
NIST trennt die ersten beiden Funktionen im Zero-Trust-Modell ausdrücklich. Authentication und Authorization sind dort eigenständige Vorgänge, die durchgeführt werden, bevor eine Sitzung zu einer Unternehmensressource überhaupt aufgebaut wird — und zwar sowohl für das Subjekt als auch für das verwendete Gerät. Zero Trust geht zudem nicht davon aus, dass Netzwerkposition oder das Eigentum an einem System implizites Vertrauen begründen.
Für RAG hat das eine unbequeme Konsequenz. Dass sich ein Benutzer erfolgreich an einer KI-Anwendung anmelden kann, sagt zunächst nichts darüber aus, welche Dokumente dieser Benutzer über das Retrieval verwenden darf. Eine RAG-Plattform sollte deshalb nicht als ein einziger vertrauenswürdiger Datenraum betrachtet werden, in dem nach erfolgreicher Anmeldung sämtliche indizierten Informationen grundsätzlich verfügbar sind. Der Retrieval-Index enthält in der Regel Inhalte mit sehr unterschiedlichen Schutzanforderungen, und das Zero-Trust-Prinzip verlangt, dass die Zugriffsentscheidung an der Ressource fällt und nicht an der Anwendungsgrenze.
Wir beobachten in Projekten regelmäßig, dass genau diese Trennung in frühen Proof-of-Concepts nicht angelegt wird. Solange der Testkorpus aus allgemein zugänglichen Dokumenten besteht, fällt das nicht auf. Die Architekturentscheidung wird jedoch beim Übergang in den produktiven Betrieb teuer, weil Ingestion, Index und Retrieval-Schnittstelle nachträglich um ein Berechtigungsmodell erweitert werden müssen.
Berechtigungen müssen Ingestion und Chunking überstehen
Eine RAG-Pipeline ohne Berücksichtigung von Berechtigungen führt ein Dokument über Extraktion, Chunking und Embedding in den Index. Für geschützte Unternehmensdaten reicht dieses Modell nicht aus, weil dem Retrieval-System zur Abfragezeit jede Grundlage für eine Autorisierungsentscheidung fehlt. Zusätzlich zum Inhalt müssen deshalb Berechtigungsinformationen aufgenommen werden, die den Chunks bis in den Index folgen.
Microsoft dokumentiert für Azure AI Search Verfahren, bei denen ACL-, RBAC- oder vergleichbare Berechtigungsinformationen gemeinsam mit den Dokumenten in den Suchindex übernommen und anschließend bei der Abfrage ausgewertet werden. Amazon dokumentiert für Bedrock Managed Knowledge Bases ein vergleichbares Vorgehen: Ist die ACL-Auswertung für eine Datenquelle aktiviert, werden die Berechtigungen — erlaubte und verweigerte Benutzer sowie erlaubte und verweigerte Gruppen — gemeinsam mit dem Dokumentinhalt aufgenommen und zur Abfragezeit gegen den übergebenen Benutzerkontext ausgewertet.
Die daraus abgeleitete Architekturregel ist einfach: Content und Authorization Context dürfen bei der Ingestion nicht unabhängig voneinander betrachtet werden.
Chunking darf den Berechtigungskontext nicht auflösen
RAG-Systeme arbeiten selten mit vollständigen Dokumenten. Ein Dokument wird in kleinere Informationseinheiten zerlegt, und aus einem einzelnen Quelldokument können Dutzende oder Hunderte von Chunks entstehen. Die Zugriffskontrolle des Quellsystems bezieht sich dagegen typischerweise auf eine übergeordnete Einheit — auf die Datei, den Ordner, die Site oder einen anderen Container.
Zwischen der Granularität der Zugriffskontrolle und der Granularität des Retrievals klafft damit eine Lücke, die das RAG-System schließen muss. Jeder Chunk benötigt eine nachvollziehbare Beziehung zu dem Berechtigungskontext, der für sein Quelldokument gilt. Wie diese Beziehung technisch gespeichert wird, hängt von der verwendeten Retrieval- und Indexarchitektur ab. Entscheidend ist nicht, dass jedes System ACLs identisch implementiert, sondern dass die durch das Chunking entstandenen Retrieval-Einheiten nicht unabhängig von der Zugriffskontrolle ihres Quellinhalts abrufbar werden.
Genau an dieser Stelle setzt auch die Empfehlung der OWASP-Risikokategorie zu Vektor- und Embedding-Schwächen an: berechtigungsbewusste Vektordatenbanken, konsequente logische Partitionierung und feingranulare Zugriffskontrolle auf der Ebene der gespeicherten Vektoren.
[BILD] Vererbung des Authorization Context vom Quelldokument über die Chunk-Bildung bis zum Indexeintrag.
Authorization gehört in den Retrieval-Pfad
Eine RAG-Abfrage mit belastbarer Zugriffskontrolle durchläuft die Autorisierung nicht am Ende, sondern innerhalb des Retrievals. Nach der Authentifizierung des Benutzers und der Übergabe der Anfrage an das Retrieval-System werden dort zwei unterschiedliche Fragen beantwortet: Welche Inhalte sind für die Anfrage relevant, und welche dieser Inhalte darf der anfragende Benutzer verwenden? Erst die Schnittmenge beider Mengen gelangt in Reranking, Context Assembly und schließlich in den Prompt.
Formal lässt sich das als R(u,q) = S(q) ∩ A(u) schreiben, wobei S(q) die aufgrund der Anfrage q semantisch relevanten Retrieval-Kandidaten bezeichnet, A(u) die für den Benutzer u autorisierten Inhalte und R(u,q) die tatsächlich verwendbaren Ergebnisse. Die Darstellung macht einen Punkt deutlich, der in Implementierungen häufig implizit unterlaufen wird: Ein hoher Similarity Score erzeugt keine Zugriffsberechtigung.
Security Trimming begrenzt die Ergebnismenge vor der Ausgabe
Ein verbreitetes Verfahren zur Umsetzung dieser Schnittmenge ist das sogenannte Security Trimming. Der Index enthält dabei neben den für die Suche benötigten Informationen zusätzliche Sicherheitsmetadaten, etwa Benutzer- oder Gruppenidentitäten, und die Identität des Aufrufers wird bei der Abfrage als Filterbestandteil in die Suche einbezogen.
Azure AI Search dokumentiert dieses Muster mit bemerkenswerter Offenheit über seine Grenzen. Der Security Filter ist ein regulärer OData-Filter, der ein Suchergebnis anhand einer Zeichenkette ein- oder ausschließt, die einen Security Principal repräsentiert. Microsoft weist ausdrücklich darauf hin, dass über diesen Security Principal weder eine Authentifizierung noch eine Autorisierung stattfindet — der Principal ist lediglich eine Zeichenkette in einem Filterausdruck. Die Wirksamkeit des Verfahrens hängt damit vollständig davon ab, welche Zeichenkette die aufrufende Anwendung übergibt.
Neuere Azure-Verfahren gehen darüber hinaus. Bei der tokenbasierten Durchsetzung werden Benutzer-, Gruppen- und Scope-Informationen aus dem übergebenen Microsoft-Entra-Token extrahiert und mit den im Index gespeicherten Berechtigungsmetadaten verglichen; zurückgegeben werden nur Dokumente, deren synchronisierte Berechtigungsmetadaten dem Aufrufer Zugriff gewähren. Diese Funktionalität befindet sich zum Zeitpunkt der Recherche im Preview-Status und setzt die Verwendung der jeweils aktuellen Preview-REST-API oder eines entsprechenden Preview-SDK-Pakets voraus. Für die Bewertung einer Zielarchitektur ist diese Unterscheidung erheblich, weil Preview-Funktionalität abweichenden Support- und Stabilitätszusagen unterliegt.
Metadatenfilterung ist nicht Autorisierung
Aus dieser Dokumentationslage ergibt sich eine Unterscheidung, die in Architekturdiskussionen häufig verwischt wird. Metadatenfilterung kann Daten anhand beliebiger Attribute aus dem Retrieval ausschließen; sie ist ein Werkzeug zur Ergebniseingrenzung. Autorisierung erfordert darüber hinaus eine vertrauenswürdige Identität und eine belastbare Policy-Entscheidung darüber, welche Daten diese Identität verwenden darf.
Der Unterschied ist auch an den APIs ablesbar. Die von AWS für Bedrock dokumentierte RetrievalFilter-Struktur erlaubt die Filterung von Retrieval-Ergebnissen anhand von Metadatenattributen und ist damit ein Instrument der Relevanzsteuerung. Sie ist ausdrücklich getrennt von der ACL-Auswertung, die über einen eigenen Benutzerkontext-Parameter erfolgt. Ein Metadatenfilter wird nicht dadurch zu einer Sicherheitsgrenze, dass das Filterfeld user, role oder department heißt.
Die übergebene Identität muss vertrauenswürdig sein — und sie ist nicht die des Dienstes
Ein Retrieval-System kann Berechtigungen nur korrekt anwenden, wenn die ihm übergebene Identität vertrauenswürdig ist. Übergibt eine Anwendung eine Benutzerkennung und filtert das Retrieval-System anschließend alle Dokumente, die diese Kennung lesen darf, dann hängt die gesamte Zugriffskontrolle an der Frage, ob der Wert manipulierbar ist.
AWS macht diese Verantwortungsteilung für Bedrock Managed Knowledge Bases explizit. Das Feature stelle ACL-bewusste Filterung bereit, jedoch keine Sicherheitsgrenze; der Dienst authentifiziere Endbenutzer nicht selbst. Die Anwendung sei dafür verantwortlich, Benutzer zu authentifizieren und einen verifizierten Identitätskontext zu übergeben. Da der Dienst die Echtheit des übergebenen Benutzerkontexts nicht prüfen könne, dürfe die Funktion nicht als alleiniger Zugriffskontrollmechanismus ohne vorgelagerte Authentifizierung verwendet werden.
Der zulässige Pfad führt damit vom Identity Provider über authentifizierte Claims in die RAG-Anwendung, die daraus einen Authorization Context ableitet und an das Retrieval übergibt. Unzulässig ist der Pfad, bei dem eine frei wählbare Benutzerkennung aus der Eingabe oder aus einem clientseitig gesetzten Parameter unmittelbar in die Retrieval-Abfrage gelangt.
Die Rechte des Ingestion-Dienstes sind nicht die Rechte des Benutzers
Für die Ingestion benötigt eine RAG-Plattform in der Regel umfangreiche Leserechte auf den gesamten anzubindenden Datenbestand. Die einzelnen Benutzer der Anwendung besitzen dagegen jeweils nur Ausschnitte dieser Rechte, und diese Ausschnitte überschneiden sich unterschiedlich stark. Die Berechtigungen des technischen Ingestion-Accounts dürfen deshalb unter keinen Umständen das spätere Retrieval-Berechtigungsmodell bestimmen.
Geschieht das doch, entsteht das klassische Muster eines Confused Deputy, das die Common Weakness Enumeration als CWE-441 führt: Ein hoch privilegierter Dienst greift im Auftrag eines weniger privilegierten Aufrufers auf Ressourcen zu, ohne dessen tatsächliche Berechtigungen ausreichend zu berücksichtigen, und wird damit selbst zum Umgehungsweg. Service Identity und End User Identity müssen aus diesem Grund architektonisch getrennt geführt werden, und zwar nicht nur konzeptionell, sondern bis in die konkrete Implementierung der Retrieval-Schnittstelle hinein.
Gruppen entscheiden über den Zugriff, ihre Auflösung über die Aktualität
Unternehmensberechtigungen bestehen selten nur aus direkten Benutzerzuweisungen. Zugriff kann über direkte ACL-Einträge entstehen, über Gruppenmitgliedschaften, über Rollen, über geerbte Rechte übergeordneter Ordner und Container, über organisatorische Policies oder über Ressourcen-Scopes. Ein Benutzer, der einer Projektgruppe angehört, darf ein Dokument möglicherweise lesen, obwohl er in dessen ACL nicht namentlich aufgeführt ist. Das Retrieval-System muss deshalb mit dem Berechtigungsmodell der jeweiligen Datenquelle umgehen können und nicht nur mit einer vereinfachten Liste von Benutzerkennungen.
Die technisch entscheidende Frage lautet, an welcher Stelle Gruppenmitgliedschaften aufgelöst werden. Sie wird von den beiden hier betrachteten Plattformen unterschiedlich beantwortet, und der Vergleich zeigt unmittelbar, welche Konsequenzen die jeweilige Entscheidung hat.
Azure AI Search löst Gruppenzugehörigkeiten zur Abfragezeit auf. Die Benutzerkennung stammt aus dem übergebenen Token, die Gruppenmitgliedschaften werden über die Microsoft Graph API abgerufen, und die Berechtigungen auf einen Storage-Container werden für den im Token enthaltenen Principal ermittelt. Änderungen an der Gruppenmitgliedschaft eines Benutzers können damit vergleichsweise schnell wirksam werden, weil die Auflösung nicht im Index eingefroren ist.
AWS Bedrock geht den umgekehrten Weg. Gruppenmitgliedschaften werden während der Ingestion aus der jeweiligen Datenquelle mit erfasst und intern gespeichert; zur Abfragezeit ermittelt der Dienst anhand dieser erfassten Daten, welchen Gruppen ein Benutzer angehört. AWS benennt die Konsequenz ausdrücklich: Gruppenmitgliedschaften sind nur so aktuell wie der letzte Synchronisationslauf, und Berechtigungsänderungen zwischen zwei Läufen werden erst mit dem Abschluss des nächsten Ingestion-Jobs berücksichtigt.
Beide Verfahren sind für sich genommen tragfähig. Sie erzeugen jedoch unterschiedliche Aktualitätszusagen, und diese Zusage ist eine Eigenschaft, die vor der Auswahl einer Plattform gegen die eigenen Anforderungen an die Wirksamkeit von Rechteentzügen geprüft werden muss.
Ein zweiter Aspekt des Gruppenmodells wird in Architekturdiskussionen häufig übergangen: die Behandlung von Deny-Regeln. AWS legt für die ACL-Auswertung eine eindeutige Vorrangregel fest. Erscheint ein Benutzer für ein Dokument sowohl in einer Allow- als auch in einer Deny-Liste, wird der Zugriff verweigert; Deny überschreibt Allow. Diese Regel gilt in beiden Auswertungsstufen gleichermaßen. Wo eine Plattform eine solche Vorrangregel nicht dokumentiert, ist das ein Prüfpunkt und keine Nebensächlichkeit.
Aktualität ist eine sicherheitsrelevante Architektureigenschaft
Zwischen Datenquelle und Retrieval-Index besteht eine zeitliche Entkopplung, die sich nicht vollständig auflösen lässt. Wird ein Dokument samt seiner ACL um zehn Uhr indexiert und der Zugriff eines Benutzers eine Stunde später im Quellsystem entzogen, dann besitzt der Index einen anderen Berechtigungszustand als das Quellsystem, sobald der Benutzer unmittelbar danach eine Anfrage stellt. Ob dieser Zustand zu einer unberechtigten Auslieferung führt, hängt ausschließlich von der gewählten Architektur ab.
Microsoft dokumentiert diese Einschränkung für die tokenbasierte Zugriffskontrolle explizit: Berechtigungsänderungen im Quellsystem — etwa an Entra-Gruppenmitgliedschaften, an ADLS-Gen2-ACLs oder an Purview-Label-Zuweisungen — wirken sich auf Suchergebnisse erst aus, nachdem die Metadaten über den quellspezifischen Mechanismus in den Index synchronisiert wurden. Das kann ein nachfolgender Indexer-Lauf sein, ein Push-API-Update oder ein Purview-getriebener Refresh. Die ACL-Synchronisationslatenz wird damit zu einer messbaren und dokumentierbaren Sicherheitseigenschaft des Gesamtsystems.
Zwei Architekturansätze mit unterschiedlichen Trade-offs
Der erste Ansatz synchronisiert die Berechtigungen gemeinsam mit dem Inhalt. Das Retrieval-System besitzt eine Kopie der für die Zugriffskontrolle benötigten Informationen und kann die Autorisierungsprüfung vollständig innerhalb des eigenen Prozesses durchführen. Der Vorteil liegt in Geschlossenheit und Latenz: Es gibt keine externe Abhängigkeit im Abfragepfad. Der Preis ist die beschriebene zeitliche Differenz zwischen einer Berechtigungsänderung und ihrer Wirksamkeit.
Der zweite Ansatz prüft den Berechtigungszustand zur Abfragezeit zusätzlich gegen das Quellsystem, bevor ein gefundenes Dokument verwendet wird. Änderungen werden dadurch abhängig von der konkreten Implementierung deutlich aktueller berücksichtigt. Der Retrieval-Pfad erhält im Gegenzug eine externe Abhängigkeit, deren Latenz und Verfügbarkeit unmittelbar auf die Anfrage durchschlagen.
Dass sich beide Verfahren kombinieren lassen, zeigt die aktuelle AWS-Dokumentation. Bedrock Managed Knowledge Bases arbeiten zweistufig: In einer Pre-Retrieval-Filterung werden die beim letzten Crawl synchronisierten ACLs angewendet, sodass nur Kandidatendokumente zurückgegeben werden, für die der Benutzer oder eine seiner Gruppen in der Allow-Liste und nicht in der Deny-Liste erscheint. In einer zweiten Stufe verifiziert der Dienst für unterstützte Connectoren in Echtzeit gegen die Datenquelle, ob der Benutzer aktuell noch Zugriff auf die verbliebenen Kandidaten besitzt, und fängt damit Berechtigungsänderungen zwischen zwei Synchronisationsläufen ab.
Diese zweite Stufe steht allerdings nicht überall zur Verfügung. AWS führt sie für SharePoint, OneDrive, Google Drive und Confluence auf. Für Amazon S3 und für Custom-Connectoren ist sie nicht verfügbar, weil dort die kundenseitig bereitgestellten ACL-Metadaten als Source of Truth gelten und kein lebendes Berechtigungssystem existiert, gegen das geprüft werden könnte. Das Beispiel zeigt zugleich, warum Berechtigungsverhalten nicht produkt-, sondern implementierungsabhängig geprüft werden muss: Innerhalb ein und derselben Plattform unterscheidet sich die Aktualitätszusage je nach angebundener Datenquelle.
[BILD] Zweistufige Autorisierung aus Pre-Retrieval-Filterung und Real-Time-Verifikation, mit Darstellung des Zeitfensters zwischen zwei Synchronisationsläufen.
Der gesamte Datenlebenszyklus erzeugt Berechtigungsereignisse
Zugriffskontrolle darf nicht nur für neu aufgenommene Dokumente funktionieren. Eine vollständige Architektur muss eine Reihe von Ereignissen berücksichtigen, die alle Auswirkungen auf Chunks, Embeddings, Indexeinträge, Berechtigungsmetadaten und gegebenenfalls Caches haben.
Bei der Neuanlage werden Dokument und Berechtigungen gemeinsam aufgenommen. Bei einer Aktualisierung können sich Inhalt und ACL unabhängig voneinander ändern, was eine erneute Verarbeitung auslösen muss, auch wenn der Inhalt unverändert bleibt. Wird ein Dokument verschoben, wechselt es möglicherweise in einen Bereich mit anderen geerbten Berechtigungen, ohne dass sich am Dokument selbst etwas ändert. Ändert sich eine Gruppenmitgliedschaft, betrifft das potenziell eine große Zahl von Dokumenten gleichzeitig, ohne dass eines davon angefasst wurde. Beim Entzug einer Berechtigung entscheidet die Synchronisationsarchitektur darüber, ab wann der Entzug wirkt. Und beim Löschen eines Dokuments in der Quelle muss geklärt sein, wann die abgeleiteten Repräsentationen im Index verschwinden.
Für jedes dieser Ereignisse braucht es eine definierte Antwort. Berechtigungsmanagement ist damit kein Merkmal der Ingestion, sondern Bestandteil des gesamten RAG Data Lifecycle.
Die Trust Boundary endet nicht beim Retrieval
Eine Architektur, die alle relevanten Chunks an das Sprachmodell übergibt und die fertige Antwort anschließend durch einen Sicherheitsfilter schickt, hat die Zugriffskontrolle an der falschen Stelle platziert. Zu diesem Zeitpunkt sind nicht autorisierte Informationen bereits in den Prompt gelangt, haben die Generierung beeinflusst und möglicherweise Systemgrenzen überschritten. Ein nachgelagerter Ausgabefilter kann eine sinnvolle zusätzliche Schutzschicht sein, ersetzt aber die Autorisierung des Retrieval-Kontexts nicht. Für die eigentliche Zugriffskontrolle muss gelten, dass nicht autorisierte Inhalte den für die Generierung verwendeten Kontext gar nicht erst erreichen.
Das Argument gilt nicht nur für das Sprachmodell am Ende der Kette. Moderne RAG-Pipelines enthalten zwischen Retrieval und Prompt weitere Verarbeitungsschritte, insbesondere Reranking und Context Assembly. Wird ein externer Reranker eingesetzt, erhält dieser die gefundenen Textpassagen im Klartext — und zwar möglicherweise, bevor irgendeine Autorisierungsentscheidung gefallen ist. Die Architektur muss deshalb explizit festlegen, an welchem Punkt nicht autorisierte Kandidaten ausgeschlossen werden.
Aus Sicht der Datenminimierung ist die frühe Entscheidung klar vorzuziehen: Komponenten hinter der Zugriffskontrolle erhalten nur noch die Daten, die für den jeweiligen Benutzer verwendet werden dürfen. Das gilt besonders dann, wenn Retrieval, Reranking und Sprachmodell über unterschiedliche Dienste, Betreiber oder Trust Domains verteilt sind. AWS beschreibt für die zweistufige Auswertung entsprechend, dass die vorgefilterten Dokumente nur für die Dauer des API-Aufrufs existieren und weder für Sprachmodelle noch für Benutzer sichtbar werden.
Mehrere Datenquellen verschärfen das Identity-Problem
Enterprise-RAG-Systeme greifen selten auf eine einzige Quelle zu. Typisch ist die gemeinsame Indexierung von Fileservices, Collaboration-Plattformen, Object Storage und Datenbanken auf einer einheitlichen Plattform. Diese Systeme verwenden unterschiedliche Berechtigungsmodelle, und sie verwenden häufig auch unterschiedliche Repräsentationen derselben Person.
Damit entsteht eine Reihe von Fragen, die vor der Anbindung beantwortet sein müssen: Ist eine Benutzeridentität in allen Systemen identisch, und woran wird sie erkannt? Wie werden Gruppen abgebildet, und welche Quelle ist für Gruppenmitgliedschaften maßgeblich? Wie werden lokale und zentrale Identity-Systeme zusammengeführt, wie werden Deny-Regeln behandelt, wie gelöschte Benutzer, wie externe Benutzer und Gäste?
Die Dokumentation der Plattformen zeigt, dass diese Fragen keine theoretischen sind. AWS verwendet für die ACL-Auswertung die E-Mail-Adresse als universellen Benutzeridentifikator: Die im Benutzerkontext übergebene Adresse muss exakt mit der Adresse übereinstimmen, die dem Benutzer in jeder angebundenen Datenquelle zugeordnet ist. Eine Alias-Auflösung oder ein Mapping über Identity-Provider-Grenzen hinweg findet nicht statt. Gruppen werden dagegen so identifiziert, wie der jeweilige Connector sie repräsentiert — als Name, als Kennung oder in anderer Form.
Die Konsequenz benennt AWS in den Betreiberpflichten ausdrücklich: Weichen die E-Mail-Adressen zwischen den Systemen voneinander ab, schlägt die ACL-Zuordnung stillschweigendfehl, und der Benutzer erhält aus der betroffenen Datenquelle schlicht keine Ergebnisse. Hinzu kommt ein Lebenszyklusproblem, das über die reine Zuordnung hinausgeht: Wird eine E-Mail-Adresse nach dem Ausscheiden eines Mitarbeiters an eine andere Person vergeben, muss die Anwendung das erkennen, bevor sie die Identität übergibt. Die Echtzeitverifikation wirkt hier laut AWS als Sicherheitsnetz für die Connectoren, die sie unterstützen, ersetzt aber kein ordentliches Identity-Lifecycle-Management.
Identity Mapping ist damit keine Nebenfunktion der Ingestion, sondern ein tragender Bestandteil der RAG-Sicherheitsarchitektur — und zugleich der Punkt, an dem sich Fehler am schwersten diagnostizieren lassen, weil sie sich nicht als Fehlermeldung, sondern als leeres Suchergebnis äußern.
Nicht entscheidbare Autorisierung muss zum Ausschluss führen
Ein besonders wichtiger Fehlerfall entsteht, wenn eine Berechtigungsprüfung gar nicht durchgeführt werden kann. Der Identity Provider ist nicht erreichbar, die ACL-Auflösung schlägt fehl, die Gruppenauflösung liefert kein Ergebnis, oder der Authorization Service läuft in ein Timeout. Für diesen Fall muss definiert sein, ob Inhalte trotzdem ausgeliefert werden. Bei Fail Open führt ein Fehler der Sicherheitskomponente dazu, dass der Zugriff zugelassen wird; bei Fail Closed werden Inhalte bei nicht eindeutig feststellbarer Berechtigung zurückgehalten.
Beide betrachteten Plattformen dokumentieren hier ein restriktives Verhalten, und die Details sind aufschlussreich.
AWS beschreibt das ACL-bewusste Retrieval ausdrücklich als Fail-Closed: Trifft die ACL-Auswertung an irgendeiner Stelle auf einen Fehler — Gruppenauflösung, Timeout der Echtzeitverifikation oder ein interner Servicefehler —, werden die betroffenen Dokumente nicht zurückgegeben; ein transienter Fehler führe nie dazu, dass Dokumente an nicht autorisierte Benutzer gelangen. Das Verhalten reicht weiter als der reine Fehlerfall. Wird in einer Retrieve-Anfrage überhaupt kein Benutzerkontext übergeben, liefern ACL-aktivierte Datenquellen null Ergebnisse. Und besitzt ein Dokument in einer ACL-aktivierten Datenquelle keine Berechtigungsmetadaten — weil der Connector die Berechtigungen nicht extrahieren konnte oder weil das Dokument tatsächlich öffentlich ist —, wird es keinem Benutzer zurückgegeben. Fehlende Berechtigungen gelten als restriktiv, nicht als öffentlich.
Microsoft verfolgt für die tokenbasierte Durchsetzung denselben Grundsatz: Wird das Benutzertoken bei der Abfrage weggelassen, werden ACL-geschützte Inhalte nicht zurückgegeben. Für Diagnosezwecke ist ein Umgehungsweg vorgesehen, der jedoch explizit über einen eigenen Header angefordert werden muss und damit nicht versehentlich aktiv sein kann.
Diese Auslegung hat eine betriebliche Kehrseite, die eingeplant werden muss. Eine fehlgeschlagene Autorisierung sieht für den Benutzer aus wie ein schlechtes Suchergebnis. AWS adressiert das, indem Fehlerantworten eine ACL-Auflösungsstörung erkennbar machen und so von einer Anfrage unterscheidbar sind, die inhaltlich schlicht nichts gefunden hat. Für eine RAG-Architektur mit vertraulichen Unternehmensdaten sollte das Verhalten bei nicht entscheidbarer Autorisierung deshalb nicht nur spezifiziert, sondern auch getestet und im Betriebsmonitoring sichtbar gemacht werden.
Typische Fehlerbilder bei RAG-Berechtigungen
Aus den beschriebenen Architekturprinzipien lassen sich mehrere Konstellationen ableiten, die in der Praxis regelmäßig zu Problemen führen.
Am folgenschwersten ist der Fall, in dem Inhalte übernommen werden, Berechtigungen jedoch nicht. Der Retrieval-Index besitzt damit ein anderes Zugriffsmodell als das Quellsystem, und dieser Unterschied ist von außen nicht sichtbar. Eine abgeschwächte Variante entsteht, wenn ACLs zwar synchronisiert, aber nicht ausreichend aktuell gehalten werden: Entzogene Rechte sind im Retrieval-System dann noch nicht wirksam.
Ein eigenes Problem bilden Skalierungsgrenzen der Berechtigungsverarbeitung, weil sie unbemerkt zu einem Autorisierungsverlust führen können. Microsoft dokumentiert für ADLS Gen2 eine Obergrenze von 32 ACL-Einträgen pro Datei oder Verzeichnis, wobei ein Eintrag jeweils einem Principal mit einem bestimmten Berechtigungssatz entspricht. Überschreitet ein Objekt dieses Limit, werden Berechtigungen jenseits der Grenze zur Abfragezeit möglicherweise nicht durchgesetzt. Solche Grenzen sind dokumentiert, aber sie erzeugen keine Fehlermeldung im laufenden Betrieb — sie müssen aktiv gegen den eigenen Datenbestand geprüft werden.
Weitere Muster ergeben sich unmittelbar aus den vorangegangenen Kapiteln. Vertraut die Anwendung ungeprüften Identitätsinformationen, kann ein Security Filter nur so zuverlässig sein wie die Identität, auf der er basiert. Werden Service-Account-Rechte mit Benutzerrechten verwechselt, bedeutet die Lesefähigkeit der Infrastruktur faktisch Lesefähigkeit für jeden Benutzer der Anwendung. Erfolgt das Security Trimming erst nach dem Retrieval, haben nicht autorisierte Informationen bereits weitere Komponenten der Pipeline erreicht. Und ist das Identity Mapping zwischen mehreren Quellen inkonsistent, werden Benutzer- und Gruppenidentitäten falsch oder gar nicht zugeordnet.
Ein letztes Muster betrifft nicht die Architektur, sondern den Betrieb: Berechtigungsfehler werden als Retrieval-Problem behandelt. Erhält ein Benutzer keine Ergebnisse, weil seine Gruppenidentität nicht korrekt aufgelöst wurde, führt die Ursachensuche im Embedding-Modell oder in der Chunking-Strategie zwangsläufig ins Leere. Semantische Retrieval-Qualität und Autorisierung müssen deshalb auch im Troubleshooting getrennt betrachtet werden — was voraussetzt, dass das System beide Fälle überhaupt unterscheidbar protokolliert.
Architekturfragen vor der Einführung eines Enterprise-RAG-Systems
Vor der produktiven Einführung sollten Unternehmen nicht nur Embedding-Modell, Vektordatenbank und Sprachmodell auswählen. Die folgenden Fragen entscheiden mindestens ebenso stark über die Tragfähigkeit der Lösung, und sie lassen sich nachträglich nur mit erheblichem Aufwand beantworten.
Auf der Identitätsseite ist zu klären, welche Identity Provider existieren, wie Benutzer und Gruppen eindeutig identifiziert werden und wie Identitäten zwischen mehreren Datenquellen abgebildet werden. Auf der Quellenseite geht es darum, welche Zugriffskontrollmodelle die anzubindenden Systeme verwenden, ob Berechtigungsinformationen gemeinsam mit den Inhalten übernommen werden und ob der Authorization Context beim Zerlegen der Dokumente erhalten bleibt.
Im Retrieval-Pfad ist zu prüfen, an welcher Stelle nicht autorisierte Inhalte ausgeschlossen werden und ob dieser Ausschluss vor der Übergabe an Reranking, Context Assembly und Sprachmodell erfolgt. Für den Betrieb sind drei Zusagen zu dokumentieren: wie schnell ACL- und Gruppenänderungen wirksam werden, was bei einem Rechteentzug geschieht und wie sich das System verhält, wenn eine Autorisierungsentscheidung nicht getroffen werden kann.
Hinzu kommen zwei Fragen, die häufig zu spät gestellt werden. Welche Rechte besitzen Ingestion-, Retrieval- und Modelldienste, und wie sind diese Rechte von den Benutzerrechten getrennt? Und lässt sich nachvollziehen, welcher Benutzer welche Daten über das Retrieval tatsächlich verwendet hat? Ohne belastbares Audit bleibt jede der vorherigen Antworten unüberprüfbar.
Diese Fragen gehören in die Architekturphase und nicht in eine nachgelagerte Security-Review.
Fazit
RAG schafft keinen automatischen Sicherheitskontext für Unternehmensdaten. Eine RAG-Plattform kann Dokumente technisch lesen, in Chunks zerlegen, als Embeddings indexieren und semantisch wiederfinden. Daraus folgt nicht, dass jeder Benutzer der Plattform diese Informationen verwenden darf.
Die tragende Trennung besteht zwischen drei Entscheidungen, die getrennt getroffen und getrennt überprüft werden müssen: Authentication bestimmt die Identität, Authorization bestimmt den zulässigen Datenzugriff, Retrieval bestimmt die inhaltliche Relevanz. Eine belastbare Architektur verbindet diese Ebenen in einer festen Reihenfolge, in der die Autorisierung vor dem Reranking und vor der Zusammenstellung des Kontexts wirkt und nicht danach.
Berechtigungsinformationen müssen dabei über den gesamten Datenlebenszyklus erhalten bleiben, und Änderungen im Quellsystem müssen mit einem ausdrücklich zugesagten Aktualitätsmodell in der Retrieval-Schicht ankommen. Die Dokumentation der großen Plattformen zeigt, dass dieses Modell je nach angebundener Datenquelle unterschiedlich ausfällt — es ist deshalb keine Produkteigenschaft, sondern eine Eigenschaft der konkreten Implementierung.
Die wichtigste Architekturregel bleibt am Ende einfach: Nur weil ein RAG-System eine Information finden kann, darf es sie einem Benutzer noch lange nicht zeigen.
[QUERVERWEIS] Grundlagen der KI-Infrastruktur und Einordnung der RAG-Komponenten in die Gesamtarchitektur — Verweis auf den KI-Architektur-Ankerartikel
[QUERVERWEIS] Datenaufbereitung, Klassifizierung und Governance-Metadaten als Voraussetzung für berechtigungsbewusstes Retrieval — Verweis auf den Artikel zu Data Intelligenceund Governance
[QUERVERWEIS] Konsolidierung von Trainings- und Retrieval-Datenbeständen sowie deren Zugriffspfade — Verweis auf den Artikel zum AI Data Lake
[QUERVERWEIS] Zugriffskontrolle und Identitätsmodelle auf der Ebene der Storage-Plattform — Verweis auf den Artikel zur Object-Storage-Datenplattform
Quellen
NIST Rose, S.; Borchert, O.; Mitchell, S.; Connelly, S.: Zero Trust Architecture. NIST Special Publication 800-207, August 2020. Abschnitt 2, Tenets. NIST SP 800-207 – Zero Trust Architecture
OWASP Gen AI Security Project LLM08:2025 – Vector and Embedding Weaknesses. OWASP Top 10 for LLM Applications, Ausgabe 2025. Abgerufen September 2026. OWASP – LLM08:2025 Vector and Embedding Weaknesses
MITRE CWE-441: Unintended Proxy or Intermediary ("Confused Deputy"). Common Weakness Enumeration.
Microsoft Document-level access control in Azure AI Search. Microsoft Learn, abgerufen September 2026. Microsoft – Document-level access control
Microsoft Security filters for trimming results in Azure AI Search. Microsoft Learn, abgerufen September 2026. Microsoft – Security Filter Pattern
Microsoft Query-time ACL and RBAC enforcement in Azure AI Search. Microsoft Learn, Preview-Dokumentation, abgerufen September 2026. Microsoft – Query-time ACL and RBAC Enforcement
Amazon Web Services Access Control Lists awareness enablement – Amazon Bedrock. AWS-Dokumentation, Abschnitte „How ACL-aware retrieval works", „Identity model", „Connector support matrix", „Failure behavior", abgerufen September 2026. AWS – ACL awareness enablement
Amazon Web Services ACL-aware retrieval on managed knowledge bases – Amazon Bedrock. AWS-Dokumentation, abgerufen September 2026. AWS – ACL-aware Retrieval
Amazon Web Services Document-level access controls – Amazon S3 – Amazon Bedrock. AWS-Dokumentation, abgerufen September 2026. AWS – Document-level Access Controls für Amazon S3
Amazon Web Services RetrievalFilter – Amazon Bedrock API Reference. AWS-Dokumentation, abgerufen September 2026. AWS – RetrievalFilter API
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
