Quand les agents IA obtiennent l'exécution on-chain : qui vérifie les informations qu'ils voient et les ordres qu'ils émettent ?

De plus en plus d'agents IA obtiennent des capacités d'exécution on-chain via des comptes intelligents (smart accounts), des portefeuilles stratégiques (strategy wallets) ou des services de signature restreints (restricted signing services)

I. Ce que l'incident KelpDAO a révélé

Le 18 avril 2026, le pont inter-chaînes rsETH de KelpDAO a été attaqué, entraînant la libération non autorisée de 116 500 rsETH, d'une valeur d'environ 292 millions de dollars au moment des faits. Le rapport d'incident de LayerZero montre que l'attaquant a obtenu les clés de session du développeur par ingénierie sociale (social engineering), a pollué le RPC interne dont dépendait le DVN de LayerZero Labs, et a supprimé les RPC externes par une attaque par déni de service (DoS), amenant le service de signature à fournir des preuves pour des messages forgés sur la base de données erronées. KelpDAO avait alors modifié la voie de vérification de 2-sur-2 à 1-sur-1 DVN. Une fois que le DVN unique désigné fournissait une preuve erronée, le système n'exigeait plus de validation croisée par un second DVN indépendant pour le même message. CrowdStrike et Mandiant ont imputé avec une haute confiance l'incident au groupe TraderTraitor (UNC4899) lié à la Corée du Nord.

Ce type d'incident n'est pas isolé. Dans de nombreux incidents de sécurité majeurs on-chain, le problème ne réside souvent pas dans le renversement des hypothèses cryptographiques elles-mêmes, mais dans la gestion des clés, les origines des données, le paramétrage des validateurs, la mise en œuvre du protocole et les droits d'exploitation — le système doit non seulement répondre à « la signature est-elle valide », mais aussi à « qui est autorisé à signer, selon quelles informations, et si l'état correspondant à la signature a réellement eu lieu ».

De plus en plus d'agents IA obtiennent des capacités d'exécution on-chain via des comptes intelligents (smart accounts), des portefeuilles stratégiques (strategy wallets) ou des services de signature restreints (restricted signing services). Une signature valide ne peut que prouver qu'une voie d'autorisation a été appelée, elle ne prouve pas que les données utilisées par l'agent sont fiables, que la décision respecte la stratégie établie, ou que cette transaction aurait dû avoir lieu à ce moment précis. Le sujet de la vérification s'étend de « la validité de la signature » à « la cohérence entre les entrées, la décision et l'exécution ».

II. Ce que les solutions existantes résolvent et ce qu'elles laissent en suspens

Les solutions existantes résolvent chacune une partie du problème de confiance, et confient chacune la confiance restante à des rôles différents :

Oracles et arbitrage des litiges : les résultats de marché de Polymarket sont d'abord proposés par les participants, et ne sont soumis au vote des détenteurs de tokens UMA que s'ils sont remis en question pendant la période de contestation. Le problème n'est pas « l'absence de re-vérification », mais la fiabilité de cette re-vérification — lorsque les règles sont floues, que les événements réels admettent de multiples interprétations, ou que le pouvoir de vote est concentré entre quelques adresses, le système confie en réalité la question de « qui détermine les faits » à une autre structure de gouvernance.

Multisignatures de ponts inter-chaînes et DVN : les deux diffèrent dans leur implémentation, mais exigent tous deux que l'application configure explicitement le jeu de validateurs et le seuil. Après que KelpDAO a configuré la voie en 1-sur-1 DVN, toute la voie de vérification dépendait d'un service de vérification unique ; et les origines des données et les mécanismes de gestion des pannes dont dépend ce service peuvent à leur tour constituer un point unique de défaillance au niveau suivant.

Conservation MPC : l'argument de vente des signatures à seuil est que la clé n'existe jamais entièrement en un seul endroit, mais le partage cryptographique n'entraîne pas automatiquement une décentralisation du pouvoir au niveau organisationnel. Selon les révélations de l'équipe Multichain à l'époque, après l'arrestation du fondateur par la police chinoise, l'équipe a immédiatement perdu l'accès aux serveurs des nœuds MPC concernés, qui fonctionnaient sous le compte cloud personnel du fondateur. Si le compte cloud, les droits d'exploitation et la réponse aux urgences sont concentrés entre les mains d'une seule personne, la conception à seuil de MPC peut encore laisser un point unique de défaillance au niveau organisationnel.

TEE : l'environnement d'exécution fiable peut isoler le code et les données sensibles, mais il n'élimine pas la confiance, il en change seulement le point d'ancrage. La racine de confiance matérielle et les mises à jour du microcode dépendent généralement du fabricant de puces, tandis que le code de l'enclave, les droits de mise à niveau et les politiques d'attestation peuvent être contrôlés par l'équipe du projet ou l'exploitant. Le TEE peut protéger le processus de calcul, mais ne peut pas automatiquement disperser ces droits de gouvernance.

Les modes de défaillance de ces solutions ne sont pas identiques, mais ils pointent vers le même type de problème : les seuils et la décentralisation écrits dans le livre blanc ne constituent un véritable périmètre de sécurité que s'ils sont réellement mis en œuvre dans les origines des données, les droits de compte, les clés de mise à niveau et les processus de gouvernance.

III. CRVA : reconcevoir la distribution des droits de vérification

DeepSafe a été rebaptisé de Bool Network en 2025. CRVA poursuit l'approche technique proposée par les chercheurs associés à Bool Network en 2022. L'article en question, publié dans IEEE Transactions on Information Forensics and Security (IEEE TIFS, Document ID 9903072), propose une plateforme de notarisation inter-chaînes basée sur un « comité caché évolutif » (evolving hidden committee).

