25 M$ Volés via Injection de Prompts MCP : Comment un Chatbot IA a Brisé la DeFi Sans Toucher la Blockchain

Qu’est-ce que Resolv et comment fonctionne la frappe d’USR ?

Resolv est un protocole de stablecoin qui utilise une stratégie appelée couverture delta-neutre pour maintenir l’USR arrimé à 1,00 $. En termes simples, le protocole détient des crypto-actifs (ETH, BTC) tout en plaçant simultanément des paris opposés sur les marchés dérivés, de sorte que les mouvements de prix s’annulent — la valeur en dollars reste à peu près constante, que la crypto monte ou descende. (Pour une explication plus approfondie de la façon dont les stablecoins synthétiques maintiennent leur ancrage et des risques impliqués, consultez notre guide sur les stablecoins et la section sur la crise d’Ethena USDe dans notre rapport sur le rendement réel.) Ce design appartient à la même famille que l’USDe d’Ethena, bien qu’avec des choix d’implémentation distincts qui se révéleraient critiques le 22 mars.

Le processus de frappe de l’USR suit un schéma en deux étapes courant dans les protocoles nécessitant une autorisation hors chaîne. Premièrement, un utilisateur appelle requestSwap(), déposant de l’USDC dans le contrat comme collatéral. Cela crée une demande de frappe en attente. Deuxièmement, une adresse privilégiée — le SERVICE_ROLE — appelle completeSwap() pour autoriser la frappe effective des tokens USR. L’idée est simple : le dépôt vient de l’utilisateur, mais le backend du protocole vérifie le montant du dépôt, calcule le ratio USR/USDC correct, puis signe la transaction de frappe avec la clé SERVICE_ROLE.

C’est ici que l’architecture devient dangereuse. Le SERVICE_ROLE était un simple compte détenu par un externe (EOA) — pas un multisig, pas un timelock, pas un contrat contrôlé par la gouvernance. Une seule clé privée, stockée dans AWS Key Management Service (KMS), contrôlait la capacité de frapper n’importe quel montant d’USR. Comme Chainalysis l’a documenté dans son post-mortem, « le contrat impose un minimum de sortie USR — mais de manière critique, aucun maximum ».

Relisez cela. Le contrat intelligent permettait au SERVICE_ROLE de frapper un milliard d’USR contre un seul dollar d’USDC, et le code s’exécutait sans erreur. Il n’y avait aucune vérification de ratio on-chain. Aucun plafond de frappe maximum. Aucune validation par oracle. Aucun disjoncteur. Le contrat faisait confiance au SERVICE_ROLE implicitement — quel que soit le montant qu’il autorisait, il était frappé, point final.

L’analyse de DeFiPrime l’a formulé sans détour : il n’y avait « aucun garde-fou on-chain imposant ce ratio ». L’ensemble du modèle de sécurité reposait sur l’hypothèse que la clé SERVICE_ROLE ne serait utilisée que par l’infrastructure backend légitime. Cette hypothèse allait s’avérer catastrophiquement erronée.

Pour comprendre pourquoi cela importe, considérez la différence entre un protocole dont la logique de frappe réside on-chain (vérifiée par le code, immuable, transparente) et un protocole dont elle réside hors chaîne (dépendante d’une seule clé, stockée dans l’infrastructure cloud, contrôlée par un logiciel pouvant être compromis). Resolv a choisi la seconde option. Et le logiciel contrôlant cette clé était un agent IA.

Comment l’assistant IA a-t-il été compromis ? L’attaque par injection de prompts

C’est ici que le hack de Resolv se distingue de tout exploit DeFi précédent dans l’histoire. Il n’y avait pas de bug de réentrance. Pas de manipulation par prêt flash. Pas de front-running d’oracle. Pas d’attaque de gouvernance. L’attaquant n’a pas touché la blockchain du tout — pas avant la toute fin, quand il a utilisé une clé de signature légitimement obtenue pour autoriser des transactions que le contrat intelligent a exécutées parfaitement.

Le vecteur d’attaque était un assistant IA — un grand modèle de langage (LLM) intégré dans l’infrastructure opérationnelle de Resolv. Comme de nombreux protocoles en 2025–2026 qui ont adopté l’IA pour l’outillage interne, Resolv avait déployé un assistant basé sur un LLM connecté à ses systèmes backend via le Model Context Protocol (MCP).

Qu’est-ce que le Model Context Protocol ?

MCP est un standard ouvert lancé par Anthropic en novembre 2024 qui permet aux modèles d’IA de découvrir dynamiquement et d’interagir avec des outils externes au moment de l’exécution. Pensez-y comme un adaptateur universel : au lieu de coder en dur chaque intégration dont une IA pourrait avoir besoin, MCP fournit un moyen standardisé pour un LLM de se connecter à des bases de données, des API, des systèmes de fichiers et des services cloud à la volée. L’IA peut interroger une base de données Supabase, lire des fichiers depuis un bucket de stockage, appeler un point de terminaison API ou exécuter une migration de base de données — le tout via des appels d’outils MCP.

La puissance est évidente. Le danger est tout aussi évident, bien que bien moins discuté. Une IA connectée via MCP opère avec les permissions que le serveur MCP lui accorde. Dans le cas de Resolv, l’assistant IA était connecté aux bases de données Supabase — et il fonctionnait avec des privilèges service_role.

Dans le modèle de sécurité de Supabase, la clé service_role contourne toutes les politiques de sécurité au niveau des lignes (Row Level Security). Elle offre un accès complet en lecture et écriture à chaque table, chaque ligne, chaque colonne. Il est explicitement documenté que cette clé ne doit jamais être exposée aux clients ou aux environnements non fiables. Resolv a accordé ce niveau d’accès à une IA qui traitait des entrées externes.

Comment fonctionne l’injection de prompts

L’injection de prompts est conceptuellement simple mais dévastatrice en efficacité. Un LLM traite du texte — il lit des entrées et génère des sorties. Le problème fondamental est que les LLM ne peuvent pas distinguer de manière fiable les instructions de leur opérateur des instructions intégrées dans les données qu’ils traitent. Si un attaquant parvient à insérer du texte malveillant dans n’importe quelle entrée que l’IA lit, l’IA peut interpréter ce texte comme une commande légitime.

Palo Alto Networks Unit 42 a publié des recherches approfondies sur les attaques par injection de prompts indirecte observées en conditions réelles. Leurs conclusions sont alarmantes : 37,8 % des attaques utilisent du texte brut visible (des instructions simplement écrites dans un document que l’IA traite), 19,8 % utilisent le masquage par attributs HTML (cachant des instructions dans des attributs HTML que les humains ne voient pas mais que l’IA lit), et 16,9 % utilisent la suppression CSS (intégrant des commandes dans du CSS rendu invisible aux yeux humains mais analysé par le modèle). Les attaques ne sont pas théoriques. Elles se produisent dans des systèmes en production, contre de vraies organisations, en ce moment même.

Le schéma d’attaque Supabase MCP avait déjà été documenté avant l’incident Resolv. Les recherches de PVML décrivaient exactement ce scénario : un ticket de support ou une entrée utilisateur contenant des instructions intégrées est traité par un assistant IA avec un accès service_role. L’IA, incapable de distinguer les instructions malveillantes des instructions légitimes, suit les commandes intégrées. Dans le cas documenté par PVML, cela a conduit à l’exfiltration de jetons d’intégration. Leur conclusion était sans ambiguïté : « Les LLM ne sont pas conçus pour être des gardiens de sécurité ».

Dans l’attaque Resolv, l’attaquant a conçu une entrée que l’assistant IA a interprétée comme des instructions légitimes. La charge utile exacte n’a pas été divulguée publiquement — le post-mortem de Resolv la désigne uniquement comme « une injection de prompts conçue » — mais le résultat est connu : l’IA a divulgué des identifiants cloud temporaires, y compris des jetons d’accès AWS qui ont fourni un point d’entrée dans l’infrastructure de Resolv.

Tableau : Anatomie d’une injection de prompts indirecte — les quatre étapes qui ont permis la fuite d’identifiants de Resolv.

Practical DevSecOps a identifié huit catégories de vulnérabilités critiques dans les serveurs MCP : injection de prompts, empoisonnement d’outils, outils à permissions excessives, le problème du député confus, la contamination inter-outils, le vol de jetons, l’usurpation de serveur et le chargement dynamique d’outils non validés. L’attaque Resolv a exploité au moins trois d’entre elles : l’injection de prompts (le point d’entrée), les outils à permissions excessives (accès service_role) et ce qui équivaut à un problème de député confus (l’IA a agi au nom de l’attaquant tout en croyant suivre des instructions légitimes).

L’enseignement crucial est que ce n’était pas une défaillance de l’IA dans un sens abstrait. L’IA a fait exactement ce pour quoi elle était conçue : elle a traité des entrées et généré des sorties. La défaillance résidait dans l’architecture qui a donné à une IA — un système qui traite des entrées non fiables par définition — un accès à des identifiants pouvant ultimement contrôler un protocole de plus de 100 M$. C’est ce que Charles Guillemet, CTO de Ledger, appelle la « triade létale » : entrée non fiable, capacités d’exécution puissantes et accès réseau pour l’exfiltration. Tout système combinant ces trois éléments est, selon les mots de Guillemet, « programmé pour échouer sous pression ».

Des identifiants cloud à AWS KMS : le mouvement latéral

Avec des identifiants AWS temporaires en main, l’attaquant est passé de l’exploitation de l’IA à un schéma d’attaque classique d’infrastructure cloud : le mouvement latéral. C’est une technique familière à toute équipe de sécurité cloud mais quasiment absente du playbook de sécurité DeFi, qui s’est historiquement concentré sur les audits de contrats intelligents et la surveillance on-chain.

L’attaquant ne s’est pas dirigé directement vers la blockchain. Il n’en avait pas besoin. L’objectif était la clé de signature, et la clé de signature résidait dans le cloud.

La première étape consistait à énumérer l’environnement AWS à l’aide des identifiants temporaires divulgués par l’IA. Les politiques AWS Identity and Access Management (IAM) déterminaient ce à quoi ces identifiants pouvaient accéder. Dans un environnement bien conçu avec un IAM de moindre privilège, les identifiants temporaires d’un assistant IA auraient été limités de manière stricte — peut-être un accès en lecture seule à des tables de base de données spécifiques et rien d’autre. Dans l’environnement de Resolv, les identifiants fournissaient un accès suffisant pour aller plus loin.

L’attaquant a navigué depuis le point d’entrée IAM initial jusqu’à AWS Key Management Service (KMS), où Resolv stockait la clé privée SERVICE_ROLE. KMS est le service géré d’Amazon pour le stockage et l’utilisation de clés cryptographiques — il est conçu pour être un coffre-fort sécurisé pour exactement ce type de matériel sensible. Mais la sécurité de KMS dépend entièrement des politiques IAM contrôlant qui peut accéder aux clés. Si un attaquant dispose d’identifiants AWS valides avec des permissions suffisantes, KMS lui servira la clé aussi volontiers qu’à l’application légitime.

Chainalysis a confirmé le chemin : l’attaquant a « accédé à l’environnement AWS Key Management Service de Resolv où la clé de signature privilégiée du protocole était stockée ». Une fois dans KMS, l’attaquant détenait la clé privée SERVICE_ROLE — le seul secret cryptographique autorisant toutes les opérations de frappe d’USR.

L’ensemble de la phase de mouvement latéral — des identifiants divulgués par l’IA à l’accès KMS — a probablement pris quelques minutes. Les attaques d’infrastructure cloud avancent vite quand l’attaquant dispose d’identifiants valides. Il n’y a pas de chaînes d’exploitation à développer, pas de zero-days à découvrir. L’attaquant se connecte simplement avec les clés volées et navigue dans l’environnement comme un administrateur légitime. C’est pourquoi le vol d’identifiants est systématiquement la technique d’accès initial la plus courante dans les brèches cloud, selon tous les rapports majeurs de renseignement sur les menaces d’AWS, Google Cloud et Microsoft Azure.

Il convient de s’arrêter pour apprécier l’ironie. Resolv a stocké son secret le plus critique — la clé qui contrôle des centaines de millions de dollars en autorité de frappe — dans AWS KMS, l’un des services de gestion de clés les plus sécurisés disponibles. La sécurité de KMS elle-même n’a jamais été remise en question. La vulnérabilité résidait dans le chemin vers KMS : un agent IA, fonctionnant avec des permissions excessives, traitant des entrées non fiables, connecté au même environnement cloud où résidait la clé de signature. La chaîne n’était aussi solide que son maillon le plus faible, et le maillon le plus faible était un LLM incapable de distinguer une instruction légitime d’une instruction malveillante.

Tableau : Chaîne d’attaque — Du prompt à 23 M$. Cinq étapes, moins de 30 minutes, zéro exploit de contrat intelligent.

L’exécution on-chain : 80 millions de tokens créés à partir de rien

Avec la clé SERVICE_ROLE compromise, l’attaquant a enfin touché la blockchain — et le contrat intelligent a fait exactement ce pour quoi il avait été conçu.

Transaction 1 : L’attaquant a déposé environ 100 000 $ en USDC dans le contrat de frappe via requestSwap(), puis a immédiatement appelé completeSwap() avec la clé SERVICE_ROLE volée, autorisant la frappe de 50 millions d’USR. C’est une sur-frappe de 500x — cinquante millions de dollars de stablecoin créés à partir de cent mille dollars de collatéral. Le contrat a accepté la transaction sans hésitation. Il n’y avait aucune vérification de ratio pour la rejeter, aucun plafond maximum pour la limiter, aucun oracle pour vérifier si le montant frappé avait un quelconque rapport avec le dépôt.

Transaction 2 : Peu après, l’attaquant a répété le processus, frappant 30 millions d’USR supplémentaires. Même méthode, même clé, même absence de garde-fous on-chain.

Au total : 80 millions d’USR créés contre environ 200 000 $ de dépôts réels en USDC. Une dilution de 400–500x de l’offre de tokens. Les tokens de chaque détenteur d’USR existant étaient instantanément adossés à une fraction de ce qu’ils valaient quelques minutes plus tôt.

La stratégie de liquidation était méthodique. Plutôt que de déverser 80 M d’USR directement sur un seul DEX — ce qui aurait déclenché des disjoncteurs immédiats et un glissement maximal — l’attaquant a d’abord converti une partie significative de l’USR en wstUSR (USR emballé et staké). Cette étape d’emballage servait un objectif tactique : le wstUSR était accepté par des pools de liquidité différents de l’USR brut, permettant à l’attaquant d’accéder à plusieurs canaux de liquidation simultanément et de réduire l’impact sur les prix dans chaque pool individuel.

L’attaquant a ensuite réparti les ventes sur trois grandes plateformes d’échange décentralisées :

• Curve Finance : Le lieu de liquidation principal pour les paires de stablecoins. Les pools USR/USDC et USR/USDT ont absorbé la pression de vente initiale avant que l’ancrage ne s’effondre.
• KyberSwap : Utilisé pour des conversions supplémentaires USDC/USDT. KyberSwap a bloqué les portefeuilles de l’exploiteur en quelques heures après l’attaque, mais le mal était déjà fait.
• Velodrome : Ciblé pour sa liquidité profonde sur Optimism, fournissant une voie de sortie supplémentaire pour les fonds volés.

Le résultat a été rapide et dévastateur. Sur Curve, l’USR est passé de 1,00 $ à 0,025 $ en environ 17 minutes — un effondrement de 97,5 %. The Block a rapporté que l’attaquant avait extrait environ 25 millions de dollars, tandis que CoinDesk situait le chiffre à environ 23 millions de dollars. L’écart reflète la difficulté de suivre les montants exacts à travers plusieurs DEX et chaînes en temps réel.

La conversion finale s’est faite de stablecoins vers ETH. L’attaquant a consolidé les gains en environ 11 400 ETH — valant approximativement 24 millions de dollars au moment de l’exploit — et a commencé à déplacer les fonds via des adresses intermédiaires. Le portefeuille principal de l’attaquant, 0x8ed8cf0c1c531c1b20848e78f1cb32fa5b99b81c, a été rapidement signalé par les sociétés de sécurité et les opérateurs de DEX.

L’ensemble de la phase on-chain — de la première frappe à la consolidation finale en ETH — a pris moins de 30 minutes. Pour contexte, c’est plus rapide que le temps nécessaire à la plupart des signataires multisig pour coordonner une réponse d’urgence, plus rapide que le temps pour la plupart des équipes de protocoles de confirmer qu’un exploit est en cours, et plus rapide que tout mécanisme de pause basé sur la gouvernance ne pourrait réagir. L’avantage de vitesse appartenait entièrement à l’attaquant.

L’analyse forensique on-chain raconte l’histoire d’un contrat intelligent faisant exactement ce que lui ordonnait la clé autorisée. Chaque transaction était valide. Chaque signature était légitime. Le contrat n’avait aucun moyen de savoir — et aucun mécanisme pour vérifier — que la clé signant ces transactions avait été volée dans l’environnement cloud d’un agent IA compromis. Du point de vue de la blockchain, ce n’était pas un hack du tout. C’était une série d’opérations parfaitement autorisées.

Ce qu’ont trouvé les sociétés de sécurité

Le hack de Resolv a déclenché une réponse immédiate de l’écosystème de sécurité blockchain. En quelques heures, plusieurs sociétés avaient publié leurs évaluations initiales. Ce qui a émergé n’était pas seulement un post-mortem d’un seul exploit mais la reconnaissance que l’ensemble du modèle de menace pour les protocoles DeFi venait de s’élargir.

Cyvers : première détection

Cyvers, une plateforme de surveillance de sécurité Web3 en temps réel, a été parmi les premiers à détecter l’activité anormale. Leurs systèmes ont signalé la création de 80 M de tokens USR comme une anomalie critique — le volume de frappe dépassait de plusieurs ordres de grandeur toute exécution précédente de completeSwap(). L’alerte de Cyvers a déclenché l’investigation de la communauté de sécurité élargie et a aidé les plateformes d’échange et les DEX à commencer à bloquer les adresses de l’exploiteur.

PeckShield : quantifier les dégâts

PeckShield, l’une des sociétés de sécurité blockchain les plus établies, a estimé le total d’USR généré artificiellement à 80 millions de dollars en valeur nominale. Leur analyse on-chain a confirmé le schéma de frappe en deux transactions et a retracé les flux de fonds à travers Curve, KyberSwap et Velodrome. Le suivi en temps réel de PeckShield a été déterminant pour aider les plateformes d’échange à geler les actifs restants de l’exploiteur avant qu’ils ne puissent être entièrement blanchis.

Chainalysis : le post-mortem définitif

Chainalysis a publié l’analyse la plus complète sous le titre « Comment une seule clé compromise a imprimé 23 millions de dollars ». Leur enquête a confirmé le vecteur AWS KMS et a fourni la description la plus claire de la chaîne d’attaque : injection de prompts → vol d’identifiants → mouvement latéral vers KMS → compromission du SERVICE_ROLE → frappe non autorisée.

Les recommandations clés de Chainalysis comprenaient :

• Surveiller les anomalies de ratio de completeSwap() : Toute frappe où la sortie USR dépasse l’entrée USDC de plus qu’une petite tolérance (tenant compte du positionnement delta-neutre) devrait déclencher une alerte immédiate.
• Pause automatisée sur les événements de frappe suspects : Si le volume de frappe dans une seule transaction ou une courte fenêtre temporelle dépasse les normes historiques de 10x ou plus, le contrat devrait automatiquement se mettre en pause et nécessiter une intervention multisig pour reprendre.
• Surveillance de l’infrastructure cloud : Les journaux d’accès KMS devraient être surveillés en temps réel. Tout accès depuis une IP, un rôle ou une session non reconnu(e) devrait déclencher une rotation immédiate des clés.
• Isolation des agents IA : Les agents IA ne devraient jamais partager d’identifiants cloud avec les systèmes qui contrôlent les clés de signature. L’environnement IA et l’environnement de gestion de clés devraient être des comptes AWS complètement séparés sans accès inter-comptes.

Charles Guillemet (Ledger) : l’avertissement structurel

La réponse la plus significative est peut-être venue non pas d’une société de sécurité blockchain mais de Charles Guillemet, CTO de Ledger, qui a publié « L’IA agentique est lâchée. Votre modèle de sécurité n’est pas prêt ». L’analyse de Guillemet allait au-delà des spécificités du hack de Resolv pour décrire un problème systémique dans la façon dont les agents IA sont déployés dans l’infrastructure crypto.

Guillemet a décrit la « triade létale » qui rend les agents IA intrinsèquement dangereux dans les environnements à forte valeur :

1. Entrée non fiable : Les agents IA traitent des données provenant de sources externes — utilisateurs, sites web, bases de données, API — dont chacune peut contenir des charges utiles d’injection de prompts.
2. Capacités d’exécution puissantes : MCP et les protocoles similaires d’utilisation d’outils donnent aux agents IA la capacité d’exécuter des actions réelles — requêtes de bases de données, appels API, opérations sur fichiers, et potentiellement la signature de transactions.
3. Accès réseau pour l’exfiltration : Les agents IA peuvent communiquer vers l’extérieur — via leur canal de réponse, via des appels d’outils, via la journalisation — ce qui signifie que toute information divulguée peut atteindre l’attaquant.

La solution proposée par Guillemet est architecturalement radicale : « Les agents proposent, les humains signent ». Dans ce modèle, un agent IA peut analyser des données, suggérer des transactions et préparer des opérations — mais l’autorisation finale doit venir d’un humain, vérifiée par une séparation imposée matériellement (comme un portefeuille matériel Ledger). L’IA ne peut jamais exécuter de manière autonome une action à forte valeur. Elle ne peut que recommander.

Sa conclusion porte un poids particulier étant donné la position de Ledger en tant que premier fabricant de portefeuilles matériels : « Si votre architecture ne peut pas clairement séparer ce qu’un agent suggère de ce qu’un humain autorise, alors elle est programmée pour échouer sous pression ».

Le message collectif de la communauté de sécurité était clair : le hack de Resolv n’était pas un incident isolé mais un présage. Tout protocole utilisant des agents IA avec des privilèges élevés — en particulier ceux ayant accès à des clés de signature, des identifiants cloud ou un accès service_role aux bases de données — doit immédiatement implémenter des défenses contre l’injection de prompts, la désinfection des entrées et le principe du moindre privilège pour tous les systèmes connectés à l’IA.

La blockchain n’a jamais été le maillon faible

C’est la partie qui devrait inquiéter chaque bâtisseur, investisseur et chercheur en sécurité de la DeFi. Le code du contrat intelligent a fonctionné parfaitement. Il a fait exactement ce pour quoi il était conçu : quand la clé SERVICE_ROLE a signé une transaction completeSwap(), le contrat a frappé le montant spécifié d’USR. Le code n’était pas bogué. Il n’était pas vulnérable à la réentrance. Il n’avait aucun appel externe non vérifié. Aucune collision de stockage. Aucun dépassement d’entier. Selon tous les critères standard de sécurité des contrats intelligents, le contrat de frappe de Resolv était techniquement sain.

La vulnérabilité existait entièrement dans la pile d’infrastructure centralisée : agent IA → MCP → Supabase → AWS IAM → AWS KMS. Chaque composant de cette chaîne est hors chaîne. Chaque composant est centralisé. Chaque composant est exactement le type d’intermédiaire de confiance que la technologie blockchain a été inventée pour éliminer.

Cela inverse entièrement le modèle de sécurité DeFi traditionnel. Au cours des six dernières années, la grande majorité des exploits DeFi ont ciblé la couche blockchain : attaques de réentrance (The DAO, 2016), manipulation d’oracles par prêts flash (bZx, 2020 ; Cream Finance, 2021), attaques de gouvernance (Beanstalk, 2022), vulnérabilités de ponts (Ronin, Wormhole, Nomad, 2022) et exploits d’approbations de tokens. La réponse standard à ces attaques a été de meilleurs audits, la vérification formelle, les programmes de bug bounty et la surveillance on-chain.

Aucune de ces défenses n’aurait empêché le hack de Resolv. Vous auriez pu auditer le contrat de frappe une centaine de fois avec les meilleures sociétés au monde et n’avoir rien trouvé, parce qu’il n’y avait rien à trouver. Le contrat était sécurisé. L’agent IA qui le contrôlait ne l’était pas.

Andrew Whong, cofondateur de Herd, a résumé la défaillance architecturale : « Le contrat de frappe n’avait ni oracle ni vérification de frappe maximale ». Mais même cela sous-estime le problème. Les vérifications par oracle et les plafonds de frappe maximale auraient aidé — ils auraient limité le rayon d’explosion — mais le problème fondamental est qu’une seule clé contrôlée par un agent IA pouvant être compromis avait une autorité de frappe illimitée. La solution n’est pas seulement d’ajouter des vérifications on-chain. C’est de repenser l’ensemble de la relation entre l’infrastructure IA et les opérations on-chain.

DeFiPrime l’a qualifié de « cas de confiance excessive dans l’infrastructure hors chaîne » — une phrase qui pourrait servir d’épitaphe à toute une génération de protocoles DeFi qui ont greffé des agents IA sur leurs opérations sans considérer les implications de sécurité.

Le paradoxe est douloureux. La promesse fondamentale de la DeFi est une finance sans confiance, sans permission, décentralisée. Aucun point de défaillance unique. Aucun intermédiaire de confiance. Le code fait loi. Et pourtant, Resolv — un protocole gérant des centaines de millions de dollars — avait sa fonction de frappe contrôlée par une seule clé centralisée, gérée par un agent IA, stockée dans l’infrastructure d’un fournisseur cloud, accessible via une chaîne d’identifiants pouvant être divulgués en trompant un chatbot. La blockchain était le composant le plus sécurisé de toute la pile. C’était l’infrastructure hors chaîne — l’IA, le cloud, la gestion de clés — qui a échoué.

Tableau : Hack DeFi traditionnel vs Hack d’infrastructure IA — l’exploit Resolv représente un changement de paradigme dans la localisation des vulnérabilités DeFi.

Pour les utilisateurs cherchant à évaluer leur propre exposition à ces risques, des outils comme CleanSky peuvent aider à surveiller les approbations de tokens et les positions à travers les protocoles — mais la leçon plus profonde est que la surveillance on-chain seule ne suffit plus. La surface d’attaque s’étend désormais à l’infrastructure cloud, aux agents IA et aux systèmes de gestion de clés que les protocoles utilisent en coulisses. Comprendre le risque en DeFi signifie désormais comprendre l’ensemble de la pile, pas seulement les contrats intelligents.

Pourquoi ce ne sera probablement pas la dernière attaque d’infrastructure IA

Si le hack de Resolv était un incident isolé — une défaillance ponctuelle d’un seul protocole ayant pris des décisions architecturales uniquement mauvaises — ce serait préoccupant mais gérable. Le problème est que chaque tendance de l’industrie pointe vers plus d’agents IA, plus de connexions MCP, plus d’opérations automatisées, et plus de protocoles commettant exactement les mêmes erreurs que Resolv.

Les agents IA sont déjà des attaquants capables

Les propres recherches d’Anthropic, publiées en décembre 2025, ont montré que les agents IA pouvaient déjà exploiter plus de 50 % des contrats intelligents vulnérables réels sur le benchmark SCONE-bench — un jeu de données de 405 contrats représentant 550 M$ en valeur simulée. Ces recherches portaient sur l’IA attaquant des contrats intelligents, mais les mêmes capacités s’appliquent en sens inverse : les agents IA sont suffisamment sophistiqués pour être des outils précieux tant pour les défenseurs que pour les attaquants.

Séparément, des chercheurs ont démontré que les modèles de pointe, dont GPT-5 et Sonnet 4.5, avaient trouvé deux failles zero-day parmi 2 849 contrats BNB Chain pour un coût de calcul de seulement 3 476 $. L’économie de la découverte de vulnérabilités par IA a basculé de manière décisive en faveur des attaquants : le coût pour trouver des bugs exploitables est désormais dérisoire par rapport au gain potentiel.

Les chiffres s’accélèrent

Le rapport annuel 2025 de Hacken a documenté une augmentation de 1 025 % des exploits liés à l’IA par rapport à 2024. Ce n’est pas une erreur de frappe — une multiplication par dix en une seule année. La catégorie comprend le phishing assisté par IA, la découverte de vulnérabilités assistée par IA, l’ingénierie sociale améliorée par deepfake, et désormais les attaques par injection de prompts sur l’infrastructure des protocoles. Les recherches de Cecuro ont révélé que les agents IA de pointe peuvent exécuter des exploits de bout en bout sur 72 % des contrats vulnérables connus, contre environ 20 % début 2024.

Le paysage de la sécurité crypto en 2025 était déjà alarmant avant Resolv : 4,65 milliards de dollars de pertes totales, la compromission multisig de Bybit, une vague de défaillances de contrôle d’accès. Le hack de Resolv ajoute une nouvelle catégorie à une surface de menace déjà en expansion.

L’adoption de MCP s’accélère sans parité de sécurité

L’adoption du Model Context Protocol a explosé tout au long de 2025 et jusque dans 2026. Des milliers de serveurs MCP existent désormais pour les bases de données (Supabase, PostgreSQL, MongoDB), les fournisseurs cloud (AWS, GCP, Azure), les outils de développement (GitHub, GitLab, Jira), les plateformes de communication (Slack, Discord, e-mail) et les services financiers (API bancaires, processeurs de paiement, nœuds blockchain). Chaque serveur MCP est une cible potentielle d’injection de prompts.

L’incident Supabase MCP documenté par PVML était le coup de semonce. Supabase a eux-mêmes publié « Défense en profondeur pour MCP » en réponse, recommandant que les serveurs MCP n’utilisent jamais de clés service_role et utilisent plutôt une authentification limitée par utilisateur. Mais l’adoption de ces recommandations a été inégale au mieux. De nombreuses équipes de protocoles ont déployé des intégrations MCP pendant la vague d’engouement pour l’IA de 2024–2025 sans implémenter les contrôles de sécurité de base.

Le hack de Resolv a été la première victime en argent réel. Ce ne sera pas la dernière. La combinaison du déploiement croissant d’agents IA, de l’adoption accrue de MCP et des énormes incitations financières pour les attaquants crée un paysage de menaces qui croît plus vite que les défenses ne sont déployées. Chaque protocole utilisant des agents IA pour des tâches opérationnelles — gestion des risques, trading, support client, surveillance, participation à la gouvernance — devrait considérer l’attaque Resolv comme un avertissement direct.

Le problème structurel

Le problème plus profond n’est pas une vulnérabilité unique mais un décalage structurel entre les capacités de l’IA et la sécurité de l’IA. Les LLM sont des outils extrêmement puissants pour traiter l’information, générer des sorties et interagir avec des systèmes externes. Ils sont également fondamentalement incapables de distinguer de manière fiable les instructions de confiance des entrées non fiables. Ce n’est pas un bug qui sera corrigé dans la prochaine version du modèle — c’est une propriété inhérente à la façon dont les modèles de langage basés sur les transformeurs traitent le texte.

Chaque connexion MCP à un agent IA crée une nouvelle surface d’attaque. Chaque donnée que l’IA traite est un vecteur potentiel d’injection de prompts. Chaque outil que l’IA peut appeler est une capacité que l’attaquant hérite. Et chaque identifiant auquel l’IA peut accéder est un identifiant que l’attaquant peut voler. Plus les agents IA deviennent puissants et connectés, plus ils deviennent précieux comme cibles d’attaque. C’est le paradoxe de sécurité de l’IA agentique : les fonctionnalités qui rendent les agents utiles sont les mêmes qui les rendent dangereux.

