Wenn KI-Agenten On-Chain-Ausführungsrechte erhalten: Wer verifiziert die Informationen, die sie sehen, und die Anweisungen, die sie senden?

Immer mehr KI-Agenten erhalten On-Chain-Ausführungsfähigkeiten über intelligente Konten, Strategie-Wallets oder eingeschränkte Signaturdienste

1. Was der KelpDAO-Vorfall offengelegt hat

Am 18. April 2026 wurde die rsETH-Cross-Chain-Brücke von KelpDAO angegriffen, wobei 116.500 rsETH unrechtmäßig freigegeben wurden, was zu diesem Zeitpunkt einem Wert von etwa 292 Millionen US-Dollar entsprach. Der Vorfallbericht von LayerZero zeigt, dass der Angreifer durch Social Engineering Sitzungsschlüssel von Entwicklern erlangte, den internen RPC kompromittierte, auf den sich das LayerZero Labs DVN stützte, und externe RPCs mit Denial-of-Service-Angriffen lahmlegte, sodass der Signaturdienst auf der Grundlage falscher Daten Signaturen für gefälschte Nachrichten erzeugte. KelpDAO hatte zu diesem Zeitpunkt den Verifizierungspfad von 2-of-2 auf 1-of-1 DVN geändert. Sobald das einzige designierte DVN einen falschen Beweis ausstellte, benötigte das System keinen zweiten unabhängigen DVN mehr, um dieselbe Nachricht gegenzuprüfen. CrowdStrike und Mandiant ordneten den Vorfall mit hoher Wahrscheinlichkeit dem mit Nordkorea verbundenen TraderTraitor (UNC4899) zu.

Solche Vorfälle sind keine Einzelfälle. Bei vielen schwerwiegenden On-Chain-Sicherheitsvorfällen liegt das Problem oft nicht darin, dass die kryptografischen Annahmen selbst widerlegt wurden, sondern in den Bereichen Schlüsselkontrolle, Datenquellen, Validator-Konfiguration, Protokollimplementierung und Betriebsberechtigungen – das System muss nicht nur die Frage beantworten, „ob diese Signatur gültig ist“, sondern auch „wer berechtigt ist zu signieren, auf welcher Informationsbasis signiert wird und ob der der Signatur entsprechende Zustand tatsächlich eingetreten ist“.

Immer mehr KI-Agenten erhalten On-Chain-Ausführungsfähigkeiten über intelligente Konten, Strategie-Wallets oder eingeschränkte Signaturdienste. Eine gültige Signatur kann nur beweisen, dass ein bestimmter Autorisierungspfad aufgerufen wurde, aber nicht, dass die Daten, auf die sich der Agent stützt, zuverlässig sind, dass die Entscheidung der festgelegten Strategie entspricht oder dass diese Transaktion überhaupt zu diesem Zeitpunkt hätte stattfinden sollen. Der Fokus der Verifizierung verschiebt sich von der Echtheit der Signatur hin zur Konsistenz von Eingabe, Entscheidung und Ausführung.

2. Was bestehende Lösungen gelöst haben und was sie offen lassen

Die bestehenden Lösungsansätze lösen jeweils einen Teil des Vertrauensproblems und legen das verbleibende Vertrauen jeweils in die Hände unterschiedlicher Akteure:

Oracle und Streitbeilegung: Die Marktergebnisse von Polymarket werden zunächst von den Teilnehmern vorgeschlagen und gelangen nur dann zur Abstimmung durch die UMA-Token-Inhaber, wenn sie während des Anfechtungszeitraums angefochten werden. Das Problem liegt nicht darin, dass es „keine Überprüfung“ gibt, sondern darin, ob die Überprüfung zuverlässig ist – wenn die Regeln vage sind, reale Ereignisse mehrere Interpretationen zulassen oder die Stimmrechte auf wenige Adressen konzentriert sind, übergibt das System die Frage „Wer definiert die Fakten?“ tatsächlich an eine andere Governance-Struktur.

Cross-Chain-Brücken-Multisig und DVN: Beide unterscheiden sich in der Implementierung, verlangen aber von der Anwendung, die Validator-Menge und den Schwellenwert explizit zu konfigurieren. Nachdem KelpDAO den Pfad als 1-of-1 DVN konfiguriert hatte, hing der gesamte Verifizierungspfad von einem einzigen Verifizierungsdienst ab; und die Datenquellen und Fehlerbehandlungsmechanismen, auf die sich dieser Dienst stützte, konnten wiederum einen Single Point of Failure auf der nächsten Ebene darstellen.