Concrètement : les nœuds participent à un tirage au sort aléatoire via Ring-VRF, les sélectionnés soumettent des preuves et des clés publiques temporaires, les observateurs extérieurs peuvent vérifier leur éligibilité mais difficilement identifier leur identité à long terme. Le comité temporaire élu signe conjointement via MPC à seuil, aucun nœud seul ne pouvant produire le résultat indépendamment. Les processus critiques comme la gestion des clés sont exécutés dans un TEE (Intel SGX par exemple) conformément à la conception de l'article, afin de réduire la possibilité pour l'opérateur de l'hôte de lire ou de modifier les parts de clé. Le comité est également renouvelé à chaque époque, la nouvelle cohorte obtenant de nouvelles parts via un transfert de clé vérifiable, les anciennes parts devenant invalides, la période de rotation spécifique étant déterminée par les paramètres réels du réseau.

Le projet espère également utiliser le TEE pour masquer l'état de fonctionnement du comité, rendant difficile pour les opérateurs de nœuds de déterminer si leur nœud a participé à une vérification donnée. La mesure dans laquelle cet objectif peut être atteint dépend du code en production, de l'attestation à distance, des métadonnées côté hôte et de la protection contre les canaux auxiliaires — ce n'est pas une conclusion automatique du simple fait d'« utiliser un TEE ».

Mais ces mécanismes résolvent « qui valide et comment produire collectivement un résultat de manière sécurisée », ils ne définissent pas automatiquement « quel résultat est correct ». Dans le scénario des agents IA, le comité doit toujours conclure sur la base de stratégies prédéfinies, de sources de données et de règles de jugement exécutables — si ces règles sont elles-mêmes défectueuses, si les sources de données ne sont pas fiables, ou si l'objet de la vérification n'admet pas de réponse objectivement déterminable, un comité même sécurisé peut confirmer collectivement une conclusion erronée.

CRVA tente de réduire les risques liés à l'exposition à long terme des validateurs fixes et à la concentration des droits de signature, mais ne peut pas éliminer complètement les points de défaillance uniques au niveau de la gouvernance et de l'implémentation. L'admission des nœuds, les mises à niveau du protocole, l'attestation TEE et la sécurité logicielle doivent encore faire l'objet d'audits continus. Sous réserve que les anciennes parts soient invalidées de manière fiable et que le nouveau comité reste suffisamment indépendant, la rotation peut raccourcir la fenêtre d'attaque contre un groupe de signature fixe, mais ne peut pas couvrir les risques systémiques tels que la chaîne d'approvisionnement logicielle ou les autorisations de mise à niveau.

IV. Fondements techniques et progrès de mise en œuvre

La lignée technique de CRVA remonte à l'article de Bool Network publié dans IEEE TIFS volume 17 (2022), DOI 10.1109/TIFS.2022.3209546. Le modèle de protocole, les preuves de sécurité et l'évaluation du prototype de l'article ont été soumis à une évaluation par les pairs, fournissant une base académique pour les conceptions telles que le comité caché dynamique, Ring-VRF, la gestion des clés à seuil et la protection TEE. Il convient de distinguer que l'évaluation par les pairs porte sur le modèle et l'implémentation de l'article ; la correspondance entre le CRVA actuellement déployé par DeepSafe et le schéma de l'article doit encore être évaluée à la lumière des spécifications techniques actuelles, des audits de code et des paramètres du réseau.

Selon les informations divulguées par DeepSafe en octobre 2025, le réseau avait alors traité cumulativement près de 120 millions de vérifications, avec plus de 2,65 millions de comptes actifs. Le projet a également indiqué que ses relations écosystémiques dépassaient 70, couvrant différents types tels que la compatibilité des portefeuilles, l'intégration technique, l'investissement et la coopération marketing.

En octobre 2025, DeepSafe a annoncé la clôture d'un tour de table de 3 millions de dollars, avec des investisseurs incluant Antalpha Global, ViaBTC Capital et Gate 1. D'un point de vue chronologique, ce financement correspond principalement à la R&D technique et à l'expansion de l'écosystème après le changement de marque.

V. De la solution de vérification à l'infrastructure générique

À mesure que l'infrastructure blockchain se modularise progressivement, le consensus, l'exécution, la disponibilité des données, l'interopérabilité et le système de comptes sont pris en charge par différents composants. La modularisation ne fait pas disparaître les problèmes de confiance, mais rend les frontières de sécurité de chaque couche plus claires — les développeurs doivent non seulement choisir quelle technologie utiliser, mais aussi déterminer qui fournit la garantie de sécurité de cette couche et qui est responsable en cas de problème. Après que les agents IA ont obtenu des capacités d'exécution on-chain, de nouvelles questions apparaissent : qui confirme que les données qu'ils lisent sont fiables, que leurs décisions ne dépassent pas leurs autorisations, et que la transaction finale est conforme à l'autorisation de l'utilisateur ? Ces questions n'obtiennent pas automatiquement de réponse du simple fait d'une signature valide.

DeepSafe espère abstraire la capacité de vérification d'un module auxiliaire interne à une application unique en une infrastructure pouvant être invoquée par différents protocoles et agents IA — « Proof, Not Promises », remplaçant les promesses de l'exécutant par des preuves vérifiables. CRVA a déjà combiné la sélection aléatoire anonyme, la collaboration à seuil et le TEE en un chemin technique ; sa capacité à couvrir davantage de scénarios tels que les oracles, le cross-chain et les agents IA, et à évoluer vers une infrastructure de vérification générique, dépendra de l'accumulation continue des capacités en production, des audits indépendants et des intégrations réelles.