/security/sensitive-information-disclosure/

LLM02

Sensitive Information Disclosure

Angriffsfläche
  • Ausgabe / Aktion
  • Memory / Zustand

Das Modell legt in seiner Antwort unbeabsichtigt vertrauliche Daten offen — Trainingsdaten, abgerufene Dokumente oder den gespeicherten Kontext eines anderen Nutzers.

Was es ist

Die Offenlegung sensibler Informationen umfasst jeden vertraulichen Inhalt, den ein Modell unbeabsichtigt in seiner Ausgabe preisgibt — personenbezogene Daten, Finanz- oder Gesundheitsdaten, Zugangsdaten, vertrauliche Geschäftsinformationen oder Fragmente seiner eigenen Trainingsdaten und Algorithmen. Ein Modell, das einen Teil seiner Trainingsdaten memoriert hat oder die Eingabe einer früheren Person im Kontext hält, kann diese bei einer unabhängigen Anfrage erneut preisgeben; Einschränkungen im System Prompt, welche Datentypen das Modell zurückgeben darf, helfen dabei, sind aber keine feste Grenze, da solche Einschränkungen durch Prompt Injection umgangen werden können. Ein Multi-Agenten-System vergrößert die Angriffsfläche mit jeder hinzukommenden Ebene: über Sitzungen oder Mandanten hinweg geteiltes Memory, ein von mehreren Agenten gespeister Retrieval-Index und Übergaben, die rohen Kontext an den nächsten Agenten weiterreichen, vervielfachen die Pfade, über die ein Geheimnis durchsickern kann. Jede dieser Ebenen als eigenständig abzusichernde Grenze zu behandeln — statt darauf zu vertrauen, dass intern geteilte Daten intern bleiben — ist die zentrale Abwehrmaßnahme.

Arten

Verlust personenbezogener Daten
Personenbezogene Daten tauchen in einer Antwort auf, weil das Modell darauf trainiert wurde, sie aus geteiltem Kontext abgerufen hat oder eine Person sie zuvor in derselben Konversation preisgegeben hat.
Offenlegung von Trainingsdaten & Algorithmen
Eine schlecht konfigurierte Ausgabe legt Fragmente von Trainingsdaten oder proprietäre Modellinterna offen und ermöglicht Inversions- oder Extraktionsangriffe, die private Eingaben aus dem Verhalten des Modells rekonstruieren.
Offenlegung sensibler Geschäftsdaten
Eine generierte Antwort enthält unbeabsichtigt vertrauliche Geschäftsinformationen, auf die das Modell zwar Zugriff hatte, die die anfragende Person aber nicht sehen sollte.

Angriffsszenarien

In einem Multi-Agenten-System

Ein Support-Agent mit mandantenübergreifend geteiltem Memory gibt beim Beantworten der Frage eines Kunden die Kontodaten eines anderen Kunden preis.

Unbeabsichtigte Offenlegung von Daten

Unzureichende Bereinigung geteilten Kontexts lässt die Antwort für eine Person Daten enthalten, die einer anderen Person oder Sitzung gehören.

Gezielte Extraktion über Injektion

Angreifende gestalten eine Eingabe, die die Ausgabefilter einer Anwendung umgehen soll, um das Modell dazu zu bringen, eingeschränkte Informationen zu wiederholen.

Datenleck über Trainingsdaten

Sensible Inhalte, die ohne ausreichende Prüfung in Trainings- oder Fine-Tuning-Daten aufgenommen wurden, tauchen später in nicht verwandten Ausgaben wieder auf.

Mandantenübergreifendes Memory-Leck

Ein von mehreren Agenten geteilter Memory-Speicher hat keine mandantenspezifische Grenze, sodass die gespeicherten Kontodaten einer Kundin bei der Beantwortung der Frage eines anderen Kunden auftauchen.

Abwehrmaßnahmen

Vor Aufnahme in den Kontext bereinigen
Bereinigen oder maskieren Sie sensible Inhalte, bevor sie in Trainingsdaten, geteiltes Memory oder einen Retrieval-Index gelangen, und wenden Sie eine strenge Eingabevalidierung an, damit identifizierbare oder vertrauliche Felder erst gar nicht in die Pipeline gelangen.
Memory- und Datenzugriff eingrenzen
Beschränken Sie den Lesezugriff jedes Agenten per Least Privilege Agent auf genau die Memory-Partition und Datenquellen, die seine Aufgabe benötigt — ein nicht partitionierter geteilter Speicher ist die häufigste Ursache dieser Leck-Klasse.
Jede Antwort filtern
Prüfen Sie ausgehende Inhalte vor Erreichen einer Nutzerin anhand einer Allow-List zulässiger Felder mit Output Validation / Schema Enforcement, statt der eigenen Zurückhaltung des Modells zu vertrauen.
Jeden Offenlegungspfad protokollieren
Halten Sie im Audit Trail fest, welche Daten welche Grenze überschritten haben, damit ein Leck forensisch bis zu seiner Quelle zurückverfolgbar ist, statt erst im Nachhinein sichtbar zu werden.

Sicherheit

Wohin als Nächstes

Suche

Patterns, Frameworks und Seiten durchsuchen.