RAG über SharePoint, Confluence und Google Drive: Permissions-First-Architektur

Das harte Problem in Enterprise-RAG ist nicht die Retrieval-Qualität, es sind die Berechtigungen: Der Assistent darf niemals ein Dokument an Nutzer ausspielen, die es nicht sehen dürfen. Das Embedding entfernt die Access Control List, sodass eine naive Pipeline nach dem Muster "alles embedden, Top-k abrufen" auf Ähnlichkeit statt auf Autorisierung matcht und so Daten leakt. Die Lösung ist architektonisch. Erzwingen Sie den Zugriff auf der Retrieval-Ebene, nicht im Prompt: Hängen Sie die ACL jedes Quelldokuments als versioniertes, filterbares Metadatum an jeden Chunk und filtern Sie die Vektorsuche vor dem Retrieval nach Identität und Gruppenzugehörigkeiten des anfragenden Nutzers, sodass das Modell nur autorisierte Chunks zu sehen bekommt. Geben Sie die Identität des Endnutzers weiter, nicht die eines Service-Accounts; speichern Sie Gruppen-IDs, nicht Nutzer-IDs; lassen Sie Deny vor Grant gewinnen; und halten Sie die ACLs aktuell, denn eine entzogene Berechtigung, die der Index noch nicht nachvollzogen hat, ist ein aktives Leak.

Dies ist der Implementierungs-Begleiter zu unserer RAG-Production-Readiness-Checkliste, die Per-User-Berechtigungen als das harte Sicherheitsproblem benennt. Dieser Beitrag zeigt, wie Sie es tatsächlich lösen. Anbieterspezifische und Preview-Funktionen ändern sich schnell; prüfen Sie die verlinkten Docs erneut, bevor Sie bauen.

Warum Berechtigungen der schwierige Teil sind

Das Fehlerszenario in einem Satz: Das Modell formuliert eine flüssige Antwort, die auf einem Dokument basiert, das der anfragende Nutzer nie sehen durfte, weil das Retrieval auf semantische Ähnlichkeit gematcht hat und nicht auf Autorisierung. Sobald ein Dokument gechunkt und in einen gemeinsamen Index embedded ist, wandern die Eigentümer, Zugriffsstufen und Sensitivitätskennzeichnungen des Quellsystems nicht mit dem Vektor mit, sofern Sie sie nicht bewusst mitführen. Ein Vektorspeicher hat kein Konzept davon, wer fragt.

Microsoft 365 Copilot ist der kanonische Praxisfall. Es bricht Berechtigungen nicht, es respektiert sie. Das Problem ist, dass es Inhalte, die bereits übermäßig geteilt, aber schwer auffindbar waren, trivial auffindbar macht, sodass latentes Over-Permissioning, das niemandem aufgefallen ist, zu einer Ein-Prompt-Anfrage wird. Microsofts eigene Gegenmaßnahmen sind aufschlussreich: Werkzeuge, die riskante Inhalte aus der Reichweite des Assistenten herausziehen (Restricted Content Discovery, Data-Access-Governance-Reports), statt das Modell zu bitten, sich zu benehmen.

Was der entscheidende Punkt ist: Dem Modell zu sagen, ein Dokument nicht preiszugeben, ist keine Kontrolle. Die OWASP-Leitlinie zu Sensitive Information Disclosure stellt klar fest, dass System-Prompt-Restriktionen möglicherweise nicht eingehalten werden und durch Prompt Injection umgangen werden können. Prompt Injection ist das LLM-Risiko Nummer eins, und es kann indirekt eintreffen, versteckt in einem abgerufenen Dokument. Forscher haben eine nahezu vollständige Umgehung von Produktions-Guardrails demonstriert, und eine Prompt-Injection-Kette in Copilots Enterprise-Suche aus dem Jahr 2026 funktionierte genau deshalb, weil ein Leak-Prevention-Schutz nur für die erste Anfrage galt. Die Grenze muss die Architektur sein, nicht der Prompt.

Das Prinzip: auf der Retrieval-Ebene durchsetzen

