L’IA transforme la sécurité Web3 en crise de contrôle des accès

OneSafe a fait son apparition dans Google News le 30 août avec un avertissement sans détour : l’intelligence artificielle rend les attaques contre le Web3 plus faciles, plus rapides et plus difficiles à reconnaître. L’article évoque des logiciels malveillants, le phishing, la compromission de clés privées et des flux de travail risqués pour les développeurs. Sa préoccupation centrale est justifiée, mais plusieurs affirmations à l’appui manquent de détails permettant une vérification indépendante.

Cette lacune compte, car les actifs numériques transforment les erreurs de sécurité ordinaires en événements financiers irréversibles. Un message convaincant peut amener quelqu’un à révéler une phrase de récupération ou à approuver une transaction malveillante. Une machine de développement infectée peut exposer des identifiants de déploiement, des clés de signature ou des accès privilégiés. Il n’existe souvent aucune banque capable d’annuler le résultat.

Le véritable conflit n’oppose donc pas l’IA à la cybersécurité traditionnelle. Il oppose une automatisation qui s’accélère à des contrôles de sécurité conçus autour d’activités humaines plus lentes et plus visibles. La couverture de la sécurité de l’IA par OneSafe illustre cette pression, tandis que les données fédérales et les recherches indépendantes montrent où se situent réellement les risques mesurables.

Ce que l’avertissement de OneSafe dans Google News a réellement changé

OneSafe a transformé une préoccupation générale concernant l’IA malveillante en avertissement sur les flux de travail Web3, mais n’a pas établi l’existence d’une nouvelle intrusion ni révélé une vulnérabilité nouvellement découverte.

L’avertissement de sécurité affirme que l’IA abaisse le niveau de compétence requis des attaquants. Il indique que les développeurs doivent examiner attentivement les fichiers de configuration de l’IA, conserver des sauvegardes propres et renforcer leur sensibilisation à la sécurité. Il met également en avant les infostealers, des programmes malveillants conçus pour collecter des identifiants, des données de navigateur, des informations de portefeuille et d’autres secrets.

Il s’agit d’une intervention éditoriale, et non d’une annonce produit, d’un avis de sécurité ou d’un rapport d’incident. OneSafe n’a pas identifié de protocole récemment compromis. L’entreprise n’a pas publié d’indicateurs techniques que les défenseurs pourraient utiliser pour détecter une infection. Elle n’a pas non plus chiffré le nombre d’attaques Web3 impliquant l’IA.

L’apparition dans Google News donne néanmoins à l’argument une portée plus large. Elle place une question opérationnelle précise devant les fondateurs et les développeurs : la production d’un outil de programmation par IA doit-elle bénéficier du même degré de confiance que le code écrit par un collègue ?

La réponse la plus prudente est non. Le code généré, les extensions téléchargées, les fichiers de configuration, les commandes shell et les instructions destinées aux agents exigent tous une vérification. Ce principe s’applique même lorsqu’un système d’IA n’est pas malveillant. Un modèle peut produire du code non sécurisé sans être contrôlé par un attaquant.

OneSafe décrit également un incident apparent de malware impliquant une personne identifiée sous le nom de Numa Lunah. Selon l’article, une interaction avec un outil d’IA aurait entraîné une infection persistante après un redémarrage. Toutefois, l’article ne renvoie ni à un rapport d’analyse forensique, ni à un échantillon de malware, ni à une chronologie de l’incident, ni au récit d’origine.

Cette omission empêche les lecteurs de déterminer ce qui s’est réellement produit. L’infection peut être arrivée par une application contrefaite, une dépendance malveillante, une commande copiée ou une configuration compromise. Chaque vecteur exige une défense différente.

L’article attribue de même un avertissement à un développeur nommé Calle, sans fournir de lien source ni suffisamment d’éléments d’identification. La position de fond est plausible, mais cette attribution ne doit pas avoir le poids d’une preuve vérifiée.

Cette distinction est essentielle dans le journalisme de sécurité. Une préoccupation crédible ne constitue pas automatiquement un incident documenté. Les lecteurs doivent distinguer l’avertissement général de OneSafe des données d’attaque établies de manière indépendante.

