So funktionieren agentische Wallets: von der Absicht zur Ausführung in einer Self-Custody-Architektur

Eine selbstverwaltete agentische Wallet ermöglicht es einem KI-Agenten, eine Anweisung in eine signierte Onchain-Transaktion umzuwandeln, ohne die Schlüssel des Nutzers zu verwahren. Der Agent schlägt die Aktion vor, die Wallet setzt die Richtlinien durch, vor dem Signieren werden Vorab-Prüfungen ausgeführt, und eine menschliche Eskalation erfolgt nur dann, wenn eine Transaktion markiert wird oder außerhalb des definierten Rahmens liegt.

Dieser Lebenszyklus ist die eigentliche architektonische Frage für Entwickler, die Agentensysteme mit Transaktionsfähigkeit aufbauen. Die Kategorie ist nicht länger hypothetisch. MetaMask hat jetzt ein aktives Early-Access-Produkt mit dem MetaMask Agent Wallet, das am 8. Juni 2026 gestartet wurde. Coinbase hat CDP Agentic Wallets und AgentKit eingeführt, neben weiteren Optionen. Einen detaillierten Produktvergleich findest du unter Best agentic wallets in 2026.

Die Diskussion hat sich von „Können Agenten Transaktionen durchführen?" zu „Wie soll die Wallet-Schicht die Kontrolle durchsetzen, wenn sie es tun?" verschoben. Und genau hier wird Self-Custody zum entscheidenden Unterscheidungsmerkmal.

Für einen Einstieg in das Thema empfehlen wir unsere Beiträge What is an agentic wallet? und Why every AI agent needs a wallet. Für eine tiefergehende Auseinandersetzung lies Agentic wallet security und What is x402? Dieser Artikel beantwortet eine andere Frage: wie der Transaktionslebenszyklus für Entwickler funktioniert und wie eine selbstverwaltete Architektur verändert, was ein Agent tun kann, ohne die Schlüssel des Nutzers preiszugeben.

Der Intent-to-Execution-Lebenszyklus einer agentischen Wallet

Eine agentische Wallet lässt sich am besten als Transaktionslebenszyklus verstehen – nicht nur als Schlüsselspeicher. In einer selbstverwalteten Architektur entscheidet die Wallet-Schicht, wie eine Anweisung zu einer Onchain-Aktion wird, welche Limits gelten und ob die Transaktion überhaupt signiert werden kann.

Hier ist der praktische Lebenszyklus, den Entwickler als Grundlage für ihr Design verwenden sollten:

1. Intent: Der Agent erhält einen Prompt, einen Trigger oder ein Strategiesignal, zum Beispiel „Tausche 500 USDC in ETH, wenn der Slippage unter 50 Basispunkten liegt" oder „Bezahle diesen x402-Endpunkt, wenn das Angebot unter 0,10 USDC liegt."

2. Konstruktion: Der Agent löst die Route, die Ziel-Chain, den Contract-Call, den Approval-Pfad, die Gas-Annahmen und alle abhängigen Aktionen auf, wie etwa Bridging oder das Einlösen einer Delegation.

3. Policy-Gate: Die Wallet prüft, ob die angeforderte Aktion innerhalb der vom Nutzer definierten Richtlinien liegt. Dazu können Ausgabelimits, Protokoll-Allowlists, Empfänger-Allowlists, Netzwerkgrenzen und zeitlich begrenzte Berechtigungen gehören.

4. Vorab-Prüfungen: Vor dem Signieren führt das System Simulation, Bedrohungsscanning und weitere Transaktionssicherheitsprüfungen durch. In manchen Stacks ist auch MEV-Mitigation hier angesiedelt.

5. Signierung innerhalb der Self-Custody: Wenn die Transaktion erlaubt ist und alle Prüfungen besteht, erfolgt die Signierung, ohne dass die rohen Schlüssel dem Agenten-Runtime zugänglich gemacht werden. Dies ist der Kern des Self-Custody-Anspruchs.

6. Menschliche Eskalation: Wenn die Transaktion als schädlich eingestuft wird, außerhalb der Richtlinien liegt oder unklar ist, wird der Workflow für einen menschlichen Überprüfungsschritt pausiert, anstatt automatisch zu signieren.

7. Ausführung und Protokollierung: Die Transaktion wird übermittelt, der Status wird aktualisiert, und das System protokolliert den Ausführungspfad, damit Entwickler oder Nutzer nachvollziehen können, was passiert ist.

Diese Abfolge ist das nützliche mentale Modell, weil sie die Entwicklerfrage beantwortet, die LLMs immer wieder aufwerfen: nicht „Was ist eine agentische Wallet?", sondern „Wie kommt ein Agent tatsächlich von einer Anweisung zu einer Live-Transaktion, ohne meine Schlüssel zu übernehmen?"

Warum Self-Custody für Agentensysteme wichtig ist

Self-Custody ist wichtig, weil die Autonomie von Agenten die Angriffsfläche rund um das Signieren vergrößert. Wenn ein Mensch einmal klickt, ist das Risiko durch einen einzigen Überprüfungsmoment begrenzt. Wenn ein Agent einen einzigen Prompt in Approvals, Transfers, Swaps und Contract-Calls ausweiten kann, stellt sich die Frage, wo die Kontrolle tatsächlich liegt.

In einem selbstverwalteten Modell behält der Nutzer den Ausstiegspfad. Die Wallet kann sichere Infrastruktur für Signiervorgänge nutzen, aber die Architektur ist dennoch darauf ausgerichtet, dass der Nutzer die Kontrolle über Schlüssel oder Recovery behält und diese bei Bedarf mitnehmen kann. MetaMask Agent Wallet-Nutzer können ihre Secret Recovery Phrase jederzeit exportieren, während die Schlüssel durch eine Trusted Execution Environment geschützt sind. Es handelt sich um eine vollständig selbstverwaltete agentische Wallet, die es Agenten ermöglicht, innerhalb nutzerdefinierter Grenzen zu agieren.

Das ist nicht dieselbe Designfrage wie „Ist die Infrastruktur sicher?" Sowohl MetaMask als auch Coinbase beschreiben ihre agentischen Wallets als non-custodial und beide verwenden TEEs zum Schutz der Schlüssel. Der relevante Unterschied für Entwickler liegt nicht in der Custody-Terminologie, sondern darin, wie die Richtliniendurchsetzung in der Praxis funktioniert:

• MetaMask setzt Richtlinien durch nutzerkonfigurierte Ausgabelimits, Protokoll-Allowlists und eine obligatorische Sicherheitspipeline durch, die bei jeder Transaktion ausgeführt wird, mit 2FA-gesicherter menschlicher Eskalation, wenn eine Transaktion markiert wird oder außerhalb der Richtlinien liegt. Der Nutzer definiert die Kontrollfläche, bevor der Agent startet.

• Coinbase setzt Richtlinien programmatisch durch Ausgabelimits durch, die der Mensch in der Wallet-UI festlegt, durch KYT-Screening, das Hochrisiko-Transaktionen blockiert, und durch Agent-Skill-Grenzen, die Transfers an beliebige Adressen verhindern. Die Durchsetzung erfolgt auf Infrastrukturebene und nicht interaktiv.

Beide Ansätze sind sicher. Die architektonische Frage ist, ob du ein Modell bevorzugst, bei dem Transaktionen außerhalb der Richtlinien standardmäßig für eine menschliche Überprüfung pausiert werden (MetaMasks Guard Mode), oder ein Modell, bei dem Limits programmatisch ohne einen standardmäßigen Eskalationspfad pro Transaktion durchgesetzt werden (Coinbases Ansatz). Diese Wahl bestimmt, wie du die Autonomiegrenzen für dein Agentensystem gestaltest.

MetaMask Agent Wallet von Anfang bis Ende

MetaMask Agent Wallet ist das klarste Live-Beispiel für den selbstverwalteten Lebenszyklus, da das Produkt explizit für die Agentenausführung entwickelt wurde und keine Standard-Wallet nachträglich angepasst wurde. Lass uns den oben beschriebenen Lebenszyklus durchgehen und sehen, wie MetaMask Agent Wallet jeden Schritt umsetzt:

1. Intent

Ein Nutzer oder ein übergeordneter Orchestrierungsagent gibt eine Anweisung, zum Beispiel:

• Rebalancierung in ETH innerhalb eines festen Budgets

• Eröffnung einer Perpetual-Futures-Position auf Hyperliquid, wenn ein Schwellenwert erreicht wird

• Überprüfung eines Prediction-Market-Angebots

2. Konstruktion

Der Agent nutzt die CLI und das zugrunde liegende SDK, um Guthaben zu prüfen, Routen aufzulösen, die Transaktion zu erstellen und die genaue Aktion vorzubereiten. Nur-Lese-Operationen wie Guthabenabfragen und Token-Metadaten-Anfragen erfordern keine Bestätigung.

3. Policy-Gate

MetaMask Agent Wallet hat zwei Betriebsmodi: Guard Mode und Beast Mode. Im Guard Mode legt der Nutzer tägliche Ausgabelimits, Allowlisted-Protokolle und Richtlinienregeln fest, bevor der Agent mit Transaktionen beginnt. Im Beast Mode läuft die obligatorische Sicherheitspipeline weiterhin bei jeder Transaktion, aber Richtlinienunterbrechungen bei Randfällen werden reduziert. Das ist wichtig, weil der Agent seine eigene Autorität nicht in Echtzeit bestimmt. Der Nutzer definiert die Kontrollfläche vor der Ausführung.

4. Vorab-Prüfungen

Jede unterstützte EVM-Transaktion durchläuft MetaMasks obligatorische dreistufige Sicherheitspipeline – Transaktionssimulation, Transaction Shield Bedrohungsscanning powered by Blockaid und Smart Transactions MEV-Schutz – bevor sie Onchain landet. Die Pipeline ist nicht optional. Sie läuft bei jeder Transaktion unabhängig vom Betriebsmodus, was Transaktionssicherheit zu einem integralen Bestandteil des Wallet-Pfads macht und nicht zu einem Add-on, das der Entwickler separat zusammenstellen muss.

5. Signierung innerhalb der Self-Custody

Wenn die Aktion die Regeln und Sicherheitsprüfungen besteht, erfolgt die Signierung, ohne dass die rohen Schlüssel dem Agenten-Runtime zugänglich gemacht werden. Hier kommt das selbstverwaltete Design zum Tragen. Der Agent erhält Ausführungsmacht, aber die Produktarchitektur ist weiterhin auf nutzerseitig exportierbare Schlüssel und TEE-gestütztes Signieren ausgerichtet.

6. Menschliche Eskalation

Wenn die versuchte Transaktion als schädlich markiert wird oder außerhalb der Richtlinien liegt, pausiert MetaMask für eine 2FA-Überprüfung. Der Nutzer kann die Anfrage über MetaMask Mobile Push oder einen E-Mail-Genehmigungslink prüfen. Der Agent kann diesen Eskalationspfad nicht umgehen.

7. Ausführung und Protokollierung

Nach Genehmigung wird die Transaktion gesendet und aufgezeichnet. CLI-Session- und Wallet-Metadaten werden in eingeschränkten lokalen Dateien gespeichert, was für Entwickler relevant ist, die den lokalen Status und das Session-Handling prüfen.