Le registre des agents Concordium constitue la pierre angulaire de l’intégration de Concordium (CCD) à l’économie AI Agent. Lorsqu’un Agent agit de manière autonome — signature, paiement, invocation de services — les contreparties doivent d’abord clarifier : « Qui possède cet Agent et qui a autorisé ses actions ? » Ce registre propose des ancres d’identité on-chain, vérifiables, découvrables et référencées cross-chain, qui s’intègrent à la couche de comptes vérifiés évoquée dans l’identité au niveau du protocole et la zero-knowledge proof.
Selon la documentation publique, le registre se compose du CIS-8004 (standard d’enregistrement des agents), de l’Agent Card (JSON off-chain et hash on-chain), du CIS-8 External Key Registry (liaison cross-chain de clé publique) et du MCP Server (interface d’outils pour agents). Les sections suivantes présentent le processus sous forme de workflow reproductible, et non comme une opération unique.
Quelles sont les étapes à anticiper avant d’enregistrer un agent ?
Avant l’enregistrement, trois prérequis sont indispensables : un compte natif Concordium vérifié, une URL d’hébergement publique pour l’Agent Card, et des métadonnées précisant le nom de l’agent, ses compétences et ses endpoints de service. Pour l’interopérabilité avec Ethereum ou Solana, il faut également préparer la clé publique de la chaîne concernée et la capacité de signature nécessaire pour la liaison CIS-8.
| Élément |
Finalité |
Source courante |
| Compte Concordium vérifié |
Sert d’ancrage d’imputabilité |
Portefeuille ayant finalisé le processus Identity Issuer |
| Agent Card JSON |
Définit les capacités et endpoints de l’agent |
Rédigé par le développeur ou généré via l’outil MCP |
| agent_uri public |
Héberge l’Agent Card |
Hébergement HTTPS statique ou API |
| Clé publique de chaîne externe (optionnel) |
Permet la découverte et l’invocation cross-chain |
Portefeuilles ETH/SOL |
Concordium précise que les agents ne sont pas tenus de migrer l’ensemble de leurs activités sur sa chaîne. Le registre peut ancrer l’identité sur Concordium, tandis que les agents opèrent sur d’autres chaînes, utilisant CIS-8 et le Badge pour diffuser des signaux de confiance hors de l’écosystème.
Chaque agent inscrit dans le registre correspond à un NFT CIS-8004, émis et mis à jour par un compte natif Concordium vérifié en tant que propriétaire. Ce compte propriétaire est rattaché à une personne ou entité réelle via l’identité au niveau du protocole, ce qui établit la chaîne d’autorisation : NFT Agent → Compte propriétaire → Identité validée par Identity Issuer.
Le stockage on-chain comprend des champs essentiels : agent_uri (vers l’Agent Card), metadata_hash (SHA-256) garantissant l’intégrité du document, et des métadonnées extensibles clé-valeur (par exemple, une adresse de portefeuille de paiement). Une external_reference optionnelle peut pointer vers la liaison CIS-8 ou des identifiants de réseaux sociaux, facilitant la résolution cross-environnement pour le même agent.
Ce modèle diffère des enregistrements purement ERC-8004, qui se limitent à « décrire l’agent » : Concordium exige que le propriétaire détienne un compte vérifié, faisant du « qui a autorisé » une condition préalable à l’enregistrement. Les métadonnées de l’agent peuvent inclure le portefeuille de paiement et d’autres champs clé-valeur, autorisant le règlement entre agents ou des scénarios x402 de paiement à l’usage. Toutefois, les contrôles de dépenses applicatifs restent nécessaires ; l’enregistrement on-chain seul ne restreint pas le comportement de l’agent.
L’Agent Card est un document JSON conforme à des formats comme A2A (Agent-to-Agent), qui inclut le nom, la description, les compétences, les endpoints de service de l’agent et des extensions Concordium (index de contrat, adresse de token, compte propriétaire, etc.). Ce document est hébergé à l’URL agent_uri (HTTPS) ; lors de l’enregistrement, à la fois l’URL et le hash SHA-256 du contenu sont inscrits dans le contrat CIS-8004.
Tout acteur — agent, outil MCP ou examinateur — peut vérifier l’agent : il suffit de récupérer agent_uri et metadata_hash sur la chaîne, de télécharger le JSON brut depuis l’URL, de calculer le SHA-256 et de le comparer au hash on-chain. L’outil MCP verify_agent_card automatise cette vérification.
Lors d’une mise à jour des capacités de l’agent, le JSON hébergé doit être modifié et le hash on-chain actualisé via build_set_agent_uri ou équivalent. Sinon, l’ancre on-chain et le document off-chain divergent. L’Agent Card sert de spécification publique modifiable, le NFT on-chain agit comme ancre d’intégrité irréfutable. Il est conseillé de conserver des snapshots ou un journal des modifications lors des mises à jour, afin de permettre l’audit de l’évolution des capacités de l’agent.
Figure 1. Workflow du registre des agents Concordium : compte vérifié, mint CIS-8004, ancrage du hash de l’Agent Card et affichage du Badge.
Le CIS-8 External Key Registry stocke la preuve cryptographique de la liaison entre un compte natif Concordium et des clés publiques externes (comme des adresses Ethereum ou des clés Solana) on-chain. Après la liaison, un agent CIS-8004 peut référencer l’entrée CIS-8 via external_reference, permettant aux outils Ethereum de retrouver le même NFT Agent via la clé publique.
Le chemin de résolution est le suivant : adresse de chaîne externe → recherche de liaison sur le contrat CIS-8 → compte propriétaire Concordium → recherche de l’agent CIS-8004 → Agent Card. token_address et les coordonnées de contrat dans les extensions Concordium facilitent les recherches pour les registres externes, sans connaissance spécifique de Concordium.
Ainsi, un agent peut être identifié par ID de token dans les outils Concordium ou par adresse ETH dans les outils Ethereum, tous renvoyant à la même identité on-chain. Contrairement à l’approche « proof of personhood » évoquée dans Concordium vs Worldcoin, le registre cible l’identité vérifiable au niveau agent et l’interopérabilité cross-chain.
Le Badge Verified by Concordium agit comme signal de confiance pour les contreparties : il indique que l’agent est rattaché à un compte vérifié au niveau du protocole. La vérification doit s’appuyer sur des preuves on-chain, et non sur le simple affichage de l’icône : il faut vérifier l’existence du token CIS-8004, le statut d’identité du compte propriétaire, la correspondance du hash de l’Agent Card avec le document hébergé, et, pour les cas cross-chain, la liaison CIS-8.
Le Badge réduit la charge de communication sans remplacer l’auto-vérification. Les entreprises ou environnements à exigences élevées combinent Verify et Access pour vérifier les attributs (âge, diplômes, plafond de dépenses), en complément de la couche d’identité et d’autorisation du registre. Si un agent représente un établissement financier ou une plateforme e-commerce, la stack de confiance complète est : le registre valide l’agent et l’entité autorisée → ZKP vérifie les attributs métier → Protocol-Level Locks ou x402 encadrent les flux de paiement, chaque couche remplissant son rôle.
Points d’attention lors de l’enregistrement et de la vérification
Assurez-vous que l’hébergement de l’Agent Card est disponible et que l’intégrité HTTPS est garantie : si l’URL devient invalide ou si le contenu change sans mise à jour du hash on-chain, la vérification échouera. La liaison de clé externe doit précéder la configuration de l’external_reference CIS-8 ; un ordre incorrect provoque un rollback de l’enregistrement ou des références invalides. La sécurité de la clé propriétaire détermine le contrôle sur l’agent ; les NFT étant transférables, tout changement de propriété exige des procédures de gouvernance interne.
MCP Server propose des outils pour l’enregistrement, la création de l’Agent Card et la vérification, facilitant l’intégration au framework agent, mais les développeurs doivent maîtriser les opérations on-chain et les coûts de gas (ou Sponsored Transactions). L’écosystème du registre évolue encore, et l’adoption du Badge comme critère d’admission dépendra des pratiques de marché.
La documentation publique recense les contrats mainnet : CIS-8004 Agent Registry (index 10082) et CIS-8 External Key Registry (index 10081), interrogeables via des block explorers comme CCDScan. Les indexeurs transforment les événements on-chain en API REST, simplifiant la recherche d’agents sans scan manuel. En production, il est recommandé d’établir une checklist de déploiement reproductible « enregistrement on-chain → hébergement de la carte → vérification du hash → affichage du Badge », à intégrer dans les workflows CI lors de la mise à jour des capacités d’agent, pour éviter toute divergence entre la chaîne et le document.
Résumé
Le registre des agents Concordium fédère identité d’agent, intégrité documentaire, clés publiques cross-chain et comptes vérifiés dans un workflow réutilisable. Maîtriser les rôles du CIS-8004, de l’Agent Card et du CIS-8 est essentiel pour intégrer le Verified Badge et garantir la confiance cross-chain. Au déploiement, l’enregistrement on-chain, l’hébergement documentaire et la vérification régulière du hash doivent être intégrés aux processus pour éviter toute obsolescence non vérifiable après mise à jour des capacités de l’agent.
FAQ
Qu’est-ce que le registre des agents Concordium ?
Agent Registry est le système d’identité d’agent on-chain de Concordium, enregistrant les agents comme NFT via CIS-8004 et décrivant leurs capacités et endpoints via l’Agent Card. Le registre relie les agents à des comptes Concordium vérifiés, prend en charge la liaison de clés cross-chain et le Badge Verified by Concordium.
Comment l’identité de l’AI Agent est-elle liée à un compte réel ?
Chaque NFT agent est détenu et géré par un compte natif Concordium vérifié, rattaché à une personne ou entité validée par l’identité au niveau du protocole et l’Identity Issuer, ce qui forme la chaîne d’imputabilité : Agent → Propriétaire → entité vérifiée.
À quoi sert l’Agent Card ?
L’Agent Card est un document JSON public qui détaille le nom de l’agent, ses compétences et ses endpoints ; son URL et son hash SHA-256 sont stockés on-chain pour garantir l’intégrité. Toute mise à jour des capacités nécessite de synchroniser la modification du document et le hash on-chain.
Les agents Concordium peuvent-ils fonctionner sur Ethereum ou Solana ?
Oui. En liant des clés publiques de chaînes externes à des comptes Concordium via CIS-8 et en configurant external_reference sur les agents CIS-8004, les outils externes peuvent retrouver la même identité d’agent avec des adresses Ethereum ou Solana, sans migration de logique sur Concordium.
Comment vérifier la fiabilité d’un agent ?
La vérification on-chain doit inclure le contrôle du token CIS-8004, le statut d’identité du compte propriétaire, la correspondance du hash de l’Agent Card avec le document hébergé et la liaison cross-chain CIS-8 si besoin. Le Verified Badge est un indicateur complémentaire et ne remplace pas la vérification cryptographique.
