25 M$ volés via une injection de prompt MCP : comment un chatbot IA a brisé la DeFi sans toucher à la blockchain

Avertissement Introduction 1. Qu'est-ce que Resolv et comment fonctionne le minting de l'USR ?

Qu'est-ce que Resolv et comment fonctionne le minting de l'USR ?

Resolv est un protocole destablecoinqui utilise une stratégie connue sous le nom decouverture delta-neutrepour maintenir l'USR indexé à 1,00 $. En termes simples, le protocole détient des actifs crypto (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 approximativement 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 lesstablecoinset la section sur lacrise d'Ethena USDedans notre rapport Real Yield.) Cette conception appartient à la même famille que l'USDe d'Ethena, bien qu'avec des choix d'implémentation distincts qui s'avéreront critiques le 22 mars.

Le processus de minting (émission) de l'USR suit un modèle en deux étapes courant dans les protocoles nécessitant une autorisation hors-chaîne. Tout d'abord, un utilisateur appellerequestSwap(), déposant de l'USDC dans le contrat comme collatéral. Cela crée une demande de minting en attente. Deuxièmement, une adresse privilégiée — leSERVICE_ROLE— appellecompleteSwap()pour autoriser l'émission effective des jetons USR. L'idée est simple : le dépôt provient 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 minting avec la clé SERVICE_ROLE.

C'est ici que l'architecture devient dangereuse. Le SERVICE_ROLE était uncompte externe unique (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é d'émettre n'importe quel montant d'USR. CommeChainalysis l'a documenté dans son post-mortem, « le contrat impose un minimum de sortie USR — mais, de manière critique, aucun maximum ».

Relisez bien ceci. Lesmart contractpermettrait au SERVICE_ROLE d'émettre un milliard d'USR contre un seul dollar d'USDC, et le code s'exécuterait sans erreur. Il n'y avait aucune vérification de ratio on-chain. Pas de plafond d'émission maximum. Pas de validation par oracle. Pas de coupe-circuit. Le contrat faisait implicitement confiance au SERVICE_ROLE — quel que soit le montant autorisé, il était émis, point final.

L'analyse de DeFiPrimel'a formulé sans détour : il n'y avait « aucun garde-fou on-chain imposant ce ratio ». Tout le 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 fausse.

Pour comprendre pourquoi cela est important, considérez la différence entre un protocole où la logique d'émission réside on-chain (vérifiée par le code, immuable, transparente) et un protocole où elle réside hors-chaîne (dépendante d'une clé unique, stockée dans une infrastructure cloud, contrôlée par un logiciel qui peut être compromis). Resolv a choisi la seconde option. Et le logiciel contrôlant cette clé était un agent IA.

2. L'attaque par injection de prompt

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

C'est ici que le piratage de Resolv se distingue de tous les exploits DeFi précédents de l'histoire. Il n'y a eu aucun bug de réentrée. Aucune manipulation de prêt flash. Aucun front-running d'oracle. Aucune attaque de gouvernance. L'attaquant n'a pas touché à la blockchain du tout — pas avant la toute fin, lorsqu'il a utilisé une clé de signature obtenue légitimement pour autoriser des transactions que le smart contract a exécutées sans faille.

Le vecteur d'attaque était unassistant IA— un grand modèle de langage (LLM) intégré à l'infrastructure opérationnelle de Resolv. Comme de nombreux protocoles en 2025-2026 ayant adopté l'IA pour leurs outils internes, Resolv avait déployé un assistant basé sur un LLM connecté à leurs systèmes backend via leModel Context Protocol (MCP).

Qu'est-ce que le Model Context Protocol ?

Le MCP est un standard ouvertlancé par Anthropic en novembre 2024qui permet aux modèles d'IA de découvrir et d'interagir dynamiquement avec des outils externes pendant l'exécution. Considérez-le comme un adaptateur universel : au lieu de coder en dur chaque intégration dont une IA pourrait avoir besoin, le 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 dans un bucket de stockage, appeler un point de terminaison d'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 l'est tout autant, bien que beaucoup 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éesSupabase— et il fonctionnait avec leservice_roleprivilèges.

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

Comment fonctionne l'injection de prompt