MPC-Verwahrung: Der Vorteil von Schwellenwertsignaturen ist, dass der Schlüssel nie vollständig an einem Ort existiert, aber die kryptografische Aufteilung führt nicht automatisch zu einer Dezentralisierung der Macht auf Organisationsebene. Wie das Multichain-Team damals offenlegte, verlor das Team, nachdem der Gründer von der chinesischen Polizei festgenommen worden war, sofort den Zugriff auf die entsprechenden MPC-Node-Server, die unter dem persönlichen Cloud-Konto des Gründers liefen. Wenn Cloud-Konten, Betriebsberechtigungen und Notfallreaktion in einer Hand konzentriert sind, kann das Schwellenwert-Design von MPC dennoch einen Single Point of Failure auf Organisationsebene hinterlassen.

TEE: Trusted Execution Environments können Code und sensible Daten isolieren, aber sie beseitigen das Vertrauen nicht, sondern verlagern nur den Punkt, an dem das Vertrauen ansetzt. Hardware-Vertrauensbasis und Mikrocode-Updates hängen in der Regel vom Chiphersteller ab, während Enclave-Code, Upgrade-Berechtigungen und Attestierungsrichtlinien vom Projektteam oder Betreiber kontrolliert werden können. TEE kann den Berechnungsprozess schützen, aber diese Governance-Berechtigungen nicht automatisch verteilen.

Die Fehlermodi dieser Lösungen sind unterschiedlich, weisen aber auf dieselbe Art von Problem hin: Die in Whitepapers festgehaltenen Schwellenwerte und die Dezentralisierung bilden nur dann eine echte Sicherheitsgrenze, wenn sie tatsächlich in Datenquellen, Kontoberechtigungen, Upgrade-Schlüsseln und Governance-Prozessen umgesetzt werden.

3. CRVA: Neuverteilung der Verifizierungsrechte

DeepSafe wurde 2025 von Bool Network umbenannt. CRVA führt den technischen Ansatz fort, den die Forscher von Bool Network bereits 2022 vorgeschlagen hatten. Das entsprechende Paper wurde in den IEEE Transactions on Information Forensics and Security (IEEE TIFS, Document ID 9903072) veröffentlicht und schlug eine Cross-Chain-Notariatsplattform vor, die auf einem „evolving hidden committee“ basiert.

Die konkrete Vorgehensweise: Nodes nehmen über Ring-VRF an einer Zufallsauswahl teil; die Ausgewählten reichen Beweise und temporäre öffentliche Schlüssel ein, sodass externe Beobachter ihre Qualifikation verifizieren, aber ihre langfristige Identität nur schwer erkennen können. Das ausgewählte temporäre Komitee signiert anschließend gemeinsam per Schwellenwert-MPC, sodass kein einzelner Node das Ergebnis unabhängig erzeugen kann. Kritische Prozesse wie die Schlüsselverwaltung laufen gemäß dem Paper-Design in einer TEE (am Beispiel von Intel SGX), um die Wahrscheinlichkeit zu verringern, dass der Host-Betreiber Schlüsselanteile ausliest oder manipuliert. Das Komitee rotiert außerdem nach Epochen; die neue Generation erhält neue Anteile durch eine verifizierbare Schlüsselübergabe, während die alten Anteile ungültig werden. Der konkrete Rotationszyklus wird durch die tatsächlichen Netzwerkparameter bestimmt.

Das Projektteam hofft außerdem, mithilfe der TEE den Arbeitsstatus des Komitees zu verbergen, sodass Node-Betreiber nur schwer feststellen können, ob ihr Node an einer bestimmten Verifizierung beteiligt war. Inwieweit dieses Ziel erreicht werden kann, hängt vom Produktionscode, der Remote-Attestierung, den hostseitigen Metadaten und dem Schutz vor Seitenkanal-Angriffen ab – es ist keine Schlussfolgerung, die allein durch den „Einsatz einer TEE“ automatisch gilt.

Diese Mechanismen lösen jedoch die Frage „Wer verifiziert und wie wird das Ergebnis sicher gemeinsam erzeugt?“, definieren aber nicht automatisch, „welches Ergebnis korrekt ist“. Im KI-Agenten-Szenario muss das Komitee weiterhin auf der Grundlage vordefinierter Strategien, Datenquellen und ausführbarer Regeln zu einem Schluss kommen – wenn diese Regeln selbst fehlerhaft sind, die verwendeten Datenquellen unzuverlässig sind oder es für den Verifizierungsgegenstand keine objektiv bestimmbare Antwort gibt, kann selbst das sicherste Komitee gemeinsam eine falsche Schlussfolgerung bestätigen.

