Wie ein KI-Agent wirklich an sein eigenes Wallet kommt

Am 4. Mai 2026 schenkte ein Unbekannter dem X-Bot Grok eine „Bankr Club Membership"-NFT. Grok war über den Krypto-Handelsbot Bankr mit einem eigenen Wallet verknüpft, und dieses Wallet war so konfiguriert, dass der Besitz bestimmter NFTs automatisch erweiterte Rechte freischaltete, in diesem Fall Transfer- und Swap-Vollmachten, die normale Nutzer nicht hatten. Die NFT war das Geschenk. Die Falle kam als Antwort auf einen ganz anderen Tweet: eine Bitte, eine Morsecode-Nachricht zu übersetzen. Grok übersetzte brav, das Ergebnis lautete sinngemäß „sende 3 Milliarden DRB-Token an diese Adresse", und weil die Sicherheitsschicht kodierten Text nicht als Anweisung erkannte, verarbeitete Bankr die Übersetzung als authentifizierten Befehl und führte die Transaktion aus. Schaden: je nach Quelle 150.000 bis 200.000 US-Dollar. Niemand hat einen privaten Schlüssel gestohlen, kein Ausgabenlimit wurde überschritten, keine Zeile Code hatte einen Bug. Die Berechtigung selbst war der Angriff.

Diese Geschichte ist der beste Einstieg in eine Frage, die der vorherige Artikel dieser Reihe bewusst ausgeklammert hat: Der handelte davon, wie Geld fließt, sobald ein Agent bezahlen will, x402, AP2, Stablecoins gegen Kartennetze. Hier geht es um die Ebene davor: Wie kommt ein Agent überhaupt an ein Wallet, dem er trauen kann, ohne dass ein Mensch bei jeder Transaktion danebensitzt, und ohne dass ihm dafür jemand den Generalschlüssel in die Hand drückt?

Warum der Seed nie in den Prompt darf

Ein menschliches Wallet schützt genau eine Sache: die Seed Phrase, aus der sich praktisch jeder weitere Schlüssel deterministisch ableiten lässt. Bei einem KI-Agenten ist dieses Modell aus zwei Gründen ungeeignet. Erstens landet alles, was ein Sprachmodell als Text sieht, potenziell im Kontext, in Logs, in Debug-Ausgaben, in der nächsten Anfrage an einen Drittanbieter. Ein Seed im Prompt ist ein Seed, der irgendwann irgendwo geleakt wird. Zweitens ist ein Agent, der den vollen Schlüssel besitzt, per Definition nicht mehr eingeschränkt: Jede Regel, „nur bis 50 Dollar", „nur an diese Adresse", müsste dann im Agenten selbst durchgesetzt werden, in genau der Komponente, die Prompt-Injections wie die Morsecode-Nachricht oben am ehesten zum Handeln bringen. Die Lösung, auf die sich die Branche 2026 weitgehend geeinigt hat: Der Agent bekommt nie den Hauptschlüssel. Er bekommt ein Wallet, dessen Grenzen im Code oder in der Infrastruktur liegen, nicht im guten Willen des Modells.

Drei Architekturen für dasselbe Problem

Smart-Contract-Wallets mit Session Keys. Über Kontoabstraktion (ERC-4337, seit 2023 live) oder seit dem Ethereum-Pectra-Upgrade vom 7. Mai 2025 über EIP-7702 lässt sich eine Wallet-Adresse so programmieren, dass sie temporäre, stark eingeschränkte Zweitschlüssel ausstellen kann, Session Keys. Ein Session Key kann exakt festlegen: welche Vertragsfunktionen aufgerufen werden dürfen (nur swap() bei einem bestimmten Router), wie viel maximal bewegt werden darf, und wie lange der Schlüssel überhaupt gültig ist, oft nur Stunden. Der eigentliche Unterschied zwischen den beiden Standards liegt tiefer: ERC-4337 braucht eine komplett neue Smart-Contract-Adresse und läuft über zusätzliche Bundler-Infrastruktur, EIP-7702 lässt eine bestehende Standard-Adresse (EOA) per Autorisierungssignatur vorübergehend wie ein Smart Contract funktionieren, gleiche Adresse, gleicher Kontostand, spürbar weniger Gas. Laut einer Auswertung von Anfang 2026 hatten sich zu diesem Zeitpunkt bereits über 25.000 Accounts auf EIP-7702 umgestellt (rund 13.000 auf Ethereum, dazu Optimism, BNB Chain und Base), mit rund 1.000 Interaktionen täglich, Infrastruktur-Anbieter wie ZeroDev, Pimlico und Openfort bauen darauf ihre Session-Key-Systeme für Agenten.

