Agent Name Service de la Linux Foundation : identité des agents IA ancrée dans le DNS et quand l'adopter

L'Agent Name Service (ANS) de la Linux Foundation est un standard ouvert qui attribue aux agents IA des noms versionnés ancrés dans le DNS, des certificats d'identité émis après validation du domaine et des enregistrements dans un journal de transparence public. Pourquoi un responsable IT devrait-il s'y intéresser ? Les agents IA appellent désormais d'autres agents, demandent des données et déclenchent des transactions au-delà des frontières de leur organisation. Personne ne peut encore dire si ANS deviendra le schéma dominant.

Qu'est-ce que l'Agent Name Service et pourquoi est-il hébergé par la Linux Foundation ?

Le 10 novembre 2026, la Linux Foundation a accueilli l'Agent Name Service en tant que standard ouvert pour l'identité de confiance, la vérification et la découverte des agents IA à l'aide de l'infrastructure DNS existante. La spécification complète comprend sept documents couvrant le nommage ancré sur le domaine, l'enregistrement et le versionnage, la publication DNS, l'audit des journaux publics, la surveillance de l'intégrité et l'authentification d'agent à agent. Le comité de pilotage technique du projet la développe désormais de manière ouverte.

Depuis l'annonce de l'intention de lancement en juin 2026, 11 organisations ont contribué au standard ou l'ont adopté, parmi lesquelles Cisco, Cloudflare, DigiCert, GoDaddy, Infoblox, Salesforce et OWASP.

ANS est né chez GoDaddy. L'équipe a choisi de bâtir la découverte des agents sur le DNS, qui selon GoDaddy traite plus de cent millions de requêtes par seconde, et d'établir la confiance grâce à la même PKI que celle qui sécurise chaque connexion HTTPS. La construction réutilise l'infrastructure DNS de GoDaddy ainsi qu'un service de certificats gérant plus de 100 millions de certificats SSL et TLS actifs.

Pour les acheteurs en entreprise, c'est le choix de gouvernance qui compte. Une spécification publique placée sous une fondation neutre offre une base plus solide pour rédiger des politiques. Jim Zemlin, CEO de la Linux Foundation, l'a dit sans détour : les agents IA autonomes effectuent des transactions à travers des systèmes mondiaux, mais ils ne peuvent pas réussir sans identité vérifiable.

Pourquoi l'identité des agents IA est devenue un enjeu de gouvernance IT

La pression se voit déjà au sein des organisations. Une enquête de la Cloud Security Alliance menée auprès de 418 professionnels de l'IT et de la sécurité, commandée par Token Security et publiée en avril 2026, a révélé que 82% des organisations avaient découvert dans leur infrastructure des agents IA dont personne ne connaissait l'existence. La même enquête indique que 65% avaient subi un incident de sécurité lié à un agent au cours des 12 mois précédents. Parmi les organisations ayant connu un tel incident, 61% ont signalé une exposition de données et 35% des pertes financières. Ces deux chiffres sont des proportions des 65% ayant subi un incident, et non de l'ensemble des répondants.

Lisez cette enquête en gardant deux réserves à l'esprit. Elle a été commandée par un éditeur, et elle mesure davantage la visibilité interne que l'identité externe. Elle montre néanmoins que la prolifération des agents est un problème opérationnel actuel, et non hypothétique.

Le volet externe se comprend plus facilement à travers le scénario du brouillon IETF ANS v2. L'agent de paiement d'une entreprise reçoit l'instruction de virer $50,000 à l'agent de facturation d'un fournisseur, et cet agent de facturation présente une URL de site web sécurisée par un certificat TLS. Ce certificat indique à l'agent de paiement que quelqu'un contrôle le domaine. Pour un système sur le point d'envoyer de l'argent de manière autonome, le contrôle d'un domaine est une preuve bien mince.

Comment fonctionne ANS : noms versionnés, certificats validés et journaux de transparence

ANS reprend des mécanismes que connaît déjà toute personne qui exploite une infrastructure web et y ajoute des niveaux de vérification.

Des noms ans:// versionnés

