RAG-Berechtigungen: Security Trimming, ACLs & sichere Suche

Authorization gehört in den Retrieval-Pfad. Nur Evidenz, die der aktuelle Nutzer sehen darf, darf überhaupt in den Modellkontext gelangen.

Ein RAG-System ist nicht sicher, nur weil das LLM angewiesen wird, nichts Vertrauliches preiszugeben. Nicht autorisierte Evidenz darf das Modell nie erreichen. Security Trimming ist damit keine UI-Regel und kein Prompting-Thema, sondern Teil der Architektur zwischen Anfrage und Context Assembly.

Der Leak passiert vor der Antwort

Stellen Sie sich eine bestehende Unternehmensanwendung vor. Sie greift auf SharePoint, ein DMS und ein internes Wiki zu. Dokumente sind für Projektgruppen, Abteilungen und einzelne Personen freigegeben; manche haben individuelle Ausnahmen.

Nutzer A darf das interne Dokument „Projekt Phoenix Budget“ sehen. Nutzer B ist nicht in der Projektgruppe und hat keine Einzelberechtigung. Beide fragen: „Wie hoch ist das Projekt-Phoenix-Budget?“

Wenn die semantische Suche das Dokument für Nutzer B findet und in den Prompt legt, ist die Sicherheitsgrenze bereits verletzt – auch wenn die finale Antwort später ausweicht, kürzt oder einen Hinweis auf fehlende Berechtigung ausgibt. Der Fehler ist nicht erst die ausgegebene Antwort. Schon das Einspeisen nicht autorisierter Evidenz in den Modellkontext ist architektonisch falsch.

Die Reihenfolge muss deshalb lauten:

Security Trimming im RAG-Pfad

1. 01

   User Identity

   Stabile ID, Tenant oder Workspace sowie aktueller Session-Kontext

2. 02

   Identity Mapping

   Anwendungsidentität auf Source-System-Principal, Gruppen und Rollen abbilden

3. 03

   Query

   Anfrage zusammen mit dem aktuellen Security Context ausführen

4. 04

   ACL-aware Retrieval

   Security Trimming begrenzt Kandidaten auf effektiv erlaubte Evidenz

5. 05

   Authorized Evidence

   Nur zulässige Chunks dürfen Reranking oder weitere Auswahl erreichen

6. 06

   Context Assembly

   Autorisierte Evidenz für das Modell zusammenstellen

7. 07

   LLM

   Antwort auf Basis eines bereits begrenzten Kontexts erzeugen

Warum Post-Filtering keine primäre Sicherheitsgrenze ist

Ein nachgelagerter Filter kann sinnvoll sein, etwa als zusätzliche Prüfung oder um Ergebnisdarstellung einzugrenzen. Er darf aber nicht die erste oder einzige Kontrolle sein.

Bei klassischem Post-Filtering kann die Suche zunächst globale Kandidaten liefern, ein Reranker diese verarbeiten oder Context Assembly sie auswählen. Erst danach werden Treffer entfernt. Damit haben bereits mehrere Komponenten nicht autorisierte Daten gesehen. Zusätzlich leidet die Qualität: Wenn acht der zehn besten Treffer nicht erlaubt sind, bleiben nach dem Filter nur zwei übrig – obwohl relevante erlaubte Dokumente weiter unten im Ranking liegen.

Bevorzugt ist daher permission-aware Retrieval beziehungsweise Pre-Filtering: Der Retrieval-Index und der Query-Pfad wenden den aktuellen Berechtigungskontext an, bevor Kandidaten ausgewählt werden. Dasselbe muss für Vector Search, Volltextsuche, Hybrid Search und Reranking gelten. Ein sicherer Vektorpfad hilft nicht, wenn ein paralleler Keyword-Pfad vertrauliche Treffer liefert.

Identity Mapping: dieselbe Person in Anwendung und Quelle

Die Unternehmensanwendung kennt eine eingeloggte Person. SharePoint, DMS oder Wiki kennen dagegen ihre eigenen Principals, Gruppen und Rollen. Zwischen beiden Welten braucht es ein belastbares Mapping.

