KI-Bedrohungskatalog Datenschutz und Datenabfluss Produktion
Cross-Tenant-Leakage (Multi-Tenant Vector-DB)
Bei KI-Plattformen, die mehrere Kunden auf gemeinsamer Infrastruktur bedienen, können Daten des einen Kunden in den Antworten eines anderen auftauchen, wenn die Mandantentrennung im gemeinsamen Wissensspeicher lückenhaft ist.
Beschreibung
Viele KI-Anwendungen schlagen Wissen per RAG (Retrieval Augmented Generation, dem Nachschlagen in einer angebundenen Wissensbasis) nach und speichern Texte dafür als Zahlenfolgen (Embeddings) in einer Vektordatenbank. Bedient eine Plattform mehrere Mandanten, also Kunden oder Abteilungen auf derselben Infrastruktur, müssen Filter und Berechtigungen bei jeder Anfrage sauber trennen, wessen Dokumente durchsucht werden. Fehlen diese Filter oder sind Speicherbereiche falsch konfiguriert, liefert die Suche eines Mandanten Textabschnitte eines anderen zurück, und das Modell webt sie in seine Antwort ein. Das geschieht teils schon im Normalbetrieb; Angreifer provozieren es mit gezielten Anfragen. Embeddings selbst schützen nicht, denn der Ursprungstext lässt sich daraus weitgehend rekonstruieren.
Mögliche Auswirkung
Vertrauliche Unterlagen eines Kunden werden gegenüber einem anderen offengelegt; das verletzt vertragliche Vertraulichkeitszusagen und bei personenbezogenen Daten die DSGVO, inklusive Meldepflichten und Bußgeldrisiko. Für die betroffenen Personen bedeutet das: Ihre Daten gelangen an unbefugte Dritte. Für den Betreiber steht das Kundenvertrauen in die gesamte Plattform auf dem Spiel.
Beispiel
Ein Software-Anbieter betreibt einen KI-Assistenten für viele Firmenkunden auf einer gemeinsamen Vektordatenbank. Ein fehlender Mandantenfilter führt dazu, dass die Frage eines Kunden nach Vertragskonditionen Passagen aus dem hochgeladenen Vertrag eines anderen Kunden in die Antwort holt.
Empfohlene Gegenmaßnahmen (6)
Vergleichen Sie Wirkung und Umsetzungsebene. Die ergänzende Einordnung und Begründung können Sie bei Bedarf aufklappen.
-
Strenge Tenant-Isolation in der Vector-DB
Technisch- Wirkung
- Präventiv, Schadensbegrenzend
- Umsetzungsebene
- Daten, Infrastruktur
Einordnung und Begründung
Primär technisch: Architektur- und Laufzeitgrenzen trennen Daten, Ausführung oder Mandanten und begrenzen die Fehlerausbreitung.
-
Tenant-spezifische Namespaces / Partitionen
Technisch- Wirkung
- Präventiv, Schadensbegrenzend
- Umsetzungsebene
- Daten, Infrastruktur
Einordnung und Begründung
Primär technisch: Architektur- und Laufzeitgrenzen trennen Daten, Ausführung oder Mandanten und begrenzen die Fehlerausbreitung.
-
Query-Scoping zum Retrieval-Zeitpunkt
Technisch- Wirkung
- Präventiv
- Umsetzungsebene
- Daten, Anwendung, API & Agenten
Einordnung und Begründung
Primär technisch: Maschinell erzwungene Identitäts-, Berechtigungs- oder Bereichsregeln begrenzen unzulässige Zugriffe und Aktionen.
-
Verschlüsselung at rest pro Tenant
Technisch- Wirkung
- Präventiv, Schadensbegrenzend
- Umsetzungsebene
- Daten, Infrastruktur
Einordnung und Begründung
Primär technisch: Kryptografische oder maschinenprüfbare Merkmale sichern Vertraulichkeit, Integrität oder Herkunft.
-
Zugriffskontroll-Tests tenantübergreifend
Technisch- Wirkung
- Aufdeckend
- Umsetzungsebene
- Daten, Anwendung, API & Agenten, Infrastruktur, Nutzung & Betrieb
Einordnung und Begründung
Ergänzende MaßnahmenartOrganisatorisch & prozessual
Primär technisch: Software oder Analysewerkzeuge erzeugen und bewerten systematisch Messwerte, Abweichungen oder Angriffsindikatoren; ergänzt durch verbindliche Abläufe.
-
Audit-Logs für Retrieval-Operationen
Technisch- Wirkung
- Aufdeckend
- Umsetzungsebene
- Daten, Anwendung, API & Agenten, Nutzung & Betrieb
Einordnung und Begründung
Ergänzende MaßnahmenartOrganisatorisch & prozessual
Primär technisch: Software oder Analysewerkzeuge erzeugen und bewerten systematisch Messwerte, Abweichungen oder Angriffsindikatoren; ergänzt durch verbindliche Abläufe.
Standard-Zuordnungen
Verifizierte Fundstellen in OWASP, NIST AI RMF, MITRE ATLAS, EU AI Act und weiteren Rahmenwerken. Die Zuordnungen zeigen fachliche Bezüge. Sie belegen nicht, dass ein System die jeweiligen Anforderungen erfüllt.
Belegte Referenzen (10)
Jede Referenz nennt Rahmenwerk, Fundstelle und die herausgebende Organisation.
- OWASP LLM Top 10 LLM02:2026 Sensitive Information DisclosureLLM02:2026 Sensitive Information Disclosure, OWASP Top 10 for LLM Applications 2026 v1.0, pp. 18-22 (doi:10.5281/zenodo.22109015); canonical text 2026/final/LLM02_SensitiveInformationDisclosure.md at commit 7e144e05 OWASP FoundationOriginal
- OWASP LLM Top 10 LLM09:2026 Vector and Embedding WeaknessesLLM09:2026 Vector and Embedding Weaknesses, OWASP Top 10 for LLM Applications 2026 v1.0, pp. 50-54 (doi:10.5281/zenodo.22109015); canonical text 2026/final/LLM09_VectorAndEmbeddingWeaknesses.md at commit 7e144e05 OWASP FoundationOriginal
- NIST AI RMF MEASURE 2.10 MEASURE 2.10MEASURE 2.10, p. 30 National Institute of Standards and Technology (NIST)Original
- NIST AI RMF NISTAML.015 Indirect Prompt InjectionTaxonomy Index, pp. x–xi; Abschnitt 3.4, pp. 50–53; Glossary, p. 110 National Institute of Standards and Technology (NIST)Original
- NIST AI RMF NISTAML.036 Leaking information from user interactionsTaxonomy Index, p. xi; Abschnitt 3.4.3, pp. 52–53 National Institute of Standards and Technology (NIST)Original
- MITRE ATLAS AML.T0025 Exfiltration via Cyber MeansATLAS-2026.09.yaml technique object with id AML.T0025 (content release 2026.09, format-version 6.0.0) MITREOriginal
- MITRE ATLAS AML.T0057 LLM Data LeakageATLAS-2026.09.yaml technique object with id AML.T0057 (content release 2026.09, format-version 6.0.0) MITREOriginal
- EU AI Act Article 9(1), 9(2)(a), 9(2)(d) Risk management systemArticle 9(1), 9(2)(a), 9(2)(d), read with Article 9(3) European Union (EUR-Lex)Original
- DSGVO Article 25(1)–(2) Data protection by design and by defaultArticle 25(1) and 25(2) European Union (EUR-Lex)Original
- BSI R23 Embedding Inversion (Text, Bild, Video)Kap. 4, R23, p. 28 Bundesamt für Sicherheit in der Informationstechnik (BSI)Original
Pflichten der KI-Verordnung zu dieser Bedrohung
Die Pflichten aus dem Pflichtenkompass, deren Artikel der Katalog dieser Bedrohung zuordnet. Jede führt auf ihren Eintrag mit Kern, Handlungsschritt und Nachweis; ob sie Sie trifft, hängt von Rolle und Risikoklasse ab.
-
Risikomanagementsystem einrichten und betreiben
Art. 9 · gilt ab Anhang III: 2. Dezember 2027 · Anhang I: 2. August 2028
Gesetzliche Rollen: Anbieter, Produkthersteller. Klassen: Hochrisiko nach Anhang III, Hochrisiko als Produkt oder Sicherheitsbauteil.
Der Verweis ist ein Prüfanlass. Ein Bedrohungstreffer allein begründet keine Anwendbarkeit.
Alle 62 Pflichten nach Rolle, Risikoklasse und Frist im Pflichtenkompass
Begriffe auf dieser Seite
Fachbegriffe aus dem Glossar, die in diesem Eintrag vorkommen. Jeder Verweis führt zur vollständigen Erklärung.
- RAG (Retrieval Augmented Generation) Das System ruft passende Inhalte ab und gibt sie dem Modell als Antwortkontext.
- Embeddings (Einbettungen) Zahlenvektoren, mit denen Inhalte für Ähnlichkeitssuchen dargestellt werden.
Verwandte Bedrohungen
Weitere Einträge aus der Themengruppe Datenschutz und Datenabfluss.
Passende Anwendungsfälle
Die Liste zeigt, wo Sie diese Bedrohung prüfen, nicht wie hoch das Risiko ist.
Besonders wichtig bei:
- KI-Assistent in BüroanwendungenIn der Dateiablage sind Ordner mit Personal- oder Vorstandsunterlagen versehentlich für alle freigegeben. Der Assistent findet sie und gibt ihren Inhalt an jeden weiter, der danach fragt.
- Polizeiliche Datenanalyse (Analyseplattformen)Die Plattform legt Daten aus Verfahren zusammen, auf die nicht jede Ermittlerin zugreifen darf. Greift die Rechteprüfung bei Suche oder Graph nicht, sieht sie Personen und Vorgänge aus fremden Verfahren.
Bei 6 weiteren Anwendungsfällen hängt es vom Aufbau des Systems ab, etwa davon, ob es Dokumente mehrerer Berechtigungsgruppen in einem Suchspeicher hält oder eine eigene Sammlung von Dokumenten durchsucht. Diese Anwendungsfälle zeigen
Häufige Fragen
- Worum geht es bei dieser Bedrohung?
- Bei KI-Plattformen, die mehrere Kunden auf gemeinsamer Infrastruktur bedienen, können Daten des einen Kunden in den Antworten eines anderen auftauchen, wenn die Mandantentrennung im gemeinsamen Wissensspeicher lückenhaft ist.
- Welche Gegenmaßnahmen nennt der Katalog?
- Der Katalog nennt 6 Gegenmaßnahmen, jede mit Maßnahmenart, Wirkung und Umsetzungsebene. Beispiele sind: Strenge Tenant-Isolation in der Vector-DB, Tenant-spezifische Namespaces / Partitionen und Query-Scoping zum Retrieval-Zeitpunkt. Die Reihenfolge ist keine Priorisierung.
- Welche Pflichten der KI-Verordnung können relevant sein?
- Der Katalog ordnet diese Bedrohung Art. 9 der EU-KI-Verordnung zu. Daraus folgen im Pflichtenkompass: Risikomanagementsystem einrichten und betreiben. Ob eine Pflicht gilt, entscheiden Rolle, Risikoklasse und Frist.
Diese Bedrohung im eigenen System bewerten
Die Live-Demo enthält alle 52 Bedrohungen dieses Katalogs sowie die Einordnung nach der EU-KI-Verordnung und die Datenschutzprüfung. Die kostenlosen Einzelmodule decken KI-Risiko, EU-KI-VO und DSGVO ab. Ohne Registrierung; die Bewertung läuft lokal in Ihrem Browser.
Diesen Eintrag zitieren
Für Berichte, Richtlinien oder interne Unterlagen; der Link führt direkt auf diesen Eintrag.
„Cross-Tenant-Leakage (Multi-Tenant Vector-DB)“. Versatile AI Risk Assessment, KI-Bedrohungskatalog, Stand Oktober 2026. https://www.versatile-ai-risk-assessment.com/wissensbasis/bedrohungen/cross-tenant-leakage/