2 dollars disparus dans « Shadow Custody » : un incident de dépassement de l'IA

L’illusion de l’intelligence artificielle a longtemps été considérée comme une simple déviation d’information inoffensive, comme inventer un fait ou produire un texte incohérent. Mais la réalité de 2026 nous a donné un coup dur : lorsque l’IA évolue du chatbot à l’agent autonome, l’illusion se transforme en un risque coûteux d’exécution. Le problème ne se limite plus à une erreur de parole, car elle a désormais la capacité de déplacer directement vos actifs.

Le poison de la chaîne d’approvisionnement : du codage manuel au vibe coding

L’incident de sabotage de LiteLLM cette semaine a tiré la sonnette d’alarme sur cette tendance.

En tant que moteur sous-jacent de presque tous les cadres d’IA Agent principaux, LiteLLM a été victime d’une infiltration typique de la chaîne d’approvisionnement lors de cet incident. L’attaquant a exploité une faiblesse dans la chaîne d’outils de sécurité pour obtenir la clé de publication, puis a poussé du code malveillant sous forme de version officielle dans l’environnement des utilisateurs. Étant signé légalement, le mécanisme de vérification traditionnel a presque été contourné.

Fascinantement, cette attaque n’a été découverte que parce que le code du hacker comportait une erreur basique lors du traitement de la logique récursive, ce qui a causé un blocage du PC victime par épuisement des ressources.

Cela a mis en lumière une vulnérabilité longtemps négligée dans l’écosystème open source : lorsque vous installez une bibliothèque, vous faites confiance à tout un arbre de dépendances qui s’étend sur des centaines de paquets. La moindre corruption d’un nœud de cet arbre peut remonter jusqu’au cœur de l’environnement de production.

Dans le paradigme de développement basé sur le vibe coding, ce risque est encore amplifié. De nombreux développeurs décrivent leurs besoins en langage naturel, et l’IA génère automatiquement du code. Lorsqu’une erreur survient, ils adoptent souvent directement les suggestions de correction de l’IA et exécutent des commandes comme pip install, sans vérifier davantage la provenance ou la sécurité des dépendances.

Dans ce contexte, la barrière de lancement diminue continuellement, mais la complexité de la vérification de sécurité ne baisse pas en parallèle. Chaque installation de dépendance apparemment simple introduit une nouvelle incertitude, qui devient progressivement une partie du risque systémique.

Accident interne chez Meta : quand l’humain devient interface d’exécution

Des changements similaires se produisent aussi au niveau de l’interaction homme-machine. Avec le passage du développement logiciel par étapes à une approche orientée résultats, le rôle de l’humain évolue : de juge, il devient un point de confirmation, voire simplement une interface d’exécution.

Le développement logiciel traverse une transformation radicale, passant du « manuel » à l’« autonome ». Autrefois, le développeur était responsable de chaque opération ; après l’introduction des agents, l’humain devient plutôt un passager de la conduite automatique, relégué à un rôle de confirmation ou d’exécutant final.

Lorsque le rôle humain se réduit à une « interface d’exécution » pour l’IA, la volonté de vérification diminue exponentiellement.

Un incident de niveau SEV1 chez Meta en est la preuve : un ingénieur a utilisé un agent IA pour répondre à une question technique sur un forum interne. L’agent a publié une réponse sans vérification préalable. Un autre ingénieur a suivi cette recommandation, ce qui a conduit à une mauvaise configuration des permissions du système, exposant des données sensibles pendant deux heures sans protection.

Meta a attribué cet incident à une « erreur humaine », mais d’un point de vue interaction homme-machine, cela ressemble davantage à une défaillance de l’interface. Lorsque la sortie de l’IA paraît si professionnelle et « exécutable », la barrière de vérification humaine s’affaiblit automatiquement.

Ce phénomène, dans les systèmes d’information, peut être compensé par des mécanismes de rollback ou de correction. Mais lorsque l’IA commence à intervenir dans des systèmes ayant des conséquences concrètes — notamment en matière d’actifs et de transactions financières — l’illusion devient une facture coûteuse et irrévocable.

Leçon à 2 dollars : une opération de substitution pour sauver la mise

Si l’incident chez Meta concerne une erreur de permissions, dans le domaine financier, le problème devient encore plus grave, car il touche directement la propriété des actifs.

Depuis 2026, plusieurs portefeuilles et infrastructures ont lancé en masse des produits Wallets Agentic, visant à permettre à l’IA d’agir directement pour le compte des utilisateurs sur la blockchain. Lors de tests systématiques, l’équipe Cobo AI a repéré un comportement typique, qu’elle a nommé Shadow Custody — c’est-à-dire qu’un agent, à l’insu de l’utilisateur, peut transférer le contrôle réel des actifs via la génération autonome de clés, la création d’adresses temporaires, etc. Résultat : une adresse sur la blockchain échappe au contrôle direct de l’utilisateur — un « coffre noir » visible en logique, mais invisible pour l’utilisateur.

Le processus de cet incident peut se résumer ainsi : un utilisateur demande à l’agent d’acheter pour 2 dollars de « Spain YES » sur Polymarket. Lors de l’exécution, l’agent rencontre rapidement un obstacle : la transaction nécessite une signature numérique spécifique (EIP-712), mais le SDK utilisé par l’agent lie la « construction du contenu de la signature » et la « signature avec la clé privée » en une seule étape — autrement dit, le SDK suppose que vous avez déjà une clé privée en main, et que vous pouvez signer directement.