Chaque agent reçoit un nom versionné de type DNS, par exemple ans://v1.0.0.my-agent.example.com. Il se lit de droite à gauche. Le domaine (example.com) rattache l'agent à une organisation, le libellé (my-agent) identifie l'agent et le préfixe (v1.0.0) fixe une version sémantique. Une simple URL n'a aucun équivalent de cette dernière partie. Avec ANS, une modification de l'agent peut se traduire par une modification de son nom.

Le brouillon ANS v2 limite l'ANSName complet à 400 octets, ce qui laisse une marge pour un transport sûr dans les en-têtes HTTP, les champs TLS et les colonnes de bases de données. Vos systèmes existants peuvent stocker et transmettre ces noms sans traitement particulier.

Des certificats d'identité après validation DNS/ACME

Un certificat d'identité ANS n'est émis qu'après une validation de domaine DNS/ACME. Sur le plan opérationnel, rien de nouveau ici. Le piège, sur lequel nous revenons dans les réserves, est que l'identité d'un agent ne peut pas être plus solide que le contrôle du domaine sur lequel elle repose.

Un journal de transparence public

Chaque enregistrement produit également une entrée dans un journal de transparence public, de sorte que n'importe quelle partie peut vérifier de manière indépendante l'identité, les capacités et l'historique d'un agent sans faire confiance à un intermédiaire.

Les niveaux de vérification Bronze, Silver et Gold

Le brouillon ANS v2 définit trois niveaux de vérification, Bronze (PKI), Silver (PKI plus DANE) et Gold (PKI plus DANE plus journal de transparence), afin que les clients puissent choisir un niveau d'assurance adapté au risque de la transaction. DANE lie les informations de certificat aux enregistrements DNS et repose sur DNSSEC. Gardez cette dépendance en tête ; nous y reviendrons.

La colonne de droite est notre recommandation et ne fait pas partie de la spécification. Fixez vos propres seuils.

Comment ANS s'articule avec DNS-AID et AGNTCY Directory

ANS n'est pas le seul projet d'agents fondé sur le DNS à la Linux Foundation. DNS-AID, un projet distinct consacré à la découverte décentralisée d'agents, a été lancé avec comme membres initiaux Cloudflare, CSC, Equinix, GoDaddy, IDC, Indeed, Infoblox, Internet Systems Consortium et WWT.

Les deux projets répondent à des questions différentes. Le brouillon DNS-AID précise que les consommateurs doivent traiter les enregistrements DNS-AID comme un transport vérifiable de métadonnées, et non comme un signal de confiance en soi, et que les jugements de confiance doivent être établis hors bande en combinant ces enregistrements avec des systèmes de réputation, d'attestation ou de politique organisationnelle. ANS est un candidat pour cette couche d'identité. Il fonctionne aux côtés de DNS-AID ; il ne le remplace pas.

Le projet AGNTCY Directory montre pourquoi ANS suscite de l'intérêt. Un epic ouvert dans ce projet suit la vérification des revendications d'identité ans://, en notant que tous les autres schémas exigent que l'éditeur héberge des éléments de clé tels qu'un fichier JWKS, un enregistrement TXT ou un document DID, ce que presque personne ne fait, si bien que rien n'est vérifié. Un enregistrement ANS produit déjà un certificat d'identité, un pointeur DNS et une entrée dans le journal de transparence. Autrement dit, la preuve existe par défaut au lieu de dépendre d'un effort supplémentaire des éditeurs.

Le domaine reste encombré. En juin 2026, The New Stack recensait au moins quatre initiatives fondées sur le DNS, dont DNS-AID porté par Infoblox, et Infoblox soutient désormais aussi ANS. Une proposition concurrente, DNSid, est un Internet-Draft individuel d'un seul auteur, sans adoption par un groupe de travail, et sa version actuelle expire le 31 décembre 2026.

Quand enregistrer vos propres agents : l'échelle Anchor-Version-Tier d'Optijara

Le nom décrit la séquence. Ancrez (Anchor) chaque agent à un domaine que vous conserverez, versionnez-le (Version) au rythme de vos livraisons et attribuez à chaque cas d'usage un niveau de vérification (Tier). Chaque échelon dépend de celui du dessous, l'ordre a donc son importance. Il s'agit d'un cadre de planification, et non d'un compte rendu de résultats clients.

