Avec le déploiement officiel de la norme ERC-8004 (Agents sans Confiance) sur le réseau principal d'Ethereum, la gestion de l'identité et de la réputation des Agents IA entre dans une nouvelle phase vérifiable et sans confiance. Cette norme fournit aux agents un « système d'identité » vérifiable sur la chaîne grâce à trois registres principaux : le registre d'identité, le registre de réputation et le registre de validation. Cet article adopte une perspective d'audit de sécurité, combine les détails techniques de l'ERC-8004, analyse les points de risque de chaque registre et fournit un guide d'audit pratique pour les développeurs et les auditeurs.
Détails techniques et points d'audit
La clé de l'ERC-8004 réside dans ses trois registres (Registry) :
1. Registre d'identité (Identity Registry)
Un identifiant minimal sur la chaîne basé sur ERC-721, avec l'extension URIStorage, qui se résout vers le fichier d'enregistrement de l'agent, fournissant à chaque agent un identifiant portable et résistant à la censure.
Dans l'architecture de l'ERC-8004, le registre d'identité est construit sur ERC-721 et étend la fonctionnalité URIStorage. En d'autres termes, chaque agent correspond à un NFT unique sur la chaîne, ce NFT étant appelé AgentID.
Lorsqu'un développeur crée un agent, il appelle la fonction register du contrat de registre pour frapper un nouvel AgentID. Ce jeton est lié à un tokenURI, pointant vers un fichier JSON stocké hors chaîne — le soi-disant « fichier d'enregistrement de l'agent ». Le fichier d'enregistrement doit suivre une spécification stricte, incluant généralement trois types de contenu principal :
- Informations de base, telles que le nom, la description, l'URL de l'avatar ;
- Points de terminaison de service, c'est-à-dire l'adresse réseau à laquelle l'agent peut être accessible, prenant en charge divers protocoles comme HTTP, WebSocket, Libp2p, A2A, MCP ;
- Déclarations de capacité, c'est-à-dire la liste des tâches que l'agent peut exécuter, comme la génération d'images, l'arbitrage de transactions ou l'audit de code.
Les simples déclarations personnelles ne suffisent évidemment pas à établir la confiance, c'est pourquoi l'ERC-8004 introduit un mécanisme de vérification de nom de domaine. L'agent doit héberger un fichier signé sous le domaine qu'il a déclaré, au chemin /.well-known/agent-card.json. Le registre sur la chaîne vérifie ce lien, liant ainsi l'AgentID sur la chaîne au nom DNS correspondant. Cette étape vise à prévenir le phishing et les attaques d'usurpation d'identité ; un agent ne peut pas prétendre arbitrairement appartenir à un domaine, il doit prouver son contrôle par une signature cryptographique.
Points d'audit :
● Vérifier le contrôle d'accès de la fonction setTokenURI, s'assurer qu'elle n'autorise que le propriétaire de l'agent ou un rôle autorisé (comme onlyOwnerAfterMint) à mettre à jour l'URI.
● Examiner si l'URI prend en charge des solutions de stockage immuables (comme IPFS, Arweave). Si un lien HTTP centralisé est utilisé, évaluer la sécurité du contrôle du domaine pour prévenir le détournement DNS.
● Vérifier la validité du format de l'URI, éviter les exceptions de contrat dues à des pointeurs nuls ou des URI invalides.
● Vérifier que le contrat exécute strictement la validation de signature cryptographique (comme EIP-712) lors de la vérification de la signature du domaine, pour prévenir la falsification ou les attaques par rejeu de signature.
● Vérifier le mécanisme d'expiration de la preuve de propriété du domaine pour empêcher la réutilisation de signatures valides à long terme.
● S'assurer que le processus de résolution du domaine ne dépend pas d'un oracle centralisé, éviter les points de défaillance uniques ou la manipulation.
2. Registre de réputation (Reputation Registry)
Une interface standard pour publier et obtenir des signaux de retour. L'évaluation et l'agrégation ont lieu à la fois sur la chaîne (composabilité) et hors chaîne (algorithmes complexes), permettant la réalisation d'un écosystème de services professionnels incluant l'évaluation d'agents, les réseaux d'audit et les pools d'assurance.
Utilisé pour évaluer et donner son avis sur les Agents IA déjà enregistrés. La soumission de retours simples se fait sur la chaîne, avec possibilité d'extension hors chaîne pour des agrégations complexes, remontées ensuite sur la chaîne.
L'ERC-8004 peut également utiliser un mécanisme de « liaison de preuve de paiement » (Payment-Proof Linking) pour empêcher l'évaluation malveillante. Lorsque l'agent A termine son évaluation de l'agent B, il appelle la fonction giveFeedback. Cette fonction accepte non seulement une note (0-100) et un hachage de commentaire, mais permet également de transmettre un champ paymentProof, généralement le hachage d'une transaction x402. Cela rend le coût de l'astroturfing extrêmement élevé, réduisant considérablement la possibilité d'attaques Sybil. Finalement, le système récompense naturellement les agents stables et de haute qualité.
Points d'audit :
● Vérifier que la fonction giveFeedback impose le paramètre paymentProof et contrôler si ce paramètre est un hachage de transaction x402 valide (ou conforme à d'autres standards de paiement). S'assurer que la preuve de paiement ne peut pas être réutilisée (par exemple en enregistrant les hachages déjà utilisés), pour empêcher plusieurs évaluations pour un seul paiement.
● Vérifier que la plage de notation (0-100) est contrainte au niveau du contrat, éviter que des notes hors limites ne perturbent la logique d'agrégation.
● Évaluer la résistance à la manipulation de l'algorithme d'agrégation hors chaîne : par exemple, s'il utilise la médiane, l'élagage des valeurs extrêmes ou la moyenne pondérée, et s'il pénalise les comportements anormaux (comme un grand nombre d'évaluations en peu de temps).
● Examiner si les conditions de pénalisation (slashing) sont claires et vérifiables, par exemple si elles dépendent de preuves sur la chaîne ou de la soumission de preuves de fraude par un oracle tiers.
● S'assurer que la logique de pénalisation ne contient pas de privilège centralisé (comme un administrateur pouvant confisquer arbitrairement les fonds stakés), les conditions de déclenchement de la pénalisation doivent être exécutées automatiquement et entièrement par le contrat intelligent.
● Tester la période de verrouillage et les conditions de retrait des fonds stakés, pour empêcher un agent de retirer ses fonds en urgence avant une pénalisation.
3. Registre de validation (Validation Registry)
Un crochet universel pour demander et enregistrer les vérifications par des validateurs indépendants (par exemple, un vérificateur zkML, un oracle TEE, un juge de confiance).
La réputation reflète le passé, mais dans des scénarios à haut risque (comme la gestion de gros montants), l'historique seul ne suffit pas. Le registre de validation permet à un agent de soumettre ses résultats à une validation par un tiers ou un système automatisé, en utilisant par exemple une réexécution de raisonnement sécurisé avec stake, un vérificateur zkML ou un oracle TEE pour valider ou rejeter la demande.
Le premier modèle est la validation cryptéo-économique, basée sur une conception sécuritaire de la théorie des jeux. L'agent doit miser (stake) un certain nombre de jetons natifs ou stables dans le registre. Si l'agent ne respecte pas ses engagements ou fournit un résultat erroné, le réseau de validateurs peut soumettre une preuve de fraude, déclenchant la confiscation automatique de sa mise par le contrat intelligent. Ce modèle convient aux tâches dont le résultat est facile à vérifier mais le processus de calcul opaque, comme le scraping de données ou les services API simples.
Le deuxième modèle est la validation cryptographique, basée sur une conception sécuritaire mathématique. La certification TEE (Trusted Execution Environment) permet à l'agent de s'exécuter dans un environnement matériel sécurisé, comme Intel SGX ou AWS Nitro. Le registre de validation peut stocker et vérifier les rapports d'attestation à distance provenant du matériel, prouvant que le code exécuté par l'agent est bien une version spécifique non altérée.
Le zkML (Zero-Knowledge Machine Learning) est une autre méthode de validation cryptographique. L'agent soumet, en même temps que le résultat de son inférence, une preuve à divulgation nulle de connaissance (ZK). Cette preuve peut être vérifiée à très faible coût par un contrat de validation sur la chaîne, garantissant mathématiquement que cette sortie a bien été produite par un modèle spécifique (comme Llama-3-70B) avec une entrée spécifique. Cela prévient les attaques de « remplacement de modèle » (model swapping), où le fournisseur de services prétend utiliser un modèle haut de gamme mais utilise en réalité un modèle inférieur pour réduire les coûts.
Points d'audit
Pour la validation cryptéo-économique, vérifier :
● Vérifier la fenêtre de soumission des preuves de fraude : les validateurs ont-ils suffisamment de temps pour découvrir et soumettre une preuve ? Une fenêtre trop courte peut laisser passer des comportements malveillants, trop longue bloque les fonds trop longtemps.
● Vérifier la logique d'arbitrage des preuves de fraude : dépend-elle d'un ensemble de validateurs multi-signatures ? Si oui, examiner le degré de décentralisation de la sélection des validateurs et le seuil défini ; si l'arbitrage est entièrement sur la chaîne, s'assurer que la base de décision (comme un résultat vérifiable sur la chaîne) existe et est sans ambiguïté.
● S'assurer que le montant de la mise est proportionnel au risque, pour empêcher les comportements malveillants à faible coût (par exemple, une mise trop faible, où le bénéfice de la mauvaise action est bien supérieur à la perte).
Pour la certification TEE, vérifier :
● Vérifier que le contrat vérifie l'actualité de la preuve TEE (comme l'inclusion d'un horodatage ou d'une hauteur de bloc), pour empêcher l'acceptation de preuves expirées.
● Vérifier que le contenu de la preuve inclut le hachage du code de l'agent, le résumé des entrées/sorties, pour s'assurer que la preuve est liée à une tâche spécifique et éviter la réutilisation entre tâches.
● Évaluer si la logique de vérification de la preuve TEE dépend d'un oracle externe (comme Intel IAS) ; si c'est le cas, auditer la sécurité et le degré de décentralisation de l'oracle.
Pour la validation zkML, vérifier :
● Confirmer que le contrat intègre une bibliothèque de vérification zk auditée (comme SnarkVerifier) et qu'elle est correctement configurée avec une clé de vérification pour le système de preuve spécifique (comme Groth16, PLONK).
● Vérifier que le contrat de validation limite les modèles et la plage d'entrées auxquels la preuve s'applique, pour prévenir les attaques par remplacement de modèle (par exemple, une preuve générée pour un petit modèle mais présentée comme la sortie d'un grand modèle).
● Évaluer le degré de décentralisation de la génération des preuves : dépend-elle d'un seul prouveur ? S'il existe plusieurs prouveurs, concevoir un mécanisme de consensus pour empêcher les prouveurs malveillants.
Conclusion
L'ERC-8004 fournit une norme pour établir la confiance dans les Agents IA, sa sécurité est cruciale pour tout l'écosystème des agents sur la chaîne. Le travail d'audit de sécurité doit comprendre en profondeur l'intention de conception et les risques potentiels des trois registres. De plus, la complexité des interactions inter-contrats et les vulnérabilités conventionnelles ne doivent pas être négligées. Un audit complet et rigoureux est nécessaire pour s'assurer que l'ERC-8004 tient réellement sa promesse de « sans confiance », jetant une base de sécurité pour l'avenir des agents autonomes.
