Zugriff auf aufgelöste Kundendaten in einer RAG-Pipeline steuern: 6 Regeln für 2026

Kurzfassung: Eine aufgelöste Kundenidentität beantwortet, was der Retrieval-Schritt eines AI Agent finden kann. Sie beantwortet nicht, wem er diese Daten zeigen darf. Sechs Regeln trennen beide Fragen 2026: Binden Sie jedes Retrieval an die tatsächlichen Berechtigungen des Requesters, behandeln Sie den Namespace einer Vector Database als Isolation statt Authorization, begrenzen Sie bereits die Query, halten Sie die Enforcement Boundary in kontrollierter Infrastruktur, minimieren Sie den Prompt und protokollieren Sie, was warum abgerufen wurde.

Entscheiden Sie vor dem Modell, wer einen aufgelösten Datensatz sehen darf. Besprechen Sie das Zugriffsmodell mit unserem Team oder testen Sie rechtebeschränkte Abfragen an Ihren eigenen Daten. Demo buchen oder Tilores Studio kostenlos testen.

Auf dieser Seite

Warum steuert eine aufgelöste Kundenidentität nicht automatisch den Zugriff?
Regel 1: Welchen Berechtigungskontext muss jedes Retrieval tragen?
Regel 2: Reicht ein Namespace oder eine Tenant-Grenze aus?
Regel 3: Sollte Access Control die Query oder erst das Ergebnis filtern?
Regel 4: Wo sollte die Enforcement Boundary liegen?
Regel 5: Gilt Datenminimierung auch für den Prompt?
Regel 6: Was braucht ein Access Review zusätzlich zu üblichen RAG-Logs?
Wo Access Control greifen kann: sechs Vergleichspunkte

Warum steuert eine aufgelöste Kundenidentität nicht automatisch den Zugriff?

Entity Resolution beantwortet eine Frage: Welche fragmentierten Datensätze aus CRM, Support, Billing und Marketing beschreiben dieselbe Person? Wenn diese aufgelöste Identität in den Retrieval-Schritt eines AI Agent fließt, entsteht sofort eine zweite, unabhängige Frage: Welche der zusammengeführten Fakten darf die anfragende Person sehen? Ein Support-Chatbot mit Zugriff auf vollständige Kaufhistorie, Rechnungsstreitigkeiten und Churn-Risk-Flag in einem Profil kann mehr preisgeben als fünf getrennte Systeme. Gerade weil Resolution gut funktioniert, wächst der mögliche Schaden.

Das ist kein hypothetischer Randfall aus einem Sicherheitsanhang. Die OWASP Top 10 for LLM Applications führen das Problem unter Sensitive Information Disclosure. Sie warnen vor unbefugtem Datenzugriff, Datenschutzverletzungen und Verlust geistigen Eigentums, wenn die Daten, die das Modell erreichen, nicht selbst zugriffsgesteuert sind. Als Gegenmaßnahmen nennt OWASP strikte Access Controls nach dem Least-Privilege-Prinzip und eine begrenzte, sicher orchestrierte Auswahl externer Datenquellen. Die folgenden sechs Regeln übersetzen diese Forderung in eine umsetzbare Architektur für identity-aware RAG.

Regel 1: Welchen Berechtigungskontext muss jedes Retrieval tragen?

Ein Retrieval-Aufruf muss vor seiner Ausführung zwei Dinge kennen: Wer fragt, und was darf genau dieser Requester sehen? In vielen Agent-Architekturen ist beides nicht an die Query gebunden. Der Agent fordert alles zu Kunde 4471 an, der Resolution oder Retrieval Layer liefert sein gesamtes Wissen zurück und die Einschränkung erfolgt später, wenn überhaupt.

Die Lösung besteht darin, den Berechtigungskontext des Requesters als Parameter an den Retrieval-Aufruf zu hängen, zum Beispiel User-ID, Rolle und Zweck. Eine gut entworfene Anwendung lässt auch keine Datenbankabfrage ohne die zeilenbezogenen Rechte der aktuellen Session laufen. Wenn ein Retrieval Layer diesen Kontext nicht als Input ausdrücken kann, kann er ihn im Output nicht zuverlässig durchsetzen, unabhängig von der Qualität der Entity Resolution dahinter.