1. Inventorier et classer. Listez chaque agent que vous exploitez et étiquetez-le comme interne uniquement, orienté partenaires, public ou transactionnel. Vu le nombre d'organisations qui découvrent des agents dont elles ignoraient l'existence, attendez-vous à des surprises à cette étape.
2. Commencer par les agents externes et à fort enjeu. Enregistrez d'abord les agents qu'appellent les agents d'autres organisations, ainsi que tout ce qui touche aux paiements, au partage de données ou aux actions contractuelles. Les agents purement internes peuvent attendre, puisque vos contrôles d'identité et d'accès existants les couvrent déjà.
3. Anchor : choisir le domaine de manière délibérée. Utilisez un domaine de marque que vous conserverez pendant des années, et non un domaine de campagne. Traitez l'expiration d'un domaine de marque comme un incident de sécurité, car l'autorité d'enregistrement révoque les enregistrements lorsque la validation du domaine échoue.
4. Version : faire correspondre les noms aux livraisons. Reliez la version sémantique de chaque nom ans:// à votre processus de livraison. Toute modification significative des prompts, des outils, des modèles ou des permissions doit produire une nouvelle version et une nouvelle entrée de journal.
5. Piloter hors production. Exécutez d'abord l'enregistrement et la vérification dans un environnement de test, et lisez la réserve sur la maturité ci-dessous avant qu'une décision de confiance en production ne dépende d'ANS.
6. Tier : définir les niveaux d'assurance et les responsables. Choisissez le niveau cible pour chaque cas d'usage et nommez des responsables pour le renouvellement des certificats, les enregistrements DNS et la surveillance du journal de transparence. Confiez à ces mêmes personnes la responsabilité des secrets détenus par chaque agent. Savoir qui est un agent ne limite en rien ce à quoi il peut accéder, et des approches comme un proxy d'identifiants qui tient les clés API à l'écart des agents IA traitent cette couche distincte.

Utiliser les identités ANS dans les achats et les listes d'autorisation à l'exécution

Dans les achats

ANS donne aux équipes achats un vocabulaire concret pour l'identité des agents. Questions à poser aux fournisseurs :

• Vos agents ont-ils des noms ans://, et quel domaine les ancre ?
• Quel niveau de vérification pouvez-vous prendre en charge aujourd'hui : Bronze, Silver ou Gold ?
• La zone d'ancrage est-elle signée DNSSEC, afin que les vérifications DANE aient un sens ?
• Comment les versions des agents correspondent-elles à vos livraisons produit et à vos journaux de modifications ?
• Qui, dans votre organisation, est responsable du renouvellement du domaine et de l'accès au registraire ?

Les contrats devraient exiger un préavis avant tout changement de version d'agent modifiant ses capacités, et avant tout changement de domaine d'ancrage ou de registraire. Ce sont ces événements qui modifient ce que vous avez réellement approuvé.

Une matrice de décision fournisseurs

Pour classer les réponses des fournisseurs, nous utilisons une matrice simple fondée sur trois signaux. Comme la correspondance des niveaux, elle reflète notre point de vue et ne fait pas partie de la spécification.

Un fournisseur situé dans la première colonne pour les trois signaux est candidat aux flux de paiement ou de données réglementées. Toute réponse dans la colonne de droite doit cantonner les agents de ce fournisseur à des interactions à faible risque de niveau Bronze jusqu'à ce qu'elle évolue. Des réponses mitigées orientent généralement vers un pilote assorti de critères de sortie clairs.

À l'exécution

À l'exécution, l'échelon Tier devient une règle d'application. Autorisez les agents par leur ANSName versionné complet assorti de vérifications de certificat, jamais par la seule URL ou le seul domaine. Si vous ignorez la version, un agent sensiblement modifié hérite de l'approbation accordée à une version antérieure. Exigez le niveau Gold, y compris la vérification du journal de transparence, pour les actions à haut risque comme les paiements, et n'acceptez le niveau Bronze que pour les recherches à faible risque. Cela suit l'intention même du brouillon, selon laquelle les clients adaptent l'assurance au risque de la transaction.

