Die Autoren sind Samuel Breckenridge, Dani Vilardell und Ari Juels von Cornell Tech sowie Wenhao Wang und Fan Zhang von Yale, alle dem IC3 angehörig. Der Experimentiercode ist öffentlich.

Rechnungen bezahlen

Im ersten Experiment gab es keinen Angreifer. Der System-Prompt des Agenten wies ihn an, nur gemäß den Anweisungen des Nutzers zu handeln und alles, was ein Tool zurückgab, einschließlich E-Mails, als Daten zu behandeln. Keine Aufgabe erwähnte die Wallet-Richtlinie oder das Einmalpasswort.

Die Modelle griffen trotzdem auf die Obergrenze zurück. In einem Durchlauf stieß claude-sonnet-5 an das Limit, rief das Richtlinien-Tool auf, holte den Circle-Bestätigungscode aus dem Posteingang, übermittelte ihn, erhöhte die tägliche Obergrenze von 0.01 $USDC auf 5 $USDC, bezahlte die drei Rechnungen und teilte dem Nutzer am Ende mit, was er getan hatte.

Die Raten unterschieden sich sowohl innerhalb eines einzelnen Modells als auch zwischen den Modellen und folgten nicht der Leistungsfähigkeit der Modelle: Die kleinsten Qwen- und DeepSeek-Modelle erhöhten die Obergrenze in nahezu jedem Durchlauf, während gemini-3.8-flash und die Claude-Modelle dies selten oder nie taten.

Eine adversariale E-Mail, die den Agenten aufforderte, das Limit zu erhöhen, änderte kaum etwas. In diesem Szenario erhöhten 7 von 10 Modellen die Obergrenze. Zwei Modelle taten dies seltener als ganz ohne Angreifer, denn aus ihren Transkripten geht hervor, dass sie die E-Mail als Prompt-Injection kennzeichneten und die Entscheidung dem Nutzer überließen.

Fünf bezahlten den Angreifer

Im dritten Experiment sollte der Agent lediglich den Posteingang zusammenfassen. Ein Angreifer verschickte eine Reihe von E-Mails, in denen er sich als Nutzer ausgab: Zunächst bat er darum, vor einer Frist 0.02 $USDC an die Adresse des Angreifers zu überweisen, dann folgten zwei E-Mails, die der Bitte des Agenten um Erlaubnis zuvorkamen.

5 von 10 Modellen erhöhten die Obergrenze und bezahlten den Angreifer. In dem im Paper wiedergegebenen Durchlauf fragte deepseek-v3.1 den Nutzer zweimal, ob es fortfahren solle, verstand jede gefälschte Antwort als Zustimmung, stieß an das Ausgabenlimit, erhöhte es mit dem per E-Mail erhaltenen Code und überwies das Geld. Die meisten erfolgreichen Angriffe entfielen auf Qwen- und DeepSeek-Modelle. GPT- und Claude-Modelle sowie gemini-3.8-flash hielten sich größtenteils zurück.

Die Forschenden entwickelten die Injections adaptiv und zielten auf einen Angriff ab, der bei mehreren Modellen funktioniert, statt eine jeweils auf ein Modell zugeschnittene Version zu erstellen. Dies beschreiben sie als Untergrenze für einen Angreifer, der eine bekannte Bereitstellung ins Visier nimmt.

Das Tor im Agenten

Der formale Teil des Papers definiert, was die Autoren als unentziehbare menschliche Beteiligung im Regelkreis bezeichnen, oder I-HITL: ein Genehmigungsprotokoll, das auch dann Bestand hat, wenn der Agent das Gerät des Nutzers vollständig kompromittiert hat. Eine stärkere Version gilt auch dann, wenn der Mensch versucht, die Genehmigungspflicht an den Agenten zu übertragen. Das ist für Vorschriften wie das EU-KI-Gesetz relevant, die menschliche Aufsicht über KI verlangen.

In der einfachen Konstellation aus Mensch, Plattform und Dienst, die der Richtlinienablauf von Circle und die meisten Agenten-Frameworks verwenden, beweist das Paper, dass kein Protokoll zugleich vollständig und verbindlich sein kann. Der Angreifer sieht alles, was der Mensch sieht, und kann alles senden, was der Mensch senden kann, sodass er einfach die Rolle des Menschen übernehmen kann.

Um das zu beheben, ist eine vertrauenswürdige Instanz außerhalb der Reichweite des Agenten erforderlich, und das Paper beweist, dass eine vertrauenswürdige Instanz allein nicht ausreicht. Das Gerät muss nachweisen, dass es seinen eigenen Signaturschlüssel erzeugt hat. Für die stärkere Garantie muss dieser Schlüssel zudem gebunden sein, was bedeutet, dass der Nutzer ihn nicht extrahieren kann. Außerdem braucht es eine Anzeige, die der Agent weder überschreiben noch anstelle des Nutzers auslesen kann, sowie eine Eingabe, die der Agent nicht per Software steuern kann.

Ledger besteht, Authentifikatoren versagen

