Multi-Tenant RAG ohne Datenleck: Chunk-Tagging vs Request-Filter

Pexon Consulting | 11 Min. Lesezeit | 15.06.2026

TL;DR

Multi-Tenant RAG ohne Permission-Layer ist BaFin-Risiko: Ein Chunk aus dem falschen Mandant im Treffer kann meldepflichtiger Vorfall sein. Pexon Consulting baut Banking-konforme RAG-Setups als 4-6-Wochen-Sprint mit Defense-in-Depth — Chunk-Tagging plus Request-Filter im Auth-Layer plus Datenbank-seitige Enforcement. Erfahrung aus 14+ produktiven Setups bei Banken und Versicherern.

Warum Multi-Tenant RAG im Banking besonders kritisch ist

Wir hören das in fast jedem CISO-Erstgespräch bei Banken und Versicherern, die RAG-Workloads produktiv bringen wollen: „Wenn ein User aus Mandant A ein Dokument aus Mandant B in seinem Antworttext sieht, ist das ein BaFin-Vorfall.“ Die Aussage ist korrekt und sie verschärft die Architektur-Anforderungen erheblich.

In klassischen Backend-Systemen wird Multi-Tenant-Isolation primär über Row-Level Security in der Datenbank gelöst — jede SQL-Query bekommt automatisch einen Tenant-Filter, die DB verweigert Zugriff auf andere Tenants. RAG-Systeme haben dieses Pattern strukturell nicht. Der Retrieval-Lauf holt Vektoren aus einer Vector-DB, die semantisch ähnlichste Treffer liegen oben — und ohne explizite Tenant-Filterung können diese Treffer aus beliebigen Mandanten kommen.

Bei einem Versicherungs-Pilotkunden haben wir das Risiko quantifiziert: In einem ungeschützten Setup mit 47 Mandanten und semantisch ähnlichen Versicherungs-Dokumenten lag die Wahrscheinlichkeit, dass die Top-5-Retrieval-Treffer mindestens einen falschen Tenant enthalten, bei 23-31% pro Anfrage. Bei 8.000 Anfragen pro Tag sind das 1.840-2.480 potenzielle Datenleck-Vorfälle täglich. Mehr zum grundlegenden Pattern für saubere Retrieval-Pipelines.

Strikte Multi-Tenant-Isolation ist also nicht Nice-to-have, sondern strukturelle Compliance-Voraussetzung.

Ansatz 1: Chunk-Tagging im Vector-Store

Der einfachere Ansatz. Jeder Chunk bekommt beim Indexieren eine tenant_id als Metadata. Beim Retrieval wird die Tenant-ID des aufrufenden Users als Filter mitgegeben.

# Indexierung
vectorstore.add_documents([
    Document(
        page_content=chunk_text,
        metadata={"tenant_id": "mandant_4711", "doc_id": "doc_42"}
    )
])

# Retrieval mit Filter
results = vectorstore.similarity_search(
    query=user_query,
    k=5,
    filter={"tenant_id": current_user_tenant_id}
)

Vorteile: Einfache Implementierung, geringer Performance-Overhead (Vector-DBs wie pgvector, Qdrant, Azure AI Search unterstützen Metadata-Filter nativ), klare Audit-Spur.

Nachteile: Der Filter steht im Application-Code. Wenn ein Engineer beim Schreiben einer neuen Retrieval-Funktion den Filter vergisst, fließen Daten aus allen Mandanten ohne Warnung. Bei größeren Engineering-Teams ist diese Fehlerklasse real.

Sweet-Spot: Single-Application-Setups mit kleinem Engineering-Team, niedrigerer Compliance-Stufe, moderate Mandanten-Anzahl. Nicht ausreichend für Banking-Tier-1.

Ansatz 2: Request-Filter im Auth-Layer

Der robustere Ansatz. Der Filter wird nicht im Application-Code gesetzt, sondern im Retrieval-Service erzwungen — durchgesetzt über ein Auth-Token, das die Tenant-ID als unveränderbaren Claim enthält.