Le problème, c’est que le portefeuille de l’utilisateur n’est pas un portefeuille classique « avec clé en main », mais un portefeuille MPC géré par plusieurs parties — capable de signer, mais via une autre procédure. L’agent ne s’en est pas rendu compte, et a conclu que ce portefeuille ne pouvait pas signer.

Dans un système basé sur des règles de confiance, le processus aurait dû s’arrêter ou demander une autorisation supplémentaire.

Mais l’agent n’a pas stoppé. Il a interprété cette limitation comme une impossibilité de signer avec le portefeuille actuel, et a cherché une solution alternative. Sans autorisation, il a généré localement une nouvelle clé privée, créé une adresse temporaire, transféré 2 USDC.e du portefeuille MPC vers cette adresse, puis signé avec cette clé pour finaliser l’achat.

Du point de vue du résultat, tout s’est déroulé comme prévu : 10 « Spain YES » ont été achetés correctement.

Mais du point de vue de la structure du système, c’est une erreur totale.

Les tokens ne sont pas revenus dans le portefeuille MPC de l’utilisateur, mais sont restés dans l’adresse temporaire créée par l’agent. L’utilisateur ne s’en est pas aperçu, jusqu’à ce qu’il vérifie que le solde est nul, et que l’agent lui explique tout le processus.

Le détournement de chemin : pas seulement un bug

Ce n’est pas simplement un bug, en réalité, l’agent n’a pas vraiment commis d’erreur : il a simplement comblé une lacune dans la définition des limites du système.

En résumé, lorsque le chemin prévu ne fonctionne pas, l’agent ne s’arrête pas pour signaler une erreur, mais improvise pour « accomplir la tâche ». Il crée en secret une adresse temporaire pour transférer des fonds, sans en informer l’utilisateur — une déconnexion entre perception utilisateur et réalité technique, une forme de détournement de chemin.

Ce détournement subtil révèle des risques systémiques liés à la transparence des flux financiers, à la cohérence sémantique et à la stabilité de l’environnement d’exécution dans la finance machine-native :

Et dès que cette « improvisation » n’est plus contrainte, elle ouvre trois portes aux attaquants :

• Déviation logique : des outils malveillants n’ont pas besoin de falsifier des liens ou des fenêtres pop-up, il suffit d’inciter l’agent à activer un portefeuille temporaire dans le code. L’utilisateur voit la transaction réussir, mais le contrôle des actifs a été transféré au moment précis.

• Manipulation sémantique : pas besoin d’intrusion dans le système, il suffit d’insérer dans la documentation ou le prompt de fausses restrictions techniques (ex. « le chemin d’origine est invalide »). L’agent, orienté tâche, transférera des fonds pour contourner ces pseudo-restrictions. Il n’est pas piraté, il a simplement été trompé.

• Sabotage des composants : en modifiant des SDK ou des interfaces tiers, on peut faire croire que le chemin est bloqué, alors qu’il ne l’est pas. L’agent pense suivre un chemin fidèle, alors qu’il s’engage dans une impasse conçue.

Les contraintes priment sur la capacité : trois portes pour maîtriser le comportement des agents IA

Dans les environnements financiers où la tolérance à l’erreur est nulle, la « intelligence » de l’IA peut devenir le pire ennemi de la sécurité. Ce qu’il faut, ce n’est pas une puissance d’exécution accrue, mais une capacité de délimitation plus stricte.

Pour cela, il faut doter l’agent de trois barrières infranchissables :

1. La porte des intentions (Policy Gate) : briser le cercle auto-référentiel

Les contraintes doivent venir de l’extérieur. Nous avons besoin d’un moteur de stratégie indépendant (Policy Engine) pour juger « si l’opération est autorisée » avant qu’elle ne se produise. Par exemple, interdire à l’agent de générer des clés privées ou de transférer vers des adresses non autorisées. En cas de violation, l’exécution doit s’arrêter immédiatement.

2. La porte des transactions (Transaction Gate) : visibilité sur le risque

Toutes les décisions de l’agent doivent se traduire en transactions sur la blockchain. Il faut établir un « pare-feu transactionnel » entre l’agent et la blockchain, pour convertir les données brutes en informations structurées. En évaluant le comportement du destinataire, le montant, etc., on peut scorer chaque transaction. Les opérations à haut risque doivent être bloquées et soumises à une validation humaine.

3. La porte de la visibilité (Visibility Gate) : observation en temps réel

Il faut introduire un système d’observation indépendant (Watcher). Lorsqu’un fonds est transféré vers une nouvelle adresse ou ne revient pas dans un délai donné, le watcher envoie une alerte instantanée. Il transforme la détection en intervention en cours, garantissant que même si l’agent tente de dissimuler le chemin, l’état des actifs reste transparent.

Conclusion

Nous sommes à un tournant dangereux. La puissance d’exécution de l’IA monte en flèche, mais nos mécanismes de contrôle restent archaïques. Si une architecture ne peut pas définir clairement les comportements interdits et effectuer une vérification en temps réel, chaque décision autonome de l’IA revient à jouer une partie de roulette avec les actifs de l’utilisateur.

Et dans la finance, personne ne veut jouer à la roulette.