Der Vektorspeicher darf ein unautorisiertes Dokument gar nicht erst zurückgeben, und das Modell darf es nie verarbeiten. Das erreichen Sie, indem Sie jeden Chunk zur Index-Zeit mit normalisierten, versionierten ACL-Metadaten taggen und zur Retrieval-Zeit einen Berechtigungsfilter in die Query einbauen. Das Filtern nach dem Retrieval, auf der Anwendungsebene oder im Prompt, scheitert auf zwei Wegen: Es verschwendet das Kontextfenster, indem es Dokumente abruft, nur um sie wieder zu verwerfen, und wenn die App-Logik einen Bug hat oder durch eine Injection umgangen wird, fließen die Dokumente trotzdem durch. Post-Filtering bricht außerdem leise den Recall, denn das Herausstreichen unautorisierter Chunks aus einem Top-k-Set kann dem Modell nichts mehr lassen, wenn die autorisierten Ergebnisse knapp außerhalb von k lagen. Filtern Sie bereits bei der Suche vor, oder rufen Sie ein Vielfaches von k ab und filtern dann.

Berechtigungsmodelle pro Quelle

Jede Quelle hat ihr eigenes ACL-Modell und ihre eigenen Fallen. Sie ingestieren mit einer erhöhten Identität, die alle Inhalte und deren Berechtigungen lesen kann, normalisieren jede Quelle auf dieselbe Form und lösen auf Gruppen-IDs auf.

Ein Detail, das Teams beißt: Programmieren Sie gegen Microsoft Graph gegen grantedToV2 und grantedToIdentitiesV2; die älteren grantedTo-Felder sind deprecated. Und die Sichtbarkeit von Berechtigungen ist selbst access-trimmed, daher braucht ein vollständiger ACL-Crawl eine Application Identity mit den richtigen Read-All-Scopes, kein delegiertes Nutzertoken.

Implementierungsmuster, die halten

• Speichern Sie Gruppen-IDs am Chunk, nicht Nutzer-IDs. Geringere Kardinalität, und eine Mitgliedschaftsänderung braucht keine Neuindexierung, nur eine Gruppenauflösung zur Query-Zeit. Lösen Sie transitive, verschachtelte Mitgliedschaft auf der Principal-Seite auf.
• Rufen Sie mit der Identität des Endnutzers ab. Ingestieren Sie mit einer Service-Identität, aber filtern Sie zur Query-Zeit mit der Identität und den Group-Claims des Endnutzers, weitergegeben über OAuth on-behalf-of. Verwenden Sie die unveränderliche Object-ID und die Group-Object-IDs für die Autorisierung, niemals einen veränderlichen Anzeigenamen. On-behalf-of funktioniert nur für Nutzer, nicht für Service Principals, daher kann eine reine Service-Account-Kette kein Per-User-Trimming leisten.
• Filtern Sie an der ANN-Query mit einem Set-Membership-Test vor. Verwenden Sie eine Set-Funktion (im Äquivalent Ihres Vektorspeichers zu search.in oder einem $in-Filter) über die erlaubten Principals des Nutzers; eine lange Kette aus Gleichheits-ORs ist Sekunden langsamer. Deny gewinnt vor Grant.
• Behandeln Sie das Entra-Groups-Overage. Ist ein Nutzer in mehr als etwa 200 Gruppen, lässt das Identity-Token den Groups-Claim fallen und gibt einen Overage-Pointer aus; die Retrieval-Ebene muss das erkennen und die vollständige Liste nachladen, sonst werden Nutzer mit hoher Gruppenanzahl still under-filtered.
• pgvector mit Postgres Row-Level Security ist ein sauberes Primitiv: Eine Select-Policy hängt an jede Query, inklusive der Ähnlichkeitssuche, ein Berechtigungsprädikat an, sodass es im App-Code unmöglich zu umgehen ist. Achten Sie auf die Latenz, denn die Policy kann mit dem approximativen Index in Konflikt geraten; mildern Sie das mit partiellen Per-Tenant-Indizes oder Partitionierung und setzen Sie die Identity-Variable pro Request in Ihrem Connection-Pooler.

Es gibt eine echte Gabelung in den Empfehlungen, die man benennen sollte. Ein Lager (darunter AWS) argumentiert, dass Metadatenfilterung zur Query-Zeit allein nicht ausreicht und Sie die Autorisierung beim Retrieval erneut gegen die Quelle prüfen sollten, weil synchronisierte Metadaten veralten. Das andere (darunter Microsofts Referenzmuster) synchronisiert ACLs in den Index und setzt sie zur Query-Zeit mit dem Token des Nutzers durch, des Durchsatzes wegen. Es ist ein echter Trade-off: Aktualität gegen Latenz. Wählen Sie nach der Sensibilität der Daten.

Das Aktualitätsproblem, das niemand einplant