Vertrauen entsteht, wenn Berechtigung und Zweck die Query begleiten, nur notwendige Daten zusammengesetzt werden und die Zugriffsentscheidung nachvollziehbar bleibt.

Regel 2: Reicht ein Namespace oder eine Tenant-Grenze aus?

Vector Databases gelten oft als Lösung, weil sie Multi-Tenant-Isolation unterstützen. Pinecone partitioniert Datensätze innerhalb eines Index in Namespaces. Upserts, Queries sowie weitere Lese- und Schreiboperationen zielen immer auf genau einen Namespace. Die Dokumentation empfiehlt einen Namespace pro Kunde, um Kundendaten voneinander zu isolieren. Weaviate verfolgt auf Storage-Ebene einen ähnlichen Ansatz: Multi-Tenancy teilt den Cluster in Shards, wobei jeder Shard die Daten eines einzelnen Tenant enthält.

Beide Mechanismen sind wertvoll, lösen aber ein anderes Problem. Namespace und Tenant-Shard verhindern, dass Daten von Kunde A in einer Query von Kunde B auftauchen. Sie sagen nichts darüber aus, ob ein bestimmter Supportmitarbeiter, Sales Rep oder AI Assistant innerhalb des Tenant von Kunde A eine konkrete Rechnungsstreitigkeit oder ein Churn-Flag sehen darf. Das ist eine Berechtigungsfrage innerhalb eines Tenant, keine Grenze zwischen Tenants. Eine Vector Database beantwortet sie nicht automatisch.

Regel 3: Sollte Access Control die Query oder erst das Ergebnis filtern?

Die GraphQL API von Tilores zeigt konkret, wie eine frühe Begrenzung aussehen kann. Einzelne Schemafelder können eine @hasPrivilege-Direktive tragen, zum Beispiel myCustomField: String! @hasPrivilege(privilege: "tilores/record.myCustomField"). Ein OAuth Client kann die Privilegien eines Tokens zugleich auf die Felder einschränken, die ein bestimmter Aufrufer erreichen darf. Statt aller grundsätzlich erlaubten Rechte kann er beispielsweise nur den Scope tilores/query.search tilores/record.myCustomField anfordern. Beim Token Request lassen sich die angeforderten Privilegien also weiter verengen.

Dieser Mechanismus ist ein Baustein, kein automatischer Standard. Das implementierende Team muss Privilegien an die richtigen Felder binden und Tokens mit dem passenden engen Scope anfordern. Die Installation einer Resolution API erzeugt nicht automatisch einen individuellen Scope für jede Person, die über einen AI Agent fragt. Ob Retrieval-Aufrufe ein auf den Requester begrenztes Token oder ein breites gemeinsames Service-Credential verwenden, bleibt eine Anwendungsentscheidung.

Darum muss Access Control greifen, bevor die Query Daten zurückliefert, nicht erst als Filter auf einem vollständigen Ergebnis. Bei nachträglicher Filterung wurde das gesamte aufgelöste Profil bereits zusammengesetzt und war zumindest kurz in einer Prozessgrenze verfügbar, der die Berechtigungsprüfung vertrauen muss. Eine Query mit engem Token setzt die Rechnungsstreitigkeit für einen nicht berechtigten Supportmitarbeiter gar nicht erst zusammen. Dadurch entfällt eine ganze Klasse möglicher Leaks.

