Technologie Radar wird geladen
Rollenbasierte Kontext-Isolation in RAG bedeutet, Zugriffsgrenzen zu erzwingen, bevor abgerufener Inhalt Modellkontext wird. Das System darf nur Dokumente, Chunks, Metadaten und abgeleiteten Kontext retrieven, reranken, cachen, zusammenfassen und generieren, auf die der aktuelle Nutzer berechtigt ist.
Das ist eine eigene Security-Schicht, weil RAG-Anwendungen oft private Daten, breit zugängliches internes Wissen und sensible Records in derselben Retrieval-Pipeline kombinieren. Microsoft beschreibt Document-Level Access Control als essenziell für sichere AI Agentic Systems, RAG-Anwendungen und Enterprise Search mit Authorization Checks auf Dokumentebene (Microsoft Learn). AWS warnt, dass unsanitized sensible Daten in einem Vector Store abgerufen und an unautorisierte Nutzer geleakt werden können, und stellt Role-Based Retrieval als ein Muster zum Schutz sensibler Daten in RAG-Anwendungen vor (AWS Machine Learning Blog).
Behalten Sie Assess, weil der Bedarf klar ist, Implementierungsmuster aber noch uneinheitlich sind. Teams sollten prüfen, ob ihre Retrieval-Schicht Source Permissions erhält, Authorization Filters vor Generation anwendet, Entscheidungen auditiert und Leakage über Embeddings, Summaries, Tool Outputs, Caches und Downstream Agent Memory verhindert.
Authorization muss passieren, bevor Inhalt den Modellkontext erreicht. Post-Generation Filtering reicht nicht, weil das LLM unautorisierte Fakten bereits gesehen haben kann und diese Summaries, Reasoning Traces, Citations, Tool Calls oder gecachten Conversation State beeinflussen.
Permission Metadata kann von Source Systems abdriften. Werden ACLs, Gruppenmitgliedschaften, Data Classifications oder Ownership bei Ingestion nicht erhalten und zur Query Time nicht erneut geprüft, kann der RAG-Index unsicherer sein als das Quellrepository.
Chunking und Embeddings verkomplizieren die Boundary. Ein Dokument erzeugt viele Chunks; Chunks können benachbarten Text mit anderer Sensibilität enthalten; Embeddings können Information über restricted Content encodieren, auch wenn Rohtext später gefiltert wird. Summaries, Reranker Inputs, Logs, Traces, Evaluation Datasets und langfristiges Agent Memory brauchen dieselbe Authorization Posture.
Role-Based Access kann zu grob sein. Viele Unternehmen brauchen relationship- oder attribute-basierte Controls, vererbte Ordnerberechtigungen, Gruppenexpansion, Projektzugehörigkeit, Customer Tenancy, Legal Hold, geografische Restriktionen oder purpose-basierten Zugriff. Auth0s Beispiel zeigt, warum Fine-Grained Authorization nötig sein kann, wenn Permissions an konkrete Ressourcen statt breite Rollen gebunden sind (Auth0 Blog).
Performance kann leiden, wenn Authorization nachträglich angeflanscht wird. Große Allow-Lists oder per-Document Checks erhöhen Latenz und können Recall senken; Retrieval sollte Authorization Constraints möglichst in die Query Planning drücken und Security- wie Relevanz-Outcomes monitoren.
Bewerten Sie dieses Muster für interne Suche, regulierte Wissensassistenten, Support Copilots, Legal- und HR-Assistenten, Healthcare- und Financial Workflows und jedes RAG-System, das öffentliche, interne, kundenspezifische oder vertrauliche Inhalte mischt. Die minimale Architektur authentifiziert den Nutzer, löst Permissions auf, erhält Authorization Metadata bei Ingestion, erzwingt Filter vor Generation und loggt, welche Dokumente oder Chunks eligible und retrieved waren.
Bevorzugen Sie source-aligned Authorization statt duplizierter Policy Logic. Nutzen Sie native Document-Level Security, wo die Plattform es unterstützt, Metadata Filtering bei einfachen stabilen Permissions und Fine-Grained Authorization Engines bei vererbten, relationship-basierten, tenant-spezifischen oder attribute-basierten Rechten. Guardrails und Redaction ergänzen Defense in Depth, aber Output Masking darf nicht die primäre Security Boundary sein.
Vor Produktion bauen Sie adversarial Evals, die belegen, dass unautorisierte Chunks nicht retrieved, zitiert, zusammengefasst, gecacht oder remembered werden. Testen Sie Gruppenänderungen, widerrufenen Zugriff, stale Indexes, Shared Folders, Mixed-Sensitivity-Dokumente, Tool Calls, Reranking, Streaming Responses und Conversation Continuation nach Access Changes.