Permissions des agents d'IA en DeFi : EIP-7702, x402 et blast radius

Donner à un agent d'IA (un logiciel qui décide et exécute des actions seul, sans qu'un humain n'approuve chaque étape) la permission de signer des transactions en DeFi crée un problème qu'aucun programme classique ne rencontre : si vous lui remettez la clé de votre wallet, un seul prompt malveillant peut le vider en un bloc, de manière irréversible. En mai 2026, la faille de Bankr a compromis 14 wallets : certains utilisateurs ont rapporté des pertes allant jusqu'à 150 000 dollars et le montant total oscille entre 170 000 et 440 000 dollars selon la source, sans chiffre officiel de Bankr lui-même — et les hypothèses des experts ne pointent pas vers le modèle d'IA, mais vers le modèle de permissions : compromission de tokens de session ou approbations avec une portée sur de nombreux utilisateurs. Parallèlement, le protocole x402 a dépassé les 100 millions de transactions de paiement agentique sur le réseau Base, et l'argent a migré des micropaiements vers des paiements réels : les opérations supérieures à 1 dollar sont passées de 49 % à 95 % du volume. De plus en plus d'argent réel circule entre les mains d'agents, au moment même où le rayon d'action d'une permission mal conçue importe le plus. Cet article établit le cadre au 6 juillet 2026 : qu'est-ce que le blast radius (rayon de dommage), les quatre modèles d'architecture de permissions, ce qui a changé avec l'EIP-7702 et pourquoi le principe du "moindre privilège" est plus difficile à appliquer on-chain que dans n'importe quel autre logiciel.

Que signifie donner une permission de signature à un agent d'IA et qu'est-ce que le "blast radius" ?

Signer une transaction en DeFi est un ordre irrévocable : il déplace des fonds, autorise un smart contract à dépenser vos tokens ou cède le contrôle d'une position. Quand le signataire est un humain, un œil vérifie l'écran avant de cliquer. Quand le signataire est un agent autonome, cet œil disparaît — et l'agent peut enchaîner des centaines de signatures par seconde sans demander de permission.

Le concept qui structure tout ce débat vient de l'ingénierie de sécurité : le blast radius (rayon de dommage) est l'étendue de ce qu'un composant compromis peut détruire avant que quelqu'un ne l'arrête. Dans le logiciel traditionnel, ce rayon est limité par plusieurs barrières : les permissions du système d'exploitation, la possibilité d'annuler une opération, la segmentation du réseau et un administrateur qui peut tuer le processus. On-chain, presque toutes ces barrières disparaissent. Une signature ne s'annule pas. Il n'y a pas de bouton "rétablir". Et si l'agent dispose d'un allowance (autorisation de dépense accordée à un contrat pour déplacer vos tokens) illimité, le rayon de dommage correspond au solde total du wallet.

Les vecteurs qui transforment un agent en danger sont au nombre de trois, et aucun ne nécessite de briser la cryptographie. Le premier est la prompt injection (injection d'instructions : texte malveillant caché dans les données que l'agent lit, qu'il exécute en le croyant légitime). Le deuxième est le tool call malveillant (un appel à un outil externe manipulé pour que l'agent signe quelque chose qu'il ne devrait pas). Le troisième est un objectif mal formulé : si vous lui demandez de "maximiser ma rentabilité" sans limites, un agent littéral peut déplacer tout le collatéral vers un protocole douteux. Dans les trois cas, le problème n'est pas que l'IA soit "bête" : c'est qu'elle a trop de permissions.

Quels sont les quatre modèles de permissions pour les agents en DeFi ?

Tous les agents ne sont pas exposés de la même manière. La différence réside dans la façon dont l'autorité de signature leur est accordée. Il existe quatre modèles, classés du plus dangereux au plus contenu :

La majorité des agents opérant aujourd'hui se situent entre le modèle naïf et une clé de session mal configurée — qui, en pratique, est un modèle naïf avec un simple vernis. L'intent (intention) est le saut conceptuel important : l'agent cesse d'être un signataire avec des pouvoirs généraux pour devenir un demandeur qui propose des opérations concrètes. L'isolement total est l'idéal de sécurité, mais reste le modèle le moins mature : plus vous isolez l'agent, plus il devient lent et moins utile, et c'est là que réside la tension fondamentale de toute conception.

Qu'est-ce que l'EIP-7702 a résolu et que reste-t-il à régler ?

L'EIP-7702 a été activé lors de la mise à jour Pectra d'Ethereum en mai 2025 et constitue la pièce technique qui rend viable le modèle de clé de session au niveau du compte. Auparavant, une EOA (compte externe : le wallet normal, contrôlé par une clé privée) ne pouvait faire qu'une chose — signer. L'EIP-7702 permet à cette même EOA de déléguer son comportement à un smart contract ; la délégation persiste jusqu'à ce que l'utilisateur signe une nouvelle autorisation qui la révoque — c'est le contrat délégué (ou le wallet, avec un modèle explicite) qui peut la limiter à une session, et non une limite automatique par transaction. C'est une forme d'abstracción de compte qui permet de regrouper des opérations, de payer le gas pour un tiers et, surtout, de déléguer des permissions limitées à une session précise.

Ce qu'il résout : on peut enfin accorder des clés de session natives — "cet agent peut dépenser jusqu'à 500 dollars sur ce protocole pendant les deux prochaines heures, puis la permission expire". Cela réduit structurellement le rayon de dommage par rapport au modèle naïf.

Ce qu'il ne résout pas : l'EIP-7702 est un mécanisme, pas une politique. Il ne décide pas de ce qu'est une permission raisonnable — c'est le contrat auquel vous déléguez qui le décide. Et c'est là que réside la nuance inconfortable : si vous déléguez votre EOA à un contrat de délégation malveillant ou comportant un bug, vous êtes dans une situation pire qu'avant, car vous avez donné à ce code la capacité d'agir en tant que votre compte. La faille de Bankr en mai 2026 en est l'exemple canonique : Bankr n'a pas publié de post-mortem officiel, mais les hypothèses des experts — compromission de tokens de session ou d'approbations avec une portée sur de nombreux utilisateurs chez le dépositaire — pointent toutes vers le même endroit : non pas la cryptographie, mais des permissions qui ont survécu plus longtemps qu'elles ne le devaient. L'outil était là ; la politique, non.

Le x402 est-il déjà le modèle "intent-based" fonctionnant en production ?

Pendant des années, le modèle intent-based était surtout théorique. En 2026, il a cessé de l'être, et le meilleur exemple vérifiable est le x402. Le nom vient d'un code HTTP oublié : le 402 Payment Required, un état que le web a réservé dans les années 90 et n'a presque jamais utilisé. Le x402 le ressuscite pour les agents : l'agent demande une ressource, le serveur répond "402" avec des instructions de paiement, l'agent paie en stablecoin (presque toujours de l'USDC) et réessaie. La clé de la sécurité réside dans le fait que l'agent n'a pas d'autorité de signature générale : il signe un paiement ponctuel contre une instruction explicite du serveur. C'est le modèle intent-based à l'état pur.