L'injection de prompt est conceptuellement simple mais d'une efficacité dévastatrice. Un LLM traite du texte — il lit des entrées et génère des sorties. Le problème fondamental est queles 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 lue par l'IA, celle-ci peut interpréter ce texte comme une commande légitime.

L'Unité 42 de Palo Alto Networksa publié des recherches approfondies sur les attaques par injection de prompt indirecte observées dans la nature. Leurs conclusions sont sombres : 37,8 % des attaques utilisent du texte brut visible (instructions simplement écrites dans un document traité par l'IA), 19,8 % utilisent le masquage d'attributs HTML (dissimulation d'instructions dans des attributs HTML que les humains ne voient pas mais que l'IA lit), et 16,9 % utilisent la suppression CSS (intégration de commandes dans du CSS rendu invisible pour les spectateurs humains mais analysé par le modèle). Ces attaques ne sont pas théoriques. Elles se produisent dans des systèmes de production, contre de réelles organisations, en ce moment même.

Le modèle d'attaque Supabase MCP avait déjà été documenté avant l'incident Resolv.Les recherches de PVMLdé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 disposant d'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 y fait référence uniquement comme une « injection de prompt élaborée » — mais le résultat est connu : l'IA a divulgué des identifiants cloud temporaires, y compris des jetons d'accès AWS qui ont permis de prendre pied dans l'infrastructure de Resolv.

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

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

L'enseignement critique est qu'il ne s'agissait pas d'un échec de l'IA au sens abstrait. L'IA a fait exactement ce pour quoi elle a été conçue : elle a traité une entrée et généré une sortie. L'échec résidait dans l'architecture qui a donné à une IA — un système qui traite par définition des entrées non fiables — l'accès à des identifiants qui pouvaient ultimement contrôler un protocole de plus de 100 millions de dollars. C'est ce quele CTO de Ledger, Charles Guillemet, appelle le « trifecta mortel » : entrée non fiable, capacités d'exécution puissantes et accès réseau pour l'exfiltration. Tout système combinant les trois est, selon les mots de Guillemet, « voué à l'échec sous pression ».

3. Mouvement latéral

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

Avec les identifiants AWS temporaires en main, l'attaquant est passé de l'exploitation de l'IA à un modèle d'attaque classique d'infrastructure cloud :le mouvement latéral. C'est une technique familière à toute équipe de sécurité cloud mais presque totalement absente du manuel de sécurité DeFi, qui s'est historiquement concentré sur les audits de smart contracts et la surveillance on-chain.

L'attaquant n'est pas allé directement sur la blockchain. Ce n'était pas nécessaire. L'objectif était la clé de signature, et la clé de signature résidait dans le cloud.

La première étape a consisté à é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 architecturé avec un IAM de moindre privilège, les identifiants temporaires d'un assistant IA seraient limités — 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 ont fourni un accès suffisant pour s'enfoncer davantage.

L'attaquant a navigué depuis le point d'ancrage IAM initial versAWS 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 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 possède des identifiants AWS valides avec des permissions suffisantes, KMS lui servira la clé aussi volontiers qu'il la sert à l'application légitime.

Chainalysis a confirmé le parcours : l'attaquant « a accédé à l'environnement AWS Key Management Service de Resolv où était stockée la clé de signature privilégiée du protocole ». Une fois à l'intérieur de KMS, l'attaquant disposait de la clé privée SERVICE_ROLE — l'unique secret cryptographique autorisant toutes les opérations de frappe (minting) d'USR.

L'ensemble de la phase de mouvement latéral — des identifiants fuités par l'IA à l'accès KMS — a probablement pris quelques minutes. Les attaques d'infrastructure cloud vont vite lorsque l'attaquant dispose d'identifiants valides. Il n'y a pas de chaînes d'exploitation à développer, pas de zero-day à 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 violations de cloud, selon tous les rapports majeurs sur la sécurité cloud des équipes de renseignement sur les menaces d'AWS, Google Cloud et Microsoft Azure.

Il convient de s'arrêter pour apprécier l'ironie. Resolv stockait son secret le plus critique — la clé qui contrôle des centaines de millions de dollars d'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 qui ne pouvait pas distinguer une instruction légitime d'une instruction malveillante.

