Entwurfsmuster für die Absicherung von LLM-Agenten

Der Problembereich

Die Autor*innen des Papers beschreiben die Tragweite des Problems folgendermaßen:

„Solange sowohl Agenten als auch ihre Verteidigung auf der aktuellen Klasse von Sprachmodellen beruhen, ist es unserer Meinung nach unwahrscheinlich, dass Allzweck-Agenten sinnvolle und zuverlässige Sicherheitsgarantien bieten können.

Dies führt zu einer produktiveren Frage: Welche Arten von Agenten können wir heute bauen, die nützliche Arbeit leisten und gleichzeitig Widerstand gegen Prompt-Injection-Angriffe bieten? In diesem Abschnitt stellen wir eine Reihe von Entwurfsmustern für LLM-Agenten vor, die darauf abzielen, das Risiko von Prompt-Injection-Angriffen zu mindern, wenn nicht sogar ganz zu eliminieren. Diese Muster erlegen den Agenten absichtliche Beschränkungen auf, die ihre Fähigkeit, beliebige Aufgaben auszuführen, explizit einschränken.“

M. a. W.: Die Autor*innen haben keine Patentlösung gegen Prompt Injection, also bieten sie realistische Kompromisse, nämlich die Fähigkeit von Agenten einzuschränken, beliebige Aufgaben auszuführen. Dies mag zwar nicht befriedigend erscheinen, ist aber dafür umso glaubwürdiger.

„Die von uns vorgeschlagenen Entwurfsmuster haben ein gemeinsames Leitprinzip: Sobald ein LLM-Agent nicht vertrauenswürdige Eingaben erhalten hat, muss er so eingeschränkt werden, dass es für diese Eingaben unmöglich ist, Folgeaktionen auszulösen, d. h. Aktionen mit negativen Nebeneffekten für das System oder seine Umgebung. Dies bedeutet zumindest, dass eingeschränkte Agenten keine Werkzeuge aufrufen können, die die Integrität oder Vertraulichkeit des Systems beeinträchtigen können. Darüber hinaus sollten ihre Ausgaben keine nachgelagerten Risiken bergen – wie z. B. das Ausschleusen sensibler Informationen z. B. über eingebettete Links) oder die Manipulation künftigen Agentenverhaltens z. B. schädliche Antworten auf die Anfrage eines Users).“

Jede Berührung mit einem potenziell bösartigen Token kann also die Ausgabe für diesen Prompt vollständig verfälschen. Damit kann ein Angriff über einen eingeschleusten Token die vollständige Kontrolle darüber erhalten, was als Nächstes passiert. Das bedeutet, dass nicht nur die Textausgabe des LLM übernommen werden kann, sondern auch alle Tool-Aufrufe, die das LLM möglicherweise auslösen kann.

Lasst uns nun ihre Entwurfsmuster genauer anschauen.

Aktions-Auswahl-Muster

„Ein relativ einfaches Muster, das Agenten immun gegen Prompt Injections macht, ihnen aber dennoch erlaubt, externe Aktionen durchzuführen, besteht darin, jegliche Rückkopplung dieser Aktionen in den Agenten zu verhindern.“

Die rote Farbe steht für nicht vertrauenswürdige Daten. Die LLM übersetzt hier zwischen einer Aufforderung in natürlicher Sprache und einer Reihe von vordefinierten Aktionen, die über nicht vertrauenswürdige Daten ausgeführt werden sollen.

Agenten können Tools auslösen, aber sie können nicht mit den Antworten dieser Tools konfrontiert werden oder darauf reagieren. Sie können keine E-Mail lesen oder eine Webseite abrufen, aber sie können Aktionen auslösen wie ‚die Benutzer*innen zu dieser Webseite schicken‘ oder ‚den Benutzer*innen diese Nachricht anzeigen‘.

Die Autor*innen fassen dieses Muster als LLM-modulated switch statement zusammen.

