Vertrauenswäsche zwischen Agenten: nicht vertrauenswürdige Eingaben werden nicht dadurch vertrauenswürdig, dass sie einen anderen Agenten durchlaufen

Worum es geht

Ein verbreitetes Multi-Agenten-Design gibt einem «Recherche»-Agenten Browsing-Werkzeuge und einem separaten «Ausführungs»-Agenten Schreibzugriff, nach der Theorie, dass der Ausführungs-Agent das Web nie zu sehen bekommt. Doch die Zusammenfassung des Recherche-Agenten ist Text, der von den gelesenen Webseiten geprägt ist. Enthielt eine davon eingeschleuste Anweisungen, kann die Zusammenfassung sie weiterreichen — mitunter umformuliert als eigene Empfehlung des Recherche-Agenten. Der Ausführungs-Agent erhält den Angreifertext dann über einen Kanal, den er als intern und vertrauenswürdig behandelt. Dieser Vorschlag nennt das Vertrauenswäsche.

Warum es wichtig ist

Die Aufteilung in mehrere Agenten wird oft als Sicherheitsgrenze dargestellt. Das ist sie nur, wenn die Schnittstelle zwischen ihnen eng ist: frei formulierter Text zwischen Agenten trägt Anweisungen ebenso leicht wie eine Webseite. Die Vertrauenswäsche unterläuft zudem die Nachvollziehbarkeit, weil das Protokoll des Ausführungs-Agenten eine Anweisung von einem Kollegen-Agenten zeigt, nicht von einer Webseite.

So wird es angewendet

• Jeder Nachricht zwischen Agenten ein Vertrauenskennzeichen mitgeben: welche nicht vertrauenswürdigen Quellen sie beeinflusst haben. Das Kennzeichen weitergeben: eine Ausgabe ist höchstens so vertrauenswürdig wie ihre am wenigsten vertrauenswürdige Eingabe.
• Schnittstellen zwischen Agenten strukturiert und eng halten: aufgezählte Felder, begrenzte Längen, wo möglich Kennungen statt Fliesstext. Ein Recherche-Agent, der «Paketname + Version + Quell-URL» zurückgibt, trägt deutlich weniger als ein Absatz.
• Die erlaubten Aktionen des empfangenden Agenten vom Kennzeichen abhängig machen: kontaminierte Eingaben dürfen einen Entwurf beeinflussen, aber Aktionen mit Nebenwirkungen brauchen eine Bestätigung der Nutzenden.
• Die ursprünglichen Quellenverweise bei der Nachricht behalten, damit Reviewende eine Anweisung bis zur Seite zurückverfolgen können, von der sie stammt.
• In Red-Team-Tests eine Injektion in Inhalte einschleusen, die der erste Agent liest, und prüfen, was der letzte Agent in der Kette damit macht.

Stolpersteine

• Ein «Kritiker»- oder «Prüf»-Agent, der denselben kontaminierten Inhalt liest und freigibt; er teilt die Gefährdung, statt sie zu beseitigen.
• Orchestratoren, die Ausgaben von Sub-Agenten in ihren eigenen System-Prompt einfügen.
• Die Annahme, ein kleineres oder stärker eingeschränktes Modell weiter unten in der Kette sei immun; es kann Anweisungen sogar wörtlicher befolgen.