Tableau : Chaîne d'attaque — Du prompt à 23M $. Cinq étapes, moins de 30 minutes, zéro exploitation de smart contract.

4. Exécution on-chain

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

Avec la clé SERVICE_ROLE compromise, l'attaquant a finalement touché la blockchain — et lesmart contracta fait exactement ce pour quoi il a été conçu.

Transaction 1 :L'attaquant a déposé environ 100 000 $ en USDC dans le contrat de frappe viarequestSwap(), puis a immédiatement appelécompleteSwap()avec la clé SERVICE_ROLE volée, autorisant la frappe de50 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 aucun contrôle de ratio pour la rejeter, aucun plafond maximum pour la limiter, aucun oracle pour vérifier si le montant de la frappe avait un quelconque rapport avec le dépôt.

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

Au total :80 millions d'USRcréés contre environ 200 000 $ de dépôts USDC réels. Une dilution de 400 à 500 fois de l'offre de jetons. Les jetons de chaque détenteur d'USR existant n'étaient instantanément plus garantis que par une fraction de ce qu'ils valaient quelques minutes auparavant.

La stratégie de liquidation a été méthodique. Plutôt que de déverser 80M d'USR directement sur un seul DEX — ce qui aurait déclenché des disjoncteurs immédiats et un glissement (slippage) maximal — l'attaquant a d'abord converti une partie importante d'USR enwstUSR (wrapped staked USR). Cette étape d'emballage servait un but tactique : le wstUSR était accepté par des pools de liquidité différents de l'USR brut, permettant à l'attaquant d'accéder à plusieurs lieux de liquidation simultanément et de réduire l'impact sur le prix sur n'importe quel pool individuel.

L'attaquant a ensuite réparti les ventes sur trois bourses décentralisées majeures :

• Curve Finance :Le principal lieu de liquidation pour les paires de stablecoins. Les pools USR/USDC et USR/USDT ont absorbé la pression de vente initiale avant que l'ancrage (peg) ne s'effondre.
• KyberSwap :Utilisé pour une conversion supplémentaire USDC/USDT.KyberSwap a bloqué les portefeuilles de l'exploitant en quelques heuresaprès l'attaque, mais le mal était déjà fait.
• Velodrome :Ciblé pour sa profonde liquidité sur Optimism, offrant une autre porte de sortie pour les fonds volés.

Le résultat a été rapide et dévastateur. Sur Curve,l'USR s'est effondré de 1,00 $ à 0,025 $ en environ 17 minutes— une chute de 97,5 %.The Block a rapporté quel'attaquant a extrait environ 25 millions de dollars, tandis queCoinDesk a chiffré le montant à environ 23 millions de dollars. Cet écart reflète la difficulté de suivre les montants exacts sur plusieurs DEX et chaînes en temps réel.

La conversion finale s'est faite des stablecoins vers l'ETH. L'attaquant a consolidé les gains en environ11 400 ETH— valant environ 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 — du premier mint à la consolidation finale en ETH — a prismoins de 30 minutes. Pour situer le contexte, c'est plus rapide que le temps nécessaire à la plupart des signataires de multisig pour coordonner une réponse d'urgence, plus rapide que ce qu'il faut à la plupart des équipes de protocole pour confirmer un exploit, et plus rapide que n'importe quel mécanisme de pause basé sur la gouvernance. L'avantage de la vitesse appartenait entièrement à l'attaquant.

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

5. Ce que les sociétés de sécurité ont découvert

Ce que les sociétés de sécurité ont découvert

Le hack de Resolv a déclenché une réponse immédiate de l'écosystème de la sécurité blockchain. En quelques heures, plusieurs firmes ont publié leurs premières évaluations. Ce qui en est ressorti n'était pas seulement le post-mortem d'un exploit isolé, mais la reconnaissance que l'ensemble du modèle de menace pour les protocolesDeFivenait de s'étendre.

Cyvers : première détection