Plan-Dann-Ausführen-Muster

„Ein freizügigerer Ansatz besteht darin, eine Rückmeldung der Tool-Ausgaben an den Agenten zuzulassen, aber zu verhindern, dass die Tool-Ausgaben die Auswahl der vom Agenten durchgeführten Aktionen beeinflussen.“

Vor der Verarbeitung nicht vertrauenswürdiger Daten definiert das LLM einen Plan, der aus einer Reihe zulässiger Werkzeugaufrufe besteht. Eine Prompt-Injektion kann das LLM dann nicht dazu zwingen, ein Werkzeug auszuführen, das nicht Teil des definierten Plans ist.

Die Idee dabei ist, die Tool-Aufrufe im Voraus zu planen, bevor es zu einem Kontakt mit nicht vertrauenswürdigen Inhalten kommt. Dies ermöglicht anspruchsvolle Aktionsfolgen, ohne dass die Gefahr besteht, dass eine dieser Aktionen bösartige Anweisungen enthält, die dann später ungeplante schädliche Aktionen auslösen.

In ihrem Beispiel wird Sende den heutigen Terminplan an meinen Chef John Doe in einen calendar.read()- gefolgt von einem email.write(…, "john.doe@company.com")-Aufruf. Die Ausgabe von calendar.read() kann zwar den Text der gesendeten E-Mail beschädigen, aber nicht den Empfänger dieser E-Mail ändern.

LLM-Map-Reduce-Muster

Das vorherige Muster ermöglichte es bösartigen Anweisungen, den an den nächsten Schritt gesendeten Inhalt zu beeinflussen. Das Map-Reduce-Muster umfasst Unteragenten, die angewiesen werden, mit nicht vertrauenswürdigen Inhalten konfrontiert zu werden und deren Ergebnisse später sicher aggregiert werden.

Nicht vertrauenswürdige Dokumente werden unabhängig voneinander verarbeitet, um sicherzustellen, dass ein bösartiges Dokument die Verarbeitung eines anderen Dokuments nicht beeinflussen kann.

In ihrem Beispiel wird ein Agent gebeten, Dateien mit den Rechnungen dieses Monats zu finden und sie an die Buchhaltungsabteilung zu senden. Jede Datei wird von einem Unteragenten verarbeitet, der mit einem Booleschen Wert antwortet, der angibt, ob die Datei relevant ist oder nicht. Dateien, die als relevant eingestuft wurden, werden dann zusammengefasst und versendet.

Duales LLM-Muster

In diesem Muster koordiniert ein privilegiertes LLM ein LLM in Quarantäne, um jegliche Offenlegung von nicht vertrauenswürdigen Inhalten zu vermeiden. Die unter Quarantäne gestellte LLM gibt symbolische Variablen zurück – z. B. $VAR1, das eine zusammengefasste Webseite repräsentiert und die die privilegierte LLM anfordern kann, um der Benutzer*in angezeigt zu werden, ohne selbst dem verdächtigen Inhalt ausgesetzt zu sein.

Ein privilegiertes LLM hat Zugriff auf Werkzeuge, verarbeitet aber niemals nicht-vertrauenswürdige Daten. Dieses LLM kann ein LLM in Quarantäne aufrufen, um nicht vertrauenswürdige Daten zu verarbeiten, jedoch ohne dabei Zugriff auf Werkzeuge zu haben. Die Ergebnisse der Verarbeitung nicht-vertrauenswürdiger Daten werden in einem Speicher abgelegt, den das privilegierte LLM nur durch Verweis manipulieren kann.

Code-Dann-Ausführen-Muster

Dieses Muster wird im sog. CaMeL-Paper von DeepMind beschrieben: Defeating Prompt Injections by Design. Es handelt sich um eine verbesserte Version des dualen LLM-Musters, bei dem der privilegierte LLM-Code in einer benutzungsdefinierten Sandbox-DSL (Domain Specific Language) generiert, die angibt, welche Tools aufgerufen werden sollen und wie ihre Ausgaben aneinander weitergegeben werden sollen.

