Les agents IA ne sont plus seulement des démonstrations techniques capables de résumer des documents ou d’automatiser quelques tâches. Ils commencent à agir dans le monde réel : rechercher des produits, composer des paniers, réserver des services, lancer des transactions et interagir avec des plateformes d’entreprise.
Cette évolution pose une question simple, mais décisive : qui est responsable lorsqu’un agent IA agit sur Internet ? Aujourd’hui, beaucoup d’agents circulent encore avec une identité limitée, souvent réduite à une adresse IP, un compte utilisateur ou des mécanismes internes propres à une plateforme. Cela peut suffire dans un environnement fermé. Cela devient beaucoup plus fragile lorsque ces agents traversent des entreprises, des clouds, des places de marché et des systèmes critiques.
C’est précisément le problème que veut attaquer DNSid, un projet porté par Innovation Labs, basé à Bellevue dans l’État de Washington. Son ambition : créer un cadre ouvert permettant d’ancrer une identité durable des agents IA dans l’infrastructure existante du Domain Name System, plus connu sous le nom de DNS.
Le projet gagne en visibilité avec l’arrivée de Vint Cerf, figure majeure de l’histoire d’Internet et co-concepteur des protocoles TCP/IP. Son implication donne un poids particulier à une initiative qui touche à l’un des sujets les plus sensibles de l’IA agentique : l’identité, l’interopérabilité et la responsabilité.
Pourquoi l’identité des agents IA devient un sujet urgent
Les agents IA sont en train de passer d’outils d’assistance à de véritables acteurs économiques automatisés. Ils peuvent déjà aider à réserver, acheter, classer, négocier, déclencher des workflows ou dialoguer avec d’autres systèmes. La tendance s’accélère.
DoorDash a récemment ouvert une bêta limitée de dd-cli, un outil en ligne de commande permettant à des développeurs, et potentiellement à des agents IA, de rechercher des magasins, construire des paniers et passer de vraies commandes alimentaires. Dans un cas d’usage très concret, un utilisateur pourrait demander à son agent de commander une pizza, l’agent utilisant ensuite les moyens de paiement et les comptes associés.
Adobe, de son côté, prépare des fonctionnalités de commerce agentique pour Adobe Commerce, une plateforme utilisée par de grandes marques, dont Coca-Cola et la Major League Baseball. L’idée est claire : les agents IA ne se contenteront pas de recommander des produits, ils participeront de plus en plus directement à l’acte d’achat.
Mais plus ces agents gagnent en autonomie, plus une faiblesse structurelle devient visible : il n’existe pas encore de couche universelle d’identité durable permettant de savoir clairement quelle organisation, quel service ou quel compte se trouve derrière un agent donné.
Le problème : un agent peut agir, mais rester difficile à attribuer
Dans une entreprise, les équipes savent généralement quels agents IA sont déployés dans leurs propres environnements. Les contrôles internes, les permissions, les journaux d’activité et les politiques de sécurité peuvent fournir un cadre relativement maîtrisé.
La difficulté apparaît lorsque l’agent sort de ce périmètre. Un agent peut interagir avec un fournisseur, une API externe, une marketplace, un service cloud, un partenaire ou un système public. Dans ce contexte, l’organisation qui reçoit une requête doit pouvoir répondre à plusieurs questions :
- Quel agent est en train d’agir ?
- Quelle organisation en est responsable ?
- Est-ce un agent légitime ou un comportement suspect ?
- Peut-on bloquer, révoquer ou isoler cet agent en cas d’incident ?
- Qui doit rendre des comptes si une action non autorisée est effectuée ?
Sans mécanisme commun, la réponse est souvent imparfaite. Une adresse IP peut être partagée, masquée ou temporaire. Un jeton d’API peut être compromis. Un identifiant de plateforme peut ne pas être reconnu ailleurs. Or, dans un Internet peuplé d’agents autonomes, cette zone grise devient un risque de sécurité, de conformité et de responsabilité juridique.
DNSid : utiliser le DNS comme socle d’identité
DNSid propose une approche pragmatique : ne pas inventer une infrastructure de confiance entièrement nouvelle, mais s’appuyer sur le DNS, l’un des systèmes fondamentaux qui permet déjà à Internet de fonctionner à l’échelle mondiale.
Le DNS est la technologie qui permet à un navigateur de trouver un site web sans que l’utilisateur ait à retenir une longue adresse IP. Il est distribué, largement adopté, reconnu par des organisations indépendantes et conçu pour fonctionner au-delà des frontières d’une seule entreprise.
Selon Innovation Labs, cette caractéristique en fait une base intéressante pour l’identité des agents IA. L’objectif serait de permettre à des systèmes différents de reconnaître un même identifiant d’agent ou d’organisation, même sans relation directe préalable entre eux.
En juin, Innovation Labs a soumis un Internet-Draft à l’Internet Engineering Task Force, l’IETF, l’organisme qui participe depuis des décennies à la normalisation des grands protocoles d’Internet. Le signal est important : DNSid se positionne comme un potentiel standard ouvert, et non comme une technologie propriétaire contrôlée par un seul acteur.
Le rôle de Vint Cerf : un symbole fort pour l’Internet des agents
L’arrivée de Vint Cerf dans le projet n’est pas anodine. Cerf est l’un des architectes historiques de l’Internet moderne. Avec ses travaux sur TCP/IP, il a contribué à bâtir une partie essentielle de l’infrastructure qui permet aux réseaux de communiquer entre eux.
Son implication suggère que l’identité des agents IA n’est pas seulement une fonctionnalité de cybersécurité parmi d’autres, mais un problème d’architecture fondamentale. À mesure que les agents deviennent capables d’agir au nom d’utilisateurs, d’entreprises ou d’administrations, Internet doit être capable de distinguer plus clairement les acteurs automatisés, leurs propriétaires et leurs responsabilités.
Vint Cerf a souligné que l’Internet a toujours progressé en traitant les défis d’infrastructure avant qu’ils ne deviennent des blocages systémiques. Les agents IA pourraient représenter une nouvelle étape de cette évolution, avec des exigences fortes en matière d’identité, d’autorité, d’interopérabilité et de responsabilité.
Identité ne veut pas dire confiance
Un point clé mérite d’être clarifié : DNSid ne vise pas à dire si un agent IA est digne de confiance. Le projet cherche plutôt à établir qui est responsable de cet agent.
La nuance est essentielle. Une identité durable permet de savoir à qui rattacher une action. Elle ne prouve pas automatiquement que l’agent est sûr, autorisé ou conforme. Pour utiliser une analogie simple, DNSid fonctionnerait davantage comme une plaque d’immatriculation que comme une enquête de moralité.
Une plaque permet d’identifier le véhicule et son propriétaire. Elle ne dit pas si le conducteur respecte le code de la route à chaque instant. De la même manière, une identité d’agent IA permettrait à une entreprise, à une équipe sécurité ou à un régulateur de savoir vers qui remonter en cas de problème, mais les décisions de confiance resteraient propres à chaque contexte.
- Une entreprise pourrait appliquer ses propres règles d’accès.
- Une équipe cybersécurité pourrait analyser le risque associé à un agent.
- Un régulateur pourrait vérifier le respect d’obligations sectorielles.
- Un tribunal pourrait trancher une question de responsabilité.
Autrement dit, DNSid serait une couche de fondation. Le contrôle d’accès, l’autorisation et la confiance resteraient gérés par les institutions, plateformes et systèmes concernés.
Comment une identité durable peut limiter les incidents
Aucune technologie ne peut garantir qu’un incident lié à l’IA n’arrivera jamais. Un agent peut être mal configuré, compromis, trop permissif ou utilisé par un acteur malveillant. En revanche, une couche d’identité durable peut éviter que les organisations ne répondent à l’aveugle.
Si un agent provoque un incident, surcharge une API, réalise une action non autorisée ou tente d’accéder à des données sensibles, l’organisation touchée doit pouvoir agir vite. L’identification est alors le point de départ de plusieurs mesures concrètes :
- Isoler l’agent pour empêcher la propagation de l’incident.
- Révoquer ses accès ou refuser ses futures requêtes.
- Informer l’organisation responsable afin qu’elle corrige ou désactive le système.
- Enquêter sur la chaîne d’événements ayant conduit à l’incident.
- Établir des responsabilités en cas de dommage, de violation contractuelle ou de non-conformité.
Dans un environnement où des millions d’agents peuvent circuler et interagir avec des services tiers, cette capacité à attribuer les actions devient une condition de confiance opérationnelle.
Et si les acteurs malveillants refusent d’adopter le standard ?
Un standard ouvert ne peut pas forcer tous les acteurs à participer. Des cybercriminels, des spammeurs ou des opérateurs douteux pourront toujours tenter de contourner les mécanismes d’identification.
Mais c’est précisément là que l’adoption large d’un standard peut créer un signal utile. Si la plupart des agents légitimes peuvent prouver leur rattachement à une organisation identifiable, alors l’absence d’identité devient elle-même un indicateur de risque.
À terme, une plateforme pourrait décider qu’un agent non identifiable ne peut pas accéder à certaines API sensibles, passer commande, déclencher un paiement ou interagir avec une infrastructure critique. L’absence d’identité ne serait plus invisible : elle deviendrait un critère de filtrage.
Pourquoi les développeurs et les entreprises doivent s’y intéresser
Pour les développeurs, le principal intérêt d’un standard comme DNSid serait d’éviter la fragmentation. Sans cadre commun, chaque plateforme IA, chaque cloud et chaque fournisseur d’API pourrait imposer sa propre manière d’identifier les agents. Résultat : davantage d’intégrations spécifiques, de maintenance et de complexité.
Un standard commun permettrait de construire une fois, puis d’interopérer plus facilement avec plusieurs environnements. C’est l’un des arguments forts d’Innovation Labs : les meilleurs standards finissent par disparaître en arrière-plan, parce qu’ils deviennent une évidence technique.
Pour les entreprises, l’enjeu est plus stratégique. L’IA agentique promet des gains de productivité importants, mais elle ne pourra pas se déployer largement si les organisations ne savent pas qui agit dans leurs systèmes. L’identité devient donc un prérequis pour passer d’expérimentations limitées à des usages industriels.
Les grands laboratoires d’IA seront déterminants
La réussite de DNSid dépendra largement de son adoption. Les grands laboratoires d’IA, les fournisseurs de cloud, les plateformes de commerce, les éditeurs logiciels et les acteurs de cybersécurité auront un rôle central.
Innovation Labs défend toutefois une idée importante : aucune entreprise ne devrait définir seule la responsabilité des agents IA pour tout l’écosystème. Si l’Internet a pu se développer à grande échelle, c’est notamment grâce à des standards ouverts que chacun pouvait implémenter.
Cette logique pourrait s’appliquer à l’IA. Une couche d’identité trop propriétaire risquerait de créer des silos, des dépendances commerciales et des incompatibilités. À l’inverse, un standard ouvert pourrait faciliter l’interopérabilité entre agents, plateformes et organisations.
Ce que DNSid pourrait changer concrètement
Si DNSid ou un standard similaire s’impose, plusieurs évolutions pourraient apparaître dans les années à venir.
- Les agents IA professionnels pourraient avoir des identifiants vérifiables, associés à un domaine ou à une organisation responsable.
- Les API pourraient refuser les agents anonymes pour certaines opérations sensibles.
- Les entreprises pourraient intégrer l’identité des agents dans leurs politiques Zero Trust.
- Les régulateurs pourraient s’appuyer sur ces identifiants pour enquêter sur des incidents ou vérifier des obligations.
- Les utilisateurs pourraient mieux comprendre qui agit en leur nom, notamment dans les achats, réservations ou démarches automatisées.
Le changement ne serait pas nécessairement visible pour le grand public. Comme le DNS lui-même, cette couche pourrait fonctionner discrètement. Mais elle deviendrait essentielle pour permettre aux agents IA de se déplacer dans un Internet plus sécurisé et plus responsable.
Un chantier technique, mais aussi politique
L’identité des agents IA ne relève pas seulement de la technique. Elle touche à la gouvernance, à la responsabilité, à la souveraineté numérique et à la concurrence entre plateformes.
Qui peut créer une identité d’agent ? Comment éviter les usurpations ? Comment gérer la révocation ? Quels journaux doivent être conservés ? Quel niveau de transparence imposer aux agents qui interagissent avec des humains ? Comment concilier traçabilité et protection des données ?
DNSid ne répondra pas seul à toutes ces questions. Mais il pourrait fournir une brique de base sur laquelle les entreprises, les développeurs, les autorités et les organismes de normalisation pourront construire.
Conclusion : les agents IA auront besoin d’une identité pour passer à l’échelle
L’arrivée de Vint Cerf dans le projet DNSid montre que l’identité des agents IA devient un sujet d’infrastructure, pas seulement une option de sécurité. À mesure que ces agents achètent, réservent, exécutent des tâches et interagissent avec des systèmes externes, l’anonymat par défaut devient difficile à soutenir.
La promesse de DNSid est simple : donner aux agents IA une identité durable, rattachée à une entité responsable, en s’appuyant sur l’infrastructure DNS déjà utilisée à l’échelle mondiale. Ce n’est pas une garantie de confiance absolue, ni un mécanisme d’autorisation universel. C’est une couche d’attribution.
Si l’écosystème l’adopte, ou si une approche comparable émerge comme standard, l’Internet des agents pourrait devenir plus lisible, plus contrôlable et plus sûr. Sans cette couche, les entreprises risquent de multiplier les agents autonomes sans toujours savoir qui agit, qui répond, et qui doit assumer les conséquences.
Source : Forbes.