Enforcement Point	Vector-Database-Layer	Resolution oder API Layer	Application oder Agent Layer
Tenant-Isolation	Stark durch Design, etwa Pinecone Namespaces und Weaviate Multi-Tenancy	Abhängig von Deployment und Scope pro Kunde	Übernimmt die Grenze des aufgerufenen Layers
Feldbezogener Scope innerhalb eines Tenant	Nicht abgedeckt. Ein Namespace kennt keine Rollen.	Mit feldbezogenen Privilegien und engen OAuth Scopes möglich, etwa bei Tilores. Muss vom implementierenden Team konfiguriert werden.	Landet häufig standardmäßig hier und wird hier leicht vergessen.
Authorization Context zur Query-Zeit	Kein natives Konzept für die Rolle des Requesters	Kann als Parameter mitgegeben werden, wenn der Caller ihn liefert.	Hier liegen meist Session und Rolle des Nutzers.
Audit Trail des Retrieval	Query Logs, selten mit geschäftlicher Begründung verknüpft	Plattformabhängig. Tilores Scores erklären, warum ein Match zurückkam, nicht wer es sehen durfte.	Bester Ort, um Zweck und Identität gemeinsam zu protokollieren.
Physischer Speicherort	Am Hosting-Ort der Vector Database	Bei Tilores im eigenen AWS Account, bei vielen Alternativen in einer externen SaaS	Am Ausführungsort der Anwendung
Änderung einer Berechtigung	Über Administration des Vector-Database-Betreibers	Durch den Betreiber des Resolution-Layer-Deployments	Durch den Eigentümer von Anwendungscode und Session-Logik

Regel 4: Wo sollte die Enforcement Boundary liegen?

Eine Access-Control-Entscheidung ist nur so vertrauenswürdig wie die Infrastruktur, die sie durchsetzt. Bei einem externen SaaS-Dienst für Resolution oder Retrieval muss ein Kunde zusätzlich zu seinen konfigurierten Regeln auch Mitarbeitern, Incident-Historie und rechtlicher Situation des Anbieters vertrauen. Tilores beschreibt für die AWS-Account-Option eine andere Grenze: dieselbe Software läuft im eigenen AWS Account auf DynamoDB, SQS und S3 innerhalb der eigenen VPC. Die Daten verlassen die eigene Umgebung nicht und Tilores-Mitarbeiter können nicht auf die Datensätze zugreifen.

Das ersetzt die Regeln 1 bis 3 nicht. Es verändert den Ort ihrer Durchsetzung. Läuft der Resolution Layer in der eigenen VPC, werden Permission Checks in einer Infrastruktur ausgeführt, die das eigene Security-Team bereits prüft. Laut Deployment-Seite ist das keine reduzierte Edition ohne bestimmte Funktionen. Die Entscheidung für eine interne Enforcement Boundary verlangt daher keinen Verzicht auf Fähigkeiten.

Regel 5: Gilt Datenminimierung auch für den Prompt?

Viele Programme zur Datenminimierung enden beim Storage: Datenbank verschlüsseln, Query-Rechte begrenzen und Datensätze nur so lange wie nötig aufbewahren. Artikel 5 der DSGVO endet dort nicht. Personenbezogene Daten müssen dem Zweck angemessen und erheblich sowie auf das notwendige Maß beschränkt sein. Sie dürfen nur für festgelegte, eindeutige und legitime Zwecke verarbeitet werden.

Ein Prompt, der aus einem aufgelösten Kundenprofil zusammengesetzt wird, ist in diesem Sinne bereits Verarbeitung. Jedes Feld in das Context Window zu laden, nur weil eine Resolution API es liefern kann, ist die RAG-Variante unnötiger Datensammlung. Der Zweck der konkreten Kundeninteraktion muss bestimmen, welche aufgelösten Felder den Prompt überhaupt erreichen.

Regel 6: Was braucht ein Access Review zusätzlich zu üblichen RAG-Logs?

Standardlogs erfassen, wer wann welche Query gestellt hat. Ein Access Review nach einem Incident, einer Kundenbeschwerde oder einer regulatorischen Frage braucht ein drittes Element: Warum war dieses Retrieval erlaubt? Dazu gehören die Permission Rule, die gegriffen hat, und der Zweck, der den Zugriff rechtfertigte. Ohne dieses Element muss ein Team Monate später den damaligen Berechtigungszustand rekonstruieren. Nach Änderungen an Rollen und Regeln ist das häufig unmöglich.

Wenn Score der aufgelösten Entität und Permission Decision im Moment des Retrieval gemeinsam protokolliert werden, wird die spätere Rekonstruktion zu einer Abfrage. Gleichzeitig entsteht ein Feedback Loop für die Regeln 1 bis 3. Wiederkehrende Near Misses, bei denen ein Requester ein nicht erlaubtes Feld beinahe gesehen hätte, zeigen früh, wo eine Regel verschärft werden muss.

