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 in der Krypto-Welt. 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 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 ist, dass KI On-Chain-Assets verwalten zu lassen überhaupt nicht damit vergleichbar ist, ihr Kalender oder E-Mails zu überlassen. On-Chain-Transaktionen sind unumkehrbar. Keine Rückerstattungen, keine Rückbuchungen. Eine einzige bösartige Signatur kann in einem einzigen Block eine gesamte Wallet leeren. Ohne Sicherheit spielt kein Feature eine Rolle.

BlockSec hat Web3 Companion, eine sicherheitsorientierte Agentic Wallet, als Open Source veröffentlicht. Dieser Artikel erläutert das Sicherheitsdesign dahinter: 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, traten alle Sicherheitslücken zutage.

Private Schlüssel lagen im Klartext in lokalen Dateien, die der Agent lesen konnte. Eine einzige Prompt-Injection-E-Mail reichte aus, um sie zu entwenden.

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

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

Auch die Zufallszahlengenerierung war fehlerhaft. OpenClaw verwendete math/rand, einen PRNG, der mit der Systemuhr initialisiert wird, 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 einigen Code-Pfaden erstreckte sich dies bis zur Wiederherstellung von Wallet-Schlüsseln.

Am schlimmsten war das Fehlen einer Policy-Schicht. Zwischen einer Prompt-Injection und einer Geldüberweisung stand nichts. Null Abfangmöglichkeit.

Das Fazit: Allzweck-KI-Agenten-Architekturen sind für Web3-Transaktionen nicht sicher.

Der grundlegende Fehler in aktuellen KI-Agenten-Architekturen

Das geht über OpenClaw hinaus. Das Wechseln von Modellen oder das Schreiben strengerer Prompts behebt das Problem nicht. Aktuelle KI-Agenten-Architekturen weisen einen inhärenten Sicherheitsfehler auf: 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-Strom an. Das Modell verfügt über keinen zuverlässigen Mechanismus, um „führe das aus" von „lies das 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 unterlaufen werden. Ein LLM, das die Transaktionssicherheit beurteilt, verlässt sich vollständig auf den Kontext. Vergiftet man den Kontext, dreht sich das Urteil um. Bösartige Signaturen werden durchgelassen.

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 Geldverlust bedeuten.

Die Sicherheitsgemeinschaft ist sich weitgehend einig: einem LLM direkten Zugang zu privaten Schlüsseln zu geben, in einer Welt, in der Prompt-Injection keine Heilung kennt, läuft darauf hinaus, Nutzervermögen in einer Komponente zu belassen, 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 nicht in der Lage sein, Nutzermittel zu verschieben.

Die Sicherheitsarchitektur von Web3 Companion basiert genau auf diesem Gedanken.

Bedrohungsmodell: Der Agent ist nicht vertrauenswürdig

Das Bedrohungsmodell von Web3 Companion 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. Die Abwehr auf Modellebene funktioniert nicht, wie oben gezeigt. Trainiert man ihn heute, Morse-Code-Injektionen zu erkennen, wechseln Angreifer morgen zu Base64, steganografischem Text in Bildern oder einer harmlos aussehenden PDF-Datei. Stattdessen haben wir die Annahme umgekehrt. Der Agent sitzt innerhalb des Bedrohungsmodells, und der Rest des Systems ist darauf ausgelegt, ihn einzuschränken. Selbst wenn ein Angreifer den Agenten vollständig kontrolliert, bleiben die Vermögenswerte der Nutzer 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 private Schlüssel niemals berühren. Private Schlüssel sind die einzige Zugangsberechtigung zur Kontrolle von On-Chain-Assets. Wenn der Agent sie lesen kann, bedeutet eine Kompromittierung verlorene Schlüssel. Schlüssel müssen dort aufbewahrt werden, wo der Agent sie architektonisch nicht erreichen kann.

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

Prinzip 3: Überprüfung ist Erkennung, keine Durchsetzung. Transaktionssimulation, Calldata-Analyse und Adressbeschriftung erkennen gängige Angriffsmuster und helfen Nutzern, Risiken zu verstehen, aber sie sind nicht das endgültige Urteil. Simulationen können scheitern, Beschriftungen können fehlen, und die eigene Analyse des LLM ist selbst anfällig für Prompt-Injection.

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

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

Diese fünf Prinzipien werden durch zwei Sicherheitsmodule umgesetzt: Sicherheit des privaten Schlüssels und Transaktionssicherheit.

Isolation privater Schlüssel: Architektonisch unerreichbar für den Agenten

Das erste Problem ist einfach. Wir wollen einen Assistenten, der On-Chain-Transaktionen vorbereitet, aber ihm Signierfähigkeiten zu geben, überträgt die Macht, echtes Geld zu bewegen. Fast jeder Web3-Agenten-Einbruch in 2025 und 2026 folgte demselben Muster: Private Schlüssel 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 Softwareebene können immer umgangen werden. Wir brauchten etwas Stärkeres.