La version la plus solide de cette histoire est donc plus nuancée que ne le suggère le titre. L’IA accroît le volume et la crédibilité des contenus nuisibles. Les systèmes Web3 exposent des cibles d’une valeur inhabituelle et aux conséquences irréversibles. Cette combinaison augmente le coût de contrôles insuffisants sur l’identité, les accès et les transactions.

Cette conclusion résiste à l’examen. Certains détails illustratifs de l’article n’atteignent pas encore le même niveau de preuve.

Pourquoi la sécurité de l’IA dans le Web3 est devenue un problème de contrôle des accès

Les pertes Web3 les plus importantes commencent de plus en plus par une autorité volée, et non par un modèle d’IA qui vainc la cryptographie blockchain.

Une clé privée permet à son détenteur d’autoriser des actions pour une adresse blockchain. Une phrase de récupération peut rétablir le contrôle d’un portefeuille entier. Des identifiants d’administrateur peuvent donner accès aux mises à niveau d’un protocole, aux systèmes cloud, aux pipelines de déploiement ou aux comptes d’entreprise.

L’IA n’a pas besoin de casser le chiffrement lorsqu’elle peut aider un attaquant à se faire passer pour un collègue, à personnaliser des messages de phishing ou à explorer des données volées. Le modèle devient un amplificateur de techniques criminelles établies.

Les données de plaintes pour 2025 du FBI illustrent cet environnement plus large. L’Internet Crime Complaint Center a reçu 1 008 597 plaintes au cours de 2025. Les pertes déclarées liées à la criminalité facilitée par le numérique ont approché 21 milliards de dollars.

Les plaintes impliquant des cryptomonnaies ont généré plus de 11 milliards de dollars de pertes déclarées sur 181 565 signalements. Ces chiffres couvrent plusieurs types de criminalité ; ils ne doivent donc pas être considérés comme une mesure du piratage Web3 propulsé par l’IA. Ils établissent l’ampleur financière de la cible.

Le même rapport comprenait pour la première fois de l’histoire du centre une section consacrée à l’IA. Il a recensé 22 364 plaintes contenant des informations liées à l’IA et environ 893 millions de dollars de pertes ajustées. Les plaintes d’investissement présentant un lien déclaré avec l’IA représentaient plus de 632 millions de dollars.

Ces catégories se recoupent sur le plan conceptuel, mais elles ne doivent pas être additionnées. Les données du FBI décrivent des plaintes et des pertes déclarées, non un recensement exhaustif de la criminalité. Elles ne prouvent pas non plus que l’IA a causé chaque perte associée à une plainte liée à l’IA.

Les tendances restent néanmoins instructives. Le FBI a identifié des messages générés imitant des dirigeants, le clonage vocal, des profils fabriqués, des recommandations synthétiques et des conversations personnalisées. Ces techniques ciblent le jugement humain et les procédures institutionnelles.

C’est pourquoi les préoccupations de OneSafe concernant la sécurité de l’IA relèvent d’une discussion sur le contrôle des accès. Si un seul message convaincant peut déclencher un transfert, le système dépend de la capacité d’une personne à détecter correctement chaque tromperie. L’IA donne aux attaquants davantage d’occasions de mettre à l’épreuve cette dépendance fragile.

Le Web3 accentue le problème, car l’autorisation y confère souvent un pouvoir financier immédiat. Un compte de messagerie d’entreprise compromis peut initier une demande de paiement frauduleuse. Un portefeuille compromis peut exécuter directement le paiement.

Les smart contracts ajoutent une couche supplémentaire. Ce sont des programmes déployés sur une blockchain, où ils peuvent détenir des actifs ou appliquer des règles financières. Certains contrats peuvent être mis à niveau ou suspendus par des comptes privilégiés. Si des attaquants s’emparent de ces privilèges, un code de contrat audité peut offrir peu de protection.

La réponse ne consiste pas simplement à renforcer la formation des employés. La formation compte, mais les personnes ne peuvent pas identifier de manière fiable chaque voix synthétique, message réaliste ou interface clonée. Les organisations ont besoin de contrôles qui partent du principe que certaines tromperies réussiront.

Ces contrôles comprennent la signature adossée à du matériel, la simulation de transactions, les listes d’autorisation de retrait, des environnements distincts pour le développement et la trésorerie, ainsi que des exigences d’approbation impliquant plus d’une personne. Les équipes ont également besoin d’identifiants de courte durée et de procédures centralisées de révocation.