Die Basis ist eine stabile User-ID aus Anwendung oder Identity Provider, nicht Display Name oder E-Mail-Adresse als dauerhafter Schlüssel. Zum Retrieval-Kontext gehören außerdem die aktuell wirksamen Gruppen und Rollen, der Tenant oder Workspace und – falls die Quelle das braucht – der zugehörige Source-System-Principal.

Service Accounts können die Ingestion vereinfachen und über breite Leserechte verfügen. Sie dürfen aber nicht stellvertretend als Nutzeridentität im Retrieval dienen. Wenn eine Anwendung delegierten Zugriff verwendet, muss der wirksame Nutzerkontext trotzdem bis zum Source- oder Authorization-Modell nachvollziehbar bleiben. Entscheidend ist eine stabile Identität über Sessions hinweg, nicht ein zufälliger Session- oder Anzeige-Wert.

ACLs sind eigene Daten, nicht Import-Beifang

Ein Dokument in SharePoint oder einem DMS kann gruppenbasierte ACLs, Einzelberechtigungen und Ausnahmen enthalten. Der Retrieval-Index muss diese wirksamen Regeln aus der Quelle übernehmen oder gegen eine aktuelle Policy-Quelle prüfen. Dabei dürfen Allow-/Deny-Semantik und Gruppenmitgliedschaften nicht zu einem vereinfachten „hat Gruppe X“ verflacht werden.

Verschachtelte Gruppen sind nur insofern relevant, wie sie im Quellsystem tatsächlich wirksame Rechte erzeugen. Die Architektur muss klar festlegen, wo diese Auflösung geschieht und wie frisch sie sein muss. Ein grober Indexfilter und eine feinere Policy-Prüfung können zusammenarbeiten – aber beide müssen vor Context Assembly greifen.

Permission State ist eine eigene Datenebene und darf nicht nur Nebenprodukt des Dokument-Imports sein.

Der Dokumenttext kann unverändert bleiben, während sich seine ACL ändert: Ein Dokument wird in eine andere Bibliothek verschoben, neu klassifiziert oder für eine Projektgruppe gesperrt. Diese Änderung muss den Retrieval-Pfad erreichen, auch wenn kein Content-Re-Index ansteht. Für die Anbindung von Quellen und Change Detection siehe RAG-Datenquellen anbinden.

Security Trimming: nur autorisierte Evidenz weitergeben

Security Trimming beschränkt die Suche auf die effektiven Rechte des aktuellen Nutzers. Praktisch kann das ACLs, Gruppen, Rollen, Tenant oder Workspace als Teil des Suchfilters verwenden. Die konkrete Datenstruktur ist abhängig von Quelle und Search Engine; die Invariante nicht:

Nicht autorisierte Chunks dürfen nicht in den Modellkontext gelangen.

Die Filterlogik muss mit dem Index und jedem Query-Pfad konsistent sein. Das betrifft auch abgeleitete Artefakte wie Chunk-Metadaten, Reranking-Kandidaten und Quellenangaben. Ein Dokumenttitel, Dateipfad oder Projektname kann bereits vertrauliche Information sein. Quellenbezug respektiert deshalb dieselbe Berechtigungsentscheidung wie der eigentliche Text.

Permission Changes und Revocation

Der schwierige Fall beginnt nach dem erfolgreichen Initialimport:

• Nutzer A verliert die Projektberechtigung.
• Eine Gruppenmitgliedschaft ändert sich.
• Das Phoenix-Dokument wandert in einen anderen Bereich.
• Seine ACL ändert sich, ohne dass sich der Text ändert.
• Index- oder Permission-Sync hinkt hinter der Quelle hinterher.

Wenn Nutzer A nach einem Entzug weiterhin Treffer bekommt, ist die Datenlage nicht „etwas stale“, sondern die Sicherheitsgrenze verletzt. Permission Sync und Revocation müssen unabhängig vom Dokumentinhalt funktionieren. Ein Nutzerzugriff darf nicht erst beim nächsten Content-Re-Index verschwinden.