Web3 Companion erzwingt Isolation auf Prozessebene. Nur eine Komponente berührt private Schlüssel: das Secure Signature Module (SSM), ein eigenständiger Go-Prozess. Der Prozessspeicher, die Umgebungsvariablen und das Dateisystem des Agenten enthalten kein Schlüsselmaterial. Alles, was der Agent jemals sieht, ist eine Transaktionsabsichts-ID. Er kann SSM bitten, diese Absicht zu signieren, aber er kann den Schlüssel dahinter niemals sehen.

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

Jede Signieranfrage durchläuft denselben Pfad. Keine Abkürzung, kein Umweg. Eine Transaktion durchläuft sieben Schritte in der Reihenfolge: Delegationsprüfung, Simulation, Sicherheitscheck, Agenten-Sicherheitsüberprüfung, Richtlinienauswertung, Passkey-Genehmigung und schließlich SSM-Signierung. Das Abschließen eines Schritts überspringt niemals den nächsten.

Ein technisches Detail, das Erwähnung verdient: Jedes zufällige Byte im System (Erzeugung privater Schlüssel, AES-GCM-Nonces, Auth-Tokens, WebAuthn-Challenges) stammt aus crypto/rand, der kryptografischen Zufallsquelle des Betriebssystems. math/rand ist in allen sicherheitskritischen Codes verboten, durchgesetzt durch Tests und CI.

Transaktionssicherheit: Vier Schichten der Verteidigung in der Tiefe

Die Isolation privater Schlüssel deckt die Schlüsselsicherheit ab, aber Risiken auf Transaktionsebene bleiben bestehen. Ein kompromittierter Agent kann eine vollkommen legitim aussehende Transaktionsabsicht zusammenstellen, um Nutzer zu täuschen oder Auto-Signing-Richtlinien auszutricksen. Prompt-Injection braucht den privaten Schlüssel nicht; sie muss nur dafür sorgen, dass das System eine bösartige Transaktion durch den normalen Ablauf signiert.

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

Keine einzelne Verteidigungsschicht hält für sich allein stand. Nur Simulation? Simulationen scheitern, RPCs fallen aus, neuartige Angriffe liegen außerhalb bekannter Muster. Nur LLM-basierte Überprüfung? Die gleiche Injection, die den Agenten kompromittiert hat, kompromittiert auch den Überprüfer, da beide auf LLMs laufen. Nur ein festes Hartlimit? Legitime Nutzer stoßen gegen eine Wand; ein 100-$-Limit bei jedem Swap ist unbrauchbar.

Wir schichten alle vier übereinander. Jede Schicht geht davon aus, dass jede Schicht vor ihr bereits versagt hat.

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

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 erfolgt über den Compliance-Service x402 von BlockSec, bei dem der Agent Labels und Risikobewertungen über x402-Mikrozahlungen abfragt, ohne API-Schlüssel oder Abonnement. Schichten 1 und 2 zusammen erkennen die meisten gängigen Probleme, aber beide können umgangen werden. Ihre Rolle ist bewusst auf Erkennung und Erläuterung beschränkt, nicht auf endgültige Entscheidungen.

Schicht 3: Durchsetzung harter Richtlinien. 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 $ gegen ein Limit von 100 $ pro Transaktion wird sofort abgelehnt. Das Ändern der Richtlinie selbst erfordert den Passkey. Warum? Wenn der Agent Richtlinien bearbeiten könnte, würde eine Injection zunächst das Limit erhöhen und dann die Wallet leeren. Auto-Signing ist standardmäßig deaktiviert; jede Transaktion erfordert manuelle Genehmigung, bis der Nutzer sich ausdrücklich dafür entscheidet.

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

Schicht 4: Nutzerbestätigung (Passkey). Wenn die Richtlinie eine manuelle Genehmigung verlangt, erfordert 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. Perfekte Simulation lockert die Richtlinie nicht. Eine falsch konfigurierte Richtlinie überspringt den Passkey nicht. Jede Schicht steht für sich.

Ein Detail, das leicht übersehen wird: 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 nachvollziehbaren 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 Betrag oder Empfänger geändert wird, behandelt das System sie als brandneue Absicht und führt alle Prüfungen erneut durch.

Die vier Verteidigungsschichten entsprechen drei unabhängigen Vertrauensgrenzen: Privater Schlüssel, Richtlinie und Passkey. Jeder einzelne Grenzübertritt lässt die anderen beiden bestehen:

Sicherheit durch Design: Die Philosophie hinter Open Source

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

KI-Agenten werden zu einer 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 tun 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 veröffentlicht (derzeit als Forschungsvorschau gekennzeichnet). Die Branche braucht jetzt einen konkreten Sicherheitsdesign-Referenzpunkt. Wie man Bedrohungsmodelle strukturiert, wie man Schlüssel isoliert, wie weit man die Transaktionsabwehr vorantreibt: Kein Team sollte das von Grund auf neu erfinden müssen. Wir veröffentlichen das vollständige Design, damit die Community darauf aufbauen kann.