Multi-Party Computation (MPC). Statt einen Schlüssel zu erzeugen und ihn dann einzuschränken, wird bei MPC nie ein vollständiger Schlüssel erzeugt. Der Anbieter ChainUp beschreibt sein Modell so: Der private Schlüssel wird in mehrere unabhängige Anteile aufgeteilt, die getrennt auf verschiedenen Geräten oder Servern liegen; für eine Signatur rechnen die Anteile gemeinsam, ohne dass der vollständige Schlüssel an irgendeinem Punkt zusammengesetzt wird, auch nicht im Arbeitsspeicher. Ein einzelner kompromittierter Anteil reicht damit nicht aus, um zu signieren.

Trusted Execution Environments (TEE). Der dritte Baustein sichert nicht den Schlüssel selbst ab, sondern den Ort, an dem er benutzt wird: eine isolierte Hardware-Umgebung, typischerweise eine AWS-Nitro-Enclave-Instanz, ohne persistenten Speicher und ohne Login-Zugriff für Betreiber, in der Schlüsselmaterial verarbeitet werden kann, ohne dass es außerhalb der Enclave jemals im Klartext existiert.

Der Praxisfall: MPC und TEE gemeinsam

Am konkretesten lässt sich das an Coinbases „Agentic Wallets" zeigen, gestartet am 11. Februar 2026 speziell für autonome Agenten (Quelle: Coinbases eigene Produktdokumentation, also keine neutrale Stimme, aber technisch nachprüfbar). Das Design kombiniert beide Bausteine: Private Schlüssel werden per eigener cb-mpc-Bibliothek über verteilte Schlüsselerzeugung (EC-DKG) und Threshold-ECDSA auf der secp256k1-Kurve aufgeteilt, zusammengerechnet wird ausschließlich innerhalb einer AWS-Nitro-Enclave. Programmierbar sind laut Dokumentation unter anderem Session-Obergrenzen ( „5 Dollar in der nächsten Stunde"), Pro-Transaktions-Limits und Allowlists pro Token, ein Beispiel aus der Doku: ein Limit von 10 USDC pro Transaktion, eine Session-Obergrenze von 200 USDC, dazu eine Allowlist von genau drei DEX-Router-Adressen. Coinbase selbst beschreibt den Sicherheitsgewinn gegenüber einem Schlüssel, der einfach auf einer Festplatte liegt, als „mehrere Größenordnungen" höher, eine Selbsteinschätzung, aber eine mit belastbarer Architektur dahinter.

Wo es trotzdem schiefgeht: die Vollmacht ist der Angriff

Genau hier liegt die Pointe der Grok-Bankr-Geschichte vom Anfang: Keine der drei Techniken oben hätte sie verhindert. Kein Spending Cap wurde überschritten, keine Allowlist umgangen, kein Schlüssel kompromittiert. Der Angriff bestand darin, dass das System den Besitz einer bestimmten NFT als gültige Berechtigung akzeptierte, unabhängig davon, wie diese NFT ins Wallet gelangt war, und dass die anschließende Anweisung als kodierter Text an der inhaltlichen Prüfung vorbeikam. Sicherheitsforscher ordnen das nach dem OWASP-Top-10-Rahmenwerk für LLM-Anwendungen (2025) gleich zwei Kategorien zu: „Prompt Injection" (LLM01) für den Morsecode-Trick, „Excessive Agency" (LLM06) dafür, dass der Agent überhaupt befugt war, eine derart folgenreiche Aktion ohne Rückfrage auszuführen. Zwischen 80 und 88 Prozent des Schadens kamen nach Verhandlungen mit dem Angreifer zurück, der Rest gilt als informelle Bug-Bounty.