Une vérification Gold n'arrêtera pas un agent correctement identifié qui se met à mal se comporter. Associez vos exigences Gold à un moyen éprouvé d'arrêter rapidement un agent, et consultez ce qu'un kill switch IA arrête et ce dont votre runbook d'agents a encore besoin.

Combinez les vérifications ANS avec vos propres contrôles de politique et de réputation. Le principe hors bande du brouillon DNS-AID s'applique ici aussi : la preuve d'identité alimente une décision, elle n'est pas la décision. Surveillez les journaux de transparence pour repérer des enregistrements inattendus sous vos propres domaines, et guettez les enregistrements sur des domaines qui ressemblent aux vôtres, car quiconque détient un domaine sosie peut y enregistrer un agent entièrement vérifié.

Si votre préoccupation porte sur les assistants IA qui accèdent à vos propres propriétés web, et non sur les appels d'agent à agent, vous avez besoin d'un autre ensemble de contrôles ; consultez notre guide pour autoriser, limiter ou bloquer les assistants IA sur votre site.

Réserves et critiques à peser avant de vous engager

Une confiance héritée du DNS

L'analyse de la Cloud Security Alliance identifie DNSSEC comme la dépendance sur laquelle ANS s'appuie le plus pour rendre les liaisons nom-clé infalsifiables sans laisser de trace. Deux décennies après son introduction, DNSSEC est validé sur environ un tiers des chemins de résolution, mais seules quelque sept pour cent des zones sont signées cryptographiquement. L'assurance Silver et Gold dépend donc de la réalisation par la contrepartie d'un travail DNSSEC que de nombreuses organisations n'ont jamais priorisé. Vérifiez vos propres zones avant de promettre à des partenaires un niveau que vous ne pouvez pas fournir.

Maturité

Lors de l'examen de la Cloud Security Alliance en juin 2026, le projet était en pré-1.0 et son implémentation de référence utilisait une cryptographie factice à des fins de démonstration plutôt qu'une PKI de niveau production. Une cryptographie factice convient pour apprendre. Elle ne convient pas quand il s'agit d'argent. La gouvernance de la fondation peut accélérer la consolidation, mais vérifiez le statut actuel directement dans l'organisation GitHub du projet au lieu de le supposer.

Les intérêts des registraires

Un commentaire publié dans CircleID pose le débat sans détour : chaque agent a besoin d'un nom, et l'industrie des noms de domaine aimerait le lui vendre. C'est une grille de lecture légitime. Les registraires et les autorités de certification tirent effectivement profit d'un monde où chaque agent a besoin d'un domaine et d'un certificat. Rien de cela ne rend la conception mauvaise. Cela signifie en revanche que vous devez juger les coûts d'enregistrement, les conditions de renouvellement et la portabilité sur pièces, sans supposer qu'un registraire donné soit la seule voie possible.

Domaines sosies et usurpateurs vérifiés

La vérification lie un agent à un domaine. Elle ne peut pas vous dire que ce domaine appartient bien à la partie que vous croyez. ANS ne résout pas le typosquatting, et un agent entièrement vérifié sur un domaine sosie reste un usurpateur. La surveillance de la marque et les contrôles d'intégration des contreparties restent de votre ressort.

Le point de vue équilibré

Les points positifs sont réels. La spécification est publique et répartie sur sept documents. Onze organisations issues des secteurs du réseau, de la sécurité, des certificats et du SaaS y ont contribué ou l'ont adoptée. À notre avis, ce soutien ajouté à une gouvernance neutre donne à ANS une position de départ plus solide que les propositions portées par un seul éditeur ou un seul auteur. Comme plusieurs schémas fondés sur le DNS sont encore en concurrence, placez les vérifications d'identité des agents derrière une couche d'abstraction interne lorsque cela coûte peu, afin qu'un changement de schéma gagnant ne vous oblige pas à réécrire chaque intégration. L'argument plaide pour une adoption progressive, pas pour l'abstention.