Auteur : Xiaobai
Cet article est une contribution originale de l'auteur. Les opinions exprimées sont celles de l'auteur. ETHPanda a édité et réorganisé le contenu.
Une fois qu'un IA Agent est déployé sur la blockchain, la question n'est plus seulement "peut-il discuter".
Il pourrait signer, recevoir des paiements, initier des transactions, déployer des contrats, gérer des portefeuilles, appeler des API, et même collaborer avec d'autres agents pour accomplir des tâches. À ce stade, ce qui intéresse vraiment l'utilisateur n'est pas d'avoir un nom agréable, mais :
Cet agent est-il fiable ?
Son portefeuille est-il propre ? Le contrat auquel il est associé existe-t-il réellement ? Son site web et ses API présentent-ils des risques ? Le contenu médiatique qu'il publie est-il falsifié ? Son code Solidity présente-t-il des vulnérabilités évidentes ? A-t-il déjà été piraté ?
C'est ce type de problème de vérification que vise l'ERC-8126.
En termes simples, l'ERC-8126 est la couche de vérification des IA Agents. Elle s'appuie sur l'enregistrement d'identité (agent registration) de l'ERC-8004, permettant à des fournisseurs de vérification indépendants d'effectuer des vérifications à plusieurs niveaux autour d'une même identité d'agent, et de transformer les résultats en signaux de risque que les portefeuilles, marchés, applications et autres agents peuvent consommer.
Il ne s'agit pas de prouver qu'un agent est éternellement digne de confiance, mais de standardiser la manière de vérifier un agent, d'exprimer les résultats de vérification, et de permettre à d'autres systèmes de lire ces résultats.
Avoir une identité ne signifie pas être digne de confiance
L'ERC-8004 résout le problème de l'identité de l'agent.
On peut le comprendre ainsi : il donne d'abord à l'IA Agent une identité enregistrable, découvrable et indexable sur la blockchain. Cette identité correspond à un agentId, et décrit via des métadonnées le nom de l'agent, son portefeuille, ses endpoints, son site web, l'adresse de son contrat, etc.
Mais l'identité en elle-même n'équivaut pas à la confiance.
Un agent malveillant peut aussi enregistrer une identité. Un agent de phishing peut aussi rédiger de belles métadonnées. Un agent qui fonctionne normalement aujourd'hui ne garantit pas que son endpoint ne sera pas détourné demain. Un agent qui a un avatar, un site web officiel, une adresse de portefeuille, ne garantit pas non plus que son contrat est sécurisé, son portefeuille propre, son contenu authentique.
Donc, l'ERC-8004 répond plutôt à la question :
Qui est cet agent ?
L'ERC-8126 pose la question supplémentaire :
Cet agent mérite-t-il d'interagir avec lui ?
Comment fonctionne la vérification ERC-8126 ?
Premièrement, une demande de vérification fait référence à l'agentId dans le registre d'identité ERC-8004. Le fournisseur de vérification lit ensuite les métadonnées correspondantes via cet agentId, en extrait des informations telles que le portefeuille, les contrats, le site web, les endpoints, le contenu médiatique, etc., et génère enfin un score de risque et une preuve de vérification.
Ce processus peut être décomposé en quatre étapes :
- L'IA Agent enregistre d'abord son identité via l'ERC-8004.
- Le fournisseur ERC-8126 lit l'agentId et les métadonnées de cet agent.
- Le fournisseur effectue des vérifications à plusieurs niveaux sur l'agent.
- Les résultats de vérification, sous forme de score de risque, de preuve, d'attestation, etc., sont consommés par des portefeuilles, des marchés, des dApps ou d'autres agents.
Le point important ici est : l'ERC-8126 n'introduit pas une unique "autorité de certification officielle".
Cela ressemble plus à un marché ouvert de fournisseurs de vérification. Différents fournisseurs peuvent utiliser leurs propres méthodes pour effectuer des contrôles de sécurité, mais les résultats doivent être exprimés dans un format standardisé. Ainsi, les portefeuilles, les marketplaces d'agents, les marchés de tâches et d'autres applications peuvent lire ces signaux de manière interopérable.
Cela va plus loin que "le projet dit de lui-même qu'il est sûr" : il décompose le jugement de confiance en signaux qui peuvent être vérifiés, enregistrés et lus par des tiers.
Cinq couches de vérification : décomposer l'agent
L'ERC-8126 définit principalement cinq types de vérifications, couvrant chacun les aspects les plus susceptibles de poser problème une fois l'agent sur la blockchain : les contrats, les médias, le code, le web et le portefeuille. Il standardise le type de vérification, l'expression des résultats et les interfaces consommables, sans faire de chaque contrôle de sécurité une unique méthode d'audit officielle. Différents fournisseurs de vérification peuvent toujours utiliser leurs propres processus de détection et modèles de risque.
ETV : Token / Contract Verification
L'ETV vérifie le token ou le contrat associé à l'agent.
Si les métadonnées de l'agent contiennent un contractAddress, le fournisseur vérifie si cette adresse contient réellement du code de contrat sur la chaîne correspondante, si elle présente des risques évidents, ou si c'est simplement une fausse adresse ajoutée au hasard.
Pour l'utilisateur, l'ETV répond à :
L'actif on-chain ou le contrat auquel cet agent prétend être associé, existe-t-il réellement ?
Car une fois qu'un agent commence à recevoir des paiements, émettre des tokens, faire du staking, exécuter des stratégies, le contrat sous-jacent n'est plus une décoration, mais l'endroit où les fonds des utilisateurs vont réellement atterrir.
MCV : Media Content Verification
Le MCV vérifie le contenu médiatique utilisé par l'agent, comme l'avatar, les images, les éléments de marque, les images de preuve, etc.
Cela peut ne pas sembler être un problème central, mais c'est très important dans le contexte des IA Agents. Un faux agent peut usurper un logo de projet, falsifier des captures d'écran officielles, voire utiliser des images générées par IA pour créer un sentiment de caution.
Le MCV doit vérifier la source du contenu, son intégrité, les traces de falsification, les filigranes, les signatures, etc.
Il répond à :
Le contenu présenté par cet agent à l'utilisateur a-t-il été falsifié ou altéré ?
SCV : Solidity Code Verification
Le SCV vérifie le code Solidity ou la sécurité du contrat associé à l'agent.
Si les métadonnées contiennent des informations sur le code ou le contrat associé, le fournisseur peut vérifier les risques courants, tels que les réentrances, les problèmes de permissions, les appels dangereux, les surfaces d'attaque par flash loan, etc.
Le SCV peut réduire certains risques contractuels courants, mais il ne remplace pas un audit humain complet.
Cela ressemble plus à une entrée standardisée pour les contrôles de sécurité des contrats. Passer le SCV ne signifie pas que le contrat est absolument sûr ; cela indique que le code ou le contrat de cet agent a subi les contrôles d'un fournisseur et a généré des signaux de risque consommables.
WAV : Web Application Verification
Le WAV vérifie le site web, les API et les endpoints de l'agent.
De nombreux agents, bien qu'ayant une identité on-chain, ont leur véritable point d'entrée d'interaction hors chaîne, comme un site web officiel, une API, un serveur MCP, un endpoint A2A ou un tableau de bord.
Un problème à ces endroits peut présenter un risque pas moindre qu'un problème de contrat. Un certificat de site web expiré peut exposer l'utilisateur à une attaque de l'homme du milieu ; une API détournée peut amener l'agent à exécuter de mauvaises instructions ; un front-end injecté avec un script malveillant peut amener l'utilisateur à signer une transaction dangereuse.
Le WAV répond à :
Les entrées web et les points de service de cet agent sont-ils sûrs ?
WV : Wallet Verification
Le WV vérifie le risque associé au portefeuille de l'agent.
Il examine si ce portefeuille a un historique de transactions, s'il vient d'être créé (coquille vide), s'il est associé à des adresses à haut risque, des adresses de phishing, des adresses d'attaquants ou d'autres objets présents dans des bases de données de renseignements sur les menaces.
Le WV répond à :
Les antécédents comportementaux on-chain de cet agent sont-ils propres ?
Score de risque unifié : rendre les portefeuilles et applications réellement utilisables
L'ERC-8126 convertit les résultats de vérification en un score de risque de 0 à 100.
Plus le score est bas, plus le risque est faible ; plus le score est élevé, plus le risque est élevé.
- 0-20 : Risque faible
- 21-40 : Risque moyen
- 41-60 : Risque croissant
- 61-80 : Risque élevé
- 81-100 : Risque critique
La pertinence produit de cette conception est directe.
Un portefeuille ne peut pas demander à un utilisateur ordinaire de lire un rapport de sécurité complet à chaque fois. Un marketplace ne peut pas non plus se contenter des auto-déclarations des projets pour le classement. Un score de risque unifié peut devenir une entrée pour les stratégies produit.
Par exemple :
- Si le score de risque est trop élevé, le portefeuille peut avertir ou bloquer l'interaction.
- S'il n'y a pas de résultat de vérification, le marketplace peut réduire le poids d'affichage.
- Si le risque du portefeuille est anormal, le marché des tâches peut limiter la prise de commandes.
- Si le risque de l'endpoint web est élevé, le front-end peut avertir l'utilisateur d'accéder avec prudence.
Cependant, un score global ne peut pas représenter l'ensemble de la situation.
Le risque contractuel, le risque de portefeuille, le risque de site web, le risque médiatique sont par nature des types de risques différents. Une meilleure conception produit serait d'afficher à la fois le score global et les scores par catégorie, pour que l'utilisateur sache où se situe précisément le problème.
PDV et ZKP : Prouver qu'on a passé la vérification sans divulguer tous les détails
La vérification d'un agent implique de nombreuses informations sensibles.
Par exemple, le code source, la configuration de l'infrastructure, les rapports de sécurité, les journaux privés, le profil du portefeuille, etc. Si tout était rendu public, cela pourrait même élargir la surface d'attaque.
C'est pourquoi l'ERC-8126 introduit le PDV et le ZKP.
PDV signifie Private Data Verification, et ZKP signifie Zero-Knowledge Proof. Leur rôle est de permettre à un agent de prouver qu'il a passé une certaine vérification, sans avoir à divulguer tous les détails sous-jacents.
On peut le comprendre ainsi :
Le monde extérieur voit "a passé la vérification, le score de risque est X, la preuve est là", et non l'intégralité des documents de sécurité internes.
Cela fait de l'ERC-8126 davantage un résumé vérifiable de due diligence, plutôt qu'un étalage de toutes les données directement à l'ensemble du réseau.
ERC-8004 / ERC-8126 / ERC-8183 : Identité, Vérification, Transaction
Si l'on décompose l'économie des IA Agents en trois couches, on peut comprendre ainsi. Il faut d'abord préciser l'état : l'ERC-8126 est dans l'état Final, tandis que l'ERC-8004 et l'ERC-8183 sont encore au stade Draft. Les trois sont donc mieux compris comme une direction d'infrastructure en formation, plutôt qu'une pile de protocoles entièrement figée.
- ERC-8004 : Identité - Donne une identité à l'agent, permet l'enregistrement et la découverte.
- ERC-8126 : Vérification - Rend les signaux de sécurité et de risque de l'agent vérifiables et consommables.
- ERC-8183 : Commerce - Permet à l'agent d'accepter des tâches, de soumettre des résultats, d'entrer dans des processus d'escrow et de règlement.
Plus simplement :
- ERC-8004 répond : Qui es-tu ?
- ERC-8126 répond : Es-tu fiable ?
- ERC-8183 répond : Peux-tu travailler, être payé, régler ?
Ensemble, ces trois éléments présentent un récit assez clair de l'économie des agents :
D'abord l'identité, puis la vérification, et enfin, plus facilement, l'entrée dans les transactions et le règlement.
Cette relation peut être détaillée un peu plus. L'ERC-8126 s'appuie bien sur l'ERC-8004 ; l'ERC-8183 et l'ERC-8126 sont plutôt naturellement complémentaires, qu'étroitement liés.
Autrement dit, un protocole de commerce d'agents comme l'ERC-8183 peut naturellement consommer les signaux de vérification de l'ERC-8126, par exemple en vérifiant le score de risque d'un agent avant qu'il n'accepte une tâche, ou en vérifiant la preuve avant qu'un évaluateur ne libère les fonds. Mais cela ressemble plus à une direction de combinaison technique, pas à une dépendance stricte de l'ERC-8183 envers l'ERC-8126.
Qu'est-ce que cela signifie pour les développeurs ?
Si l'on ne considère les IA Agents que sous l'angle du récit de marché, la discussion reste facilement bloquée sur les tokens, les lancements, les marketplaces et l'engouement transactionnel. Mais pour ceux qui veulent réellement créer des produits d'agents, des intégrations de portefeuilles, des réseaux de tâches ou des infrastructures de protocole, la question clé est : lorsqu'un agent commence à gérer des actifs, appeler des services, soumettre des résultats, collaborer avec d'autres agents, qui supporte le coût de la confiance ?
Par le passé, ce coût était souvent laissé à l'utilisateur. L'utilisateur jugeait lui-même si le projet était fiable, vérifiait lui-même si le contrat était audité, vérifiait lui-même si le portefeuille était propre, identifiait lui-même si le site officiel était faux, et supportait finalement lui-même les conséquences d'une arnaque ou d'une interaction ratée.
La valeur de l'ERC-8126 réside dans le fait qu'elle tente de décomposer ces jugements en signaux de vérification standardisés, combinables et lisibles par les produits.
Elle n'éliminera pas le risque et ne garantira pas qu'un agent soit éternellement digne de confiance. Mais si ce type de signaux de vérification est adopté par plus de portefeuilles, marketplaces, dApps et réseaux d'agents, de nombreuses décisions produit pourront ne plus dépendre uniquement des auto-déclarations des projets.
Concrètement :
Pour les portefeuilles, le score de risque peut devenir une entrée pour le contrôle des risques avant transaction et les avertissements.
Pour les marketplaces d'agents, les résultats de vérification peuvent influencer le classement, le filtrage, le poids d'affichage et les étiquettes de risque.
Pour les applications AI x ETH, cela peut devenir une vérification de sécurité avant l'intégration d'un agent.
Pour la collaboration agent-to-agent, cela peut aider un agent à filtrer les objets manifestement à haut risque avant de coopérer.
C'est aussi là que réside l'intérêt de l'ERC-8126 : ce n'est pas un autre ERC conceptuel sur l'IA, mais une tentative de faire passer les agents on-chain de "pouvant être enregistrés" à "pouvant être vérifiés et contrôlés en termes de risque".
C'est encore une norme, pas un réseau déjà opérationnel
On peut voir cette partie sous un autre angle.
L'ERC-8126 définit des interfaces standard et un cadre de vérification. Elle explique comment la vérification peut être faite, comment les résultats peuvent être exprimés, mais cela ne signifie pas qu'il existe déjà un réseau de vérification public mature et unifié fonctionnant de manière inter-chaînes et inter-portefeuilles/marchés.
D'après la spécification actuelle, elle a clarifié plusieurs points :
- L'ERC-8126 définit le processus standard de vérification des agents.
- Elle exige que la vérification s'ancre sur l'agentId de l'ERC-8004.
- Elle couvre cinq types de risques : token/contrat, médias, Solidity, Web, portefeuille.
- Elle prend en charge le score de risque, les preuves et les attestations.
- Elle fournit une base pour que les portefeuilles, marketplaces, dApps consomment les signaux de vérification.
Le véritable déploiement de ces capacités dépendra du nombre de fournisseurs, portefeuilles, marketplaces et applications qui adopteront la norme par la suite. Autrement dit, elle n'est pas encore dans l'état suivant :
- Tous les portefeuilles sont déjà intégrés.
- Tous les marketplaces d'agents l'ont déjà adoptée.
- Tous les fournisseurs utilisent des critères de notation parfaitement identiques.
- L'industrie a déjà formé un réseau de vérification mature.
- Le ZKP et le scoring de risque sont déjà complètement unifiés en environnement de production.
Autrement dit :
L'ERC-8126 standardise d'abord le langage de vérification des IA Agents. Pour devenir une couche de confiance publique, elle a encore besoin que les fournisseurs, portefeuilles, marchés et applications continuent de s'y connecter.
Conclusion
Une fois que les IA Agents entrent dans l'économie on-chain, l'identité n'est qu'un point de départ. Une question plus pratique se posera ensuite : peuvent-ils être vérifiés ?
L'ERC-8004 donne une identité à l'agent. L'ERC-8126 permet de vérifier les risques derrière cette identité. L'ERC-8183 permet quant à elle à l'agent d'utiliser ces signaux de vérification dans des scénarios de tâches, d'escrow et de règlement.
Ainsi, la signification de l'ERC-8126 n'est pas de décerner un badge "digne de confiance pour toujours" à un agent, mais de standardiser une question plus réaliste :
Lorsqu'un IA Agent doit entrer dans les flux des portefeuilles, des marchés, des réseaux de tâches et des transactions on-chain, comment devrions-nous le vérifier ? Comment les résultats de vérification devraient-ils être exprimés ? Et comment les autres systèmes devraient-ils consommer ces résultats ?
C'est peut-être la couche de confiance que l'économie des IA Agents doit maintenant combler.
Références
- ERC-8126: AI Agent Verification
- ERC-8126 Raw Markdown
- ERC-8004: Trustless Agents
- ERC-8183: Agentic Commerce
- Ethereum Magicians: ERC-8126 Discussion
- DonJohnson X Thread: Introducing ERC-8126
- Cybercentry Web3 Security & Verification Services
- ERC-8126 Scan