Cyvers, une plateforme de surveillance de la sécurité Web3 en temps réel, a été parmi les premières à détecter l'activité anormale. Leurs systèmes ont signalé la création de 80 millions de jetons USR comme une anomalie critique — le volume de minting dépassait de plusieurs ordres de grandeur toute exécution précédente de completeSwap(). L'alerte de Cyvers a déclenché l'enquête de la communauté de sécurité au sens large et a aidé les exchanges et les DEX à commencer à bloquer les adresses de l'exploitant.

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 modèle de minting en deux transactions et a tracé les flux de fonds à travers Curve, KyberSwap et Velodrome. Le suivi en temps réel de PeckShield a été déterminant pour aider les exchanges à geler les actifs restants de l'exploitant avant qu'ils ne puissent être totalement blanchis.

Chainalysis : le post-mortem définitif

Chainalysis a publié l'analyse la plus complètesous le titre « Comment une 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 prompt → vol d'identifiants → mouvement latéral vers KMS → compromission du SERVICE_ROLE → minting non autorisé.

Les recommandations clés de Chainalysis incluaient :

• Surveiller les anomalies de ratio completeSwap() :Tout mint où la sortie USR dépasse l'entrée USDC de plus d'une faible tolérance (tenant compte du positionnement delta-neutre) devrait déclencher une alerte immédiate.
• Pause automatisée sur les événements de Mint suspects :Si le volume de minting dans une seule transaction ou une courte fenêtre de temps dépasse les normes historiques de 10 fois ou plus, le contrat devrait automatiquement se mettre en pause et nécessiter l'intervention d'un multisig pour reprendre.
• Surveillance de l'infrastructure cloud :Les journaux d'accès KMS doivent être surveillés en temps réel. Tout accès à partir d'une IP, d'un rôle ou d'une session non reconnus 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 des systèmes contrôlant des clés de signature. L'environnement de l'IA et l'environnement de gestion des clés doivent être des comptes AWS complètement séparés, sans accès croisé.

Charles Guillemet (Ledger) : l'avertissement structurel

La réponse la plus significative n'est peut-être pas venue d'une société de sécurité blockchain, mais deCharles 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 est allée au-delà des spécificités du hack de Resolv pour décrire un problème systémique sur la manière dont les agents IA sont déployés dans l'infrastructure crypto.

Guillemet a décrit la « trifecta létale » qui rend les agents IA intrinsèquement dangereux dans les environnements à haute 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 n'importe laquelle peut contenir des charges utiles d'injection de prompt.
2. Puissantes capacités d'exécution :Le 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 base de données, appels d'API, opérations sur fichiers et potentiellement 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 fuité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 provenir d'un humain, vérifiée par une séparation matérielle (comme un portefeuille matériel Ledger). L'IA ne peut jamais exécuter de manière autonome une action de haute valeur. Elle ne peut que recommander.

Sa conclusion a un poids particulier compte tenu de la position de Ledger en tant que leader des portefeuilles matériels :« Si votre architecture ne peut pas séparer clairement ce qu'un agent suggère de ce qu'un humain autorise, alors elle est vouée à l'échec sous pression. »

Le message collectif de la communauté de la sécurité était clair : le hack de Resolv n'était pas un incident isolé mais un signe avant-coureur. 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 database via service_role — doit immédiatement mettre en œuvre des défenses contre l'injection de prompt, la désinfection des entrées et le principe du moindre privilège pour tous les systèmes connectés à l'IA.

6. La blockchain n'a jamais été le maillon faible

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

C'est la partie qui devrait inquiéter tout bâtisseur, investisseur et chercheur en sécurité DeFi. Le code dusmart contracta fonctionnéparfaitement. Il a fait exactement ce pour quoi il a été conçu : lorsque la clé SERVICE_ROLE a signé une transaction completeSwap(), le contrat a minté le montant spécifié d'USR. Le code n'était pas buggé. Il n'était pas vulnérable à la réentrée. Il n'avait pas d'appels externes non vérifiés. Pas de collision de stockage. Pas d'overflow d'entier. Selon tous les critères standards de sécurité des smart contracts, le contrat de mint de Resolv était techniquement sain.