Ce que les protocoles devraient faire maintenant

Le hack de Resolv fournit un plan clair des mesures défensives que chaque protocole DeFi utilisant des agents IA doit implémenter. Ce ne sont pas des bonnes pratiques optionnelles — ce sont des exigences minimales pour tout protocole qui ne veut pas être le prochain gros titre à 23 M$.

1. Séparer la signature de l’IA — de manière permanente

C’est la conclusion la plus importante. Les agents IA ne doivent jamais détenir, accéder ni se trouver dans le même chemin d’identifiants que les clés de signature. L’architecture « Les agents proposent, les humains signent » préconisée par Guillemet devrait être la norme pour chaque protocole. Une IA peut analyser une demande de swap en attente et recommander un montant de frappe. Elle peut préparer les paramètres de la transaction. Elle peut même soumettre la transaction à une file d’attente. Mais la signature effective — l’autorisation cryptographique qui rend la transaction exécutable — doit nécessiter une approbation humaine à travers une frontière imposée matériellement.

En pratique, cela signifie : le compte AWS où les agents IA s’exécutent doit avoir zéro accès au compte AWS (ou HSM, ou multisig) où les clés de signature résident. Aucun rôle IAM, aucune confiance inter-comptes, aucun identifiant partagé. Une séparation architecturale complète.

2. Durcir chaque connexion MCP

Chaque serveur MCP qui se connecte à un agent IA devrait implémenter :

• Désinfection des entrées : Supprimer ou échapper les schémas potentiels d’injection de prompts de toutes les données avant qu’elles n’atteignent l’IA.
• Filtrage des sorties : Surveiller les sorties de l’IA à la recherche de schémas d’identifiants (clés API, jetons, chaînes de connexion) et les bloquer avant qu’ils ne quittent le système.
• Accès basé sur les rôles : Utiliser le niveau de privilège minimum requis. Ne jamais connecter une IA à une base de données avec un accès service_role. Utiliser des jetons limités et en lecture seule dans la mesure du possible.
• Liste blanche d’outils : Définir explicitement quels outils MCP l’IA peut appeler. Bloquer tous les outils qui ne figurent pas sur la liste blanche. Empêcher l’IA de découvrir ou d’invoquer de nouveaux outils au moment de l’exécution.
• Limitation de débit : Limiter la fréquence et le volume des appels d’outils qu’une IA peut effectuer dans une fenêtre temporelle pour empêcher une exfiltration rapide.

3. Implémenter des garde-fous on-chain

Même si l’infrastructure hors chaîne est compromise, des mécanismes de sécurité on-chain peuvent limiter les dégâts. Le contrat de Resolv n’en avait aucun. Chaque contrat de frappe ou d’opération à forte valeur devrait inclure :

• Plafonds de frappe maximum : Un plafond par transaction et par heure sur le montant pouvant être frappé. Si Resolv avait plafonné la frappe à, disons, 2x la valeur du dépôt, l’attaquant aurait pu voler 400 000 $ au lieu de 23 M$.
• Vérifications par oracle : Avant la frappe, vérifier le ratio dépôt/frappe par rapport à un oracle externe. Si le ratio dévie au-delà d’un seuil, annuler la transaction.
• Verrous temporels : Les opérations de frappe importantes devraient nécessiter un délai obligatoire (par ex. 15 minutes à 24 heures) pendant lequel la frappe en attente peut être examinée et annulée.
• Pauses déclenchées par anomalie : Si le volume de frappe dépasse les normes historiques d’un facteur important (10x, 50x), le contrat devrait automatiquement se mettre en pause et nécessiter une intervention multisig pour reprendre.

4. Multisig pour toutes les opérations critiques

Le SERVICE_ROLE n’aurait jamais dû être un simple EOA. Les opérations critiques du protocole — frappe, destruction, modification de paramètres, mises à jour, pauses d’urgence — devraient nécessiter plusieurs signataires indépendants. Un multisig 3 sur 5 ou 4 sur 7 utilisant des signataires géographiquement distribués avec des portefeuilles matériels aurait rendu l’attaque de Resolv virtuellement impossible, même avec la clé SERVICE_ROLE compromise, car l’attaquant aurait dû compromettre plusieurs signataires indépendants simultanément.

5. Fondamentaux de la sécurité cloud

L’attaque Resolv a exploité des défaillances basiques de sécurité cloud qui auraient été détectées par un audit de sécurité cloud standard :

• IAM de moindre privilège : Les identifiants temporaires délivrés aux agents IA devraient être limités aux permissions minimales requises. Un assistant IA qui interroge des tables de base de données n’a pas besoin d’accès à KMS.
• Pas d’identifiants de longue durée : Les agents IA devraient utiliser des identifiants de courte durée, renouvelés automatiquement. Si les identifiants de l’IA de Resolv avaient expiré en quelques minutes plutôt que de rester valides assez longtemps pour le mouvement latéral, l’attaque aurait été significativement plus difficile.
• Journalisation et alertes d’accès KMS : Chaque accès à une clé KMS devrait générer une alerte. Les schémas d’accès inhabituels (nouvelle IP, nouveau rôle, nouvelle heure de la journée) devraient déclencher une enquête immédiate.
• Segmentation réseau : L’environnement de l’agent IA et l’environnement de gestion de clés devraient être dans des VPC (Virtual Private Clouds) séparés sans chemin réseau entre eux.

