RAG-Berechtigungen: Security Trimming, ACLs & sichere Suche

Ein internes RAG-System kann fachlich hervorragende Antworten liefern und trotzdem nicht produktionsfähig sein, wenn seine Berechtigungen nicht sauber funktionieren.

Die kritische Frage lautet:

Sieht ein Nutzer über die KI exakt die Informationen, die er auch in den Quellsystemen sehen darf – nicht mehr und nicht weniger?

Das ist kein Prompt-Thema. Es ist klassische Zugriffskontrolle im Retrieval-Layer.

Die wichtigste Regel: Rechte greifen vor dem Modell

Eine häufige Fehlkonstruktion sieht so aus:

1. Das Retrieval findet alle semantisch passenden Dokumente.
2. Nicht erlaubte Dokumente landen im Context Window.
3. Der Systemprompt sagt dem LLM: „Nutze nur Inhalte, die der Nutzer sehen darf.“

Damit ist die Sicherheitsgrenze bereits verletzt.

Sobald vertraulicher Inhalt im Kontext liegt, hängt die Zugriffskontrolle vom Verhalten eines generativen Modells ab. Das ist nicht die richtige Schicht für Authorization.

Die robustere Reihenfolge lautet:

Nutzeridentität → effektive Rechte → Retrieval-Filter → erlaubte Chunks → LLM

Was Security Trimming bedeutet

Security Trimming ist aus Enterprise Search bekannt: Die Suche liefert nur Treffer, für die der aktuelle Principal berechtigt ist.

Bei RAG gilt dasselbe Prinzip.

Ein Dokument oder Chunk kann beispielsweise folgende Metadaten tragen:

• allowed_user_ids
• allowed_group_ids
• denied_user_ids
• tenant_id
• department_id
• classification
• source_acl_version

Beim Query werden die effektiven Principals des Nutzers aufgelöst und als Filter in die Suche eingebracht.

Vereinfacht:

semantic_query AND tenant_id = X AND allowed_group_ids IN user_groups

Das konkrete Datenmodell hängt von Quelle und Search Engine ab. Das Prinzip bleibt gleich: Retrieval darf nur autorisierte Evidenz zurückgeben.

Early Binding vs. Late Binding

Early Binding

Die Berechtigungsinformationen werden bei der Ingestion in den Suchindex materialisiert.

Vorteile:

• schnelle Query-Filter,
• klarer Security Boundary im Retrieval,
• gute Skalierbarkeit bei vielen Dokumenten.

Nachteile:

• Gruppen- und Rechteänderungen müssen synchronisiert werden,
• ACLs können große Metadatenstrukturen erzeugen,
• komplexe Gruppenbeziehungen brauchen saubere Auflösung.

Late Binding

Das System prüft Berechtigungen dynamisch gegen das Quellsystem oder einen Authorization Service.

Vorteile:

• Rechte bleiben näher an der Source of Truth,
• weniger duplizierte ACL-Daten,
• Änderungen können sofort wirksam werden.

Nachteile:

• zusätzliche Latenz,
• mehr Runtime-Abhängigkeiten,
• komplexer bei großen Candidate Sets.

In realen Enterprise-Systemen sind auch Mischformen sinnvoll: grobe Filter früh, feinere Policy-Prüfung später – aber immer bevor nicht erlaubter Inhalt ins LLM gelangt.

Nutzeridentität muss stabil sein

Berechtigungen werden unsauber, wenn Systeme E-Mail-Adressen oder Display Names als dauerhafte IDs verwenden.

Besser sind stabile Identity-Provider-IDs, beispielsweise aus:

• Microsoft Entra ID,
• LDAP/Active Directory,
• Keycloak,
• Authentik,
• einem internen IAM.

Das Retrieval sollte mit einer stabilen User-ID und den effektiv aufgelösten Gruppen/Rollen arbeiten.

Gruppen sind der Normalfall

In Unternehmen werden Dokumente selten für einzelne Nutzer freigegeben. Typisch sind:

• Abteilungen,
• Projektgruppen,
• Teams,
• Rollen,
• SharePoint-Gruppen,
• Mandanten,
• externe Partnergruppen.

Deshalb braucht die Architektur eine klare Antwort auf:

