Ein Kunde öffnet einen Support-Chat und fragt: „Können Sie erklären, warum die Rechnung INV-1042 als überfällig markiert wurde?“ Der Support-Assistent antwortet mit einer souveränen Erklärung und zitiert eine interne Notiz, die zu einem anderen Unternehmen gehört – einschließlich einer Zeile wie: „Gemäß den Verlängerungsbedingungen von ACME: Gebührenerlass bei Zahlungsziel Netto-60.“ Die Support-Benutzeroberfläche hatte dem Mitarbeiter oder dem Kunden zu keinem Zeitpunkt ACME-Tickets angezeigt, doch der Assistent bezog diese Notiz dennoch in seine Antwort ein. Es geschah hier nichts Ungewöhnliches. Der Kunde musste lediglich eine normale Frage über den üblichen Kanal stellen, und die Anwendung erledigte den Rest.
Die Systemstruktur, die zu diesem Leck führte, ist überschaubar genug, um sie sich leicht vorstellen zu können. Ein Endnutzer sendet eine Nachricht an die Support-Anwendung; diese ruft zugehörige Datensätze aus einer Datenbank ab, stellt einen Prompt zusammen, der sowohl die Nachricht des Nutzers als auch die abgerufenen Datensätze enthält, und sendet diesen Prompt an einen Modellanbieter. Das Modell liefert Text zurück, und die Anwendung zeigt diesen Text als Antwort des Assistenten an. Der Fehler äußert sich in einem Zitat, das Daten eines anderen Mandanten (Tenants) betrifft: Die Anwendung gab private Daten eines Mandanten an den Nutzer eines anderen Mandanten weiter.
Wir können das Leck erst beheben, wenn wir genau die Grenze benennen können, an der nicht vertrauenswürdige Daten in den Bereich einer vertrauenswürdigen Aktion übergehen. Eine Vertrauensgrenze (Trust Boundary) ist die Schnittstelle, an der Daten von einer Seite nicht automatisch die Berechtigungen der anderen Seite erhalten dürfen, da beide Seiten unterschiedliche Interessen und Zugriffsrechte haben. Bei unserem Support-Assistenten befindet sich der Endnutzer auf der einen Seite und der Datenzugriff der Anwendung auf der anderen; diese Grenze tritt jedoch an jedem Schritt (Hop) erneut auf, der beeinflussen kann, welche Daten gelesen oder offengelegt werden.
Entlang des gesamten Anfragepfads betrachten wir vier Elemente als nicht vertrauenswürdig, da jedes davon Anweisungen oder Inhalte enthalten kann, die nicht von der Anwendung selbst stammen. Die Nachricht des Endnutzers ist nicht vertrauenswürdig, da der Nutzer sie kontrolliert. Die Datenbankdatensätze sind nicht vertrauenswürdig, da die Datenbank bei fehlerhaften Abfragen oder Filtern unerwartete Datensätze liefern kann und da abgerufener Text Inhalte enthalten kann, die wie Anweisungen wirken, aber nicht in eine Antwort gehören. Die Modellausgabe ist nicht vertrauenswürdig, da das Modell dem empfangenen Text folgt und Lese-, Schreib- oder Offenlegungsvorgänge vorschlagen kann, die von der Anwendung nie beabsichtigt waren. Lediglich die eigene Konfiguration der Anwendung – etwa eine statische Positivliste (Allowlist) von Tool-Namen oder eine fest programmierte Liste auszuwählender Spalten – gilt von Anfang an als vertrauenswürdig; doch auch diese bleibt nur dann vertrauenswürdig, wenn die Anwendung sie aus einer kontrollierten Quelle lädt. Das nachstehende Diagramm der Vertrauensgrenzen benennt jeden Übertragungsschritt sowie die darüber fließenden Daten. Markieren wir nun, an welcher Stelle jede nicht vertrauenswürdige Eingabe in den Datenfluss gelangt: