Web3-Begleiter: Die Open-Source-sichere agentische Wallet

GitHub: blocksecteam/web3-companion

Docker: blocksecteam/web3-companion

KI On-Chain-Transaktionen für Nutzer ausführen zu lassen ist derzeit der heißeste Trend im Krypto-Bereich. Coinbase hat im Februar 2026 Agentic Wallets eingeführt, und McKinsey schätzt, dass der durch KI-Agenten vermittelte Handel bis 2030 weltweit 3–5 Billionen US-Dollar erreichen könnte. Wie Coinbase-CEO Brian Armstrong es formulierte: KI-Agenten können keine Bankkonten eröffnen, aber sie können eine Krypto-Wallet besitzen.

Das Problem besteht darin, dass es KI On-Chain-Assets verwalten zu lassen nichts damit gemein hat, ihr die Verwaltung von Kalendern oder E-Mails zu überlassen. On-Chain-Transaktionen sind unumkehrbar. Keine Rückerstattungen, keine Rückbuchungen. Eine einzige bösartige Signatur kann eine gesamte Wallet in einem einzigen Block leeren. Ohne Sicherheit zählt kein einziges Feature.

BlockSec hat Web3 Companion als Open Source veröffentlicht – eine Agentic Wallet mit Sicherheit als oberster Priorität. Dieser Artikel erläutert das dahinterstehende Sicherheitsdesign: warum aktuelle Agentic-Wallet-Architekturen grundlegend fehlerhaft sind und wie wir Sicherheit von Grund auf in die Wallet-Architektur eingebaut haben.

Wie gefährlich sind aktuelle Agenten: Der OpenClaw-Vorfall

Was passiert, wenn ein KI-Agent keine Sicherheitsgrenzen hat? OpenClaw Anfang 2026 beantwortet diese Frage.

OpenClaw ist ein quelloffener Allzweck-KI-Agent, der in fünf Tagen 100.000 GitHub-Sterne gesammelt hat. Als allgemeiner Agent funktionierte er gut, aber in dem Moment, in dem er Web3-Transaktionen berührte, wurden alle Sicherheitslücken sichtbar.

Private Keys lagen im Klartext in lokalen Dateien, die der Agent lesen konnte. Eine einzige Prompt-Injection-E-Mail genügte, um sie zu stehlen.

Das Signieren war nicht isoliert. Derselbe Prozess, der nicht vertrauenswürdige Webseiten abruf, konnte auch Transaktionen signieren, sodass eine einzige RCE-Schwachstelle einem Angreifer die vollständige Kontrolle über den Agenten und seine Keys über eine bösartige Webseite ermöglichte.

Der Skills-Marktplatz war ein weiterer Schwachpunkt. Forscher stellten fest, dass 7,1 % der ClawHub-Skills Anmeldedaten leakten, und einige waren geradezu darauf ausgelegt, Krypto-Wallets zu leeren.

Auch die Zufallszahlengenerierung war fehlerhaft. OpenClaw verwendete math/rand, einen mit der Systemuhr initialisierten PRNG, auf sicherheitskritischen Pfaden. Forscher zeigten, dass zwei aufeinanderfolgende Token-Werte ausreichten, um den internen Zustand zu rekonstruieren und jeden zukünftigen Token- und Challenge-Wert vorherzusagen. In manchen Code-Pfaden erstreckte sich dies bis zur Wiederherstellung von Wallet-Keys.

Am schlimmsten war, dass es keine Policy-Schicht gab. Zwischen einer Prompt-Injection und einer Geldüberweisung stand nichts. Null Abfangmöglichkeiten.

Die Erkenntnis: Allgemeine KI-Agentenarchitekturen sind für Web3-Transaktionen nicht sicher.

Der grundlegende Fehler in aktuellen KI-Agentenarchitekturen

Dies geht über OpenClaw hinaus. Das Wechseln von Modellen oder das Schreiben strengerer Prompts behebt das Problem nicht. Aktuelle KI-Agentenarchitekturen tragen einen inhärenten Sicherheitsfehler in sich: Das LLM selbst ist eine dauerhaft exponierte Angriffsfläche.

Die Grundursache: LLMs können Anweisungen nicht von Daten unterscheiden. System-Prompts, Benutzernachrichten, Webseiteninhalt, sogar der Name eines Tokens – alles kommt als derselbe Token-Stream an. Das Modell verfügt über keinen zuverlässigen Mechanismus, um „führe dies aus" von „lies dies nur" zu trennen. Daraus folgen drei Konsequenzen.

Erstens ist Prompt-Injection auf der Modellebene unlösbar. Angreifer können Anweisungen in allem verstecken, was der Agent verarbeitet: E-Mails, Contract-Kommentare, Webseiten, Token-Namen. Wenn der Agent Transaktionen signieren kann, verwandelt eine erfolgreiche Injection einen Streich in einen Diebstahl.

Zweitens kann die eigene Skills-basierte Sicherheitsüberprüfung des Agenten unterwandert werden. Ein LLM, das die Transaktionssicherheit beurteilt, verlässt sich vollständig auf den Kontext. Den Kontext vergiften und das Urteil kippt. Bösartige Signaturen passieren problemlos.

Drittens laufen Agenten rund um die Uhr, verarbeiten kontinuierlich nicht vertrauenswürdige Eingaben und können Transaktionen autonom ausführen. Das Angriffsfenster schließt sich nie, und ein einziger Einbruch kann sofortigen Fondsverlust bedeuten.

Die Sicherheits-Community ist sich weitgehend einig: Einem LLM direkten Zugriff auf Private Keys zu geben, in einer Welt, in der Prompt-Injection keine Lösung hat, kommt dem Aufbewahren von Nutzer-Assets in einer Komponente gleich, die jederzeit übernommen werden könnte. Da die Modellebene nicht gehärtet werden kann, muss das Risiko auf der Architekturebene eingedämmt werden. Selbst ein vollständig kompromittiertes Modell sollte keine Nutzergelder bewegen können.

Das Sicherheitsarchitektur von Web3 Companion basiert genau auf diesem Gedanken.

Bedrohungsmodell: Der Agent ist nicht vertrauenswürdig

Web3 Companions Bedrohungsmodell lässt sich in einem Satz zusammenfassen: Der Agent selbst ist nicht vertrauenswürdig. Die gesamte Architektur geht davon aus, dass der Agent jederzeit kompromittiert werden kann.

Wir verlassen uns nicht darauf, den Agenten robust genug zu machen, um jeden Angriff zu erkennen. Eine Verteidigung auf Modellebene funktioniert nicht, wie oben gezeigt. Ihn heute beibringen, Morse-Code-Injections zu erkennen; morgen wechseln Angreifer zu Base64, steganografischem Text in Bildern oder einer harmlos wirkenden PDF. Stattdessen haben wir die Annahme umgekehrt. Der Agent befindet sich innerhalb des Bedrohungsmodells, und der Rest des Systems ist darauf ausgelegt, ihn einzudämmen. Selbst wenn ein Angreifer den Agenten vollständig kontrolliert, bleiben die Nutzer-Assets sicher. Einzeilige Positionierung: The Secure Agentic Wallet – eine Wallet, die ihren eigenen Agenten standardmäßig als nicht vertrauenswürdig behandelt und unabhängig davon sicher bleibt.

Aus diesem Bedrohungsmodell haben wir fünf Designprinzipien abgeleitet.

Prinzip 1: Der Agent darf niemals Private Keys berühren. Private Keys sind die einzige Berechtigung zur Kontrolle von On-Chain-Assets. Wenn der Agent sie lesen kann, bedeutet eine Kompromittierung verlorene Keys. Keys müssen dort gespeichert sein, wo der Agent architektonisch nicht hingelangen kann.

Prinzip 2: Vorbereitung ist keine Autorisierung. Eine Transaktion zu erstellen und sie zu genehmigen sind zwei getrennte Handlungen. Der Agent kann Nutzern helfen, den On-Chain-Zustand zu verstehen und Absichten zusammenzustellen, aber die Signierentscheidung liegt bei einem unabhängigen Backend-Modul, auf das der Agent keinen Zugriff hat.

Prinzip 3: Überprüfung ist Erkennung, keine Durchsetzung. Transaktionssimulation, Calldata-Analyse und Adress-Labeling erkennen gängige Angriffsmuster und helfen Nutzern, Risiken zu verstehen, sind aber kein abschließendes Urteil. Simulationen können fehlschlagen, Labels können fehlen, und die eigene Analyse des LLMs ist selbst anfällig für Prompt-Injection.

Prinzip 4: Harte Policies sind die letzte Absicherung. Angenommen, ein Agent wird dazu gebracht, eine Überweisung von 100.000 US-Dollar zu initiieren, und die Sicherheitsüberprüfung wird manipuliert, um sie zu genehmigen. Ein per Code durchgesetztes Tageslimit von 1.000 US-Dollar blockiert sie dennoch. Der Agent hat keine Berechtigung, diese Limits zu ändern.

Prinzip 5: Kein Nachweis, keine Ausführung. Ein fehlgeschlagener Scan ist kein Freibrief. Fehlende Daten bedeuten nicht „sicher". Wenn Sicherheitsnachweise fehlen, widersprüchlich, veraltet oder unzureichend sind, hält das System an und wartet auf eine explizite Nutzerbestätigung.

Diese fünf Prinzipien werden durch zwei Sicherheitsmodule umgesetzt: Private-Key-Sicherheit und Transaktionssicherheit.

Private-Key-Isolierung: Architektonisch unerreichbar für den Agenten

Das erste Problem ist einfach. Wir möchten einen Assistenten, der On-Chain-Transaktionen vorbereitet, aber ihm Signierfähigkeit zu geben, übergibt die Macht, echtes Geld zu bewegen. Fast jeder Web3-Agenten-Einbruch im Jahr 2025 und 2026 folgte demselben Schema: Private Keys lagen im Agentenprozess, und Angreifer fanden einen Weg, sie zu extrahieren.

Also haben wir die Frage neu formuliert: Was wäre, wenn der Agent buchstäblich nicht signieren kann? Nicht „wird angewiesen, es nicht zu tun", sondern architektonisch nicht kann. Zugriffskontrollen auf Software-Ebene können immer umgangen werden. Wir brauchten etwas Stärkeres.

Web3 Companion setzt Isolierung auf Prozessebene durch. Nur eine Komponente berührt Private Keys: das Secure Signature Module (SSM), ein eigenständiger Go-Prozess. Der Prozessspeicher, die Umgebungsvariablen und das Dateisystem des Agenten enthalten kein Key-Material. Alles, was der Agent jemals sieht, ist eine Transaktionsabsichts-ID. Er kann SSM bitten, diese Absicht zu signieren, aber er kann niemals den dahinterliegenden Key einsehen.

Für die Key-Speicherung haben wir drei Optionen bewertet. Klartext auf der Festplatte: Ein Lesevorgang legt den Key sofort offen. Abgelehnt. Passwortbasierte Verschlüsselung: Erfordert erneute Eingabe bei jedem Neustart, unpraktisch für einen dauerhaft laufenden Docker-Dienst. Abgelehnt. Wir entschieden uns für Envelope-Verschlüsselung: Jeder Wallet-Key wird mit seinem eigenen Datenschlüssel verschlüsselt, und dieser Datenschlüssel wird von einem Master-Key (AWS KMS oder lokales AES-256) umhüllt. Selbst wenn die verschlüsselten Dateien vollständig exfiltriert werden, sind sie ohne den Master-Key nutzlos. Keys existieren nur kurzzeitig im Klartext im SSM-Speicher und werden direkt nach dem Signieren auf null gesetzt.

Jede Signieranfrage geht denselben Weg. Keine schnelle Spur, keine Abkürzung. Eine Transaktion durchläuft der Reihe nach sieben Schritte: Delegationsprüfung, Simulation, Sicherheitscheck, Agenten-Sicherheitsüberprüfung, Policy-Auswertung, Passkey-Genehmigung und schließlich SSM-Signierung. Der Abschluss eines Schritts überspringt niemals den nächsten.

Ein Detail auf niedriger Ebene, das erwähnenswert ist: Jedes zufällige Byte im System (Private-Key-Generierung, AES-GCM-Nonces, Auth-Tokens, WebAuthn-Challenges) stammt aus crypto/rand, der kryptografischen Zufallsquelle des Betriebssystems. math/rand ist in sämtlichem sicherheitskritischen Code verboten, durchgesetzt durch Tests und CI.

Transaktionssicherheit: Vier Schichten der Defense-in-Depth

Die Private-Key-Isolierung deckt die Key-Sicherheit ab, aber Risiken auf Transaktionsebene bleiben bestehen. Ein kompromittierter Agent kann eine völlig legitim aussehende Transaktionsabsicht zusammenstellen, um Nutzer zu täuschen oder Auto-Signing-Policies zu überlisten. Prompt-Injection braucht den Private Key nicht; sie muss nur das System dazu bringen, eine bösartige Transaktion durch den normalen Ablauf zu signieren.

Die Kernfrage: Wenn der Agent, der Transaktionen vorbereitet, selbst kompromittiert sein könnte, wie erkennt man eine bösartige Transaktion?

Keine einzelne Verteidigungsschicht hält allein stand. Simulation allein? Simulationen schlagen fehl, RPCs gehen offline, neuartige Angriffe fallen außerhalb bekannter Muster. LLM-basierte Überprüfung allein? Dieselbe Injection, die den Agenten kompromittiert hat, kompromittiert auch den Prüfer, da beide auf LLMs laufen. Ein pauschales hartes Limit allein? Legitime Nutzer stoßen an eine Wand; ein 100-Dollar-Limit bei jedem Swap ist nicht nutzbar.

Wir schichten alle vier zusammen. Jede Schicht geht davon aus, dass jede vorherige Schicht bereits versagt hat.

Schicht 1: Transaktionssimulation. Vor dem Signieren simuliert das System die Ausführung: Calldata-Dekodierung, Revert-Vorhersage, Feldformat-Prüfungen. Die Simulation erkennt offensichtliche Probleme, hat aber blinde Flecken. Neue Angriffstechniken und RPC-Ausfälle können beide überwunden werden.

Schicht 2: Gegenpartei-Bewertung. Eine Reihe statischer Prüfungen zielt auf die Gegenpartei ab: Empfänger-/Betragsabgleich, Erkennung unbegrenzter Genehmigungen, Erkennung von Burn-Adressen, unerwartete Delegate-Calls. Die Risikobewertung von Adressen läuft über den Compliance-Dienst x402 von BlockSec, bei dem der Agent Labels und Risikobewertungen über x402-Mikrozahlungen abfragt, ohne dass ein API-Schlüssel oder ein Abonnement erforderlich ist. Schichten 1 und 2 zusammen erkennen die meisten häufigen Probleme, können aber beide umgangen werden. Ihre Rolle ist bewusst auf Erkennung und Erklärung beschränkt, nicht auf endgültige Entscheidungen.

Schicht 3: Harte Policy-Durchsetzung. Reine Code-Durchsetzung in Go. Das LLM ist nicht beteiligt, und der Agent kann die Regeln nicht ändern. Limits pro Transaktion, Tagesbudgets, Empfänger-Whitelists, Auto-Signing-Schwellenwerte: Eine Überweisung von 5.000 US-Dollar gegen ein Limit von 100 US-Dollar pro Transaktion wird sofort abgelehnt. Das Ändern der Policy selbst erfordert einen Passkey. Warum? Wenn der Agent Policies bearbeiten könnte, würde eine Injection zuerst das Limit erhöhen und dann die Wallet leeren. Auto-Signing ist standardmäßig deaktiviert; jede Transaktion erfordert manuelle Genehmigung, bis der Nutzer explizit zustimmt.

Das bedeutet: Selbst wenn jede Erkennungsschicht umgangen wird und ein vollständig kompromittierter Agent eine bösartige Transaktion signiert, ist der tatsächliche Verlust durch die Policy begrenzt. Wenn der Nutzer den täglichen Auto-Signing-Schwellenwert auf 500 US-Dollar setzt, beträgt der schlimmste Fall 500 US-Dollar, nicht die gesamte Wallet. Die Policy-Schicht verwandelt eine Kompromittierung von einem katastrophalen Ereignis in einen begrenzten Verlust.

Schicht 4: Nutzerbestätigung (Passkey). Wenn die Policy eine manuelle Genehmigung erfordert, verlangt das System eine WebAuthn-Verifizierung (Fingerabdruck oder Gesicht). Kein reiner Software-Exploit kann dies fälschen.

Die vier Schichten operieren auf gegenseitigem Misstrauen. Jede geht davon aus, dass alles davor bereits versagt hat. Eine perfekte Simulation lockert die Policy nicht. Eine falsch konfigurierte Policy überspringt den Passkey nicht. Jede Schicht steht für sich.

Ein leicht zu übersehenes Detail: die Wiederverwendung von Urteilen. Eine bekannte DeFi-Angriffstechnik spielt ein altes Sicherheitsurteil gegen eine modifizierte Transaktion ab. Web3 Companion bindet jede Schreiboperation an eine eindeutige Transaktionsabsicht mit prüfbaren Zustandsübergängen. Ein Sicherheitsurteil gilt nur für die genaue Absicht, die es überprüft hat. Wenn der Agent eine Transaktion neu erstellt, selbst wenn nur der Betrag oder der Empfänger geändert wird, behandelt das System sie als brandneue Absicht und führt alle Prüfungen erneut durch.

Die vier Verteidigungsschichten sind drei unabhängigen Vertrauensgrenzen zugeordnet: Private Key, Policy und Passkey. Jeder einzelne Grenzverstoß lässt die anderen zwei bestehen:

Sicherheit durch Design: Die Philosophie hinter Open Source

BlockSec arbeitet seit dem ersten Tag an On-Chain-Sicherheit. Wir haben Milliarden von US-Dollar in On-Chain-Assets geschützt und dieselbe Lektion immer wieder erlebt: Sicherheit, die nicht von Anfang an in die Architektur eingebaut ist, kommt immer zu spät.

KI-Agenten werden zur neuen Eingangstür für On-Chain-Transaktionen. Der Bereich entwickelt sich schnell, aber Sicherheitsstandards existieren kaum. Die meisten Teams konzentrieren sich darauf, was ihr Agent leisten kann. Nur wenige haben ernsthaft gefragt: Wenn dieser Agent übernommen wird, kann die Architektur den Schadensradius begrenzen?

Web3 Companion ist BlockSecs Bemühung, jahrelange On-Chain-Sicherheitsarbeit in eine Agentic-Wallet-Architektur einfließen zu lassen. Der Code ist vollständig unter der MIT-Lizenz offen (derzeit als Research Preview gekennzeichnet). Die Branche braucht jetzt einen konkreten Sicherheitsdesign-Referenzpunkt. Wie man Bedrohungsmodelle strukturiert, wie man Keys isoliert, wie weit man Transaktionsverteidigung treiben soll: Kein Team sollte das von Grund auf neu erfinden müssen. Wir veröffentlichen das vollständige Design, damit die Community darauf aufbauen kann.