6. Déployer des défenses contre l’injection de prompts

Bien qu’aucune défense ne soit efficace à 100 % contre l’injection de prompts (cela reste un problème de recherche ouvert), plusieurs techniques relèvent significativement la barre pour les attaquants :

• Spotlighting : Une technique qui marque la frontière entre les instructions de confiance et les données non fiables à l’aide de délimiteurs spéciaux que l’IA est entraînée à respecter. Le prompt système instruit explicitement l’IA de traiter le contenu dans les délimiteurs non fiables comme des données uniquement, jamais comme des instructions.
• Hiérarchie d’instructions : Configurer l’IA pour que les instructions de niveau système prennent toujours le dessus sur toute instruction trouvée dans les entrées utilisateur ou les données externes. C’est imparfait mais augmente la difficulté d’une injection réussie.
• Tests adversariaux : Tester régulièrement vos intégrations IA en red team avec des tentatives d’injection de prompts. Si votre équipe de sécurité ne parvient pas à extraire des identifiants par injection de prompts, cela ne signifie pas qu’un attaquant ne le peut pas — mais c’est un minimum nécessaire.
• Classificateurs de sorties : Utiliser un modèle d’IA séparé et plus simple pour analyser les sorties de l’agent principal à la recherche de fuites potentielles d’identifiants, d’appels d’outils anormaux ou de signes de suivi d’instructions provenant d’entrées non fiables.

7. Surveiller l’ensemble de la pile

La surveillance on-chain est nécessaire mais n’est plus suffisante. Les protocoles doivent désormais surveiller :

• Journaux d’audit cloud : AWS CloudTrail, GCP Cloud Audit, Azure Activity Logs — chaque appel API dans l’environnement cloud devrait être journalisé et analysé.
• Comportement des agents IA : Journaliser chaque appel d’outil, chaque entrée, chaque sortie. Établir des lignes de base pour le comportement normal et alerter sur les déviations.
• Invocations d’outils MCP : Suivre quels outils MCP sont appelés, à quelle fréquence et avec quels paramètres. Un pic soudain dans les appels d’outils liés aux identifiants devrait déclencher une enquête immédiate.
• Anomalies on-chain : Continuer à surveiller les frappes inhabituelles, les transferts importants et les déviations de prix — mais reconnaître qu’au moment où ceux-ci apparaissent on-chain, la compromission hors chaîne peut déjà être terminée.

Vue d’ensemble : quand la machine est la vulnérabilité

Le hack de Resolv USR n’est pas seulement l’histoire d’un protocole qui a pris de mauvaises décisions architecturales. C’est un aperçu d’une nouvelle catégorie de risque à laquelle l’ensemble de l’industrie crypto doit faire face alors que l’intégration de l’IA s’accélère.

Au cours de la dernière décennie, le récit de la sécurité crypto a été dominé par les bugs de contrats intelligents. Le hack de The DAO en 2016 nous a appris la réentrance. Le gel du portefeuille Parity nous a appris les contrats de bibliothèque. Le hack du pont Wormhole nous a appris la vérification inter-chaînes. Chaque exploit a fait progresser la compréhension de l’industrie en matière de sécurité on-chain, conduisant à de meilleurs outils d’audit, à la vérification formelle et aux programmes de bug bounty. L’industrie de la sécurité des contrats intelligents est maintenant mature, bien financée et véritablement efficace pour trouver les vulnérabilités au niveau du code.

Mais le hack de Resolv a contourné tout cela. L’attaquant n’avait pas besoin de trouver un bug de code parce que le code était sans importance. L’attaquant devait trouver un moyen d’obtenir une clé de signature, et le chemin passait par un chatbot IA, une base de données cloud et un service de gestion de clés — tous hors chaîne, tous centralisés, tous invisibles aux systèmes de surveillance on-chain que l’industrie a dépensé des milliards à construire.

Ce n’est pas un problème que de meilleurs audits de contrats intelligents peuvent résoudre. Ce n’est pas un problème que la vérification formelle peut adresser. Cela nécessite une discipline de sécurité entièrement nouvelle qui combine la sécurité cloud, la sûreté de l’IA, la défense contre l’injection de prompts, les bonnes pratiques de gestion de clés et la surveillance DeFi traditionnelle dans un cadre unifié. Un tel cadre n’existe pas aujourd’hui sous une forme standardisée et largement adoptée. Le hack de Resolv est le signal d’alarme.

L’industrie fait désormais face à un choix. Elle peut traiter le hack de Resolv comme une anomalie — l’erreur d’une seule équipe, peu susceptible d’être répétée — et continuer à déployer des agents IA avec des privilèges élevés et des contrôles de sécurité minimaux. Ou elle peut reconnaître que la combinaison de l’IA agentique, de l’accès aux outils MCP et des opérations on-chain à forte valeur crée une surface de menace fondamentalement nouvelle qui exige des défenses fondamentalement nouvelles.

L’argent intelligent parie sur la seconde option. Mais l’histoire suggère que de nombreux protocoles choisiront la première — et nous écrirons sur le prochain exploit de type Resolv avant la fin de l’année.

Rester en sécurité dans la crypto a toujours exigé de comprendre où les risques se trouvent réellement. Après le 22 mars 2026, ces risques incluent les agents IA auxquels les protocoles font confiance pour gérer leur infrastructure.

Lectures associées