Une base de connaissances consultable peut soutenir la préparation aux incidents en gardant des procédures vérifiées accessibles. Elle ne peut pas remplacer l’application technique des contrôles, mais elle peut réduire la confusion lorsque les équipes ont rapidement besoin d’instructions fiables.

La sécurité de l’IA dans le Web3 consiste donc moins à reconnaître chaque faux qu’à empêcher qu’un faux réussi n’obtienne suffisamment d’autorité pour vider un portefeuille ou modifier des systèmes de production.

L’automatisation aide les attaquants, mais le Web3 fournit toujours l’effet de levier

L’IA améliore la rapidité et la présentation des attaques, tandis que les identifiants concentrés et les transactions irréversibles du Web3 déterminent leur impact.

L’expression « attaque propulsée par l’IA » peut masquer davantage qu’elle n’explique. Elle peut désigner du texte de phishing généré, de la vidéo synthétique, la découverte automatisée de vulnérabilités, la génération de code malveillant ou un agent manipulé par une entrée hostile. Ces mécanismes ne sont pas interchangeables.

Le phishing est actuellement l’intersection la plus claire. Un modèle de langage peut créer des messages grammaticalement corrects dans de nombreuses langues et les adapter au rôle du destinataire. Les attaquants peuvent combiner ce texte avec des informations issues de profils publics, de bases de données compromises ou d’e-mails volés.

Les communautés crypto dépendent également fortement de Discord, Telegram, X et d’autres canaux ouverts. Les échanges d’assistance, les annonces de tokens, les discussions de gouvernance et les offres d’emploi peuvent arriver par les mêmes interfaces que celles utilisées par les usurpateurs.

Check Point a documenté ce schéma dans sa recherche sur Inferno Drainer. Les chercheurs ont découvert une campagne qui faisait passer les utilisateurs d’un site Web3 légitime vers Discord, puis leur présentait un bot Collab.Land contrefait et une page de phishing.

Les victimes étaient invitées à connecter leurs portefeuilles et à signer des transactions malveillantes. La technique exploitait un processus de vérification familier plutôt qu’une capacité d’IA exotique. Check Point estime qu’Inferno Drainer a touché plus de 30 000 portefeuilles et causé au moins 9 millions de dollars de pertes en six mois.

Le service utilisait également des contrats de courte durée, une configuration on-chain chiffrée, des adresses en rotation et une infrastructure proxy. Ces mécanismes rendaient la détection et le blocage plus difficiles. Ils montrent comment l’automatisation et une infrastructure criminelle réutilisable peuvent faire passer une attaque à l’échelle sans exiger de nouveau modèle.

Les infostealers créent une autre voie. Ils collectent les cookies de navigateur, les mots de passe enregistrés, les tokens, les fichiers et les données liées aux portefeuilles sur une machine infectée. Les attaquants peuvent les diffuser par des applications contrefaites, des publicités malveillantes, des cracks logiciels, des dépôts empoisonnés ou de faux entretiens d’embauche.

L’IA peut rendre ces campagnes plus convaincantes. Elle peut rédiger des messages de recrutement ciblés, générer des documents réalistes ou aider à créer des sites Web d’imitation. Toutefois, la pièce jointe, le package ou la commande malveillante reste le point où la persuasion devient exécution.

Cette frontière est importante pour la défense. Les classificateurs de contenu peuvent détecter des formulations suspectes, mais ils ne peuvent pas empêcher un utilisateur d’exécuter un binaire non signé. De même, un audit de smart contract ne supprimera pas un malware de l’ordinateur portable d’un développeur.

Hacken a signalé une évolution plus large dans son rapport de sécurité H1. L’entreprise a comptabilisé 3,1 milliards de dollars de pertes Web3 au cours du premier semestre 2025. Elle a attribué 1,83 milliard de dollars aux exploits de contrôle des accès, 600 millions de dollars au phishing et à l’ingénierie sociale, et environ 263 millions de dollars aux bugs de smart contracts.