Revoke-Latenz ist ein Security-Kriterium.

Für jedes System sollte deshalb definiert sein, innerhalb welcher Zeit ein Entzug in Retrieval, Context Assembly und Quellenangaben wirksam wird – und wie Abweichungen sichtbar werden. Diese Zeit ist eine fachliche und technische Anforderung, keine Optimierungsnotiz.

Caches müssen dieselben Grenzen kennen

Ein technisch korrekter Retrieval-Filter hilft nicht, wenn ein Cache Antworten oder Treffer über Identitätsgrenzen hinweg wiederverwendet.

• Ein Retrieval Cache benötigt mindestens den relevanten Nutzer-, Gruppen- und Tenant-/Workspace-Kontext.
• Ein Answer Cache darf eine Antwort nicht für eine andere Rolle oder einen anderen Tenant ausliefern.
• Ein Permission Cache braucht eine begrenzte Gültigkeit und eine Strategie für Änderungen und Entzüge.

Ein Cache-Key allein löst nicht jedes Aktualitätsproblem. Entscheidend ist, wie Permission Changes ihn invalidieren oder seine Gültigkeit begrenzen. Die Regeln müssen für alle Caches dieselben Sicherheitsgrenzen abbilden wie das Retrieval.

Tenant- und Workspace-Grenzen sind nicht dasselbe wie Gruppenrechte

User- und Group-Level Permissions entscheiden, welche Inhalte eine Person innerhalb ihres Bereichs sehen darf. Tenant- oder Workspace-Isolation trennt dagegen die primäre Sicherheitsdomäne des Systems.

Wenn ein Tenant die zentrale Grenze darstellt, darf er nicht nur ein optionaler Filterwert sein, der bei einer Query vergessen werden kann. Welche zusätzliche Trennung sinnvoll ist – etwa eigene Collections, Indizes oder Storage-Grenzen – hängt vom Schutzbedarf ab. Die Architekturentscheidung muss aber verhindern, dass ein fehlender Gruppenfilter gleich tenantübergreifende Evidenz sichtbar macht.

Permission-Aware Tests und Evaluation

Ein Golden Dataset für RAG sollte Nutzerkontext, Tenant und erwartete Evidenz enthalten. Es testet nicht nur, ob eine Antwort fachlich stimmt, sondern ob genau die zulässige Evidenz gefunden wurde.

Zwei Fehlerklassen sollten getrennt gemessen werden: False Denial bedeutet, dass erlaubte Evidenz fälschlich fehlt. Unauthorized Retrieval bedeutet, dass nicht erlaubte Evidenz gefunden oder weitergegeben wird. Bei sensiblen Daten ist die zweite Klasse ein Sicherheitsvorfall, nicht bloß ein Qualitätsproblem.

Der Artikel RAG-Evaluation: Metriken & Golden Dataset ordnet ein, wie Retrieval, Context Assembly und Antwort getrennt geprüft werden. Berechtigungen gehören dort als testbarer Retrieval- und Kontextvertrag hinein.

Architecture View

Ich würde Berechtigungen nicht als UI- oder Prompting-Problem behandeln. Die Sicherheitsgrenze liegt im Retrieval-Pfad: Nicht autorisierte Evidenz darf den Modellkontext nicht erreichen.

Das erfordert kein unnötig komplexes IAM-Projekt. Es erfordert eine explizite Entscheidung: Welche Identität fragt an, welche ACL ist aktuell wirksam, wo wird sie durchgesetzt und wie schnell verschwinden alte Rechte? Für SharePoint-spezifische Integrationsfragen siehe SharePoint an RAG anbinden. Wenn ein bestehendes System auf Retrieval, Rechte und Revocation geprüft werden soll, passt AI Production Readiness.

Sie bauen RAG mit internen Unternehmensdaten und wollen die Berechtigungsgrenzen sauber entwerfen oder testen?
→ RAG-Architektur besprechen