Wie ein RAG-Assistent keine Dokumente preisgibt, die Nutzer nicht öffnen dürfen

Wo Berechtigungen verloren gehen

Im Quellsystem liegen ein Dokument und seine Zugriffsliste zusammen. Eine RAG-Pipeline kopiert den Text heraus, zerlegt ihn in Chunks, berechnet Embeddings und speichert alles an einem anderen Ort. Jeder Schritt kann die Verbindung zwischen einem Chunk und den Personen, die ihn lesen dürfen, kappen. Die Schwachstellen sind vorhersehbar:

• Die Ingestion läuft unter einem Dienstkonto, das alles lesen darf, und der Index speichert den Text ohne Zugriffsliste
• Chunks übernehmen die Berechtigungen zum Zeitpunkt der Indexierung, und spätere Änderungen im Quellsystem erreichen sie nie
• Die Anwendung fragt den Index mit eigenen Zugangsdaten ab und gibt die Identität der Person nie weiter
• Gruppenmitgliedschaften werden einmal aufgelöst und zwischengespeichert, sodass jemand, der ein Team verlassen hat, weiter Zugriff hat
• Logs, Caches und Evaluierungsdaten halten geschützten Text außerhalb jeder Zugriffskontrolle vor

OWASP zählt unbefugten Zugriff und Datenabfluss zwischen Gruppen, die sich einen Vektorspeicher teilen, zu den wichtigsten Schwachstellen embedding-basierter Systeme. Die Empfehlung lautet: berechtigungsbewusstes Retrieval mit nach Nutzern oder Gruppen getrennten Daten.

Beim Retrieval filtern

Die Designregel ist kurz: Die Suchanfrage selbst liefert nur Chunks, die die Person lesen darf, sodass geschützter Text nie in den Prompt gelangt. Suchmaschinen setzen das unterschiedlich um, und die Details bestimmen, was Sie testen müssen.

Die Document-Level Security von Elasticsearch hängt eine Abfrage an eine Rolle, und diese Abfrage lässt sich mit Attributen der aktuellen Person als Vorlage gestalten. Hat jemand mehrere Rollen, werden die Rollenabfragen mit ODER verknüpft, sodass eine weit gefasste Rolle die engen aufhebt. Azure AI Search bietet ACL- und RBAC-Durchsetzung zur Abfragezeit, die Microsoft als Preview kennzeichnet, ohne SLA und nicht für Produktionslasten empfohlen. Die Anwendung übergibt das Token der Person, und der Dienst baut aus Berechtigungsfeldern im Index einen Sicherheitsfilter.

Welche Suchmaschine Sie auch nutzen: Die Identität muss aus der authentifizierten Sitzung stammen. Sie darf nie aus einem Parameter kommen, den die Person, das Modell oder ein Tool-Aufruf setzen kann.

Berechtigungsänderungen kommen verspätet an

Wer Zugriffslisten in einen Index kopiert, schafft eine zweite Kopie, die veralten kann. Die Azure-Dokumentation ist hier eindeutig: Ein geplanter SharePoint-Indexer übernimmt Berechtigungsänderungen auf Elementebene bei jedem Lauf, aber geerbte Änderungen an Site, Bibliothek oder Ordner erfordern eine erneute Synchronisierung, und per Push geladene Inhalte müssen neu eingespielt werden. Bis dahin kann jemand, dem der Zugriff entzogen wurde, das Dokument weiter abrufen.

Legen Sie für jede Quelle fest, wie lang dieses Zeitfenster sein darf, und richten Sie den Synchronisierungsplan danach aus. Für besonders sensible Inhalte können Sie zusätzlich zur Abfragezeit beim Quellsystem prüfen, ob die wenigen Dokumente, die gleich verwendet werden, lesbar sind, auf Kosten zusätzlicher Latenz.

Lesen Sie auch die aktuellen Grenzen Ihrer Suchmaschine nach. Azure dokumentiert höchstens 32 ACL-Einträge pro Datei für ADLS Gen2 und 1.000 Berechtigungseinträge pro Datei für SharePoint, und Einträge über dem Limit werden möglicherweise nicht durchgesetzt. Elastic weist darauf hin, dass Nutzer mit Document-Level Security weiterhin Aggregationen ausführen können, die Begriffe oder Anzahlen aus Dokumenten offenlegen, die sie nicht lesen dürfen.

Negativtests für jede Art von Nutzer

Die meisten RAG-Testsets prüfen, ob die richtige Antwort zurückkommt. Berechtigungstests prüfen das Gegenteil und brauchen echte Testidentitäten mit bekannten Rechten. Prüfen Sie die abgerufenen Dokumente ebenso wie die Antwort, denn ein Modell kann eine geschützte Textstelle umschreiben, ohne sie zu nennen.

# Permission test cases (hypothetical identities and files)
# Each case runs through the full application path as a real test user.

- id: salary-bands-denied
  user: test-engineer-01        # member of Engineering only
  question: "What is the salary band for senior engineers?"
  must_not_retrieve: [hr/compensation-bands.pdf]
  expect: decline

- id: removed-member
  user: test-former-finance     # removed from Finance in the source system
  question: "Summarise the Q3 board pack"
  must_not_retrieve: [finance/board-pack-q3.pptx]
  expect: decline
  run_after: permission change has synced

- id: missing-identity
  user: none                    # request without a user token
  question: "List open incident reports"
  must_not_retrieve: [any restricted document]
  expect: error or public results only

- id: allowed-control
  user: test-hr-02              # HR member, should succeed
  question: "What is the salary band for senior engineers?"
  must_retrieve: [hr/compensation-bands.pdf]

Der letzte Fall ist genauso wichtig wie die anderen, denn ein Filter, der alle blockiert, besteht jeden Negativtest. Führen Sie die Tests nach jeder Änderung an Ingestion, Gruppenzuordnung oder Suchkonfiguration aus, und planen Sie den Fall des entfernten Mitglieds nach einer echten Berechtigungsänderung im Quellsystem ein.

Bei unklarer Identität sicher ablehnen

Schlägt die Auflösung der Identität fehl, ist das sichere Ergebnis: keine geschützten Treffer. Azure gibt an, dass der Dienst bei fehlgeschlagener ACL-Auswertung, etwa wenn Microsoft Graph nicht erreichbar ist, einen Fehler statt eines teilweise gefilterten Ergebnisses liefert. Microsoft hat das Verhalten außerdem im November 2025 geändert: Frühere Preview-API-Versionen lieferten bei Aufrufen mit Dienstschlüssel und ohne Nutzertoken alle Dokumente. Anwendungen, die gegen diese Versionen gebaut wurden, sollten Sie prüfen.

Wenden Sie dieselbe Regel in Ihrem eigenen Code an. Ein fehlendes Token, eine unbekannte Gruppe oder ein Timeout bei der Berechtigungsprüfung endet mit einer Ablehnung und einem Logeintrag, der Identität und betroffene Dokumente festhält, ohne den geschützten Text selbst zu speichern.

Wenn Sie einen bestehenden Assistenten prüfen, beginnen Sie mit dem Fall der fehlenden Identität: Rufen Sie die Retrieval-Schicht ohne Nutzertoken auf und sehen Sie sich an, was zurückkommt.