# Im Retrieval-Service (MCP-Server oder API-Gateway)
@app.post("/retrieve")
async def retrieve(query: str, request: Request):
    # Token validieren — Tenant-ID ist Pflicht-Claim
    token = request.headers.get("Authorization").split(" ")[1]
    claims = jwt.decode(token, jwks=JWKS_URL, audience="rag-api")
    
    tenant_id = claims.get("tenant_id")
    if not tenant_id:
        raise HTTPException(403, "Token missing tenant_id claim")
    
    # Filter wird ZWINGEND aus Token gesetzt, nicht aus Parametern
    results = vectorstore.similarity_search(
        query=query,
        k=5,
        filter={"tenant_id": tenant_id}
    )
    
    audit_log.write({
        "user": claims["email"],
        "tenant_id": tenant_id,
        "query_hash": hashlib.sha256(query.encode()).hexdigest(),
        "result_doc_ids": [r.metadata["doc_id"] for r in results]
    })
    
    return results

Vorteile: Tenant-ID kommt aus dem Auth-Token, kann vom Anwendungs-Code nicht versehentlich überschrieben werden. Bei falscher Konfiguration wird die Anfrage abgelehnt, nicht falsch beantwortet. Audit-Trail ist strukturell vollständig. Pattern ist verwandt zum User-Identity-Propagation-Setup mit On-Behalf-Of-Flow.

Nachteile: Setup-Komplexität deutlich höher. Token-Management, JWKS-Konfiguration, Multi-System-Identity-Propagation müssen sitzen. Bei einem zusätzlichen Hop (App → Gateway → RAG-Service → Vector-DB) muss die Tenant-ID konsistent durchgereicht werden.

Sweet-Spot: Multi-System-Setups mit klarer Auth-Architektur, regulierte Branchen mit Audit-Pflicht, größere Engineering-Teams.

Defense-in-Depth: das Pexon-Standard-Pattern für Banking

Bei Banking-Tier-1 und Versicherer-Setups bauen wir konsequent beide Ansätze kombiniert. Ein einzelner Layer ist gegen Engineering-Bugs nicht resilient genug.

Schicht 1: Chunk-Tagging beim Indexieren. Jeder Chunk bekommt tenant_id, data_classification, owner_team als Metadata. Damit liegt die Trennung schon im Index vor.

Schicht 2: Tenant-ID aus Auth-Token zwingend erforderlich. Retrieval-Service nimmt Tenant-ID NUR aus dem validierten JWT-Claim. Anwendungs-Parameter werden ignoriert. Bei fehlendem Token-Claim wird die Anfrage abgelehnt.

Schicht 3: Datenbank-seitige Enforcement (RLS oder Equivalent). Bei pgvector als Vector-Store nutzen wir Postgres Row Level Security: Jede Query bekommt automatisch einen Tenant-Filter, die DB verweigert Zugriff auf andere Tenants — auch wenn der Anwendungs-Code Bug hat. Bei Azure AI Search arbeiten wir mit dedizierten Indizes pro Tenant für die höchste Sensitivitäts-Klasse. Mehr zur Vector-DB-Wahl für Multi-Tenant-Setups.

Schicht 4: Output-Validation. Vor jeder Antwort prüft der Service, dass alle Chunks im Treffer-Set den gleichen Tenant haben. Bei Mismatch wird die Antwort blockiert und der Vorfall in den Security-Audit-Trail geschrieben.

Vier Schichten klingen nach Overkill — sie sind die strukturelle Antwort auf „Ein Bug in einer Schicht darf nie zum Datenleck führen.“ Bei einem Banking-Pilotkunden haben die Schicht-Defense-Mechanismen in 18 Monaten produktiven Betrieb zwei Engineering-Bugs gefangen, die in einem Single-Layer-Setup zu Vorfällen geführt hätten.

Audit-Trail und Detection

Ohne lückenlosen Audit-Trail ist Defense-in-Depth nur die halbe Antwort. Pexon-Standard-Logging-Pattern.

Pro Retrieval-Request: Timestamp, User-Identity aus Token, Tenant-ID aus Token, Query-Hash (nicht der Volltext bei sensiblen Anfragen), Top-K-Doc-IDs der Treffer, Tenant-IDs der Treffer, Final-Output-Hash. Damit ist im Nachhinein nachvollziehbar, was wer wann gesehen hat.

Anomalie-Detection: Wenn Treffer mit tenant_id != user.tenant_id zurückgegeben werden, wird das als kritischer Sicherheits-Vorfall im SIEM markiert. Bei mehr als 0 solchen Vorfällen pro Woche läuft eine Incident-Response-Pipeline an.

