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 Kryptowelt. Coinbase hat im Februar 2026 Agentic Wallets eingeführt, und McKinsey schätzt, dass AI Agent-vermittelter Handel bis 2030 weltweit 3–5 Billionen Dollar erreichen könnte. Wie Coinbase-CEO Brian Armstrong sagte: AI Agents können keine Bankkonten eröffnen, aber sie können eine Krypto-Wallet besitzen.
Das Problem ist: KI On-Chain-Vermögenswerte verwalten zu lassen, ist etwas völlig anderes als Kalender oder E-Mails zu managen. On-Chain-Transaktionen sind irreversibel. Keine Rückerstattungen, keine Rückbuchungen. Eine einzige bösartige Signatur kann eine gesamte Wallet in einem Block leeren. Ohne Sicherheit spielt keine Funktion eine Rolle.
BlockSec hat Web3 Companion als Open Source veröffentlicht, eine Security-First Agentic Wallet. Dieser Artikel geht durch 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 Agents: Der OpenClaw-Vorfall
Was passiert, wenn ein AI Agent keine Sicherheitsgrenzen hat? OpenClaw Anfang 2026 beantwortet diese Frage.
OpenClaw ist ein universeller Open-Source AI Agent, der in fünf Tagen 100.000 GitHub-Sterne sammelte. Als universeller Agent funktionierte er gut, aber sobald er Web3-Transaktionen berührte, zeigten sich sämtliche Sicherheitslücken.
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 stehlen.
Die Signierung hatte keine Isolierung. Derselbe Prozess, der nicht vertrauenswürdige Webseiten abrief, konnte auch Transaktionen signieren, sodass eine einzige RCE-Schwachstelle einem Angreifer die vollständige Kontrolle über den Agent und seine Schlüssel über eine bösartige Webseite ermöglichte.
Der Skills-Marktplatz war eine weitere Schwachstelle. Forscher fanden heraus, dass 7,1 % der ClawHub Skills Zugangsdaten preisgaben und einige gezielt darauf ausgelegt waren, Krypto-Wallets zu leeren.
Auch die Zufallszahlengenerierung war fehlerhaft. OpenClaw verwendete math/rand, einen mit der Systemuhr geseedeten 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 einigen Codepfaden erstreckte sich dies bis zur Wiederherstellung von Wallet-Schlüsseln.
Am schlimmsten war: Es gab keine Policy-Schicht. Nichts stand zwischen einer prompt injection und einer Geldüberweisung. Keine Abfangmechanismen.
Die Erkenntnis: Universelle AI Agent-Architekturen sind für Web3-Transaktionen nicht sicher.
Der grundlegende Fehler in aktuellen AI Agent-Architekturen
Dies geht über OpenClaw hinaus. Modelle wechseln oder strengere Prompts schreiben löst das Problem nicht. Aktuelle AI Agent-Architekturen tragen einen inhärenten Sicherheitsfehler: Das LLM selbst ist eine permanent exponierte Angriffsfläche.
Die Ursache: LLMs können Anweisungen nicht von Daten unterscheiden. Systemanweisungen, Benutzernachrichten, Webseiteninhalte, selbst der Name eines Tokens — alles kommt als derselbe Token-Strom an. Das Modell hat keinen zuverlässigen Mechanismus, um „führe dies aus” von „lies dies nur” zu trennen. Drei Konsequenzen folgen daraus.
Erstens: prompt injection ist auf der Modellebene unlösbar. Angreifer können Anweisungen in allem verstecken, was der Agent aufnimmt: E-Mails, Smart-Contract-Kommentare, Webseiten, Token-Namen. Wenn der Agent Transaktionen signieren kann, verwandelt eine erfolgreiche Injektion einen Streich in Diebstahl.
Zweitens: Die eigene Skills-basierte Sicherheitsprüfung des Agent kann unterwandert werden. Ein LLM, das die Transaktionssicherheit beurteilt, verlässt sich vollständig auf den Kontext. Vergiftet man den Kontext, kippt das Urteil. Bösartige Signaturen passieren ungehindert.
Drittens: Agents laufen rund um die Uhr, konsumieren ununterbrochen nicht vertrauenswürdige Eingaben und können autonom Transaktionen ausführen. Das Angriffsfenster schließt sich nie, und ein einziger Einbruch kann sofortigen Fondsverlust bedeuten.
Die Sicherheitsgemeinschaft stimmt weitgehend überein: Einem LLM direkten Zugang zu privaten Schlüsseln zu geben — in einer Welt, in der prompt injection keine Heilung hat — kommt dem gleich, Nutzer-Vermögenswerte in einer Komponente zu belassen, die jederzeit kompromittiert 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 Nutzerfonds bewegen können.
Die Sicherheitsarchitektur von Web3 Companion basiert genau auf dieser Idee.
Bedrohungsmodell: Der Agent ist nicht vertrauenswürdig
Das Bedrohungsmodell von Web3 Companion passt in einen Satz: 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 Agent robust genug zu machen, um jeden Angriff zu erkennen. Verteidigung auf Modellebene funktioniert nicht, wie oben gezeigt. Trainiert man ihn heute, Morsecode-Injektionen zu erkennen, wechseln Angreifer morgen zu Base64, steganographischem Text in Bildern oder einem harmlos aussehenden PDF. Stattdessen haben wir die Prämisse umgekehrt. Der Agent befindet sich innerhalb des Bedrohungsmodells, und der Rest des Systems ist darauf ausgelegt, ihn einzudämmen. Selbst wenn ein Angreifer den Agent vollständig kontrolliert, bleiben die Nutzer-Vermögenswerte sicher. Positionierung in einem Satz: Die Sichere Agenten-Wallet — eine Wallet, die ihren eigenen Agent 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 Schlüssel berühren. Private Schlüssel sind die einzige Berechtigung, die On-Chain-Vermögenswerte kontrolliert. Wenn der Agent sie lesen kann, bedeutet eine Kompromittierung verlorene Schlüssel. Schlüssel müssen dort liegen, wo der Agent architektonisch nicht hingelangen kann.
Prinzip 2: Vorbereitung ist keine Autorisierung. Eine Transaktion aufzubauen und sie zu genehmigen sind zwei getrennte Handlungen. Der Agent kann Nutzern helfen, den On-Chain-Zustand zu verstehen und Absichten zusammenzustellen, aber die Signaturentscheidung gehört einem unabhängigen Backend-Modul, auf das der Agent keinen Zugriff hat.
Prinzip 3: Prüfung ist Erkennung, nicht Durchsetzung. Transaktionssimulation, calldata-Analyse und Adress-Labeling erkennen gängige Angriffsmuster und helfen Nutzern, Risiken zu verstehen, sind aber nicht das endgültige Urteil. Simulationen können fehlschlagen, Labels können fehlen, und die eigene Analyse des LLM ist selbst anfällig für prompt injection.
Prinzip 4: Harte Policies sind die letzte Verteidigungslinie. Angenommen, ein Agent wird dazu gebracht, eine 100.000-Dollar-Überweisung zu initiieren, und die Sicherheitsprüfung wird manipuliert, sie zu genehmigen. Ein codebasiertes Tageslimit von 1.000 Dollar blockiert sie trotzdem. Der Agent hat keine Berechtigung, diese Limits zu ändern.
Prinzip 5: Ohne Beweis keine Ausführung. Ein fehlgeschlagener Scan ist keine Freigabe. Fehlende Daten sind nicht „sicher”. Wenn Sicherheitsnachweise fehlen, widersprüchlich, veraltet oder unzureichend sind, hält das System an und wartet auf explizite Nutzerbestätigung.
Diese fünf Prinzipien werden durch zwei Sicherheitsmodule implementiert: Sicherheit der privaten Schlüssel und Transaktionssicherheit.
Isolierung privater Schlüssel: Architektonisch unerreichbar für den Agent
Das erste Problem ist einfach. Wir wollen einen Assistenten, der On-Chain-Transaktionen vorbereitet, aber ihm Signaturfähigkeit zu geben, überträgt die Macht, echtes Geld zu bewegen. Nahezu jeder Web3-Agent-Einbruch in 2025 und 2026 folgte dem gleichen Muster: Private Schlüssel befanden sich im Agent-Prozess, 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 „angewiesen wird, nicht zu signieren”, sondern architektonisch nicht kann. Software-Level-Zugriffskontrollen können immer umgangen werden. Wir brauchten etwas Stärkeres.
Web3 Companion erzwingt Prozess-Level-Isolierung. Nur eine Komponente berührt private Schlüssel: das Secure Signature Module (SSM), ein eigenständiger Go-Prozess. Der Prozessspeicher des Agent, Umgebungsvariablen und das Dateisystem enthalten kein Schlüsselmaterial. Alles, was der Agent sieht, ist eine Transaktionsabsichts-ID. Er kann SSM bitten, diese Absicht zu signieren, aber er kann niemals den Schlüssel dahinter sehen.
Für die Schlüsselspeicherung haben wir drei Optionen evaluiert. Klartext auf der Festplatte: Ein Festplattenlesen legt den Schlüssel sofort offen. Abgelehnt. Passwortbasierte Verschlüsselung: erfordert bei jedem Neustart eine erneute Eingabe, unpraktisch für einen lang laufenden Docker-Dienst. Abgelehnt. Wir haben uns für Envelope-Verschlüsselung entschieden: Jeder Wallet-Schlüssel wird mit seinem eigenen Datenschlüssel verschlüsselt, und dieser Datenschlüssel wird mit einem Masterschlüssel (AWS KMS oder lokales AES-256) umhüllt. Selbst wenn die verschlüsselten Dateien komplett entwendet werden, sind sie ohne den Masterschlüssel nutzlos. Schlüssel existieren nur momentan im Klartext im SSM-Speicher und werden direkt nach der Signatur auf null gesetzt.
Jede Signaturanfrage nimmt denselben Weg. Keine Abkürzung, keine Schnellspur. Eine Transaktion durchläuft sieben Schritte in Reihenfolge: Delegationsprüfung, Simulation, Sicherheitsprüfung, Agent-Sicherheitsreview, Policy-Evaluierung, Passkey-Genehmigung und schließlich SSM-Signierung. Das Abschließen eines Schrittes überspringt niemals den nächsten.
Ein Low-Level-Detail, das erwähnenswert ist: Jedes zufällige Byte im System (Erzeugung privater Schlüssel, AES-GCM-Nonces, Auth-Tokens, WebAuthn-Challenges) stammt aus crypto/rand, der kryptographischen Zufallsquelle des Betriebssystems. math/rand ist in allem sicherheitskritischen Code verboten und wird durch Tests und CI durchgesetzt.
Transaktionssicherheit: Vier Schichten tiefgestaffelter Verteidigung
Die Isolierung privater Schlüssel deckt die Schlüsselsicherheit ab, aber Risiken auf Transaktionsebene bleiben. Ein kompromittierter Agent kann eine völlig legitim aussehende Transaktionsabsicht zusammenstellen, um Nutzer zu täuschen oder Auto-Signatur-Policies zu umgehen. Prompt injection braucht den privaten Schlüssel nicht; es muss nur das System dazu bringen, eine bösartige Transaktion über 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 fallen aus, neuartige Angriffe fallen aus bekannten Mustern. LLM-basiertes Review allein? Dieselbe Injektion, die den Agent kompromittiert hat, kompromittiert auch den Prüfer, da beide auf LLMs laufen. Ein pauschales hartes Limit allein? Legitime Nutzer stoßen an die Wand; eine 100-Dollar-Obergrenze auf jeden Swap ist unbenutzbar.
Wir schichten alle vier zusammen. Jede Schicht geht davon aus, dass jede vorherige Schicht bereits gefallen ist.
Schicht 1: Transaktionssimulation. Vor der Signatur simuliert das System die Ausführung: calldata-Dekodierung, Revert-Vorhersage, Feldformat-Prüfungen. Die Simulation fängt offensichtliche Probleme ab, hat aber blinde Flecken. Neue Angriffstechniken und RPC-Ausfälle können sie besiegen.
Schicht 2: Gegenparteibewertung. Eine Batterie statischer Prüfungen zielt auf die Gegenpartei: Empfänger-/Betragsabgleich, Erkennung unbegrenzter Genehmigungen, Burn-Adress-Erkennung, unerwartete Delegate Calls. Adress-Risikobewertung läuft über den Compliance-Service x402 von BlockSec, wobei der Agent Labels und Risikobewertungen über x402-Mikrozahlungen ohne API-Schlüssel oder Abonnement abfragt. Schicht 1 und 2 zusammen fangen die meisten gängigen Probleme ab, aber beide können 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-Signatur-Schwellenwerte: Eine 5.000-Dollar-Überweisung gegen ein 100-Dollar-Limit pro Transaktion wird sofort abgelehnt. Das Ändern der Policy selbst erfordert Passkey. Warum? Wenn der Agent Policies bearbeiten könnte, würde eine Injektion zuerst das Limit erhöhen und dann die Wallet leeren. Auto-Signatur ist standardmäßig deaktiviert; jede Transaktion erfordert manuelle Genehmigung, bis der Nutzer sich explizit dafür entscheidet.
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-Signatur-Schwellenwert auf 500 Dollar setzt, beträgt der schlimmste Verlust 500 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 verlangt, erfordert das System eine WebAuthn-Verifizierung (Fingerabdruck oder Gesicht). Kein reiner Software-Exploit kann dies fälschen.
Die vier Schichten arbeiten auf Basis gegenseitigen Misstrauens. Jede nimmt an, dass alles vor ihr bereits gescheitert ist. Perfekte Simulation lockert die Policy nicht. Fehlkonfigurierte Policy überspringt Passkey nicht. Jede Schicht steht für sich allein.
Ein Detail, das leicht übersehen wird: Wiederverwendung von Urteilen. Eine bekannte DeFi-Angriffstechnik spielt ein altes Sicherheitsurteil gegen eine modifizierte Transaktion erneut ab. Web3 Companion bindet jede Schreiboperation an eine eindeutige Transaktionsabsicht mit prüfbaren Zustandsübergängen. Ein Sicherheitsurteil gilt nur für die exakte Absicht, die es geprüft hat. Wenn der Agent eine Transaktion neu aufbaut — selbst wenn er nur den Betrag oder Empfänger ändert — behandelt das System sie als brandneue Absicht und führt alle Prüfungen erneut durch.
Die vier Verteidigungsschichten bilden drei unabhängige Vertrauensgrenzen ab: Privater Schlüssel, Policy und Passkey. Jeder einzelne Grenzbruch lässt die anderen beiden bestehen:
| Verletzte Grenze | Verbleibender Schutz |
|---|---|
| Agent (prompt injection, RCE) | Keine Schlüssel = keine Signatur; Policy blockiert Limitüberschreitung; Passkey blockiert nicht genehmigte Operationen |
| Sicherheitsprüfung (Urteil vergiftet) | Policy setzt weiterhin Limits durch; manuell zu genehmigende Operationen brauchen weiterhin Passkey |
| Policy (Fehlkonfiguration durch Nutzer) | Manuell zu genehmigende Operationen erfordern weiterhin biometrische Verifizierung |
| Alles außer Passkey | Anmeldedaten sind hardwaregebunden; Angreifer benötigt die physische Anwesenheit des Nutzers |
Security by Design: Die Philosophie hinter Open Source
BlockSec arbeitet seit dem ersten Tag an On-Chain-Sicherheit. Wir haben Milliarden von Dollar an On-Chain-Vermögenswerten geschützt und die gleiche Lektion immer wieder gesehen: Sicherheit, die nicht von Anfang an in die Architektur eingebaut ist, kommt immer zu spät.
AI Agents werden zu einem neuen Eingangstor für On-Chain-Transaktionen. Der Bereich bewegt sich schnell, aber Sicherheitsstandards existieren kaum. Die meisten Teams konzentrieren sich darauf, was ihr Agent kann. Wenige haben ernsthaft gefragt: Wenn dieser Agent kompromittiert wird, kann die Architektur den Schadensradius begrenzen?
Web3 Companion ist der Beitrag von BlockSec, Jahre an On-Chain-Sicherheitsarbeit in eine Agentic Wallet-Architektur zu überführen. Der Code ist unter der MIT-Lizenz vollständig offen (derzeit als Research Preview gekennzeichnet). Die Branche braucht jetzt einen konkreten Referenzpunkt für Sicherheitsdesign. Wie man Bedrohungsmodelle strukturiert, wie man Schlüssel isoliert, wie weit man Transaktionsverteidigung treiben sollte — kein Team sollte das von Null erfinden müssen. Wir veröffentlichen das vollständige Design, damit die Community darauf aufbauen kann.