Ces chiffres reposent sur la méthodologie d’un fournisseur de sécurité plutôt que sur un recensement gouvernemental. Ils soutiennent néanmoins une comparaison cruciale. Les défaillances d’accès et la manipulation humaine ont engendré des pertes déclarées bien supérieures à celles des bugs de contrats durant cette période.

Hacken a également signalé une hausse de 1 025 % des exploits liés à l’IA, principalement impliquant des interfaces de programmation d’applications non sécurisées et des configurations d’inférence vulnérables. Cette affirmation exige une interprétation prudente, car le résumé public ne fournit ni liste complète des événements ni dénominateur.

Un taux de croissance élevé peut partir d’une base faible. Les normes de classification peuvent également évoluer à mesure que les chercheurs qualifient davantage d’incidents de liés à l’IA. Ce chiffre signale une catégorie à surveiller, mais il ne prouve pas que l’IA soit devenue la principale cause des pertes dans le Web3.

La conclusion la plus défendable est que l’IA étend les surfaces d’attaque existantes. Le Web3 fournit ensuite aux attaquants une autorité inhabituellement précieuse à dérober.

Les agents IA créent un accès plus direct aux actifs numériques

Le risque devient structurellement différent lorsqu’un système d’IA peut lire du contenu externe et autoriser des transactions sans qu’un humain examine chaque action.

Un agent IA est un logiciel qui utilise un modèle pour sélectionner et exécuter des actions à travers différents outils. Dans un contexte Web3, ces actions peuvent inclure la consultation de données de marché, l’échange d’actifs, le vote en gouvernance, l’interaction avec des contrats ou le transfert de fonds.

Cette configuration modifie le modèle de menace. Un chatbot classique peut fournir des conseils erronés. Un agent ayant accès à un portefeuille peut transformer une instruction incorrecte en transaction irréversible.

Des chercheurs de Princeton University et de l’University of Illinois ont étudié ce problème dans une étude sur les attaques contre les agents. Leurs travaux portaient sur la manipulation de contexte, une attaque qui insère des instructions malveillantes dans les informations lues par un agent.

Les chercheurs ont testé des attaques contre ElizaOS, un framework utilisé pour des applications Web3 autonomes. Ils ont indiqué que des prompts manipulés et des historiques d’interaction pouvaient provoquer des transferts involontaires et des violations de protocole.

Cela s’apparente à l’injection de prompt, où un contenu non fiable ordonne à un modèle d’ignorer sa tâche prévue. La différence réside dans la conséquence opérationnelle. Un agent manipulé peut faire davantage que produire une mauvaise réponse. Il peut utiliser un outil ou un portefeuille connecté.

L’étude a également conclu que les défenses fondées sur les prompts étaient insuffisantes dans l’environnement testé. Des informations malveillantes pouvaient persister dans le contexte stocké et influencer des interactions ultérieures. Cette persistance crée la possibilité de défaillances en cascade entre les sessions.

Ces résultats ne doivent pas être généralisés à tous les agents ou à toutes les configurations de portefeuille. L’article a testé des systèmes et des modes d’attaque spécifiques. Les déploiements en production peuvent imposer des autorisations et une vérification externe qui réduisent l’exposition.

Le mécanisme reste toutefois crédible et important. Un agent a souvent besoin de données externes pour fonctionner. Ces données peuvent inclure des publications sur les réseaux sociaux, des propositions de gouvernance, des descriptions de tokens, des messages de support et des interfaces d’applications décentralisées. Chacune de ces surfaces peut transporter des instructions hostiles.

Les développeurs devraient traiter le contexte du modèle comme une entrée non fiable. Ils devraient également supposer qu’un agent finira par mal comprendre une demande ou rencontrera des informations manipulées. La sécurité doit se situer en dehors du processus de raisonnement du modèle.

Une approche consiste à séparer les capacités. Un agent qui surveille les marchés n’a pas automatiquement besoin d’une autorité de signature. Un système qui prépare des transactions peut produire une proposition non signée qu’un autre service ou une autre personne examinera.

Les limites de transaction offrent une autre frontière. Les équipes peuvent plafonner le montant transféré sur une période définie, restreindre les contrats approuvés et interdire les adresses de destination arbitraires. Un moteur de politiques dédié peut évaluer ces règles sans dépendre d’un modèle.