Access Control in eine bestehende identity-aware RAG-Pipeline einbauen

Keine dieser sechs Regeln verlangt eine neue Resolution-Plattform oder den Neubau einer funktionierenden RAG-Pipeline. Sie verlangen einen Berechtigungskontext an jedem Retrieval-Aufruf, eine klare Trennung von Tenant-Isolation und Authorization, Query-Zeit-Scoping statt nachträglicher Filterung, eine Enforcement Boundary in kontrollierter Infrastruktur, Datenminimierung im Prompt und ein Log, das nicht nur den Zugriff, sondern auch seine Begründung festhält.

Der vollständige Leitfaden zu IdentityRAG erklärt, wie aufgelöste Identitäten verbessern, was ein Agent findet. Der Beitrag über Entity-Resolution-basiertes RAG in regulierten Branchen behandelt den Genauigkeitsgewinn durch Resolution vor dem Retrieval. Beide setzen voraus, was dieser Artikel ausdrücklich trennt: Identität zuverlässig aufzulösen ist notwendig, aber es ist nicht dasselbe wie zu entscheiden, wer die aufgelösten Daten sehen darf.

FAQ

Was bedeutet Access Control in einer RAG-Pipeline?

Access Control entscheidet vor dem Retrieval, welche aufgelösten Daten ein bestimmter menschlicher Requester oder ein in seinem Auftrag handelnder AI Agent sehen darf. Sie ist von Entity Resolution getrennt, denn Resolution bestimmt, welche Daten zu einer Person gehören, nicht wer sie ansehen darf.

Übernehmen Pinecone oder Weaviate die Access Control automatisch?

Pinecone und Weaviate unterstützen Tenant-Isolation, nicht automatisch Berechtigungen pro Nutzer innerhalb eines Tenant. Namespaces und Tenant Shards verhindern Zugriffe zwischen Kunden. Eine rollen- und feldbezogene Permission-Schicht muss separat aufgebaut werden.

Kann Tilores einschränken, welche Felder ein API Caller sieht?

Die GraphQL API von Tilores unterstützt feldbezogene Access Control über @hasPrivilege-Direktiven. OAuth Clients können Tokens auf bestimmte Privilegien einschränken. Das implementierende Team muss diese Mechanismen an Feldern konfigurieren und pro Requester einen passenden engen Scope anfordern.

Was verlangt die DSGVO, wenn aufgelöste Kundendaten in einen AI-Agent-Prompt fließen?

Artikel 5 verlangt, personenbezogene Daten auf das für einen festgelegten Zweck notwendige Maß zu begrenzen. Für RAG bedeutet das, dass nur die Felder in den Prompt gehören, die die aktuelle Aufgabe benötigt, nicht das gesamte aufgelöste Kundenprofil.

Sollte Access Control im Vector Store, im Resolution Layer oder in der Anwendung liegen?

Alle drei Ebenen haben unterschiedliche Rollen. Vector Store und Resolution Layer eignen sich für Tenant-Isolation und feldbezogenes Query Scoping. In der Anwendung liegen meist Session, Rolle und Zweck des Nutzers. Sie muss diesen Kontext an das Retrieval übergeben und die Begründung des Zugriffs protokollieren.

Quellen

LLM02:2025 Sensitive Information Disclosure, OWASP Gen AI Security Project, geprüft am 26. August 2026.
Indexing overview: namespaces and metadata filtering, Pinecone Documentation, geprüft am 26. August 2026.
Data structure and multi-tenancy, Weaviate Documentation, geprüft am 26. August 2026.
Art. 5 GDPR: Principles relating to processing of personal data, General Data Protection Regulation, geprüft am 26. August 2026.
API Reference, Tilores Documentation, geprüft am 26. August 2026.
Authorization, Tilores Documentation, geprüft am 26. August 2026.
Deployment Options: Run Tilores Where Your Data Is, Tilores, geprüft am 26. August 2026.
IdentityRAG: The Complete Guide to Identity-Aware Retrieval-Augmented Generation (2026), Tilores, geprüft am 26. August 2026.
Improving LLM Accuracy in Regulated Industries with Entity-Resolution-Based RAG (EntityRAG), Tilores, geprüft am 26. August 2026.