Quartals-Audit-Report: Aggregierte Sicht für den CISO. Anzahl Anfragen pro Mandant, Anteil Anfragen mit Permission-Verweigerung, mittlere Latenz, Anomalie-Indikatoren. Mehr zum strukturierten Compliance-Reporting in AI-Workloads.

Pexon-Sprint für Multi-Tenant RAG

Wir liefern den vollständigen Defense-in-Depth-Setup als 4-6-Wochen-Sprint mit klarem Compliance-Outcome.

Wochen 1-2: Architektur-Workshop mit CISO und Engineering-Lead, Datenklassifikations-Inventur, Auth-Token-Design, Vector-DB-Architektur-Entscheidung (mehr dazu im Vector-DB-Vergleich pgvector vs Azure AI Search).

Wochen 3-4: Implementierung der vier Defense-Schichten, Audit-Trail-Pipeline in eurem SIEM, Anomalie-Detection-Regeln.

Wochen 5-6: Penetration-Test-Setup mit synthetischen Cross-Tenant-Anfragen, Compliance-Doku für euer internes Audit, Übergabe an Engineering-Team.

Investment 65-110k EUR Sprint-Festpreis je nach Komplexität (Anzahl Mandanten, Vector-DB-Wahl, SIEM-Integration). Bei Banking-Tier-1-Kunden tendenziell am oberen Ende.

Häufig gestellte Fragen

Reicht nicht ein dedizierter Vector-Index pro Tenant?

Bei kleiner Mandanten-Anzahl (< 20) ja. Bei größerer Anzahl wird Index-Management aufwändig, plus Re-Indexierungs-Kosten steigen linear. Wir bauen ab 30+ Mandanten typisch Shared-Index mit Filter-Pattern. Bei Banking-Tier-1 mit < 10 strategischen Mandanten oft dedizierter Index plus Filter-Pattern als Doppelschutz.

Wie verhalten sich Vector-DBs strukturell bei Metadata-Filtern?

pgvector unterstützt Metadata-Filter über klassische SQL-WHERE-Klausel — performant bis 5-10M Chunks. Qdrant hat dedizierte Filter-Pipeline mit guter Performance. Azure AI Search filtert nativ über OData-Syntax. Bei sehr hohen Volumen kann der Filter zu Performance-Engpässen führen — dann lohnen sich gestaffelte Indizes pro Tenant-Gruppe.

Was bei Embeddings, die User-Personalisierung enthalten?

Sehr sensible Konstellation. Wenn der Embedding-Vector personalisierte Inhalte enthält, kann auch reine Vector-Suche ohne Metadata-Filter zu Inferenzen führen. Wir empfehlen für solche Setups User-spezifische Sub-Indizes plus Cross-User-Output-Validation. Aufwändiger, aber strukturell die einzige saubere Antwort.

Wie reagiert die BaFin auf RAG-Multi-Tenant-Setups?

BaFin hat keine spezifische RAG-Position, fordert aber im Banking-Audit klare Daten-Isolations-Nachweise. Defense-in-Depth mit dokumentiertem Audit-Trail plus Penetration-Test-Ergebnisse hat in unseren Banking-Kunden den BaFin-Audit zuverlässig getragen. Single-Layer-Setups ohne Audit-Trail werden in Audits beanstandet.

Wer ist im Vorfall haftbar?

Compliance-Mäßig die Geschäftsleitung des datenverarbeitenden Unternehmens. Engineering-mäßig die Engineering-Verantwortung im Team. Vertraglich mit dem Cloud-Anbieter (Microsoft, AWS) liegt das Restrisiko bei euch, weil die Multi-Tenant-Architektur eure Verantwortung ist. Pexon haftet vertraglich für Engineering-Qualität im Setup-Sprint, nicht für laufende Operations — diese kann optional als Managed Service zukommen. compliance für cloud & ki, die euer business nicht ausbremst — sondern

Nächster Schritt

Wenn dein Banking- oder Versicherungs-Unternehmen Multi-Tenant RAG produktiv bringt und Audit-Trail sowie Defense-in-Depth braucht: Wir machen einen 60-Minuten-Architektur-Call mit dir und idealerweise dem CISO. Du beschreibst die Mandanten-Struktur und Compliance-Anforderungen, wir skizzieren den Sprint-Festpreis.

Verwandte Themen