La vulnérabilité résidait entièrement dans lapile d'infrastructure centralisée : Agent IA → MCP → Supabase → AWS IAM → AWS KMS. Chaque composant de cette chaîne est off-chain. 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 totalement lemodèle de sécurité DeFitraditionnel. Au cours des six dernières années, l'immense majorité des exploits DeFi ont ciblé la couche blockchain : attaques de réentrée (The DAO, 2016), manipulation d'oracle par prêt flash (bZx, 2020 ; Cream Finance, 2021), attaques de gouvernance (Beanstalk, 2022), vulnérabilités de ponts (Ronin, Wormhole, Nomad, 2022) etexploits d'approbation de jetons. La réponse standard à ces attaques a été de meilleurs audits, la vérification formelle, les bug bounties 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 mint cent fois avec les meilleures firmes au monde sans rien trouver, car il n'y avait rien à trouver. Le contrat était sécurisé. L'agent IA qui le contrôlait ne l'était pas.

Andrew Whong, co-fondateur de Herd, a résumé l'échec architectural : « Le contrat de mint n'avait pas d'oracle ni de vérification de mint maximum. » Mais même cela sous-estime le problème. Des vérifications d'oracle et des plafonds de mint auraient aidé — ils auraient limité le rayon d'action — mais le problème fondamental est qu'une seule clé contrôlée par un agent IA compromissible avait une autorité de minting illimitée. La solution n'est pas seulement d'ajouter des vérifications on-chain. C'est de repenser toute la relation entre l'infrastructure IA et les opérations on-chain.

DeFiPrime a qualifié cela de« cas de confiance excessive dans l'infrastructure off-chain » — 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 sécuritaires.

Le paradoxe est douloureux. La promesse centrale de la DeFi est une finance sans confiance, sans permission et décentralisée. Pas de point de défaillance unique. Pas d'intermédiaire de confiance. Le code fait loi. Et pourtant, voici Resolv — un protocole gérant des centaines de millions de dollars — où la fonction de minting était 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 fuités en trompant un chatbot. La blockchain était le composant le plus sûr de toute la pile. C'est l'infrastructure off-chain — l'IA, le cloud, la gestion des 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 commeCleanSkypeuvent aider à surveiller lesapprobations de jetonset 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 lerisquedans la DeFi signifie désormais comprendre l'intégralité de la pile technologique, et pas seulement les contrats intelligents.

7. Pourquoi ce ne sera pas la dernière

Pourquoi ce ne sera probablement pas la dernière attaque contre l'infrastructure IA

Si le piratage de Resolv était un incident isolé — une défaillance ponctuelle d'un seul protocole ayant pris des décisions architecturales exceptionnellement mauvaises — cela 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 du monde réel sur le benchmark SCONE-bench — un ensemble de données de 405 contrats représentant 550 millions de dollars en valeur simulée. Cette recherche portait sur l'IA attaquant des contrats intelligents, mais les mêmes capacités s'appliquent en sens inverse : les agents IA sont assez 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 des modèles de pointe, notamment GPT-5 et Sonnet 4.5, ont trouvé deux failles zero-day parmi 2 849 contrats de la BNB Chain pour un coût de calcul de seulement 3 476 $. L'économie de la découverte de vulnérabilités assistée 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é uneaugmentation de 1 025 % des exploits liés à l'IApar rapport à 2024. Ce n'est pas une faute de frappe — une multiplication par dix en une seule année. Cette catégorie comprend le phishing alimenté par l'IA, la découverte de vulnérabilités assistée par l'IA, l'ingénierie sociale améliorée par deepfake, et maintenant les attaques par injection de prompt 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 % au début de 2024.

Lepaysage de la sécurité crypto en 2025était déjà sombre avant Resolv : 4,65 milliards de dollars de pertes totales, la compromission du multisig de Bybit, une vague d'échecs de contrôle d'accès. Le piratage de Resolv ajoute une nouvelle catégorie à une surface de menace déjà en expansion.

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

L'adoption du Model Context Protocol a explosé tout au long de 2025 et en 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, email) et les services financiers (API bancaires, processeurs de paiement, nœuds de blockchain). Chaque serveur MCP est une cible potentielle d'injection de prompt.

L'incident Supabase MCP documenté par PVMLétait le coup de semonce.Supabase a lui-même publié « Defense in Depth for MCP »en réponse, recommandant que les serveurs MCP n'utilisent jamais de clés service_role et utilisent plutôt une authentification par utilisateur avec un périmètre restreint. Mais l'adoption de ces recommandations a été au mieux inégale. De nombreuses équipes de protocoles ont déployé des intégrations MCP pendant la vague de hype de l'IA de 2024-2025 sans mettre en œuvre de contrôles de sécurité de base.