Wer löst verschachtelte Gruppen auf – und wie aktuell ist dieses Mapping?

Drei Varianten:

1. Gruppenauflösung bei jeder Anfrage.
2. gecachter Principal-Index.
3. Materialisierung der effektiven Gruppen beim Sync.

Keine Variante ist immer richtig. Entscheidend sind Größe, Änderungsrate und Latenzanforderung.

Berechtigungsänderungen sind wichtiger als der initiale Import

Der Demo-Fall ist einfach:

• Dokument importieren,
• ACL mitnehmen,
• Search Filter funktioniert.

Der produktive Fall ist schwieriger:

Ein Mitarbeiter wechselt die Abteilung. Eine Projektgruppe wird geschlossen. Ein Dokument wird neu klassifiziert.

Dann müssen Rechteänderungen zuverlässig propagiert werden.

Dazu gehören:

• Permission Change Detection,
• Gruppen-Synchronisierung,
• Cache Invalidierung,
• Reindex oder ACL-Update,
• Audit-Logs.

Ein Index mit gestern gültigen Rechten ist bei sensiblen Daten kein Detailproblem.

Permission Revocation: Zugriff muss auch verschwinden

Ein besonderes Risiko sind entzogene Rechte.

Wenn ein Nutzer gestern Zugriff hatte und heute nicht mehr, darf ein alter Cache oder Index nicht weiterhin Treffer liefern.

Deshalb sollte ein Permission-System explizit testen:

• Entzug einzelner Nutzerrechte,
• Entfernen aus Gruppen,
• Verschieben zwischen Mandanten,
• Dokument-Reklassifizierung,
• Löschen von Gruppen.

Revocation ist ein eigenes Abnahmekriterium.

Mandantentrennung ist mehr als ein Filter

Bei Multi-Tenant-Systemen darf tenant_id nicht nur ein optionales Metadatum sein.

Die Mandantengrenze sollte möglichst auf mehreren Ebenen abgesichert werden:

• Datenmodell,
• Query Filter,
• Index/Collection,
• Storage,
• Auth Token,
• Logging.

Je höher der Schutzbedarf, desto weniger sollte eine einzelne vergessene Filterbedingung den gesamten Schutz tragen.

Für besonders sensible Architekturen kann ein separater Index oder sogar eine physische Trennung sinnvoll sein.

Chunk-Level oder Document-Level ACL?

Wenn alle Chunks eines Dokuments dieselben Rechte haben, ist Document-Level ACL meist ausreichend und einfacher.

Chunk-Level ACL wird relevant, wenn:

• ein Dokument intern unterschiedliche Schutzbereiche besitzt,
• Inhalte aus mehreren Quellen zusammengeführt werden,
• Abschnitte unterschiedliche Klassifizierungen haben.

Das erhöht jedoch Komplexität und Fehlerfläche.

Leitprinzip:

Berechtigungsgranularität nur so fein machen, wie es der echte Use Case verlangt.

Filter vor oder nach Vector Search?

Wenn eine Search Engine Metadatenfilter effizient mit Vektorsuche kombinieren kann, ist ein Pre-Filter meist ideal: nicht erlaubte Dokumente nehmen gar nicht am Candidate Set teil.

Post-Filtering ist problematisch, wenn:

1. Vector Search die Top 10 Treffer liefert.
2. Acht davon nicht erlaubt sind.
3. Nach dem Filter bleiben nur zwei – obwohl andere erlaubte Dokumente auf Rang 11–30 lagen.

Das kann die Retrieval-Qualität verschlechtern.

Deshalb sollten Berechtigungsfilter in der Retrieval-Architektur und in den Eval-Metriken mitgedacht werden.

Hybrid Search + ACL

Berechtigungen gelten nicht nur für Vektorsuche.

Wenn ein RAG-System kombiniert:

• BM25 / Volltext,
• Vector Search,
• Metadatenfilter,
• Reranking,

muss dieselbe Authorization-Logik für alle Retrieval-Pfade gelten.

Ein sicherer Vector Store bringt wenig, wenn ein paralleler Keyword-Search-Pfad vertrauliche Treffer ungefiltert liefert.

Reranking darf keine Sicherheitsgrenze überschreiten

Ein Reranker sollte nur Kandidaten sehen, die bereits berechtigt sind.

