Pexon Consulting | 10 Min. Lesezeit | 15.06.2026
TL;DR
Knowledge-Bot ohne Permission-Layer bedeutet: HR-User sieht Vorstandsprotokolle. Entra ID Groups als OAuth-Token-Claim filtern die Vector-DB-Treffer auf die Berechtigungen des aufrufenden Users — ohne separate ACL-Datenbank. Pexon Consulting hat das Pattern in 14+ produktiven RAG-Setups bei Mittelständlern, Versicherern und KRITIS-Betreibern implementiert. Sprint-Investment 28-48k EUR Festpreis.
Das Problem: RAG ohne Berechtigungslayer
Wir hören das fast wöchentlich in CIO-Erstgesprächen, wenn der erste RAG-Pilot intern verteilt wird: „Plötzlich findet die Suche Dokumente, die der User in SharePoint nie hätte sehen dürfen.“ Das ist kein RAG-Bug — das ist eine Architektur-Lücke.
Klassische Dokumenten-Suche in SharePoint, M365 oder File-Servern hat ACLs (Access Control Lists) pro Datei. Wenn ihr diese Dokumente in eine Vector-DB embedded und der Retrieval-Lauf darüber sucht, sind die ACLs nicht mehr in der Pipeline. Der Retrieval-Service holt semantische Treffer — ungeachtet der Berechtigungen.
Bei einem Versicherungs-Pilotkunden haben wir das im Discovery-Test quantifiziert: In einem ungeschützten RAG-Setup mit 18.000 indexierten Dokumenten wären 6,4% der Treffer für den anfragenden User in SharePoint blockiert gewesen. Auf 8.000 Anfragen pro Tag sind das 512 potenzielle ACL-Verletzungen täglich. Für Banking und Versicherung ist das ein BaFin-meldepflichtiges Compliance-Risiko.
Drei Architektur-Ansätze stehen zur Wahl.
Ansatz 1: Statischer Tenant-Filter
Der naive Ansatz. Jeder Chunk bekommt eine tenant_id, jeder Retrieval-Lauf filtert auf die tenant_id des aufrufenden Users.
Was geht damit: Mandant-Trennung in Multi-Tenant-SaaS. Wir haben das im Multi-Tenant-RAG-Pattern ausführlich behandelt.
Was NICHT geht: Innerhalb eines Mandanten sind alle Dokumente gleich sichtbar. Wenn ihr HR-Dokumente, Vorstandsprotokolle und Strategie-Papers im gleichen Index habt, sieht jeder User alles.
Geeignet für: Multi-Mandant-Setups OHNE intra-Mandant-Berechtigungslayer. Sub-Optimal für Enterprise-RAG.
Ansatz 2: User-ID-basiertes ACL
Pro User wird eine ACL-Liste gepflegt: „User Müller darf Dokumente A, B, C sehen“. Beim Retrieval wird der Filter aus dieser Liste gebaut.
Vorteile: Sehr feinkörnig steuerbar, präzise Berechtigungen pro Dokument möglich.
Nachteile (warum wir das NICHT empfehlen): Pflegeaufwand explodiert. Bei 800 Mitarbeitern und 25.000 Dokumenten habt ihr theoretisch 20 Millionen ACL-Einträge zu pflegen. Synchronisation mit SharePoint, OneDrive, File-Servern wird zur Vollzeit-Aufgabe. Operativ in der Praxis nicht durchhaltbar.
Geeignet für: Sehr kleine Setups (< 50 User, < 500 Dokumente) mit extrem sensiblen Inhalten und vollzeitlichem Pflege-Team.
Ansatz 3: Entra ID Groups als Permission-Layer (Pexon-Standard)
Der Pattern, den wir seit 2024 als Standard in 14+ produktiven Setups deployen. Sauber, skalierbar, Audit-fest.
Grundidee: Die Berechtigungen liegen in Entra ID Groups, nicht in einer separaten ACL-Datenbank. Jeder User ist Mitglied von Gruppen (z.B. hr-team, versicherung-aussendienst, vorstand). Jeder Chunk in der Vector-DB hat einen Metadata-Eintrag mit den Gruppen, die ihn sehen dürfen. Beim Retrieval kommen die User-Gruppen als Claim im OAuth-Token mit — und werden im Vector-DB-Filter benutzt.
Die drei Komponenten.
# Komponente 1: Beim Embedden — Gruppen-Tagging
def index_document(doc, sharepoint_acl):
allowed_groups = extract_groups_from_acl(sharepoint_acl)
# Beispiel: ["hr-team", "personalleitung", "vorstand"]
chunks = split_document(doc.content)
for chunk in chunks:
vectorstore.add_documents([
Document(
page_content=chunk,
metadata={
"doc_id": doc.id,
"allowed_groups": allowed_groups,
"data_classification": doc.classification
}
)
])# Komponente 2: Beim Retrieval — Token-Claim als Filter
@app.post("/retrieve")
async def retrieve(query: str, request: Request):
token = request.headers.get("Authorization").split(" ")[1]
claims = jwt.decode(token, jwks=JWKS_URL, audience="rag-api")
# Entra ID liefert Gruppen-IDs als Claim
user_groups = claims.get("groups", [])
if not user_groups:
raise HTTPException(403, "No group memberships in token")
# Filter: Chunk muss MINDESTENS eine User-Gruppe zulassen
results = vectorstore.similarity_search(
query=query,
k=10,
filter={"allowed_groups": {"$in": user_groups}}
)
return results# Komponente 3: Audit-Trail
audit_log.write({
"user_id": claims["oid"],
"user_groups_hash": hashlib.sha256(
json.dumps(sorted(user_groups)).encode()
).hexdigest(),
"query_hash": hashlib.sha256(query.encode()).hexdigest(),
"result_doc_ids": [r.metadata["doc_id"] for r in results],
"filter_applied": True,
"timestamp": datetime.utcnow().isoformat()
})Warum das sauber funktioniert. Die Berechtigungen werden in Entra ID gepflegt — das Tool, das eure IT bereits für M365, SharePoint und Azure-Ressourcen nutzt. Bei einem Abteilungswechsel passt ihr die Gruppenmitgliedschaft an, der Permission-Layer im RAG zieht automatisch nach. Keine separate Berechtigungs-Datenbank, keine ACL-Synchronisation.
Bei Anbindung an SharePoint-Quellen mappen wir die SharePoint-Permission-Gruppen 1:1 auf Entra-ID-Gruppen — damit ist die SharePoint-ACL technisch in der Vector-DB nachgebaut. Mehr zum User-Identity-Propagation-Pattern mit OAuth On-Behalf-Of.
Die typischen Engineering-Fallen
Wo wir bei eigenen Setups regelmäßig Bugs einsammeln.
Falle 1: Token-Refresh übersieht Gruppen-Änderungen. Wenn ein User aus der Vorstands-Gruppe entfernt wird, der Access-Token aber noch 60 Minuten gültig ist, sieht der User in dieser Zeit weiter Vorstands-Dokumente. Mitigation: Token-Lifetime auf 15 Minuten reduzieren, plus serverseitiger Token-Revocation-Check bei sensiblen Endpunkten.
Falle 2: Nested Groups werden nicht korrekt aufgelöst. Wenn hr-team-muenchen Mitglied von hr-team-bundesweit ist und Dokumente nur hr-team-bundesweit als allowed_group haben, müssen die Mitglieder der Unter-Gruppe trotzdem Zugriff bekommen. Entra ID liefert per Default nur direkte Gruppen-Mitgliedschaften — geschachtelte Gruppen müssen explizit angefragt werden über die Group Token Claim-Konfiguration.
Falle 3: Gruppen-Count-Limit im OAuth-Token. Entra ID begrenzt die Gruppen im Token auf maximal 200 Gruppen pro User. Wenn ein User in 250 Gruppen ist, kommt nur ein Pointer auf die Graph-API mit — das bricht den Filter-Mechanismus. Mitigation: Bei sehr granular berechtigten Setups arbeiten wir mit Application Roles statt Groups, oder mit Graph-API-Lookup beim Retrieval (zusätzliche Latenz, deutlich resilienter).
Falle 4: Group-IDs vs Group-Names. Entra ID liefert standardmäßig die Group-Object-ID als Claim (UUID), nicht den lesbaren Namen. Wenn ihr beim Indexieren Namen wie „hr-team“ speichert, der Filter aber UUIDs erwartet, läuft nichts. Mitigation: Beim Setup klar entscheiden — wir empfehlen Object-IDs für Resilienz gegen Umbenennungen.
SharePoint-Integration im Detail
Bei den meisten Mittelständlern und Enterprises ist SharePoint die Hauptquelle für indexierte Dokumente. Pattern für saubere Permission-Übernahme.
Schritt 1: SharePoint-Permission-Inventur. Beim ersten Setup lesen wir die SharePoint-Berechtigungen pro Site, Library, Folder aus. Output: Tabelle Dokument → ACL-Liste.
Schritt 2: Mapping auf Entra-ID-Gruppen. Wenn SharePoint mit Entra-ID-Gruppen statt mit direkten Benutzern arbeitet (Best Practice), ist das Mapping trivial. Bei direkten User-ACLs schlagen wir vor, vor dem RAG-Roll-out die SharePoint-Permissions auf Gruppen-Basis zu konsolidieren — Aufwand 1-2 Wochen, danach ist die RAG-Berechtigungs-Architektur sauber.
Schritt 3: Beim Re-Index-Lauf. Jedes Mal, wenn ein Dokument neu indexiert wird, prüfen wir die aktuelle SharePoint-ACL und übernehmen die Gruppen-Liste als allowed_groups-Metadata. Bei Permission-Änderung in SharePoint reicht ein Re-Index des betroffenen Dokuments.
Schritt 4: Synchronisations-Frequenz. Bei wenig dynamischen Permission-Strukturen reicht ein nächtlicher Sync. Bei häufigen Permission-Änderungen (z.B. nach Onboarding) synchronisieren wir alle 4-6 Stunden. Bei sehr dynamischen Setups (Vertrieb mit häufigen Account-Zuteilungen) hooken wir uns in die Microsoft Graph Change Notifications ein.
Pexon-Sprint und Investment
Wir liefern den Permission-Layer als 3-Wochen-Sprint.
Wochen 1: Discovery der bestehenden Permission-Struktur (SharePoint, M365, Quellen-Systeme), Mapping auf Entra-ID-Gruppen, Architektur-Workshop mit CISO und Engineering-Lead.
Wochen 2: Implementierung Indexer mit Permission-Übernahme, Retrieval-Service mit Token-Claim-Filter, Audit-Trail-Pipeline.
Wochen 3: Penetration-Test mit synthetischen Cross-Permission-Anfragen, Pen-Test-Report für eure interne Compliance, Übergabe an Engineering-Team.
Investment 28-48k EUR Festpreis je nach Komplexität. Bei Banking-Tier-1 und KRITIS-Tier-1 am oberen Ende. Mehr zur breiten Compliance-Architektur in eurer AI Landing Zone.
Häufig gestellte Fragen
Reicht nicht der SharePoint-Built-in-Search-Endpoint?
Bei reinem Dokumenten-Such-Use-Case ja — SharePoint Search hat die ACL-Logik nativ. Bei RAG mit LLM-Antworten (statt nur Treffer-Liste) braucht ihr trotzdem den Permission-Filter im Retrieval-Lauf, weil der LLM-Output Inhalte aus mehreren Dokumenten kombiniert. SharePoint Search liefert die rohe Treffer-Liste, nicht den vereinheitlichten LLM-Output.
Was bei Microsoft 365 Copilot anstelle eigener Architektur?
Microsoft 365 Copilot hat ACL-Vererbung aus SharePoint und M365 nativ. Wenn euer RAG-Use-Case innerhalb der M365-Welt bleibt, ist Copilot oft die pragmatischere Antwort. Wenn ihr externe Quellen (CRM, ERP, eigene Datenbanken) einbinden wollt, braucht ihr eigene Architektur — und dann ist Entra-ID-Permission-Layer der saubere Pfad.
Wie schnell ist der Filter bei vielen Gruppen?
In unseren Setups sehen wir mittlere Filter-Latenzen von 8-15 ms bei pgvector mit GIN-Index auf allowed_groups. Azure AI Search filtert ähnlich performant. Bei extrem hohen Volumen (>5M Chunks) lohnen sich gestaffelte Indizes pro Permission-Klasse.
Was bei Cross-Tenant-Berechtigungen (Partner-Firmen)?
Sauberes Pattern: B2B-Guest-Users in eurem Entra ID anlegen, sie in die passenden Permission-Gruppen aufnehmen. Damit ist die Berechtigung in eurer Identity-Domäne, der Partner-Mitarbeiter loggt sich mit seinem eigenen Konto ein. B2B-Direct-Connect zwischen Entra-Tenants ist für höhere Sensitivitäts-Klassen die nächste Stufe.
Wie reagiert der Datenschutzbeauftragte auf Group-Claims im Token?
Group-Memberships im OAuth-Token sind Standard-Pattern und in Microsoft-Architekturen seit Jahren etabliert. Datenschutz-Bedenken kommen typisch nicht aus dem Claim selbst, sondern aus der Audit-Trail-Frage: Wir loggen den Group-Membership-Hash, nicht die Klartextliste — damit ist die Logs-Sensitivität reduziert.
Nächster Schritt
Wenn dein Unternehmen RAG produktiv ausrollt und der Permission-Layer noch nicht sauber sitzt: Wir machen einen 45-Minuten-Architektur-Call mit dir und idealerweise dem CISO. Du beschreibst die Quellen-Systeme und Permission-Struktur, wir skizzieren den 3-Wochen-Sprint mit Festpreis.
Verwandte Themen
→User-Identity-Propagation mit OAuth On-Behalf-Of
→AI Landing Zone als Fundament für KRITIS und NIS2
→Vector-DB-Wahl für regulierte Multi-Tenant-Setups
