Vector and Embedding Weaknesses
- Memory / Zustand
- Tools & externe Daten
Die Embedding-Schicht, die entscheidet, was das Modell zu sehen bekommt — Vektorspeicher, Ähnlichkeitssuche, semantische Caches —, wird über ihre Geometrie angegriffen: vergiftete Vektoren, Rückschlüsse über Mandantengrenzen hinweg, Inversion oder blockiertes Retrieval.
Was es ist
Jede Anwendung, die Text, Bilder, Code oder Audio in Vektoren umwandelt und per Ähnlichkeitssuche entscheidet, was in den Prompt gelangt, macht die Embedding-Schicht zu einem Teil ihrer Vertrauensgrenze. Das bekannteste Beispiel ist Retrieval-Augmented Generation, es gilt aber ebenso für vektorgestütztes Agenten-Memory, semantische Caches und Deduplizierung. Diese Schwachstellen unterscheiden sich von Prompt Injection: Sie nutzen die Geometrie des Embedding-Raums aus, und viele gelingen, obwohl der abgerufene Inhalt gar keine Anweisung enthält. OWASP fasst es knapp: Poisoning macht das System falsch, Inversion lässt es Daten preisgeben, Jamming lässt es verstummen, und fehlende Zugriffskontrolle macht es wahllos.
Zwei Tatsachen sind im Betrieb entscheidend. Die Ähnlichkeitssuche läuft oft über den ganzen Index, bevor ein Zugriffsfilter auf Anwendungsebene greift. Trefferzahlen, Scores und Antwortzeiten verraten so, was andere Mandanten gespeichert haben. Und moderne Inversion rekonstruiert große Teile des Ausgangstexts aus gespeicherten Vektoren. Ein Leck, bei dem „nur Embeddings“ abfließen, ist also ein Leck der Quelldokumente.
Ein Multi-Agenten-System, das einen Vektorindex oder Memory-Speicher über Agenten oder Mandanten hinweg teilt, vergrößert die Angriffsfläche für Poisoning und für Offenlegung zugleich: Alles, was die Ingestion-Pipeline eines Agenten einbettet, wird für jede andere Abfrage gegen diesen Index abrufbar, sofern der Zugriff nicht innerhalb der Suche selbst partitioniert ist.
Arten
- Mandantenübergreifendes Leck über geteilte Suche
- Die Zugriffsentscheidung fällt erst nach der Suche im Embedding-Raum. Gezielte Abfragen verraten so, dass Dokumente eines anderen Mandanten existieren und worum es darin geht.
- Embedding-Inversion
- Ein Angreifer rekonstruiert Quellinhalte aus exportierten, gesicherten oder offengelegten Vektoren.
- Poisoning beim Retrieval
- Inhalte, deren Embedding gezielt nahe an einer Zielabfrage landet, werden abgerufen und dem Modell als vertrauenswürdiger Kontext übergeben.
- Retrieval-Jamming
- Ein „Blocker“-Dokument, das gezielt für eine Abfrage abgerufen wird, bringt das Modell dazu, die Antwort zu verweigern oder fehlende Informationen zu behaupten — ein Angriff auf die Verfügbarkeit, ganz ohne bösartige Anweisung.
- Poisoning des semantischen Caches
- Inhalte, die knapp jenseits einer Ähnlichkeitsschwelle liegen, liefern jeder gleichwertigen Abfrage den Text des Angreifers — oder sorgen dafür, dass legitime Inhalte als Duplikat verworfen werden.
Angriffsszenarien
In einem mandantenübergreifenden Support-System rankt das platzierte Dokument eines Mandanten hoch für die themenfremde Anfrage eines anderen Mandanten und lässt so mandantenfremde Inhalte in die Antwort einfließen.
Versteckte Anweisungen in einem Lebenslauf
Ein Angreifer reicht einen Lebenslauf mit Anweisungen in weißem Text auf weißem Hintergrund ein. Eine RAG-basierte Screening-Pipeline nimmt ihn ungefiltert auf und folgt später der versteckten Anweisung, wenn jemand nach dem Kandidaten fragt.
Mandantenübergreifendes Abtasten
In einer geteilten Vektordatenbank, die erst auf Anwendungsebene filtert, verraten die gezielten Abfragen eines Mandanten über Trefferzahlen und Score-Abstände, dass Inhalte eines anderen Mandanten existieren und worum es darin geht.
Invertiertes Vektor-Backup
Eine Fehlkonfiguration legt ein Backup der Vektordatenbank offen. Der Vorfall wird als geringfügig eingestuft, weil „nur die Embeddings geleakt sind“ — bis eine Zero-Shot-Inversion die Kundengespräche dahinter rekonstruiert.
Abwehrmaßnahmen
- Innerhalb der Abfrage eingrenzen
- Zugriff auf Mandanten- und Chunk-Ebene innerhalb der Index-Suche durchsetzen und serverseitig prüfen, und für sensible Workloads getrennte Indizes pro Mandant oder Vertrauensstufe nutzen, gemäß Semantic / Vector / Graph Memory.
- Vor der Aufnahme validieren und Herkunft festhalten
- Inhalte normalisieren (Zeichen ohne Breite, versteckten Text und Homoglyphen entfernen), für jedes Embedding Quelle und Vertrauensstufe erfassen und das Embedding-Modell selbst prüfen — die Rolle des Integrators für Retrieval.
- Kein Orakel bieten
- Nie rohe Ähnlichkeitsscores an Clients zurückgeben, die Rate für Embedding- und Such-Endpunkte begrenzen und neue Vektoren markieren, die ungewöhnlich nah an vielen häufigen Abfragen liegen.
- Vektoren wie die Dokumente behandeln, die sie kodieren
- Embeddings verschlüsselt speichern, sie zusammen mit ihrer Quelle löschen, Backups auf der Schutzstufe der Quelle absichern und unveränderliche Protokolle darüber führen, wer was abgerufen hat.