La simulation ajoute du contexte avant l’exécution. Elle estime comment une transaction modifie les soldes, les autorisations et l’état des contrats. La simulation n’identifiera pas toutes les conséquences malveillantes, mais elle peut révéler des transferts inattendus ou des autorisations de tokens illimitées.

La révocation mérite également de l’attention. Les équipes ont besoin d’une méthode rapide pour désactiver des identifiants, faire tourner les clés, suspendre l’automatisation et isoler les composants compromis. Une procédure d’arrêt compliquée constitue une vulnérabilité de sécurité lorsqu’un agent fonctionne en continu.

C’est l’impact le plus concret de l’IA sur le Web3. Les modèles passent de la génération de contenu à des systèmes détenant une autorité opérationnelle. Le risque qui en résulte provient de la combinaison de décisions probabilistes et d’une exécution financière déterministe.

Le récit de Google News présente toujours une lacune en matière de preuves

OneSafe identifie un danger légitime, mais les lecteurs devraient éviter de regrouper chaque perte crypto, campagne de phishing et infection par malware dans une seule statistique sur l’IA.

Google News peut faire remonter un article, mais l’agrégation ne valide pas chaque affirmation qu’il contient. La visibilité dans les résultats de recherche mesure la découvrabilité. Elle ne remplace pas les dossiers de réponse aux incidents, l’analyse technique ou une collecte de données transparente.

L’article de OneSafe propose des recommandations pertinentes, en particulier son conseil d’examiner attentivement les fichiers liés à l’IA et les sauvegardes propres. Pourtant, son exemple le plus marquant de malware ne renvoie à aucun rapport d’analyse forensique. Les lecteurs ne peuvent pas examiner le logiciel concerné, le vecteur d’infection, le système affecté ou le processus de récupération.

Ces informations manquantes limitent la portée de l’enseignement. Si un attaquant a distribué une fausse application d’IA, la signature des applications et la vérification des téléchargements deviennent centrales. Si du code généré a introduit une vulnérabilité, la revue de code et les tests comptent davantage. Si une instruction malveillante a déclenché une commande, le sandboxing et les contrôles d’approbation deviennent prioritaires.

La terminologie crée un autre problème. L’expression « malware imprégné d’IA » peut laisser entendre qu’un modèle opérait à l’intérieur du programme malveillant. Dans de nombreux incidents, l’IA aide plus tôt l’attaquant en rédigeant des messages ou en adaptant du code. Le malware qui atteint la victime peut se comporter comme un infostealer établi.

Cette différence influe sur les achats et les politiques. Une entreprise pourrait acheter un détecteur de contenu IA tout en laissant des identifiants de développeur exposés. Elle pourrait interdire des assistants approuvés tandis que les employés continuent de télécharger des outils non vérifiés. Elle pourrait également étendre la surveillance sans restreindre l’autorité de transaction.

Les chiffres du FBI exigent une discipline similaire. Sa catégorie liée à l’IA dépend des informations signalées dans les plaintes. L’agence indique que l’IA permet de créer des profils et conversations synthétiques convaincants, mais son total de pertes n’isole pas l’exploitation technique des protocoles Web3.

La catégorie des cryptomonnaies est également plus large que le piratage de la blockchain. Elle inclut la fraude à l’investissement et d’autres stratagèmes dans lesquels les criminels demandent ou déplacent des paiements via des actifs numériques. La cryptomonnaie peut être le rail de paiement plutôt que la vulnérabilité.

Les rapports de fournisseurs répondent à des questions différentes. Une entreprise de sécurité blockchain peut analyser les pertes on-chain et classer les incidents selon sa propre taxonomie. Son jeu de données peut inclure des attaques contre des protocoles que les victimes ne signalent jamais aux autorités fédérales.

Ces sources peuvent se renforcer mutuellement sans être directement comparables. Le FBI montre l’ampleur de la fraude signalée. Check Point documente une opération spécifique de vidage de portefeuilles. Hacken catégorise les pertes dans le secteur Web3. Des chercheurs universitaires testent la manière dont les agents réagissent à un contexte hostile.

Ensemble, elles étayent une conclusion mesurée. L’IA rend la tromperie moins coûteuse à produire et plus facile à personnaliser. Les agents autonomes peuvent également créer de nouveaux risques d’exécution. Aucun de ces éléments ne prouve que l’IA soit responsable de la majorité des pertes Web3.