Le piratage 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 du MCP et des énormes incitations financières pour les attaquants crée un paysage de menaces qui croît plus vite que le déploiement des défenses. 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 de Resolv comme un avertissement direct.

Le problème structurel

Le problème de fond 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 résultats 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é intrinsèque de la manière dont les modèles de langage basés sur les transformers traitent le texte.

Chaque connexion MCP à un agent IA crée une nouvelle surface d'attaque. Chaque donnée traitée par l'IA est un vecteur potentiel d'injection de prompt. Chaque outil que l'IA peut appeler est une capacité dont 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 des cibles d'attaque précieuses. C'est le paradoxe de la sécurité de l'IA agentique : les fonctionnalités qui rendent les agents utiles sont les mêmes qui les rendent dangereux.

8. Ce que les protocoles devraient faire maintenant

Ce que les protocoles devraient faire maintenant

Le piratage de Resolv fournit un modèle clair pour les mesures défensives que chaque protocole DeFi utilisant des agents IA doit mettre en œuvre. Ce ne sont pas des options facultatives — ce sont des exigences minimales pour tout protocole qui ne veut pas faire la une des journaux pour une perte de 23 millions de dollars.

1. Séparer la signature de l'IA — de façon permanente

C'est la leçon la plus importante à retenir.Les agents IA ne doivent jamais détenir, accéder ou se trouver sur le même chemin d'accès que les clés de signature.L'architecture « Les agents proposent, les humains signent »préconisée par Guillemetdevrait être la norme pour chaque protocole. Une IA peut analyser une demande de swap en attente et recommander un montant de mint. Elle peut préparer les paramètres de la transaction. Elle peut même soumettre la transaction à une file d'attente. Mais la signature réelle — l'autorisation cryptographique qui rend la transaction exécutable — doit nécessiter une approbation humaine via une barrière matérielle (hardware).

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

2. Sécuriser chaque connexion MCP

Chaque serveur MCP qui se connecte à un agent IA devrait mettre en œuvre :

• Assainissement des entrées :Supprimer ou échapper les schémas potentiels d'injection de prompt de toutes les données avant qu'elles n'atteignent l'IA.
• Filtrage des sorties :Surveiller les sorties de l'IA pour détecter des 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 en lecture seule avec un périmètre restreint autant que possible.
• Liste d'autorisation d'outils :Définir explicitement quels outils MCP l'IA peut appeler. Bloquer tous les outils qui ne sont pas sur la liste. 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 de temps pour empêcher une exfiltration rapide.

3. Mettre en œuvre des garde-fous on-chain

Même si l'infrastructure off-chain est compromise, les mécanismes de sécurité on-chain peuvent limiter les dégâts. Le contrat Resolv n'en avait aucun. Chaque contrat de mint ou d'opération de haute valeur devrait inclure :

• Plafonds de mint maximum :Un plafond par transaction et par heure sur le montant pouvant être minté. Si Resolv avait plafonné le mint à, disons, 2x la valeur du dépôt, l'attaquant aurait pu voler 400 000 $ au lieu de 23 millions.
• Vérifications de prix par oracle :Avant le mint, vérifier le ratio dépôt/mint par rapport à un oracle externe. Si le ratio s'écarte au-delà d'un seuil, annuler la transaction.
• Verrous temporels (Time-locks) :Les opérations de mint importantes devraient nécessiter un délai obligatoire (ex: 15 minutes à 24 heures) pendant lequel le mint en attente peut être examiné et annulé.
• Pauses déclenchées par des anomalies :Si le volume de mint dépasse les normes historiques par 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 une simple EOA. Les opérations critiques du protocole — mint, burn, modifications 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 de Resolv a exploité des défaillances de base de la sécurité cloud qui auraient été détectées par un examen standard :

