Les gestionnaires de mots de passe d'entreprise deviennent discrètement des courtiers d'identité pour les agents d'IA

1Password a lancé Agentic AI Security au sein de sa plateforme Extended Access Management le 22 avril 2025, conçue spécifiquement pour gérer les identités, les identifiants et les accès des agents d'IA autonomes, et non des employés humains. Trois semaines plus tard, Microsoft a intégré les agents d'IA à sa propre pile d'identité avec un aperçu public d'Entra Agent ID destiné aux agents créés dans Azure AI Foundry et Copilot Studio, attribuant à chacun un identifiant unique au sein du tenant. Aucune des deux entreprises ne réagissait à une hypothèse. Le rapport Identity Security Landscape 2025 de CyberArk, publié ce même mois d'avril, a recensé 82 identités machines pour chaque identité humaine dans l'entreprise moyenne, et une grande partie des plus récentes sont des agents d'IA disposant d'un accès permanent aux outils internes.

Ce changement compte parce que les outils d'identité et de gestion des identifiants n'ont jamais été conçus autour des exigences réelles des agents d'IA. Un gestionnaire de mots de passe suppose une personne, une session de connexion, une réauthentification manuelle occasionnelle et un nombre prévisible de comptes par personne. Un agent d'IA peut ouvrir une nouvelle session toutes les quelques secondes, appeler une dizaine d'API dans une seule tâche, et se multiplier en instances parallèles qui ont toutes besoin d'identifiants en même temps. Adapter l'infrastructure d'identité humaine à ce schéma est désormais une véritable catégorie de produits, pas un sujet de recherche.

Ce qui est réellement commercialisé

L'approche de 1Password consiste à donner aux agents des identités propres, afin qu'ils cessent de partager ou d'imiter des comptes humains, un problème plus courant qu'il n'y paraît : dans de nombreux déploiements d'agents précoces, on confiait simplement à l'agent une copie des identifiants d'un employé. À la place, 1Password propose un kit de développement logiciel (SDK) permettant aux équipes d'ingénierie d'émettre par programmation des clés API à portée limitée pour un agent, afin que celui-ci ne reçoive que le secret précis nécessaire à une tâche donnée, et non l'intégralité du coffre-fort d'une personne. Une fonctionnalité distincte, Secure Agentic Autofill, en accès anticipé depuis le 8 octobre 2025 via une intégration avec Browserbase, permet à un agent de se connecter à un service web sans que l'identifiant ne soit jamais exposé au contexte de l'agent lui-même : le remplissage automatique se produit au niveau du navigateur, invisible pour le modèle.

Microsoft a adopté un point d'entrée différent avec Entra Agent ID : unifier l'identité des agents et des humains sous une seule console d'administration plutôt que de construire un système parallèle. Depuis son aperçu de mai 2025, Microsoft a ajouté des couches de protection spécifiques aux agents qui n'ont pas d'équivalent dans l'identité humaine : défense contre l'injection d'instructions (prompt injection), blocage de l'accès non autorisé aux connexions Model Context Protocol (MCP), et détection de l'IA fantôme (shadow AI) pour repérer les agents opérant hors de la visibilité de l'informatique. Cet aperçu est désormais aussi relié à Agent 365, le tableau de bord de gestion des agents plus large de Microsoft, traitant l'identité de l'agent comme une entrée parmi d'autres dans un plan de contrôle opérationnel plus vaste, et non comme une fonctionnalité de coffre-fort isolée.

Pourquoi cela diffère de la sécurisation des connexions humaines

La sécurité de l'identité humaine fonctionne selon des boucles de rétroaction relativement lentes : intégration, revues d'accès périodiques, départ lors d'un changement d'emploi. L'identité d'un agent, elle, doit fonctionner selon des boucles mesurées en secondes. Un agent qui doit lire un enregistrement CRM, écrire dans un système de tickets et appeler une API de facturation en une seule tâche a besoin que les trois identifiants à portée limitée soient émis, utilisés et, idéalement, expirés avant le début de la tâche suivante, et non conservés indéfiniment dans un coffre-fort comme les identifiants enregistrés d'un humain. C'est un cycle de vie fondamentalement différent, ce qui explique pourquoi les fournisseurs construisent des parcours d'émission et de révocation distincts pour les agents plutôt que de simplement ajouter une case «agent» à un type de compte humain existant.

L'exigence d'audit diffère aussi par nature, pas seulement par volume. Lorsqu'un employé humain fait quelque chose d'inhabituel avec un identifiant, il y a une personne à interroger. Lorsqu'un agent le fait, la question devient de savoir si la définition de la tâche de l'agent, la portée de son identifiant, ou une instruction injectée est à l'origine du comportement, ce qui explique pourquoi Microsoft a intégré la défense contre l'injection d'instructions directement dans son produit d'identité plutôt que de la laisser à une couche de sécurité distincte.

Ce que cela signifie maintenant pour les équipes sécurité et informatique

• Vérifiez ce qui est réellement codé en dur. Avant d'évaluer la proposition d'un fournisseur d'identité pour agents, déterminez combien de vos déploiements d'agents actuels utilisent des secrets codés en dur ou des identifiants humains empruntés ; le marketing de 1Password cible précisément cette pratique parce qu'elle reste très répandue, et c'est le point le plus simple à corriger quel que soit le fournisseur choisi.
• Exigez une émission à portée limitée, pas seulement un tableau de bord. Une vue unifiée des identités des agents (ce que mettent en avant Entra Agent ID et des outils similaires) est utile pour la visibilité, mais la capacité la plus difficile à obtenir est de savoir si la plateforme peut émettre un identifiant limité à une tâche et l'expirer automatiquement. Demandez aux fournisseurs de démontrer précisément ce flux, pas seulement la console d'administration.
• Considérez le ratio de 82 pour 1 comme un plancher, pas un plafond. Le chiffre de CyberArk a été mesuré sur l'ensemble des identités machines, incluant des comptes de service et des clés API antérieurs à la vague actuelle d'agents. À mesure que les déploiements d'agents se multiplient dans votre organisation, attendez-vous à ce que le ratio d'identités non humaines par rapport aux humaines croisse plus vite que ce que votre processus actuel de revue des accès a été conçu pour gérer.
• Distinguez «lʼagent peut se connecter» de «lʼagent devrait se connecter sans supervision». Des fonctionnalités comme Secure Agentic Autofill résolvent le problème d'exposition des identifiants, mais ne répondent pas à la question de gouvernance de savoir quelles tâches un agent devrait pouvoir exécuter sans intervention humaine. Cette décision de politique revient à votre équipe, pas à votre fournisseur d'identité.

La conclusion pratique est que le modèle de coffre-fort lui-même est en train d'être reconstruit sous vos pieds, que vous ayez consciemment adopté ou non un produit d'«identité d'agent d'IA». Si votre organisation fait tourner des agents sur des systèmes de production aujourd'hui, partez du principe que le parcours d'identifiants qu'ils utilisent a été conçu pour un humain, et commencez à le faire migrer vers un accès à portée limitée, auditable et de courte durée avant que votre équipe d'audit, ou un attaquant, ne trouve cette faille en premier.