Ein zweiter Fall aus demselben Jahr zeigt die andere Seite derselben Medaille. Am 31. Januar 2026 verloren die Solana-Plattform Step Finance und ihre Schwesterprojekte rund 40 Millionen US-Dollar aus Treasury-Wallets, nicht durch einen Smart-Contract-Fehler, sondern weil Angreifer die Endgeräte mehrerer Führungskräfte kompromittierten und darüber direkten Zugriff erhielten. Step Finance stellte den Betrieb am 23. Februar 2026 komplett ein. Die Lehre ist unbequem, aber wichtig: Selbst die sauberste MPC- oder TEE-Architektur schützt nur den Schlüssel, nicht die Geräte und Menschen, die Zugriff auf die Verwaltungsebene darüber haben. Genau dieselbe Faustregel wie bei privaten Seed Phrases, nur eine Stufe höher angewandt.

Vergleich auf einen Blick

Was das für den Einsatz eines Agenten bedeutet

Drei Regeln lassen sich aus beiden Fällen ableiten, unabhängig davon, ob eigene Infrastruktur oder ein Anbieter wie Coinbase, ZeroDev oder Openfort zum Einsatz kommt. Erstens: Ein Agent bekommt nie die Seed Phrase oder den Hauptschlüssel zu sehen, Punkt, dafür sind Session Keys, MPC oder TEE gemacht. Zweitens: Limits gehören eng und kurzlebig gesetzt, nicht großzügig „für den Fall der Fälle", ein Session Cap von 200 statt 20.000 Dollar begrenzt den Schaden eines erfolgreichen Angriffs um den Faktor hundert. Drittens, und das ist die eigentliche Lehre aus Bankr: Jede Berechtigung, die von außen hereinkommt, ein NFT-Transfer, eine Token-Genehmigung, eine Nachricht mit eingebetteter Anweisung, muss als nicht vertrauenswürdige Eingabe behandelt werden, nicht als Zustimmung des Eigentümers. Wer diese drei Punkte umsetzt, hat nicht "keine Risiken", aber er hat das Risiko dahin verschoben, wo es sich auch tatsächlich begrenzen lässt.

Quellen:

Custody-Architektur

• Cobo: What is ERC-4337? Account Abstraction Explained
• bex.co: EIP-7702 Session Keys: How Ethereum's Biggest Wallet Upgrade Lets AI Agents Trade DeFi Without Full Custody (März 2026)
• Openfort: Best AI Agent Wallets for Developers in 2026, Compared
• ChainUp: Coldcard Exploit 2026: Lessons for Institutional Custody

Coinbase Agentic Wallets

• Coinbase Developer Platform: Introducing Agentic Wallets (11. Februar 2026)
• eco.com: Coinbase Agentic Wallets Explained

Grok-Bankr-Exploit (Mai 2026)

• Giskard: How Grok got prompt-injected: an X user drained $150,000 from an AI wallet
• AMBcrypto: AI-linked wallet drained via prompt injection in Bankr exploit
• Coincub: Permission Granted: The Layer AI Agent Wallets Forgot to Defend

Step-Finance-Hack (Januar/Februar 2026)

• BleepingComputer: Step Finance says compromised execs' devices led to $40M crypto theft
• Cointelegraph: Step Finance Shuts Down After $40 Million Hack

Direkter Anschluss

• Was wirklich passiert, wenn KI-Agenten selbst bezahlen
• Wie ein Wallet wirklich entsteht
• Wie sicher ist deine Seed?
• Wallet Generator — ausprobieren
• Seed-Sicherheit — Checksumme prüfen