• IAM au moindre privilège :Les identifiants temporaires délivrés aux agents IA devraient être limités aux permissions minimales absolues requises. Un assistant IA qui interroge des tables de base de données n'a pas besoin d'accéder au KMS.
• Pas d'identifiants à longue durée de vie :Les agents IA devraient utiliser des identifiants à courte durée de vie, 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 un mouvement latéral, l'attaque aurait été nettement plus difficile.
• Journalisation et alertes d'accès KMS :Chaque accès à une clé KMS devrait générer une alerte. Des 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 du réseau :L'environnement de l'agent IA et l'environnement de gestion des 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 prompt

Bien qu'aucune défense ne soit efficace à 100 % contre l'injection de prompt (cela reste un problème de recherche ouvert), plusieurs techniques relèvent considérablement 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 entre délimiteurs non fiables uniquement comme des données, jamais comme des instructions.
• Hiérarchie des instructions :Configurer l'IA pour que les instructions au niveau système l'emportent toujours sur toutes les instructions trouvées dans les entrées utilisateur ou les données externes. C'est imparfait mais cela augmente la difficulté d'une injection réussie.
• Tests adverses :Effectuez régulièrement des tests de type « red-team » sur vos intégrations d'IA avec des tentatives d'injection de prompt. Si votre équipe de sécurité ne peut pas extraire d'identifiants par injection de prompt, cela ne signifie pas qu'un attaquant ne le peut pas — mais c'est un minimum nécessaire.
• Classificateurs de sortie :Utiliser un modèle d'IA séparé et plus simple pour scanner 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'intégralité 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 d'API dans l'environnement cloud doit être consigné et analysé.
• Comportement des agents IA :Consigner chaque appel d'outil, chaque entrée, chaque sortie. Établir des références pour le comportement normal et alerter en cas de déviation.
• Invocations d'outils MCP :Suivre quels outils MCP sont appelés, à quelle fréquence et avec quels paramètres. Un pic soudain d'appels d'outils liés aux identifiants devrait déclencher une enquête immédiate.
• Anomalies on-chain :Continuer à surveiller les mints inhabituels, les transferts importants et les écarts de prix — mais reconnaître qu'au moment où ceux-ci apparaissent on-chain, la compromission off-chain peut déjà être complète.

9. Vue d'ensemble

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

Le piratage de l'USR de Resolv n'est pas seulement l'histoire d'un protocole ayant pris de mauvaises décisions architecturales. C'est un aperçu d'une nouvelle catégorie de risques auxquels toute l'industrie crypto doit faire face à mesure 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 piratage 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 piratage du pont Wormhole nous a appris la vérification cross-chain. Chaque exploit a fait progresser la compréhension de la sécurité on-chain par l'industrie, menant à de meilleurs outils d'audit, à la vérification formelle et aux bug bounties. L'industrie de la sécurité des contrats intelligents est désormais mature, bien financée et véritablement efficace pour trouver des vulnérabilités au niveau du code.

Mais le piratage de Resolv a contourné tout cela. L'attaquant n'a pas eu besoin de trouver une faille dans le code car celui-ci était hors de cause. 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 — le tout hors chaîne, centralisé et invisible pour les systèmes de surveillance on-chain dans lesquels l'industrie a investi des milliards.

Ce n'est pas un problème que de meilleurs audits de smart contracts peuvent résoudre. Ce n'est pas un problème que la vérification formelle peut traiter. Cela nécessite une toute nouvelle discipline de sécurité combinant la sécurité cloud, la sécurité de l'IA, la défense contre l'injection de prompts, les meilleures pratiques de gestion des clés et la surveillance DeFi traditionnelle dans un cadre unifié. Aucun cadre de ce type n'existe aujourd'hui sous une forme standardisée et largement adoptée. Le piratage de Resolv est un signal d'alarme.

L'industrie fait désormais face à un choix. Elle peut traiter le piratage de Resolv comme une anomalie — l'erreur d'une seule équipe, peu susceptible de se reproduire — 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 à haute valeur crée une surface de menace fondamentalement nouvelle qui exige des défenses fondamentalement nouvelles.

Les investisseurs avisés parient sur la deuxième 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 cryptoa toujours nécessité de comprendre où résident réellement les risques. Après le 22 mars 2026, ces risques incluent les agents IA auxquels les protocoles font confiance pour gérer leur infrastructure.

Appel à l'action Indépendance éditoriale Lectures associées

Lectures associées