CRVA versucht, die Risiken zu verringern, die durch die langfristige Exposition fester Validatoren und die Konzentration von Signaturberechtigungen entstehen, kann aber Single Points of Failure auf Governance- und Implementierungsebene nicht vollständig beseitigen. Node-Zulassung, Protokoll-Upgrades, TEE-Attestierung und Softwaresicherheit müssen weiterhin kontinuierlich geprüft werden. Unter der Voraussetzung, dass alte Anteile zuverlässig ungültig werden und das neue Komitee ausreichend unabhängig bleibt, kann die Rotation das Angriffsfenster gegen eine feste Signaturgruppe verkürzen, aber keine systemischen Risiken wie Softwarelieferketten oder Upgrade-Berechtigungen abdecken.

4. Technische Grundlagen und Umsetzungsfortschritt

Die technische Entwicklung von CRVA lässt sich auf das Bool-Network-Paper zurückführen, das in IEEE TIFS, Band 17 (2022), mit der DOI 10.1109/TIFS.2022.3209546 veröffentlicht wurde. Das Protokollmodell, die Sicherheitsbeweise und die Prototyp-Evaluierung des Papers wurden einem Peer-Review unterzogen und lieferten die akademische Grundlage für Designs wie dynamische versteckte Komitees, Ring-VRF, Schwellenwert-Schlüsselverwaltung und TEE-Schutz. Es ist zu unterscheiden, dass sich das Peer-Review auf das Modell und die Implementierung im Paper bezieht; inwieweit das derzeit von DeepSafe eingesetzte CRVA dem Paper-Ansatz entspricht, muss anhand der aktuellen technischen Spezifikationen, Code-Audits und Netzwerkparameter beurteilt werden.

Laut der Offenlegung von DeepSafe im Oktober 2025 hatte das Netzwerk zu diesem Zeitpunkt bereits fast 120 Millionen Verifizierungen verarbeitet und mehr als 2,65 Millionen aktive Konten. Das Projektteam gab außerdem an, dass seine Ökosystem-Partnerschaften 70 überschritten haben und verschiedene Typen wie Wallet-Kompatibilität, technische Integration, Investitionen und Marktkooperationen umfassen.

Im Oktober 2025 gab DeepSafe den Abschluss einer Seed-Finanzierungsrunde in Höhe von 3 Millionen US-Dollar bekannt, zu den Investoren gehörten Antalpha Global, ViaBTC Capital und Gate 1. Zeitlich gesehen entspricht diese Finanzierungsrunde hauptsächlich der technischen Entwicklung und Ökosystemerweiterung nach der Umbenennung.

5. Von Verifizierungslösungen zu allgemeiner Infrastruktur

Mit der zunehmenden modularen Architektur der Blockchain-Infrastruktur werden Konsens, Ausführung, Datenverfügbarkeit, Interoperabilität und Kontosysteme von verschiedenen Komponenten übernommen. Die modulare Architektur hat das Vertrauensproblem nicht beseitigt, sondern die Sicherheitsgrenzen jeder Schicht klarer gemacht – Entwickler müssen nicht nur entscheiden, welche Technologie sie einsetzen, sondern auch beurteilen, wer die Sicherheitsgarantie für diese Schicht bereitstellt und wer im Fehlerfall die Verantwortung trägt. Nachdem KI-Agenten On-Chain-Ausführungsfähigkeiten erhalten haben, entstehen neue Fragen: Wer bestätigt, dass die von ihnen gelesenen Daten vertrauenswürdig sind, dass ihre Entscheidungen nicht ihre Befugnisse überschreiten und dass die endgültige Transaktion mit der Autorisierung des Nutzers übereinstimmt? Diese Fragen werden nicht automatisch durch eine einzige gültige Signatur beantwortet.

DeepSafe möchte die Verifizierungsfähigkeit von einem internen Zusatzmodul einzelner Anwendungen zu einer Infrastruktur abstrahieren, die von verschiedenen Protokollen und KI-Agenten aufgerufen werden kann – „Proof, Not Promises“, also überprüfbare Beweise anstelle von Versprechen der ausführenden Partei. CRVA hat bereits anonyme Auswahl, Schwellenwert-Kooperation und TEE zu einem technischen Pfad kombiniert; ob es sich weiter auf verschiedene Szenarien wie Oracle, Cross-Chain und KI-Agenten ausdehnen und zu einer allgemeinen Verifizierungsinfrastruktur entwickeln kann, wird von der kontinuierlichen Akkumulation von Produktionsfähigkeiten, unabhängigen Audits und realen Integrationen abhängen.