Pipeline:

Authorization → Retrieval Candidates → Reranking → Context Assembly

Nicht:

Global Retrieval → Reranker → ACL Filter

Je später die Zugriffskontrolle greift, desto mehr Komponenten verarbeiten unnötig sensible Daten.

Caching: unterschätzte Fehlerquelle

Caches können Berechtigungen unterlaufen.

Beispiele:

• gecachte Retrieval-Ergebnisse eines anderen Nutzers,
• Query Cache ohne User-/Tenant-Key,
• Gruppen-Mapping mit zu langer TTL,
• gecachter finaler LLM-Response für mehrere Rollen.

Deshalb muss jeder Cache-Key den relevanten Security Context enthalten.

Bei sensiblen Systemen sollte dokumentiert sein:

• was gecacht wird,
• wie lange,
• mit welchem Nutzer-/Tenant-Kontext,
• wie Revocation den Cache invalidiert.

Quellenbezug darf ebenfalls nichts leaken

Selbst wenn der Antworttext sauber gefiltert ist, können Quelleninformationen vertrauliche Daten verraten:

• Dokumenttitel,
• Dateipfad,
• Projektname,
• URL,
• Autor,
• Abteilung.

Source Attribution muss deshalb dieselben Berechtigungen respektieren wie der eigentliche Text.

Permission-Aware Evaluation

Ein normales RAG-Eval-Set reicht nicht.

Sie brauchen zusätzlich Rollen- und Rechtefälle.

| Test | Erwartung | |---|---| | Nutzer A fragt nach erlaubter Richtlinie | richtige Quelle wird gefunden | | Nutzer A fragt nach vertraulichem HR-Thema | kein HR-Dokument im Retrieval | | HR-Nutzer stellt dieselbe Frage | HR-Dokument wird gefunden | | Nutzer wird aus HR-Gruppe entfernt | Zugriff verschwindet | | Dokument wird neu klassifiziert | neue ACL greift nach Sync |

Messen Sie zwei Fehlerklassen getrennt:

False Denial

Der Nutzer dürfte die Information sehen, Retrieval filtert sie aber fälschlich aus.

Folge: schlechte Antwortqualität.

Unauthorized Retrieval

Der Nutzer dürfte die Information nicht sehen, Retrieval liefert sie trotzdem.

Folge: Sicherheitsvorfall.

Bei sensitiven Systemen ist die zweite Klasse deutlich kritischer.

Logging: erklären können, warum ein Treffer erlaubt war

Für Debugging und Audit sollte nachvollziehbar sein:

• User-/Tenant-ID,
• effektive Rollen/Gruppen,
• angewandte Filter,
• gefundene Dokument-IDs,
• ACL-Version,
• verwendete Quellen.

Nicht jedes Detail gehört dauerhaft in Logs; insbesondere personenbezogene Daten und Inhalte sollten minimiert werden. Aber das System muss erklären können, warum ein bestimmter Treffer zugelassen wurde.

Architektur-Checkliste für RAG-Berechtigungen

Vor Production sollten Sie diese Fragen beantworten:

1. Was ist die Source of Truth für Identitäten?
2. Was ist die Source of Truth für ACLs?
3. Early Binding, Late Binding oder Hybrid?
4. Wie werden Gruppen aufgelöst?
5. Wie schnell müssen Rechteänderungen wirksam werden?
6. Wie funktioniert Revocation?
7. Wie wird Mandantentrennung erzwungen?
8. Werden alle Retrieval-Pfade gleich gefiltert?
9. Enthalten Cache Keys den Security Context?
10. Sind Quellenangaben ebenfalls geschützt?
11. Gibt es Permission-Eval-Fälle?
12. Werden Unauthorized-Retrieval-Fälle als kritische Fehler behandelt?

SharePoint, DMS und andere Quellen

Bei SharePoint ist permission-aware RAG besonders wichtig, weil das Quellsystem bereits ein ausgeprägtes Berechtigungsmodell besitzt. Der Guide SharePoint an RAG anbinden zeigt die konkrete Integrationsarchitektur.

Für mehrere Quellen gleichzeitig siehe RAG-Datenquellen anbinden.

Wenn ein vorhandenes System vor Go-live auf Rechte, Retrieval und Fehlerklassen 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