La compétition possède aussi un volet défensif. Les équipes de sécurité utilisent le machine learning pour prioriser les alertes, classer les contrats, identifier les transactions suspectes et détecter les anomalies comportementales. Les développeurs utilisent des modèles pour examiner le code et générer des tests.

Ces applications peuvent réduire le risque lorsque des humains vérifient leurs résultats. Elles peuvent créer un faux sentiment de sécurité lorsque les équipes traitent l’évaluation d’un modèle comme une preuve de sûreté.

La confrontation principale oppose l’automatisation à des contrôles applicables. Les attaquants automatisent la découverte et la persuasion. Les défenseurs doivent automatiser le confinement, le moindre privilège, la simulation, la surveillance et la révocation.

Ce cadrage est moins spectaculaire qu’une menace IA généralisée. Il est aussi plus concret.

Trois signaux indiqueront si la menace s’intensifie

La prochaine phase se mesurera par des incidents d’agents vérifiés, des pertes liées au contrôle d’accès et des garanties de transaction plus solides, non par le nombre de titres alarmants.

Le premier signal est une perte documentée causée directement par un agent IA manipulé. Une divulgation utile identifierait l’autorité du modèle, l’entrée hostile, les actions réalisées et les contrôles qui ont échoué.

Un tel incident renforcerait l’argument selon lequel l’IA crée une catégorie distincte de vulnérabilités Web3. En l’absence de ces preuves, de nombreuses attaques signalées resteront des vols d’identifiants ou du phishing classiques, préparés avec l’aide de l’IA.

Le deuxième signal est la part des pertes Web3 attribuée à des clés compromises, des autorisations compromises et à l’ingénierie sociale. Les rapports de sécurité devraient publier des définitions claires et, lorsque cela est possible, des données au niveau des événements.

Si les pertes liées au contrôle d’accès restent dominantes, les équipes devraient prioriser les frontières d’identité et l’architecture de signature. Une hausse durable des compromissions propres aux modèles justifierait un investissement accru dans l’isolation des agents et le filtrage du contexte.

Le troisième signal est l’adoption de systèmes indépendants de politiques de transaction. Les fournisseurs de portefeuilles, les plateformes d’échange et les équipes de protocoles peuvent exiger une simulation, des restrictions de destination, des limites de dépenses ou plusieurs approbations avant le déplacement d’actifs.

Une adoption généralisée affaiblirait l’avantage des attaquants. Un message synthétique persuasif devient moins précieux lorsqu’un seul employé ne peut pas autoriser l’action demandée. Un agent compromis devient moins dangereux lorsque ses identifiants ne permettent que des opérations limitées.

L’avertissement de OneSafe dans Google News est utile parce qu’il attire l’attention sur le comportement des développeurs avant une crise. Sa lacune en matière de preuves démontre également pourquoi les affirmations de sécurité nécessitent des sources, des détails reproductibles et des catégories rigoureuses.

Les développeurs devraient examiner chaque service pouvant accéder au code, aux sessions de navigateur, aux secrets de déploiement ou aux portefeuilles. Ils devraient identifier quels systèmes peuvent seulement recommander une action et lesquels peuvent l’exécuter. Cette cartographie révèle souvent davantage de risques qu’une liste de produits IA approuvés.

Les acheteurs en entreprise devraient demander aux fournisseurs comment les agents stockent le contexte, isolent les outils et révoquent l’autorité. Ils devraient également demander si les politiques de transaction opèrent en dehors du modèle. Un prompt de sécurité n’est pas un système de contrôle d’accès.

Les travailleurs du savoir devraient vérifier les demandes financières urgentes par un canal distinct. La voix, la vidéo et un style d’écriture familier ne constituent plus une preuve fiable d’identité. Une méthode de contact connue et un processus d’approbation établi ont davantage de valeur.

La question importante après cet article de Google News n’est pas de savoir si l’IA a sa place dans le Web3. Elle est de savoir si chaque système automatisé dispose d’une autorité suffisante pour transformer une seule entrée trompeuse en perte permanente. Auditez cette frontière dès maintenant, documentez qui peut arrêter une action et testez le chemin d’arrêt avant que les attaquants ne le testent à votre place.