Das tödliche Trifecta: private Daten, nicht vertrauenswürdige Inhalte und ein ausgehender Kanal in einem Agenten

Worum es geht

Simon Willison benannte die Kombination im Juni 2025: ein Agent mit (1) Zugriff auf private Daten, (2) Exposition gegenüber nicht vertrauenswürdigen Inhalten und (3) der Fähigkeit, nach aussen zu kommunizieren. Sind alle drei vorhanden, kann eine in den nicht vertrauenswürdigen Inhalt eingeschleuste Anweisung den Agenten bitten, die privaten Daten zu lesen und nach aussen zu senden. Das Argument stützt sich auf die Beobachtung, dass LLMs Anweisungen befolgen, die sie in Inhalten finden.

Warum es wichtig ist

Jedes Bein wird gewöhnlich aus gutem Grund hinzugefügt, oft von verschiedenen Personen: ein Mail-Werkzeug zum Lesen, ein Browser für die Recherche, ein HTTP-Werkzeug für Integrationen. Das Risiko zeigt sich erst in der Kombination, daher erkennt keine einzelne Werkzeugprüfung es. Werkzeuge aus mehreren Quellen zu mischen — der typische MCP-Aufbau — macht es leicht, die Kombination versehentlich zusammenzustellen.

Ausgehende Kanäle, die leicht übersehen werden:

• Ein gerenderter Markdown-Bild- oder -Linkverweis, dessen URL Daten im Query-String trägt; der Client ruft ihn automatisch ab, wenn er die Antwort rendert.
• Ein Web-Abruf- oder Suchwerkzeug: Die Anfrage-URL selbst ist die Nachricht.
• Das Erzeugen eines öffentlichen Artefakts: ein Gist, ein Kommentar, ein Issue, ein Pull Request, eine Kalendereinladung.
• Das Senden von Mail- oder Chat-Nachrichten, einschliesslich Entwürfen, die mit einem Server synchronisieren.
• DNS-Abfragen, ausgelöst durch ein beliebiges Netzwerkwerkzeug.
• Das Schreiben in eine gemeinsam genutzte Datei, die der Prozess einer anderen Person hochlädt.

So wird es angewendet

• Für jede Agentenkonfiguration die Werkzeuge auflisten und markieren, welches Bein jedes davon liefert; jede Konfiguration mit allen drei braucht eine Neugestaltung, keine Warnung.
• Das Entfernen des ausgehenden Beins bevorzugen: keine frei formulierten URL-Abrufe in Sitzungen, die private Daten gelesen haben, eine Egress-Positivliste auf Netzwerkebene und kein automatisches Rendern entfernter Bilder im Client.
• Die Arbeit auf getrennte Sitzungen aufteilen: Eine liest nicht vertrauenswürdige Inhalte und liefert ein strukturiertes, grössenbegrenztes Ergebnis zurück; eine andere, ohne die nicht vertrauenswürdige Eingabe, behandelt private Daten.
• Für jede ausgehende Aktion, deren Inhalt von nicht vertrauenswürdiger Eingabe beeinflusst wurde, eine menschliche Bestätigung verlangen.

Stolpersteine

• Sich auf einen Filter zu verlassen, der eingeschleusten Text erkennt; die Quelle argumentiert, dass solche Schutzmassnahmen keinen vollständigen Schutz versprechen können.
• Eine Domain auf die Positivliste zu setzen, die Nutzerinhalte hostet (ein Code-Host, eine Paste-Seite), was den Kanal wieder öffnet.
• Zu vergessen, dass das Leck langsam sein kann: Wenige Bytes pro Anfrage über viele Anfragen hinweg schleusen dennoch einen Schlüssel aus.