Dans cette architecture apparaît un nouvel acteur, le facilitator (facilitateur : l'intermédiaire qui vérifie la demande et liquide le paiement). L'agent exprime l'intention, le facilitateur l'exécute selon des règles. Personne ne signe en blanc une autorisation qu'un prompt malveillant pourrait détourner pour vider le wallet.

La question naturelle est : "qui contrôle ce standard de permissions de paiement ?". La réponse est importante : en avril 2026, Coinbase a transféré la garde du x402 à la Linux Foundation, créant la x402 Foundation avec plus de 20 membres fondateurs, dont Coinbase, Cloudflare et Stripe. C'est un mouvement vers une standardisation neutre — le standard sur lequel un agent décide comment il paie ne dépend plus d'une seule entreprise.

Les données d'adoption, issues d'un rapport de Chainalysis de début juin 2026, montrent pourquoi ce n'est plus une expérience :

Ce basculement de 49 % à 95 % pour les paiements supérieurs à 1 dollar est l'élément pertinent pour notre sujet : le système est passé du transfert de centimes au transfert d'argent réel. Et quand le montant augmente, le rayon de dommage d'une faille de permissions augmente avec lui.

Le marché a déjà détecté que le standard de base ne suffit pas. Le 20 mai 2026, Fireblocks a rejoint la x402 Foundation et a lancé sa Agentic Payments Suite, apportant une couche d'"intégrité de demande et de gouvernance des dépenses" (request integrity et spend governance) au-dessus du x402. Cette extension prévient les attaques de redirection de type man-in-the-middle (un intermédiaire qui détourne le paiement vers une autre destination) que le standard de base ne couvre pas, et inclut des wallets pour agents avec des limites de dépenses, des listes de destinataires autorisés, des fenêtres temporelles et des restrictions par actif. En clair : même le modèle intent-based le mieux conçu a besoin d'une ceinture de sécurité supplémentaire de permissions. Personne ne se fie au standard seul — et ce scepticisme est la leçon à retenir, pas une simple note de bas de page.

Pourquoi le "moindre privilège" est-il plus difficile on-chain que dans un logiciel normal ?

Le principe du moindre privilège stipule que chaque composant ne doit avoir que les permissions nécessaires à sa tâche, et rien de plus. C'est un dogme de la sécurité informatique depuis des décennies. On-chain, l'appliquer est beaucoup plus difficile, et il convient de comprendre pourquoi :

• Pas d'annulation possible. Dans un système traditionnel, un administrateur annule une transaction erronée. Une signature sur blockchain est finale. L'erreur ne se corrige pas : elle se paie.
• La composabilité propage la permission. Un allowance accordé à un protocole peut se répercuter en cascade sur d'autres contrats que celui-ci appelle. Vous autorisez A, et A invoque B et C. La permission voyage plus loin que vous ne l'imaginiez.
• Les allowances persistent. Une autorisation illimitée signée il y a un an reste active jusqu'à ce que vous la révoquiez manuellement. Des milliers de wallets portent des permissions zombies oubliées.
• Pas d'administrateur central. Il n'existe pas de département informatique pour mettre en quarantaine un agent rebelle. Des outils comme le Microsoft Agent Governance Toolkit (avril 2026) ou les travaux de l'OWASP sur les risques des applications agentiques gouvernent les agents au sein d'une entreprise — mais la DeFi est permissionless par conception, sans annuaire d'entreprise ni interrupteur central.
• La clé, c'est le pouvoir. Posséder la clé équivaut à une autorité pleine : une signature brute n'a pas de second facteur. Il n'y a pas de "confirmer sur le mobile" pour stopper un agent compromis.

C'est pourquoi l'identidad de machine et la traçabilité on-chain sont devenues un domaine à part entière : sans un "qui est-ce" et un "qu'a-t-il fait" pour chaque agent, le moindre privilège reste une simple intention.

Quels incidents réels illustrent chaque faille de permissions ?

La taxonomie se comprend mieux avec des victimes concrètes. Chacun de ces cas vérifiables correspond à une faille distincte de la chaîne de permissions :

Le cas des routeurs LLM malveillants — documenté en avril 2026 par des chercheurs de l'UC Santa Barbara, l'UC San Diego et Fuzzland — est le plus instructif, car l'attaque ne touche ni le wallet ni le modèle directement : elle empoisonne la couche intermédiaire qui traduit la requête de l'agent en une action. L'agent "croit" qu'il exécute une opération légitime. C'est le même modèle d'injection de prompts qui a déjà drainé des fonds via des protocoles de connexion d'outils : la vulnérabilité ne réside pas dans celui qui signe, mais dans ce qu'on lui dit de signer.

Aucun de ces incidents n'était une faille de cryptographie. Tous étaient des failles d'architecture de permissions : un agent avec plus d'autorité qu'il n'en avait besoin, exécutant une instruction qu'il n'aurait pas dû accepter.

Comment connecter un agent d'IA à votre wallet sans tout exposer ?

Si vous allez déléguer des opérations DeFi à un agent — le vôtre ou celui d'un service d' agentes de trading —, voici la checklist des permissions, classée par impact :

• Ne remettez jamais la clé privée ni un allowance illimité. C'est le modèle naïf, et son rayon de dommage englobe tout votre wallet. Utilisez un wallet séparé uniquement pour ce que l'agent gère.
• Exigez des clés de session avec expiration. Une permission sans date de fin est une porte ouverte indéfiniment — la faille exacte de Bankr. Qu'elle expire en quelques heures, pas en mois.
• Fixez des limites de dépenses par transaction, par protocole et par jour. Si l'agent doit dépasser votre plafond, qu'une approbation humaine soit requise. Le coût est une friction ; le bénéfice est de contenir le désastre.
• Privilégiez le modèle intent-based lorsqu'il existe. Un agent qui signe des paiements ponctuels contre des instructions explicites (le modèle x402) a un rayon de dommage limité à chaque opération, et non à votre solde.
• Vérifiez la couche d'intermédiation. Si l'agent se connecte à des outils ou des facilitateurs externes, vérifiez qui les exploite. Un routeur ou un serveur malveillant peut lui injecter des instructions — le vecteur des routeurs LLM.
• Révoquez périodiquement les anciennes permissions. Les allowances persistent. Vérifiez et retirez ceux que vous n'utilisez plus avant d'en accorder de nouveaux. Ici, il est utile de savoir lire les permissions d'un protocole avant de signer.

Aucune de ces étapes n'exige de faire moins confiance à l'IA. Elles exigent de lui donner moins de pouvoir que ce que votre instinct vous pousse à lui accorder — ce qui est, précisément, la définition pratique du moindre privilège.

Que retenir sur les permissions agentiques en DeFi ?

La leçon qui traverse tout ce cadre est que le risque d'un agent en DeFi réside presque toujours dans l'architecture de permissions qui l'entoure, et non dans le modèle d'IA. Bankr n'est pas tombé à cause d'une IA défectueuse, mais — selon toutes les hypothèses publiques — à cause de permissions de session qui ont survécu à leur usage ; les routeurs malveillants n'ont pas brisé le modèle, ils ont empoisonné ce qu'il lisait. Le même agent, avec le bon modèle de permissions, est un outil utile ; avec le modèle naïf, c'est une bombe à retardement.

L'orientation du secteur est claire et cohérente : de la garde totale vers l'intent-based, puis vers des couches de gouvernance des dépenses qui ne se fient même pas au standard intent-based seul — comme le démontre le fait que Fireblocks ait construit des contrôles additionnels par-dessus le x402. Le "fully sandboxed" reste l'horizon aspirationnel, plus cité que déployé, car sa sécurité se paie en autonomie. Choisir où vous vous situez sur ce spectre, pour chaque euro qu'un agent touche, est la décision de sécurité qui définit l'ère agentique de la DeFi. Avant de connecter n'importe quel agent, il convient de savoir clairement quel wallet vous utilisez et ce qu'il expose.

Sources et liens : Chainalysis — Inside x402: 100M Agentic Payments on Base · Fireblocks — Agentic Payments Suite · Coinbase — x402 Foundation (Linux Foundation) · Microsoft — Agent Governance Toolkit · CoinDesk — Routers LLM malveillants