Kernaussage: Ein RAG-System wird nicht dadurch sicher, dass sich Mitarbeitende anmelden. Sicher wird es erst, wenn die vorgelegte Identität in eine Berechtigungsliste für die Retrieval-Abfrage übersetzt, vor dem Retrieval durchgesetzt und als Nachweis protokolliert wird. Gelangt ein unzulässiger Chunk in den Prompt, kann eine spätere Modellverweigerung die Offenlegung nicht zurücknehmen.
Der Kontrollpunkt liegt im Retrieval, nicht in der Antwort
Unternehmens-Wissensbasen übernehmen Berechtigungen häufig aus SharePoint, Dateispeichern, Ticketsystemen oder Fachanwendungen. Die Architektur muss diese Quellautorität über Ingestion, Indexierung, Abfrage und Beobachtbarkeit erhalten. Authentifizierung beantwortet, wer anfragt; Autorisierung beantwortet, welches Dokument und welcher Chunk abgerufen werden darf. OWASP empfiehlt Least Privilege, „deny by default“ und die Berechtigungsprüfung bei jeder Anfrage.
Eine belastbare Reihenfolge lautet: (1) Anfragende Person und Gruppen im Identity Provider auflösen; (2) Quell-ACLs oder eine freigegebene Berechtigungsprojektion auswerten; (3) den resultierenden Filter in der Retrieval-Abfrage anwenden; (4) nur erlaubte Chunks abrufen; (5) nur diese Chunks an das Modell senden; (6) ein prüfbares Ereignis schreiben. Das Modell erhält Kontext, aber keine Entscheidungsbefugnis.
Referenzarchitektur: vier übereinstimmende Kontrollen
1. Stabile Identitäten und Gruppen-Claims
Verwenden Sie unveränderliche Subject- und Gruppen-IDs statt Anzeigenamen. Cachen Sie Gruppenzugehörigkeiten zurückhaltend und definieren Sie ein Ziel für Widerrufe: Eine Berechtigungsänderung wirkt erst, wenn Index-Metadaten und Claim-Cache konvergiert sind. Für Service-zu-Service-Retrieval benötigen Sie eine eigene Workload-Identität; ein weitreichendes Ingestion-Credential darf nicht zur Laufzeit wiederverwendet werden.
2. Berechtigungsmetadaten auf Dokumenten und Chunks
Erfassen Sie bei der Ingestion mindestens Quelldokument-ID, ACL-Version oder Hash, Klassifikation, Mandant und Löschstatus. Jeder abgeleitete Chunk muss die Einschränkung des Quelldokuments erben, sofern Sie keine strengere Chunk-Regel ausdrücklich entwerfen und testen. Ein Vektor-Embedding ist eine Indexfunktion, keine Sicherheitsgrenze.
3. Query-time Enforcement vor dem Ranking
Setzen Sie die Autorisierungsbedingung im Retrieval-Backend durch und ranken Sie innerhalb dieser erlaubten Menge. Nachgelagertes Filtern erzeugt vermeidbare Exposition: verbotene Inhalte können bereits in Anwendung, Cache, Trace oder Modell-Prompt angekommen sein. Microsoft beschreibt dieses Muster als dokumentenbasierte Filterung zur Abfragezeit.
4. Nachweise für die Incident Response
Protokollieren Sie Request-ID, pseudonymisierte Subject-ID, Version der effektiven Gruppenmenge, Policy-Entscheidung, Index-/Versionsstand, abgerufene Dokument-IDs und Chunk-IDs, Modellaufruf-ID sowie Ergebnis. Schreiben Sie nicht routinemäßig sensible Prompt- oder Chunk-Texte in Logs. Das NIST Generative AI Profile nennt Dokumentation, Logging, Change-Management-Aufzeichnungen, Versionshistorie und Metadaten als hilfreiche Grundlagen für Incident Response und Rechenschaft.
Das Durchsetzungsmuster bewusst auswählen
Security Filters eignen sich für eigene Identitätssysteme und Push-Index-Pipelines: Die Anwendung übergibt ein freigegebenes Benutzer- oder Gruppenattribut, und die Suche filtert auf gespeicherten ACL-Metadaten. Eine native Synchronisierung von Quellberechtigungen kann doppelte Identitätslogik reduzieren, wenn die Plattform sie unterstützt. Microsoft unterscheidet Security Filters, ACL/RBAC Scopes, Sensitivity Labels und SharePoint-ACLs; einzelne Integrationen sind Preview-Funktionen. Prüfen Sie daher Synchronisationsverzögerung, Fehlerbehandlung und vertragliche Eignung, bevor Sie sie produktiv voraussetzen.
Produktionstests gegen die teuren Fehler
Bauen Sie ein festes Autorisierungs-Evaluationsset, nicht nur Relevanztests. Enthalten sein sollten: eine Person ohne Zugriff; eine Person mit Zugriff auf eines von zwei fast gleichen Dokumenten; ein kürzlich widerrufener Zugriff; ein Dokument, das zwischen Gruppen verschoben wurde; ein adversarialer Prompt für eingeschränkte Inhalte; und eine Anfrage über ein Agenten-Tool statt die Chat-Oberfläche. In jedem Fall müssen Sie beweisen, dass verbotene Dokument-IDs und Chunks weder in Retrieval-Ergebnissen, Prompts, Zitaten, Caches noch Logs erscheinen.
Messen Sie Sicherheit und Betrieb gemeinsam: Rate unautorisierter Retrievals (im Testset Zielwert null), ACL-Synchronisationsverzug, Filterlatenz, Empty-Result-Rate nach Filterung und Anteil der Retrieval-Ereignisse mit vollständigem Entscheidungsnachweis. Mehr leere Ergebnisse können auf legitime Rechte, veraltete Gruppen-Claims oder einen Indexierungsfehler hindeuten. Verbreitern Sie nicht einfach die Zugriffsrechte.
Grenzen und Umsetzungsplan
Dokumentbasierte Filterung löst weder Prompt Injection in erlaubten Dokumenten noch schwache Modellanweisungen, überprivilegierte Tools oder Datenresidenz. Sie kann Recall senken und Abfragen komplexer machen. Kombinieren Sie sie daher mit Quellhygiene, Content-Scanning, Tool-Allow-Lists, Output-Kontrollen und einem getesteten Incident-Prozess. Dieser Beitrag ist technische Umsetzungshilfe und keine Rechtsberatung.
Beginnen Sie mit einem abgegrenzten Korpus und einer Identitätsquelle. Inventarisieren Sie deren ACL-Semantik, beweisen Sie Deny-by-default-Tests und ergänzen Sie ein Audit-Ereignisschema, bevor weitere Repositories folgen. So entsteht ein belastbares Fundament für RAG-Qualität, ohne das Modell zum Berechtigungssystem zu machen.
Primärquellen
Microsoft Learn, Document-level access control in Azure AI Search: https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview
OWASP, Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
NIST AI 600-1, Generative AI Profile: https://doi.org/10.6028/NIST.AI.600-1
