Des chercheurs alertent sur les routeurs d’agents IA malveillants, nouveau vecteur de vol de cryptomonnaies

Des chercheurs de l’Université de Californie ont identifié une nouvelle classe d’attaque au niveau de l’infrastructure, capable de vider des portefeuilles crypto et d’injecter du code malveillant dans les environnements de développement – et ce type de vol a déjà eu lieu en conditions réelles.

Une étude systématique publiée sur arXiv le 8 avril 2026, intitulée « Measuring Malicious Intermediary Attacks on the LLM Supply Chain », a testé 428 routeurs d’API d’IA et a révélé que 9 d’entre eux injectaient activement du code malveillant, 17 accédaient aux identifiants AWS des chercheurs, et qu’au moins un routeur gratuit a réussi à siphonner de l’ETH à partir d’une clé privée contrôlée par les chercheurs.

La surface d’attaque se situe au niveau de la couche de routage des agents IA – une infrastructure qui s’est développée rapidement à mesure que les agents IA s’intègrent dans les flux d’exécution de la blockchain.

La question n’est plus de savoir si cette menace est théorique, mais combien de routeurs compromis gèrent déjà des sessions utilisateur en direct.

Comment fonctionnent réellement les routeurs d’agents IA malveillants – Des proxys en texte clair, pas des tunnels chiffrés

L’infrastructure API standard des LLM a été conçue pour un simple relais requête-réponse : un client envoie une instruction (prompt), le routeur la transmet au fournisseur de modèle, et la réponse revient.

Les routeurs malveillants exploitent précisément ce modèle de confiance – ils se placent comme des proxys de couche applicative au milieu de cet échange, avec un accès complet en lecture-écriture aux charges utiles JSON en texte clair qui transitent par eux dans les deux sens.

Il n’existe aucune norme de chiffrement régissant ce qu’un routeur peut inspecter ou modifier en transit. Un routeur malveillant voit le prompt brut, la réponse du modèle et tout ce qui est intégré dans l’un ou l’autre – y compris les clés privées, les identifiants API, les phrases de récupération de portefeuille ou le code généré pour un environnement de déploiement en direct.

Il peut modifier la réponse avant qu’elle n’atteigne l’utilisateur, injecter du code supplémentaire dans une sortie de génération de code ou exfiltrer silencieusement des identifiants vers un point de terminaison externe.

Les chercheurs de l’UC ont construit un agent nommé « Mine » pour simuler quatre types d’attaques distincts contre des frameworks publics, ciblant spécifiquement les sessions autonomes en mode YOLO où l’agent exécute des actions sans confirmation humaine à chaque étape.

Deux des 428 routeurs testés ont déployé une évasion adaptative – l’un d’eux a attendu 50 appels API avant d’activer son comportement malveillant, précisément pour éviter d’être détecté lors des tests initiaux. Il ne s’agit pas d’un simple extracteur d’identifiants basique, mais d’un outil ciblé conçu pour résister à l’examen.

Le vecteur d’attaque par empoisonnement aggrave encore le risque. Lorsque des clés API OpenAI fuitées sont traitées via une infrastructure de routage compromise, la zone d’impact s’élargit rapidement – 2,1 milliards de tokens traités, 99 identifiants exposés sur 440 sessions Codex rien que dans l’environnement de test contrôlé des chercheurs.

Qui est réellement exposé – et pourquoi les défenses existantes ne couvrent pas ce type de vol

Le problème n’est pas l’existence de routeurs API tiers. Le problème est que l’ensemble du modèle de confiance pour l’infrastructure des agents IA suppose que la couche de routage est neutre – et aucun mécanisme de contrôle ne vérifie actuellement cette hypothèse à grande échelle.

Les développeurs créant des outils on-chain, des scripts d’automatisation DeFi et des agents de trading autonomes acheminent constamment des appels API via des infrastructures tierces.

Les routeurs gratuits provenant de communautés publiques – la catégorie où 8 des 9 injecteurs malveillants ont été trouvés – sont largement utilisés précisément parce qu’ils réduisent le coût de création d’applications basées sur les LLM. Alors que l’infrastructure d’exécution automatisée dans la DeFi dépend de plus en plus de données externes et de la coordination d’agents, la couche de routage devient une cible de plus en plus attrayante.

La sécurité actuelle des portefeuilles – appareils matériels (hardware wallets), configurations multisig, stockage de clés hors ligne – ne protège pas contre un routeur qui intercepte une clé privée avant qu’elle n’atteigne la couche de signature, ou qui injecte du code malveillant dans un script de déploiement exécuté ultérieurement on-chain.

Les pertes annuelles dues au vol de cryptomonnaies atteignent déjà 1,4 milliard USD. Ce vecteur d’attaque ne nécessite pas de briser la cryptographie. Il nécessite de compromettre un élément intermédiaire (middleware) que la plupart des utilisateurs n’examinent jamais.

Les sessions autonomes en mode YOLO constituent le point d’exposition le plus risqué. Lorsqu’un agent exécute des transactions en plusieurs étapes sans point de contrôle humain, un routeur malveillant dispose d’une fenêtre d’action plus large – et l’utilisateur n’a aucun moment intermédiaire pour détecter un comportement anormal.

Le fondateur de Solayer, @Fried_rice, a relayé les conclusions sur X le 10 avril 2026, décrivant la situation comme des « routeurs d’API tiers largement utilisés par les agents de modèles de langage à grande échelle » présentant des « vulnérabilités de sécurité systémiques » – une caractérisation qui a eu un fort écho compte tenu de l’adoption massive des agents autonomes dans les outils DeFi.

26 LLM routers are secretly injecting malicious tool calls and stealing creds. One drained our client $500k wallet.

We also managed to poison routers to forward traffic to us. Within several hours, we can directly take over ~400 hosts.

Check our paper: https://t.co/zyWz25CDpl pic.twitter.com/PlhmOYz2ec

— Chaofan Shou (@Fried_rice) April 10, 2026

Les défenses recommandées par les chercheurs se situent côté client : des barrières de type « fault-closure » qui interrompent l’exécution lorsque des réponses anormales sont détectées, le filtrage des anomalies de réponse et la journalisation en ajout uniquement pour des pistes d’audit qui ne peuvent pas être altérées par le routeur lui-même.

À plus long terme, l’équipe de l’UC préconise des normes de signature cryptographique qui rendraient les réponses des LLM vérifiables – le même principe architectural qui fait de l’intégrité des oracles on-chain une exigence de conception fondamentale et non plus une considération secondaire.