Die DSL ist so konzipiert, dass sie eine vollständige Datenflussanalyse ermöglicht, so dass alle verfälschten Daten als solche markiert und durch den gesamten Prozess verfolgt werden können.

Das LLM schreibt einen Code, der Tools aufrufen und andere LLMs anrufen kann. Der Code wird dann auf nicht-vertrauenswürdigen Daten ausgeführt.

Kontext-Minimierung-Muster

„Das sicherste Design, das wir hier in Betracht ziehen können, ist eines, bei dem der Code-Agent nur über eine streng formatierte Schnittstelle mit nicht vertrauenswürdiger Dokumentation oder nicht vertrauenswürdigem Code interagiert (z. B. sieht der Agent anstelle von beliebigem Code oder Dokumentation nur eine formale API-Beschreibung). Dies kann durch die Verarbeitung nicht vertrauenswürdiger Daten mit einem unter Quarantäne gestellten LLM erreicht werden, der angewiesen ist, die Daten in eine API-Beschreibung mit strengen Formatierungsanforderungen zu konvertieren, um das Risiko von Prompt Injections zu minimieren (z. B. Methodennamen mit maximal 30 Zeichen).

Nutzwert

Der Nutzen ist eingeschränkt, da der Agent nur APIs und keine Beschreibungen in natürlicher Sprache oder Beispiele für Code von Dritten sehen kann.

Sicherheit

Prompt-Injektions müssten überleben, in eine API-Beschreibung formatiert zu werden, was unwahrscheinlich ist, wenn die Formatierungsanforderungen streng genug sind.”

Die Eingabeaufforderung des Users informiert die Aktionen des LLM-Agenten (z. B. den Aufruf eines bestimmten Tools), wird aber danach aus dem Kontext des LLM entfernt, um zu verhindern, dass sie die Antwort des LLM verändert.

Empfehlungen

Auch wenn die Absicherung von universellen Agenten mit den derzeitigen Möglichkeiten unerreichbar bleibt, können anwendungsspezifische Agenten durch prinzipielles Systemdesign abgesichert werden. Die von den Autor*innen vorgeschlagenen Entwurfsmuster machen KI-Agenten gegen Prompt-Injection-Angriffe widerstandsfähiger. Dabei haben sie die Muster bewusst einfach gehalten, um sie leichter verständlich zu machen. Sie geben folgende zwei Empfehlungen für Entwickler*innen und Entscheider*innen:

1. Priorisiert die Entwicklung anwendungsspezifischer Agenten, die sich an sichere Entwurfsmuster halten und klare Vertrauensgrenzen definieren.
2. Verwendet eine Kombination von Entwurfsmustern, um robuste Sicherheit zu erreichen: kein einzelnes Muster wird wahrscheinlich für alle Bedrohungsmodelle oder Anwendungsfälle ausreichen.

Neben den vorgestellten Entwurfsmustern gibt es einige allgemeine Best Practices, die idealerweise beim Entwurf eines KI-Agenten immer berücksichtigt werden sollten. Diese beziehen sich auf den konservativen Umgang mit Modellprivilegien, User-berechtigungen und -bestätigungen. Darüberhinaus ermöglicht Sandboxing, minimale Berechtigungen und feingranulare Berechtigungen für jede Aktion zu definieren. Bewährte Sicherheitspraktiken gelten nach wie vor und sollten bei der Konzentration auf die Sicherung der KI-Komponente nicht vergessen werden.

Resümee

Prompt-Injections sind weiterhin eine der größten Herausforderungen für den verantwortungsvollen Einsatz von agentenbasierten Systemen, die viele so gerne bauen möchten. Erfreulicherweise nimmt die Aufmerksamkeit in der Forschungsgemeinschaft für diese Problemfälle zu.