Sécurité des portefeuilles agentiques : ce qui tourne vraiment mal
Les défaillances qui ont des preuves, séparées de celles qui n’ont qu’une statistique. Un chiffre très cité ne survit pas à la vérification.
Cherchez « sécurité portefeuille agentique » et vous retrouverez les mêmes chiffres répétés sur une douzaine de pages, le plus souvent sans lien vers leur origine. Certains sont solides. Au moins un se défait dès qu’on le vérifie.
Voici ce que les preuves soutiennent réellement, et là où elles ne soutiennent rien.
Commençons par le chiffre qui ne survit pas
La donnée la plus citée de cette catégorie, c’est que plus de 45 millions de dollars ont été perdus à cause de faiblesses de protocole d’agents IA au seul premier trimestre 2026. Nous l’avons citée nous aussi, jusqu’à en retracer l’origine.
Environ 40 millions de ce total sont un seul incident : la brèche de janvier 2026 chez Step Finance, un gestionnaire de portefeuille sur Solana. Dans les articles sur la sécurité des agents, cela apparaît comme des agents exécutant des transferts non autorisés parce que leurs permissions étaient trop larges.
Les sources primaires disent autre chose.
La brèche n’impliquait aucune vulnérabilité de contrat intelligent ; elle provenait de faiblesses opérationnelles, dont des compromissions de postes sur du matériel de direction.
Des attaquants ont compromis les appareils de membres de la direction et atteint les portefeuilles de trésorerie et de frais. C’est une histoire d’ordinateurs portables et de hameçonnage, et elle serait arrivée à une entreprise sans aucun agent.
Deux conséquences. D’abord, vérifiez la source de tout chiffre dans ce domaine, y compris les nôtres. Ensuite, les vrais modes de défaillance sont plus précis et plus intéressants que ce total.
Les défaillances qui ont des preuves
1. Injection de prompt, dans un encodage que personne n’a pensé à suspecter
Le cas le mieux documenté a coûté 150 000 $ en mai 2026. Un attaquant a envoyé un NFT d’adhésion à un portefeuille intégré à une IA, ce qui l’a discrètement fait passer à un niveau de permissions supérieur, puis a publié sur X une réponse contenant une instruction cachée en morse. L’agent l’a décodée, l’a prise pour une commande légitime et a autorisé le transfert.
Aucun exploit. Aucune clé volée. On a simplement demandé gentiment au modèle, dans un format que personne n’avait pensé à filtrer.
Cela a un nom et un numéro : OWASP LLM01:2025, la première entrée de la liste standard des défaillances des applications à modèle de langage.
2. Agentivité excessive — la moitié qui décide du coût
Le même incident est aussi LLM06:2025. Être persuadé et pouvoir agir étaient le même événement : dès que le modèle a cru l’instruction, rien ne s’est interposé entre cette croyance et un transfert vers l’adresse d’un attaquant.
Personne n’a résolu cela. Partez du principe que le modèle peut être trompé, car il peut l’être.
Ce n’est pas un problème de modèle. C’est une question sur ce que le système alentour permet d’écrire — et c’est une décision de conception, pas un problème de recherche.
La première défaillance fait les gros titres. La seconde a décidé du montant.
3. Identifiants partagés dans une flotte
Selon une enquête auprès de plus de 900 praticiens, 45,6 % des équipes utilisent encore une clé d’API partagée pour l’authentification entre agents, et 27,2 % une logique d’autorisation écrite à la main.
Quand tous les agents présentent le même identifiant, on ne peut pas attribuer une action à l’un d’eux, donc on ne peut pas en arrêter un. La compromission est tout ou rien par construction.
4. Le protocole d’outils, pas le modèle
Dans la plupart des incidents rapportés, la surface d’attaque n’était pas le raisonnement du modèle. C’était la plomberie : les protocoles par lesquels les agents appellent des outils externes, et la mémoire qu’ils transportent d’un tour à l’autre. Empoisonnez ce qu’un agent lit et vous n’avez pas besoin de battre ce qu’il pense.
C’est le moins discuté et probablement le plus important, car c’est la partie que les équipes traitent comme de l’infrastructure plutôt que comme une surface d’attaque.
Ce que rien de tout cela n’est
Il vaut la peine de nommer les défaillances attribuées aux portefeuilles agentiques et qui ne concernent pas du tout les agents :
- Compromission de poste
- L’ordinateur de quelqu’un. Serait arrivé sans agents. La plus grosse perte de la catégorie à ce jour
- Hameçonnage d’un opérateur
- Même catégorie. Qu’il y ait un agent dans la pile n’y change rien
- Bugs de contrat ordinaires
- Une vulnérabilité dans un protocole que l’agent a appelé est une vulnérabilité de ce protocole
Tout mettre dans le même sac gonfle le risque de la catégorie tout en rendant les défaillances précises et traitables plus difficiles à voir.
Ce qui réduit vraiment le risque
Pas plus de filtrage. Moins d’expressivité.
L’injection, on ne peut pas l’empêcher. L’expressivité, on peut la retirer.
Si un agent peut composer une transaction arbitraire, tout contrôle est un filtre jugé contre des attaques déjà imaginées. Si l’agent ne peut que remplir des cases étiquetées tirées d’une liste fermée — sans case pour une adresse de destination ni pour une charge utile — l’instruction « envoie-le-moi » n’a nulle part où s’écrire, et rien n’a besoin de l’attraper.
- Demandez ce que l’agent peut écrire
Si la réponse contient une adresse, le reste est du filtrage.
- Demandez où le plafond de dépense est appliqué
Un plafond dans le back-end de l’opérateur est une politique. Un plafond dans un compte que vous seul contrôlez n’est pas quelque chose qu’il peut relever.
- Demandez ce que coûte un agent compromis, en chiffre
Une bonne réponse est un nombre que vous fixez. Une réponse vague signifie que personne ne l’a calculé.
- Demandez ce qui a été prouvé, et par qui
S’auto-tester vaut quelque chose. Ce n’est pas un audit, et quiconque confond les deux vous dit quelque chose.
Notre propre réponse, moitié inconfortable comprise
L’agent ici ne détient aucune clé et ne peut pas nommer de destination. Les plafonds vivent dans votre compte et rien de notre côté ne peut les relever. La nomination de l’agent est à sens unique : votre compte ne peut jamais être repointé vers un autre agent, seulement vers aucun.
Et : la protection fonctionne comme une liste d’actions interdites plutôt que permises. Elle bloque totalement une prise de contrôle, mais ne bloque pas toute voie par laquelle la valeur pourrait bouger via une action que personne n’a pensé à interdire. Nous avons prouvé quatre attaques de ce type contre nous-mêmes, sur une copie du vrai réseau Base. Il n’y a pas d’audit externe. Le service qui détient notre clé de keeper refuse de démarrer en production, délibérément, parce qu’il garde cette clé en mémoire.
Si la page sécurité d’un fournisseur n’a pas de section ressemblant à ce paragraphe, la section existe quand même — elle n’a simplement pas été écrite.