Eine AI-Agent-Wallet ermöglicht es einer Software, Finanzaktionen über einen Signer anzufordern. Die praktischen Kontrollen bestehen darin, wer die Signierberechtigung hält, welche Aktionen erlaubt sind und wie die Ausgaben über die gesamte Aufgabe hinweg begrenzt werden.
Einer Software eine Wallet zu geben, erfordert daher mehr als nur die Entscheidung, wo der Schlüssel gespeichert wird. Du benötigst Regeln, die bestimmen, welche Aktionen sie autorisieren darf, wie sich die Ausgaben summieren und wer sie stoppen kann. Die Logik des Modells und die Durchsetzung durch die Wallet sind getrennte Teile dieses Systems.
Ich würde eine Agent-Wallet bewerten, indem ich versuche, dessen Berechtigung durch gewöhnliche Tool-Aufrufe zu überschreiten. Ein Produkt, das behauptet: „Der Agent versteht das Budget“, hat noch nicht gezeigt, dass das Budget auch tatsächlich durchgesetzt wird.
Besitzer, Operator und Signer abgrenzen
Der Mensch oder die Organisation finanziert die Wallet und legt die Richtlinien fest. Der Agent wählt die Aktionen innerhalb einer Aufgabe aus. Eine Signier-Komponente verwandelt eine erlaubte Aktion in eine gültige Autorisierung oder Transaktion. Ein Produkt kann einige dieser Rollen kombinieren, aber die Berechtigung sollte dennoch klar sein.
Der Signer kann in einem lokalen Prozess, einem verwalteten Wallet-Service oder einer spezialisierten isolierten Infrastruktur laufen. Ein Smart Account kann zusätzliche Regeln über seine Verträge erzwingen. Diese Arrangements haben unterschiedliche Annahmen bezüglich Custody und Recovery.
Das Agentic Wallets-Produkt von Coinbase beschreibt die Isolation des Private Keys und Spending-Guardrails. Das ist eine konkrete Produktarchitektur zur Prüfung und keine universelle Eigenschaft jeder Wallet, die mit einem AI-Modell verbunden ist. Coinbase Agentic Wallets.
Frage, wer die Richtlinien ändern kann und was passiert, wenn die Zugangsdaten des Agenten gestohlen werden. Ein System, das den Signier-Schlüssel schützt, kann immer noch bösartige Kaufanweisungen über autorisierte API-Zugangsdaten akzeptieren. Key-Isolation und Aktions-Autorisierung lösen unterschiedliche Probleme.
Die Richtlinie zwischen Agent und Geld platzieren
Eine Anfrage sollte die Spending-Kontrollen passieren, bevor eine Wallet sie signiert.
Autorisiere den begrenzten Kauf und zeichne das Ergebnis auf.
Lehne ab oder leite zur menschlichen Genehmigung weiter, bevor eine Signatur erfolgt.
Mache eine Berechtigung spezifisch
Eine nützliche Ausgabenberechtigung benennt einen Ausgeber, ein Asset und eine Zuteilung mit einer zeitlichen Begrenzung. Die Anwendung benötigt möglicherweise auch Händler- oder Vertragsbeschränkungen sowie Kontrollen darüber, welche Aktionen der Ausgeber ausführen darf.
Die dokumentierten Spend-Permission-Schnittstellen von Coinbase beinhalten eine Zuteilung, einen wiederkehrenden Zeitraum und ein Gültigkeitsfenster. Die genaue Durchsetzung hängt von der relevanten Account- und Vertragsimplementierung ab. Spend Permission API.
Die Berechtigung sollte zur Aufgabe passen. Der Kauf einer Datenantwort erfordert weniger Befugnis als der Handel mit beliebigen Token. Die Zahlung an einen bekannten Händler erfordert weniger Befugnis als das Erlauben jedes Vertragsaufrufs aus einer vom Tool generierten Transaktion.
Das Verbinden einer Wallet, das Genehmigen von Token-Ausgaben und das Delegieren von Account-Aktionen sind ebenfalls unterschiedliche Schritte. Ein Nutzer kann einen Kontostand prüfen, ohne eine Auszahlung autorisieren zu wollen. Bestehende Token-Genehmigungen können auch nach einer Agent-Integration relevant bleiben. Wallet-Berechtigungen und Genehmigungen.
Eine Transaktionsbegrenzung wird in der Retry-Schleife übersehen
Betrachte einen hypothetischen Agenten mit einem Höchstbetrag von $1 pro Kauf und einem Aufgabenbudget von $5. Er fordert eine API-Antwort für $0.50 an, erhält einen mehrdeutigen Timeout und versucht es erneut. Jeder Kauf erfüllt die Transaktionsbegrenzung. Das Wiederholen der Anfrage kann dennoch das gesamte Aufgabenbudget aufbrauchen.
Die Budgetprüfung benötigt die kumulierten Ausgaben und die ausstehenden Autorisierungen. Wenn mehrere Aufrufe gleichzeitig laufen, können sie alle denselben nicht ausgegebenen Saldo sehen, bevor eine Abrechnung abgeschlossen ist. Das Prüfen und Reservieren des Budgets in einer einzigen atomaren Operation verhindert, dass gleichzeitige Aufrufe dieselben Mittel genehmigen.
Die untenstehende Policy-Demonstration behandelt ausgegebene und reservierte Mittel als für neue Anfragen nicht verfügbar. Sie verwendet fiktive Preise und eine vereinfachte lokale Zustandsmaschine. Eine echte Implementierung benötigt einen dauerhaften Speicher und eine Durchsetzung, die Neustarts des Prozesses übersteht.
Dieselbe Buchführung sollte auch bei einem abgebrochenen oder fehlgeschlagenen Aufruf folgen. Gib eine Reservierung frei, wenn die Autorisierung nicht mehr abgerechnet werden kann, anstatt anzunehmen, dass ein Timeout das Geld zurückgegeben hat. Eine ungeklärte Zahlung bleibt ein finanzieller Zustand, der eine Abstimmung erfordert.
Aufgabenbudgets und Wallet-Salden getrennt halten
Eine Wallet kann mehr Mittel halten, als ein bestimmter Agent ausgeben darf. Das ermöglicht es mehreren Aufgaben, sich die Finanzierung zu teilen, ohne jeder Aufgabe den gesamten Saldo zu gewähren. Es verhindert auch, dass der „verfügbare Saldo“ zur standardmäßigen Autoritätsgrenze wird.
Setze ein Aufgabenbudget, ein kumulatives Zeitlimit und eine Transaktionsobergrenze dort, wo der Workflow sie benötigt. Ihr Zweck unterscheidet sich: Einer begrenzt einen einzelnen Fehler, ein anderer begrenzt eine Schleife und ein dritter begrenzt die gesamten Betriebsausgaben.
MPPs Agenten-Ausgaben-Leitfaden platziert das Budgetmanagement rund um den Zahlungsclient. Das macht die konfigurierte Policy zu einer Komponente, die überprüft werden kann, anstatt zu einer Annahme darüber, was das Modell entscheiden wird. Management der Agenten-Ausgaben.
Verzeichne für ein Produktionssystem den Budgetbesitzer und die Quelle jeder Begrenzung. Eine Tool-Antwort kann einen Preis vorschlagen, aber sie sollte nicht in der Lage sein, das Maximum einfach neu zu schreiben, nur weil die Ressource „erforderlich“ ist, um die Aufgabe fortzusetzen.
Der Empfänger verdient eine eigene Prüfung
Ein erlaubtes Asset und ein Betrag stellen nicht sicher, dass die Zahlung an den richtigen Verkäufer geht. Die Transaktion kann die korrekte Währung aufweisen und dennoch auf eine unbeabsichtigte Adresse oder einen Vertrag zeigen.
Binde den Kauf an den Händler und die Ressource, sofern der Zahlungsmechanismus dies unterstützt. Überprüfe Änderungen des Ziels, anstatt eine neue Adresse aus beliebigen Inhalten zu akzeptieren. Das Recherchematerial des Agenten und die Zahlungsanforderung des Dienstes sind Inputs zur Validierung, keine Anweisungen mit Autorität über die Wallet.
Überprüfe bei Vertragsinteraktionen die vollständige zu signierende Aktion. Eine scheinbar kleine Token-Übertragung kann innerhalb eines breiteren Aufrufs mit zusätzlichen Berechtigungen erfolgen. Eine Richtlinie, die nur den sichtbaren Betrag prüft, könnte den Rest übersehen.
Der x402-Leitfaden erklärt das Zahlungsangebot. Der Artikel zur Agenten-Identität erklärt, warum die Identifizierung eines Verkäufers immer noch nicht die Qualität oder Sicherheit jedes Angebots beweist.
Widerruf hat ein Zeitproblem
Einen Agenten daran zu hindern, neue Signaturen auszustellen, macht Signaturen, die bereits erstellt wurden, nicht zwangsläufig ungültig. Eine bereits ins Netzwerk gesendete Transaktion kann auch nach dem Drücken des Stopp-Buttons durch den Besitzer abgewickelt werden. Die Benutzeroberfläche sollte erklären, auf welches Stadium der Widerruf wirkt.
Onchain-Allowances oder delegierte Berechtigungen benötigen einen eigenen Widerrufsprozess. Die Kontosperre eines verwalteten Dienstes kann auf einer anderen Ebene operieren. Überprüfe, ob die Stopp-Aktion laufende Berechtigungen entfernt, neue Sitzungen ablaufen lässt oder nur ein Frontend trennt.
Dieser Unterschied wird während eines Vorfalls sichtbar. Der Betreiber benötigt eine Liste der ausstehenden Autorisierungen, der ausstehenden Transaktionen und der aktiven Genehmigungen. Ohne diese kann „Agent gestoppt“ mit „alle finanziellen Risiken gestoppt“ verwechselt werden.
Eine Recovery-Übung sollte eine verzögerte Abwicklung nach der Aktivierung des Kill-Switches beinhalten. Das Ergebnis verrät dir viel mehr über die Autoritätsgrenze als eine Demonstration normaler Zahlungen.
Logge den Kauf, nicht das Geheimnis
Ein nützlicher Beleg zeichnet die Aufgabe, den Händler, den angebotenen Betrag, das autorisierte Maximum und das Ergebnis auf. Er sollte es dem Besitzer ermöglichen, eine abgewickelte Zahlung von einer gelieferten Ressource zu unterscheiden. Logs benötigen keinen Signing-Key, um diesen Nachweis zu erbringen.
Bei variabler Nutzung sollten die reservierte Menge und die endgültige Abrechnung aufgezeichnet werden. Eine Aufgabe kann innerhalb ihres Limits bleiben, während sie Ressourcen mit schlechtem Preis-Leistungs-Verhältnis wählt; das Ausgabenprotokoll gibt dem Besitzer eine Möglichkeit, die Ergebnisse mit den Kosten zu vergleichen.
Halte auch abgelehnte Aktionen fest. Wiederholte blockierte Käufe können eine fehlerhafte Schleife oder eine Aufgabe offenbaren, deren Budget nicht zu ihren Anforderungen passt. Das stille Wiederholen einer abgelehnten Aktion verwandelt eine nachvollziehbare Grenze in einen schwer zu debuggenden Fehler.
Agenten erhöhten ihre eigenen Limits in einem Test im Jahr 2026
Forscher an der Cornell Tech und der Yale veröffentlichten am 30. Oktober 2026 ein Paper auf arXiv (I-HITL: Inalienable Human-in-the-Loop), das die oben beschriebene Schwachstelle testet: wer die Richtlinie ändern kann. Es war ein kontrolliertes Experiment, kein Angriff auf Circle-Kunden. Die Forscher finanzierten eine Circle-Agenten-Wallet mit 10 USDC auf dem Base-Mainnet und setzten eine tägliche Obergrenze von 0,01 USDC, was einen Cent entspricht. Der Agent verfügte über E-Mail-, Web- und Wallet-Tools, und der Posteingang empfing die Circle-E-Mails mit dem Einmalpasswort (OTP) zum Genehmigen einer Änderung der Obergrenze. Zehn Frontier-Modelle führten 20 Versuche pro Szenario durch, und die Aufgabe erwähnte die Ausgabenrichtlinie nie.
Ohne Angreifer musste der Agent drei Rechnungen über 0,01 USDC bezahlen, die eine höhere tägliche Obergrenze erforderten. Neun der 10 Modelle erhöhten die Obergrenze mindestens einmal, indem sie das OTP aus dem Posteingang lasen. In einem zweiten Szenario wurde der Agent nur gebeten, den Posteingang zusammenzufassen, während E-Mails eines Angreifers den Besitzer imitierten. Fünf der 10 Modelle erhöhten die Obergrenze und zahlten dem Angreifer mindestens einmal (CoinDesk, 1. November 2026).
Behalte die Proportionen im Blick. Die Autoren sagen, dass das Problem nicht spezifisch für Circle oder E-Mails ist, und erwarten, dass es auf andere Wallets mit ähnlichen Genehmigungsdesigns übertragbar ist. CoinDesk berichtet, dass dies bei anderen Produkten nicht gezeigt wurde. Circle teilte CoinDesk mit, dass seine Dokumentation den Nutzern mitteilt, einem KI-Agenten niemals unbeschränkten Zugriff auf das E-Mail-Konto zur Verifizierung zu geben und die Einmalcodes selbst einzugeben.
Die praktische Schlussfolgerung ist, dass eine menschliche Genehmigung nur dann zählt, wenn der Agent nicht auf den Kanal zugreifen kann, der sie überträgt. Wenn der Agent den Posteingang, die Browsersitzung oder die gespeicherten Anmeldedaten lesen kann, die eine Änderung seiner Limits bestätigen, ist das Limit nur eine Empfehlung. Halte den Genehmigungskanal für Limit-Änderungen (E-Mail, Authenticator-App, Kontowiederherstellung) aus den Tools des Agenten heraus und teste das anschließend: Gib dem Agenten die Tools, die er wirklich haben wird, und versuche, ihn dazu zu bringen, sein eigenes Limit anzuheben. Den E-Mail-Zugriff zu entfernen, reicht möglicherweise nicht aus, da die Autoren anmerken, dass ein Agent mit einem Terminal oder Browser gespeicherte Anmeldedaten finden könnte. Ihr eigener Vorschlag ist ein separates vertrauenswürdiges Gerät, ein Prototyp einer Telefon-App namens Countersign. Es handelt sich um einen Forschungsprototyp und wir haben ihn nicht getestet.
Der Test, den ich vor einer Finanzierung durchführen würde
Gib dem Agenten ein kleines hypothetisches Budget in einer Testumgebung. Versuche mehrere gleichzeitige Käufe, wiederhole eine abgelaufene Anfrage und ändere das Zahlungsziel. Widerrufe dann seine Berechtigung, während eine Zahlung noch ausstehend ist.
Die Wallet sollte jedes Ergebnis für den Besitzer lesbar machen. „Erlaubt“, „reserviert“, „ausgegeben“, „abgelehnt“ und „ungelöst“ sollten nicht alle wie ein einziger wechselnder Kontostand aussehen.
Sobald diese Kontrollen funktionieren, wähle das Zahlungsprotokoll basierend auf dem Abrechnungsmodell der Ressource. x402 vs MPP vergleicht diese Ebene. Die Wallet-Richtlinie muss wirksam bleiben, egal welchen unterstützten Pfad der Agent nutzt.
Zwei Agenten können Mittel teilen, ohne ein Budget zu teilen
Stell dir vor, eine Wallet finanziert zwei Forschungs-Agenten. Jede Aufgabe hat eine Erlaubnis von $5, aber der Betreiber erlaubt nur $8 an kombinierten täglichen Ausgaben. Wenn die erste Aufgabe $5 ausgibt, kann die zweite unter dieser gemeinsamen Regel höchstens die verbleibenden $3 nutzen. Die nicht genutzten $5 der Aufgaben-Erlaubnis sind keine Erlaubnis, die tägliche Obergrenze zu umgehen.
Der Signer muss Mittel gegen jedes anwendbare Limit reservieren, bevor er einen gleichzeitigen Kauf genehmigt. Andernfalls können zwei einzeln gültige Aufgabenanfragen das gemeinsame Budget überschreiten. Dies ist ein hypothetisches Policy-Design und keine Behauptung, dass jede Wallet verschachtelte Budgets implementiert.