Wenn Berechtigungen beim Ingest materialisiert werden, wird ein quellseitiger Entzug nicht automatisch propagiert, sodass ein Nutzer, dem der Zugriff entzogen wurde, ein Dokument im Index bis zur nächsten Synchronisation weiterhin sehen kann. Es gibt zwei Leak-Fenster: das Sync-Fenster zwischen einer Quelländerung und dem Index-Update sowie der Blindspot beim vererbten Scope, bei dem ein Werkzeug ACLs auf Elementen mit eindeutigen Berechtigungen aktualisiert, aber Änderungen verpasst, die aus einem Parent-Scope kamen. SharePoint braucht einen expliziten Permissions-Resync für vererbte Änderungen; Parent-Änderungen an Google Drives Shared Drives hinterlassen keinen Change-Log-Eintrag am Kind. Nutzen Sie die Change-Feeds der Quelle (Google Drives Changes-API feuert bei Berechtigungsänderungen, nicht nur bei Edits) und materialisieren Sie entweder schneller mit Webhooks oder führen Sie eine Live-Last-Mile-Prüfung durch, gemäß der obigen Gabelung.

Löschung ist die andere Hälfte. Das Recht auf Vergessenwerden bedeutet, auf jeder Ebene zu löschen: das Quellobjekt, jeden abgeleiteten Chunk und jedes Embedding, samt Caches. Entwerfen Sie die Chunk-IDs von Anfang an so, dass das Löschen eines Dokuments und all seiner Chunks eine günstige Operation ist. Und behandeln Sie das Embedding selbst als personenbezogene Daten: Forschung zu Embedding-Inversion hat den Großteil kurzer Quelltexte allein aus dem Vektor rekonstruiert, sodass ein Löschen, das das Embedding zurücklässt, in Wahrheit nichts vergessen hat.

DSGVO und Datenresidenz

Permissions-First-RAG bildet die DSGVO sauber ab. Datenminimierung spricht gegen das Bulk-Vektorisieren von allem Erreichbaren; rufen Sie nur ab und embedden Sie nur, was der Assistent braucht. Dem Rechenschaftsprinzip dient am besten ein konkretes Artefakt: ein Per-Query-Retrieval-Audit-Log, das festhält, welche Dokumente welcher Identität für welche Query ausgespielt wurden, was Ihnen zudem erlaubt, einen vermuteten Stale-ACL-Leak im Nachhinein zu untersuchen. Und wo die Daten liegen, ist weiterhin wichtig, also routen Sie die Inferenz in eine EU-Region und schließen Sie einen Auftragsverarbeitungsvertrag mit dem Modellanbieter, was wir in EU-Datenresidenz für KI-Apps im Jahr 2026 behandeln.

Die Referenzarchitektur, und die Anti-Pattern

End-to-End: Ingestieren Sie jede Quelle mit einer Identität, die alle Inhalte und ACLs lesen kann; extrahieren Sie die effektive ACL pro Element (unter Beachtung gebrochener Vererbung, Durchlaufen der Confluence-Vorfahren, Lesen der Drive-Vererbung); chunken, embedden und hängen Sie die normalisierte versionierte ACL als filterbares Metadatum an jeden Chunk; rufen Sie mit der Endnutzer-Identität und einem verpflichtenden Berechtigungsfilter ab; generieren Sie nur aus autorisierten Chunks; loggen Sie jede Entscheidung; und betreiben Sie eine Aktualitäts-Schleife aus den Change-Feeds der Quelle mit explizitem Resync für vererbte Änderungen und kaskadierenden Löschungen bis zu Chunks und Embeddings.

Die Anti-Pattern, von denen die meisten reale Vorfälle sind, die nur darauf warten zu passieren: ein gemeinsamer Index ohne Berechtigungsfilter; Filtern nach dem Retrieval oder im Prompt; dem Modell zu vertrauen, dass es sich selbst zensiert; mit einer Service-Account-Identität abzurufen, was das Per-User-Trimming aushebelt; Per-User-IDs statt Gruppen-IDs zu speichern; SharePoints "Limited Access" als Lesezugriff zu behandeln; Confluence-Restrictions ohne Durchlaufen der Vorfahren zu lesen; nur SharePoint-ACLs zu spiegeln und dabei die Label-Verschlüsselung zu ignorieren; nur bei vollständigen Crawls zu aktualisieren, sodass Entzüge nachhängen; und das Quelldokument zu löschen, aber das Embedding zurückzulassen.

"Das Modell ist nicht Ihre Zugriffskontrolle, und der Prompt ist nicht Ihre Sicherheitsgrenze. Wenn ein Nutzer ein Dokument nicht lesen darf, darf der Vektorspeicher es nie zurückgeben. Alles andere, die Labels, die Aktualität, das Audit-Log, steht im Dienst dieser einen Regel."