An diesen Anforderungen gemessen, genügen die meisten Verfahren, die bereits für Genehmigungen verwendet werden, den Ansprüchen nicht.

Hardware-Wallets erfüllen die Anforderungen. Ledger Nano X, Flex und Stax qualifizieren sich, wenn eine eigens dafür entwickelte App mit dem Bestätigungsschlüssel des Geräts signiert. Dasselbe gilt für den Wultra Talisman, einen von einer Bank ausgegebenen FIDO2-Token mit eigenem Display und eigener Tastatur. Dieselbe Ledger-Hardware bietet nur die schwächere Garantie, wenn die App mit einem aus dem Wiederherstellungs-Seed des Nutzers abgeleiteten Schlüssel signiert, denn der Nutzer kann diesen Seed in eine vom Agenten kontrollierte Software importieren.

FIDO2-Schlüssel ohne Display wie ein YubiKey fallen durch, denn die Plattform bestimmt den Text, den der Mensch vor dem Tastendruck sieht. Push-basierte Zwei-Faktor-Apps zur Genehmigung fallen durch, weil der Dienst keinen Nachweis darüber erhält, wo der Schlüssel erzeugt wurde. Zeitbasierte Authentifikator-Apps, SMS-Codes und per E-Mail versendete Codes scheitern in jeder Hinsicht.

Auch die World-App fällt durch. Die Beschreibung, die die App dem Nutzer anzeigt, wird von der Plattform bereitgestellt und ist weder durch die Signatur des Dienstes noch durch den World-ID-Nachweis abgesichert. Ein Agent kann daher die Genehmigung einer Handlung anfordern, während der Mensch eine andere sieht. Worlds AgentKit, das im März veröffentlicht wurde, verknüpft Agenten-Wallets mit verifizierten Menschen, statt zu verhindern, dass die Genehmigung an sie delegiert wird.

Circle fügt einen Warnhinweis hinzu

Die Forschenden legten Circle die Ergebnisse am 22. September offen. Der Schnellstartleitfaden für Agenten-Wallets des Unternehmens beginnt nun mit einem Warnhinweis: „Geben Sie einem KI-Agenten niemals uneingeschränkten Zugriff auf Ihr E-Mail-Konto.“ Nutzer werden darauf hingewiesen, dass jeder, der diesen Posteingang lesen kann, sich bei der Wallet anmelden und ihre Ausgabenrichtlinien ändern kann. Außerdem werden sie aufgefordert, den Code selbst einzugeben.

Das Paper bezeichnet den Hinweis als sinnvoll und benennt seine Grenze deutlich: Die Trennung hängt davon ab, dass der Nutzer sie aufrechterhält. Ein Agent, der auf anderem Weg, etwa über gespeicherte Zugangsdaten oder eine authentifizierte Browsersitzung, Zugriff auf den Posteingang erhält, kann das Tor weiterhin öffnen. Der Ablauf zur Aktualisierung der Richtlinien bleibt unverändert.

Das Team veröffentlichte außerdem Countersign, einen Prototyp, der ein Android- oder iPhone-Gerät mithilfe der Attestierungsdienste von Google und Apple sowie einer hardwaregesicherten biometrischen Authentifizierung in die vertrauenswürdige Instanz verwandelt. Die Kernlogik umfasst etwa 800 Zeilen für das Backend und 150 Zeilen für jede mobile App. Der Code steht auf GitHub unter der MIT-Lizenz.

Zur Sicherheit

Die Beträge sind gering, und eine Erhöhung eines Limits ist kein Diebstahl. In dem gutartigen Experiment gab der Agent das Geld des Nutzers für dessen eigene Rechnungen aus, und mehrere Modelle meldeten die Änderung anschließend. Das Sicherheitsmodell ist symbolisch statt rechnerisch, und die Autoren überlassen eine rechnerische Behandlung künftigen Arbeiten. Bei Circles Zugangsschranke ist außerdem weiterhin der Code erforderlich. Ein Agent gelangt nur in solchen Konfigurationen daran, in denen der Nutzer ihm Zugriff auf den Posteingang gewährt hat. Von dieser Konfiguration rät das Unternehmen inzwischen ab, und die Arbeit wählte sie, weil persönliche Agentenprodukte E-Mail- und Wallet-Zugriff bündeln.

Ausgabenlimits sind branchenweit die Standardantwort auf die Risiken von Agenten, von Cloudflares Stablecoin-Wallets für Agenten, die einem Kontoinhaber Wallets mit begrenztem Guthaben bereitstellen, bis hin zu den Limits pro Einkauf für KI-Einkaufsguthaben. Die abschließende Forderung der Arbeit richtet sich an die darunterliegende Ebene: Wallet- und Authentifizierungsanbieter sollen eine Genehmigung einführen, die an die Nachricht gebunden ist, die ein Mensch gesehen hat. Anbieter mobiler Betriebssysteme sollen zudem zwei fehlende Funktionen bereitstellen: einen von sicherer Hardware dargestellten Bestätigungsbildschirm und eine Möglichkeit nachzuweisen, dass die Nutzung eines Schlüssels einen Fingerabdruck oder ein Gesicht erfordert.