Les registres d’agents vous indiquent ce qui existe, mais pas si vous pouvez encore leur faire confiance.
Un cadre de quatre questions pour les registres de capacités des agents, couvrant l’existence, la conformité, le statut et l’origine, ainsi qu’un test simple de dernière vérification que vous pouvez exécuter dès aujourd’hui.
Imaginez un agent qui, lors d’une exécution de routine, cherche un outil par son nom, l’appelle, reçoit une réponse pertinente et continue. L’exécution réussit, et c’est justement cela qui est inquiétant, car personne au sein de l’équipe n’a jamais examiné cette fonctionnalité. Les registres et les services de découverte sont censés mettre ce genre de situation sous contrôle, et en l’espace d’une seule semaine, plusieurs produits et spécifications sont arrivés, prétendant tous faire partie de cette couche de contrôle.
Aucun d’eux n’est erroné, mais ensemble ils ne couvrent que la moitié des informations dont une équipe a besoin avant qu’un agent n’utilise une nouvelle fonctionnalité. Cet article décompose le problème en quatre questions distinctes, montre celles auxquelles les registres actuels répondent, et propose une vérification concrète, ainsi qu’une courte liste d’actions, pour les aspects qui restent en suspens.
Qu’est-ce qui est arrivé dans la couche de registre
Les détails ci-dessous reflètent les annonces au moment de la rédaction ; veuillez consulter la documentation actuelle avant de vous fier à des fonctionnalités spécifiques ou à des numéros de version.
Registre des agents AWS
Le Registre des agents sur AWS est désormais disponible de manière générale. Pensez-y comme à un catalogue privé doté d’une gouvernance intégrée, capable de stocker des agents, des serveurs MCP, des cartes d’agents A2A, des compétences ainsi que des ressources personnalisées arbitraires. La conception sépare délibérément deux plans distincts : les curateurs travaillent dans un plan de gouvernance où les entrées sont approuvées ou rejetées ; les utilisateurs effectuent des requêtes dans un plan de découverte qui ne met en évidence que les entrées approuvées. Chaque enregistrement passe par cinq états (brouillon, en attente, approuvé, rejeté, obsolète). Les événements EventBridge déclenchent les transitions entre ces états, tandis que CloudTrail gère le journal d’audit.
Avec la disponibilité générale, des fonctionnalités de gestion d’infrastructure par code (CloudFormation, CDK et Terraform) ont été mises en place, permettant le partage entre comptes via RAM, ainsi qu’une détection automatique, au sein de toute l’organisation, des agents déjà en cours d’exécution sur AgentCore. Cette fonction de détection est facile à négliger, mais elle existe car les agents « fantômes » non suivis constituent déjà un véritable problème de gestion des actifs. Parmi les entreprises qui l’ont adoptée figurent Southwest, PepsiCo, Syngenta, Amdocs et Sony, ce qui indique que les acheteurs sont passés au-delà des phases de test pilote. AWS décrit en détail cette conception sur son blog de machine learning.
Découverte des ressources agissantes (ARD)
Parallèlement, une spécification soutenue par plusieurs fournisseurs vise à combler ce même manque. Agentic Resource Discovery a été rédigée par des contributeurs de Google, Microsoft et Hugging Face et est publiée sous licence Apache 2.0, avec la participation également de NVIDIA, Salesforce et Databricks. L’article de The New Stack la présente comme un équivalent DNS pour les agents. Son interface est délibérément restreinte : les messages sont envoyés sous forme JSON-LD via REST. Un seul point de terminaison est obligatoire, POST /search, et il est sollicité en fournissant une description de la tâche plutôt que le nom d’une ressource. Les points de terminaison permettant une navigation sont optionnels. La fonction de fédération permet à une entreprise de conserver son propre catalogue privé tout en transmettant les requêtes aux registres externes qu’elle a choisis de faire confiance. Au moment où cet article est écrit, la spécification est à la version 0.91, son modèle de gouvernance reste ouvert, et le W3C a été mentionné comme un éventuel organisme de gestion.
Vérification continue en tant que produit
Le troisième projet lancé était une startup, AIR, qui est apparue soudainement après avoir levé 50 millions de dollars lors de deux tours de financement initial (Sequoia ayant mené le premier, Greenoaks le second). Son activité consiste à examiner les plugins, compétences et serveurs MCP que chargent les agents. Une statistique fournie par cette entreprise mérite d’être retenue : environ 27 % des compétences et add-ons provenant de sources publiques qu’ils évaluent actuellement sont filtrés.
Lorsque trois projets ciblent un même domaine en l’espace de quelques jours, cela signifie généralement que le secteur a atteint un consensus quant à l’endroit où se trouve l’élément manquant.
Pourquoi la découverte n’est pas la mission de MCP
MCP ne prétend jamais résoudre le problème de la découverte des outils. Il définit les mécanismes permettant d’invoquer un outil une fois que l’agent a déjà choisi celui à utiliser. A2A fait de même pour les conversations entre agents qui se connaissent déjà. Dans les deux cas, on suppose que la localisation et le choix de la capacité correspondante ont eu lieu précédemment. Si vous souhaitez un rappel de cette distinction, consultez comment le Model Context Protocol permet aux agents d’IA de découvrir et d’appeler des outils.
Ce qui a changé, c’est le volume. Le câblage manuel des serveurs MCP est gérable avec une douzaine d’outils. Avec plus d’un millier d’outils, appartenant à différentes équipes internes, des fournisseurs SaaS et des plateformes cloud, un agent limité à une liste fixe dans sa configuration n’est guère un agent ; il ressemble plutôt à un script fixe qui se contente d’appeler un modèle. La découverte permet aux capacités de changer en temps de exécution. Cette même caractéristique signifie que personne n’a audité cet ensemble d’outils, et peu d’équipes ont pris en compte ce compromis dans leurs calculs de coûts.
Une deuxième pression provient de la manière dont les agents sont étendus. Des chercheurs ayant examiné le code source de onze outils de codage de production, soit environ quatre millions de lignes couvrant des outils tels que OpenHands, Gemini CLI, Codex CLI et Claude Code (arXiv 2609.00006), ont constaté que les compétences au format SKILL.md y avaient pris le dessus sur MCP : neuf des onze outils prennent en charge les compétences, tandis que huit prennent en charge MCP. Ainsi, le mécanisme d’extension qui se propage le plus rapidement est un fichier Markdown rempli d’instructions que l’agent exécutera. De tels fichiers ne disposent d’aucun mécanisme de signature et pratiquement aucune gestion de version, ce qui signifie qu’une entrée dans un registre la désignant ne vous en dit pas beaucoup sur ce qu’il fera demain.
Quatre questions auxquelles un registre doit répondre
Lorsqu’un agent est sur le point d’utiliser une fonctionnalité qui n’était pas disponible pour lui récemment, quatre réponses distinctes sont nécessaires. Elles semblent similaires mais correspondent à des problèmes différents, et les séparer permet de voir ce que fait réellement un produit donné par rapport à l’objectif pour lequel il est acheté.
Existence : existe-t-il quelque chose qui fait cela ?
Existe-t-il une fonctionnalité capable de gérer cette tâche, et où est-elle hébergée ? C’est là que le mécanisme POST /search d’ARD intervient, et le système de découverte d’AWS s’en charge très bien. Le problème est réel, et à des fins pratiques, il est désormais presque résolu.
Adéquation : quel candidat convient le mieux à cette tâche ?
Une recherche renvoie plusieurs candidats, alors lequel l’agent doit-il utiliser ? Les auteurs d’ARD eux-mêmes affirment que la comparaison DNS échoue dans ce cas : une requête produit des candidats plutôt qu’une adresse autoritaire unique, et chaque service applique ses propres règles de confiance et de classement. Laisser cette question ouverte est raisonnable pour une spécification encore jeune. Cependant, ce n’est pas adapté à votre déploiement, car c’est précisément au niveau du classement que les attaquants cherchent le plus à s’infiltrer, tout comme lors du poisonage des moteurs de recherche ou du typosquatting dans les registres de paquets.
Statut : est-il approuvé actuellement ?
C’est là que AWS est le plus fort : les états du cycle de vie ainsi que les événements fournissent une réponse bien structurée, plus avancée que tout autre système de ce type. La faiblesse réside dans le fait qu’une approbation peut devenir obsolète. Supposons qu’un élément ait été détecté automatiquement, approuvé en mars puis ignoré. En septembre, le système le présente toujours avec autant de confiance que s’il avait été vérifié par un responsable ce matin même.
Provenance : qui l’a écrit et qu’est-ce qui a changé ?
Qui a développé cette fonctionnalité, qu’a changé depuis la dernière vérification, et que charge-t-elle en temps de exécution ? Aucun des nouveaux produits lancés ne répond à ces questions, et c’est justement le fondement du financement d’AIR. Leur position, qui reste valable, est que la vérification doit être continue et non résider dans une étape unique. Une compétence ayant été approuvée il y a un mois peut devenir malveillante suite à une mise à jour de dépendance ou au piratage d’un compte d’administrateur, tandis que sa fiche dans le catalogue reste parfaitement identique. Les travaux académiques vont dans le même sens. Des recherches récentes sur les fondements des agents basés sur des compétences (arXiv 2608.29596) modélisent un cycle de vie en neuf étapes et placent les registres publics, les marchés et les adversaires au cœur de l’architecture, plutôt que de les considérer comme des éléments ajoutés ultérieurement.
Problèmes de recherche versus problèmes de chaîne d’approvisionnement
Les deux premières questions portent sur la recherche. Les deux dernières concernent la chaîne d’approvisionnement, et l’industrie a déjà fait face à cela par le passé avec des extensions de navigateur, des images de base pour les conteneurs et des paquets npm. Dans chaque cas, des catalogues existaient bien avant que quiconque ne puisse garantir leur contenu, et les incidents de sécurité se sont concentrés durant cette période.
Le dernier test vérifié
Cette vérification est délibérément simple, car la réponse compte plus que le cadre utilisé. Prenez votre liste actuelle des capacités des agents, qu’il s’agisse d’un registre approprié ou simplement d’une feuille de calcul, et choisissez une entrée au hasard. Ensuite, recherchez deux dates horaires :
- Quand a-t-elle été approuvée ?
- Quand quelqu’un, qu’il s’agisse d’une personne ou d’une tâche automatisée, l’a-t-il comparée pour la dernière fois à sa source ?
Lorsque ces timestamps coïncident, on a affaire à un catalogue plutôt qu’à un plan de contrôle. Le premier enregistre une décision antérieure ; le second reflète la réalité actuelle. Comptez les jours entre ces deux dates : c’est le temps pendant lequel une fonctionnalité approuvée puis oubliée a pu être modifiée sans que personne ne s’en aperçoive. Étant donné qu’environ un quart des compétences accessibles au public échouent déjà aux vérifications de base, ce chiffre constitue une mesure fiable de votre véritable exposition.
De nombreuses équipes ne disposent pas de second timestamp à afficher. Cet absence est le véritable problème : il ne s’agit pas d’une valeur incorrecte, mais bien d’un champ manquant.
Que faire ce trimestre
Le plan pratique se compose de trois parties, classées par ordre de difficulté.
- Adoptez un registre. L’inventaire constitue un véritable problème, et un agent non traçé est plus dangereux qu’une abonnement SaaS non suivi, car il agit de sa propre initiative. Les équipes qui développent déjà sur Bedrock devraient sérieusement envisager l’option AWS ; celles qui ont besoin de fédération et de neutralité vis-à-vis des fournisseurs préféreront probablement ARD.
- Ajoutez le champ manquant au registre. Donnez à chaque entrée une date et heure de dernière vérification mises à jour par un processus automatisé, et non par une personne. Déterminez à l’avance ce qui déclenchera la mise à jour : l’expiration, le placement en quarantaine ou une alerte. L’un de ces critères vaut mieux que le comportement actuel, où une entrée obsolète reste active indéfiniment.
les permissions, les portes d’approbation et les niveaux de risque pour les agents traitent ce aspect.
Points clés
- Les registres et les spécifications de découverte répondent désormais de manière assez satisfaisante aux questions « qu’est-ce qui existe ? » et « est-ce approuvé ? ».