Modèles et plateformes d’IA
La Linux Foundation lance un service de noms pour l’identité des agents d’IA

La Linux Foundation a annoncé, le 10 novembre 2026, que l’Agent Name Service (ANS) était officiellement lancé en tant que projet de la fondation, apportant aux agents d’IA une identité ancrée dans un domaine, des capacités de découverte et d’authentification grâce à une spécification ouverte et à des outils libres.
L’ANS est conçu pour permettre à un système de déterminer avec quel agent enregistré il communique avant d’appliquer sa propre politique de sécurité. Il associe un nom versionné à un domaine contrôlé par l’opérateur de l’agent, utilise le Domain Name System (DNS) pour publier des informations de découverte et consigne les événements signés du cycle de vie dans un journal de transparence. Cette approche réutilise l’infrastructure Internet existante, au lieu d’exiger un registre d’agents propriétaire unique.
Le lancement fait de la déclaration d’intention de la fondation du 23 juin 2026 un projet encadré par une gouvernance. La fondation indique que 11 organisations ont contribué à l’ANS ou l’ont adopté depuis cette date : Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP et Trustmodel.ai.
Fonctionnement de l’enregistrement et de l’authentification ANS
La spécification en sept couches couvre l’identité, l’enregistrement, la dénomination versionnée, la publication DNS, la transparence, la surveillance de l’intégrité et l’authentification des agents. Un nom ANS associe une version à un domaine, comme dans ans://v1.0.0.payments.example.com ; une nouvelle version nécessite un nouvel enregistrement.
Lors de l’enregistrement, l’opérateur transmet à une autorité d’enregistrement l’hôte de l’agent, sa version, ses points de terminaison et les éléments relatifs à son certificat. L’autorité vérifie le contrôle du domaine et les preuves requises. L’opérateur publie les enregistrements DNS reçus, puis l’autorité les vérifie avant l’activation. Elle signe ensuite l’événement du cycle de vie et le fait sceller par le journal de transparence, produisant des artefacts publics qui associent l’enregistrement aux certificats autorisés.
Les pairs utilisent un profil de découverte pris en charge pour localiser les points de terminaison et le _ans-badge registre partagé afin de trouver les preuves de transparence. La découverte, à elle seule, n’authentifie pas l’appelant. L’authentification nécessite trois vérifications : le certificat est associé à l’identité enregistrée, l’enregistrement est toujours valide et l’appelant détient la clé privée correspondante.
Le projet de norme d’authentification ANS-6 accorde le même statut à TLS mutuel (mTLS) et à la preuve de possession démontrée au niveau applicatif (DPoP). mTLS convient à une connexion TLS de bout en bout, tandis que DPoP associe une preuve à usage unique à une requête HTTP et peut fonctionner avec des passerelles qui terminent TLS. Un vérificateur de niveau badge interroge le journal de transparence pour obtenir des preuves à jour ; le niveau SCITT vérifie localement un reçu et un jeton d’état, sans appels réseau pour chaque requête. DPoP nécessite la liaison SCITT.
Logiciels et premières étapes vers l’interopérabilité
Les logiciels disponibles comprennent une implémentation de référence en Go de l’autorité d’enregistrement, du journal de transparence et du vérificateur hors ligne, ainsi que des SDK en Go, Rust et Java, dont les API et les fonctionnalités prises en charge diffèrent. L’ ans-cli outil prend en charge l’enregistrement, la découverte, la gestion des certificats et les requêtes au journal de transparence sous macOS, Linux et Windows. Le guide de démarrage rapide en local utilise des clés de développement et un noop vérificateur DNS, ce qui signifie qu’une vérification concluante du reçu ne teste ni le DNS public, ni l’émission de certificats en production, ni un déploiement en conditions réelles.
En matière d’interopérabilité, la Linux Foundation indique que l’Agent Directory Service d’AGNTCY prend en charge la vérification des identités ANS et qu’ANS Finder met en œuvre Agentic Resource Discovery (ARD) et réussit ses tests de conformité du registre. La spécification propre à l’ARD porte sur la découverte avant l’invocation, et non sur l’exécution, et autorise plusieurs services de découverte appliquant des politiques différentes en matière de confiance, de classement et d’accès, au lieu d’imposer un catalogue central. Ces travaux relient les preuves d’identité vérifiables à la découverte sans créer de répertoire universel d’agents.
Projets de spécifications et limites de sécurité
Le comité technique de pilotage initial compte cinq membres votants : Scott Courtney, Keith Perry et Connor Snitker, de GoDaddy ; Ken Huang, de DistributedApps.AI ; et Michael Kantor, de Hashgraph Online. Il définit les orientations techniques, tandis que les responsables de la maintenance des dépôts examinent les modifications, gèrent les versions et traitent les signalements de sécurité. Bien que le communiqué de lancement présente la spécification comme étant formalisée, la documentation du projet qualifie les spécifications publiées de projets en cours de développement ; ANS-6 porte la mention DRAFT v1.0, la version 0.2.0 et la date du 3 novembre 2026.
Le modèle de sécurité établit l’identité, et non les autorisations. L’autorisation, la délégation au fil d’une chaîne d’appels et l’évaluation du niveau de confiance ne relèvent pas d’ANS-6 ; il revient donc à chaque application de décider de ce qu’un agent authentifié peut faire. Les condensats scellés des métadonnées n’attestent pas du code exécuté sur une machine distante et ne garantissent pas le comportement de l’agent. Les clients ont toujours besoin de clés de journal fiables, d’une vérification correcte des signatures et des preuves, de contrôles de fraîcheur et d’une politique en cas d’échec. Les badges publics, les reçus et les jetons d’état peuvent également être rejoués si le vérificateur omet de vérifier la possession.
Un reçu atteste l’historique du journal, et non la validité actuelle, et peut continuer à servir à la vérification après la révocation d’un agent ; il doit donc être associé à une vérification de son statut actuel. Le degré de maturité des intégrations varie également. Les travaux sur NVIDIA OpenShell sont présentés comme un aperçu de recherche, et ses vérifications de l’enregistrement des destinations ne mettent pas en œuvre la liaison d’ANS-6 au certificat TLS réel du pair.
ANS dispose désormais d’une gouvernance assurée par une fondation, de projets publiés et d’implémentations de référence. Sa valeur pratique en matière de sécurité dépend de la capacité des déploiements à vérifier conjointement l’identité, le statut actuel et la possession de la clé, tout en excluant de l’attestation d’identité l’autorisation et les jugements sur le comportement de l’agent.












