9 septembre 2026
Accorder à un agent IA l’accès via le compte d’un employé peut sembler être le choix le plus pragmatique. Le compte est déjà authentifié, il dispose déjà des autorisations nécessaires, et le projet peut avancer sans passer par un nouvel examen de sécurité fastidieux. Le problème apparaît dès que l’agent commence à agir. À partir de là, la frontière entre la personne et le logiciel s’estompe. Le journal d’audit indique qu’un employé a ouvert un fichier, modifié un enregistrement ou approuvé une transaction, alors qu’en réalité, c’est un agent qui a effectué cette tâche. La responsabilité devient aléatoire, et l’agent dispose discrètement d’un accès bien plus étendu que ne l’exige sa mission.
Le « Hype Cycle™ 2026 de Gartner® pour l’identité numérique » définit cette catégorie comme suit : « L’identité des agents IA est la représentation numérique unique des agents IA au sein d’une organisation. La mise en place et la gestion de l’identité des agents IA, y compris les assistants et les chatbots, permettent aux systèmes de gestion des identités et des accès (IAM) d’attribuer des identifiants uniques, de délivrer des identifiants ciblés pour l’accès aux ressources (par exemple, les API, les données et les services), et d’établir une responsabilité humaine claire ainsi que des pistes d’audit à travers l’ensemble des systèmes de l’entreprise. »
Cette définition fixe un seuil clair, et la plupart des premiers déploiements d'IA en sont bien loin. C'est dans l'écart entre le fait de disposer d'un agent et celui de lui attribuer une identité que réside le risque.
Les identifiants empruntés et la sécurité des comptes de service créent un angle mort
Les premiers projets d’IA ont tendance à fonctionner avec les accès déjà disponibles. Un assistant interne hérite des autorisations de l’employé qui l’utilise. Un workflow transite par un compte de service partagé. Un développeur connecte un agent à une API à l’aide d’une clé à durée de vie prolongée. Chaque raccourci fonctionne, mais chacun d’entre eux présente les mêmes faiblesses. L’agent se voit souvent attribuer toutes les autorisations dont dispose l’employé alors qu’il n’a besoin d’accéder qu’à un seul système. L'activité humaine et celle de l'agent se confondent. Les équipes de sécurité peuvent ne disposer d'aucun moyen fiable de savoir quand un agent est en cours d'exécution ou quelles transactions il a effectuées.
C'est pourquoi la sécurité des comptes de service est devenue un problème urgent, et non plus une simple question d'organisation interne. Un compte de service partagé n'a jamais été conçu pour représenter un acteur autonome prenant ses propres décisions à la vitesse d'une machine, et une clé API statique ne fournit aucune information sur l'identité de la personne ayant autorisé l'opération ni sur la raison de cette autorisation.
L'utilisation d'identifiants empruntés porte également atteinte à la non-répudiation. Lorsqu'une personne et un agent partagent une même identité, l'organisation ne peut pas prouver lequel des deux a effectué une action donnée. Selon le rapport : « La pratique dangereuse consistant à déployer des agents IA comme mandataires opérant avec les identifiants d'accès d'un humain enfreint les exigences en matière d'audit, de traçabilité et de non-répudiation, ce qui augmente considérablement le risque d'octroi de droits excessifs, ainsi que l'impact de la compromission des identifiants et de la prise de contrôle des comptes. »
Ce qu'une identité distincte change
Une identité dédiée confère à l’agent son propre enregistrement dans l’environnement IAM, avec un propriétaire désigné, un objectif défini et un ensemble d’autorisations délibérément restreint. Elle peut être désactivée sans perturber l’employé ou l’équipe qui l’utilise. Cette séparation rend possible un véritable contrôle. L’authentification de l’agent IA devient un événement distinct que vous pouvez observer et analyser, plutôt qu’un élément dissimulé au sein d’une session humaine. L’agent peut se voir attribuer des identifiants à durée de vie limitée plutôt qu’un mot de passe permanent ou une clé API. Son accès peut être restreint à une application, une tâche ou une transaction spécifique. Son activité peut être examinée selon ses propres critères, indépendamment de celles d’un utilisateur humain. La propriété peut être réattribuée à mesure que son rôle évolue, et les autorisations peuvent expirer dès la fin de la tâche.
Cela correspond bien davantage au fonctionnement prévu du modèle « Zero Trust », dans lequel l’accès dépend du contexte et des besoins du moment, plutôt que du simple fait qu’une identité ait été authentifiée à un moment antérieur.
Les agents IA ont rarement besoin d’un accès permanent
L'accès des utilisateurs est généralement lié à leur fonction. Une personne travaillant dans le service financier a besoin d'un accès permanent à un ensemble de systèmes financiers, car ses responsabilités sont permanentes. Ce n'est généralement pas le cas d'un agent. Celui-ci peut avoir besoin uniquement de récupérer une seule facture, de la faire correspondre à un bon de commande et de renvoyer le résultat. Il serait injustifiable de lui accorder l'ensemble des droits d'accès dont dispose un employé.
C'est le cas des identifiants éphémères. Alors qu'un compte humain conserve un mot de passe pendant des mois, un agent peut se voir attribuer un identifiant valable uniquement pour la durée d'une tâche et qui expire dès que celle-ci est terminée. Il ne reste ainsi aucune trace susceptible d'être découverte par un pirate.
La gestion des accès aux charges de travail répond à ce défi en remplaçant les identifiants statiques et les autorisations permanentes par un accès dynamique et contextuel. Le rapport la décrit ainsi : « La gestion des accès aux charges de travail, qui s’inscrit dans le cadre d’un programme global d’IAM (gestion des identités et des accès) au niveau des machines, sécurise l’univers en pleine expansion des charges de travail — qui comprend les agents d’IA, les applications, les conteneurs et les microservices — en appliquant le principe du moindre privilège lors de l’exécution, et en remplaçant les identifiants statiques par des contrôles dynamiques et contextuels. La gestion des accès aux charges de travail élimine les autorisations permanentes, réduit les surfaces d’attaque de machine à machine et comble le angle mort critique qui sape la plupart des stratégies « zero trust». »
L’identité à elle seule ne suffit pas à expliquer l’intention
Le fait qu’un agent agisse en tant qu’entité distincte ne dit rien sur ce qu’il cherche à accomplir. Cette distinction prend toute son importance dès qu’un agent reçoit une instruction générale telle que « organise mon voyage d’affaires » ou « résous le problème lié au compte de ce client ». L’agent peut interpréter la demande d’une manière que l’utilisateur n’avait pas prévue, et il peut être détourné de son objectif par l’injection de messages ou de données corrompues.
C'est là que l'authentification et l'autorisation se distinguent. L'autorisation d'un agent IA doit répondre à une question à laquelle une simple connexion ne peut pas répondre : cette action spécifique s'inscrit-elle dans le cadre de ce que la personne a réellement demandé ?
Le rapport décrit un autre profil d’innovation qui aborde précisément cette question : « Le contrôle d’accès basé sur l’intention est un cadre d’autorisation émergent qui remplace les autorisations générales et permanentes ; il est actuellement destiné à l’IA agentique, mais offre un large champ d’application. Le contrôle d’accès basé sur l’intention accorde l’accès aux ressources back-end en fonction de l’intention capturée ou déduite des utilisateurs interagissant avec un agent, et évalue les actions envisagées par l’agent à l’aune de cette intention.»
Les chargés de clientèle font monter les enchères
Les organisations doivent également se préparer à faire face à des agents qu’elles ne gèrent pas du tout. D’ici peu, les clients utiliseront leurs propres agents pour effectuer des achats, mettre à jour leurs comptes, envoyer des formulaires et contacter les équipes de service. L’entreprise devra déterminer qui est le client, si l’agent est réellement autorisé à agir en son nom, et ce que le client lui a précisément permis de faire. Le rapport met en avant « les solutions IAM (gestion des identités et des accès) destinées aux clients, permettant de gérer les identités des agents IA dans les contextes en contact avec la clientèle, où les clients envoient leurs agents IA interagir avec les entreprises».
Nous pensons que c’est là que le défi se complique. Il ne suffit pas de détecter si le trafic provient d’un bot. Les organisations ont besoin d’un moyen fiable de relier trois éléments entre eux : une personne réelle, l’agent agissant en son nom et l’autorisation spécifique que cette personne a accordée. Ce lien ne tient que si vous pouvez d’abord prouver qu’un véritable être humain est présent et qu’il est bien celui qu’il prétend être. Si ce point d’ancrage est correctement établi, l’autorité de l’agent remonte à un individu vérifié plutôt qu’à un identifiant emprunté.
Nous avons examiné comment cette délégation devrait fonctionner concrètement dans un article distinct consacré à l'autorisation humaine vérifiée dans le domaine de l'IA agentique.
Commencez par faire la distinction entre les personnes et les agents
Les agents ne doivent pas être des extensions invisibles du compte d’un employé. Il faut attribuer à chacun d’entre eux une identité propre, désigner un responsable, restreindre strictement ses autorisations, suivre ses activités et lui retirer ses droits d’accès une fois sa mission terminée. Lorsqu’elle est gérée correctement, il s’agit d’une gestion du cycle de vie des agents IA plutôt que d’une simple configuration ponctuelle : les agents sont créés, évalués, réaffectés et retirés, et c’est la gouvernance des agents IA qui garantit l’intégrité de ce cycle à mesure que leur nombre augmente.
Ces étapes demandent un certain effort au début d'un projet, mais elles permettent d'éviter un problème bien plus grave par la suite : des milliers d'agents autonomes fonctionnant avec des identifiants qui n'ont été conçus que pour des personnes.
Gartner, « Hype Cycle for Digital Identity », 2026, Zachary Smith, Nayara Sangiorgio, 6 juillet 2026.
« Gartner » et « Hype Cycle » sont des marques déposées de Gartner, Inc. et/ou de ses filiales.
Gartner ne cautionne aucune entreprise, aucun fournisseur, aucun produit ni aucun service mentionné dans ses publications, et ne conseille pas aux utilisateurs de technologies de choisir exclusivement les fournisseurs ayant obtenu les meilleures notes ou d’autres distinctions. Les publications de Gartner reflètent les opinions de son équipe d’analyse des marchés et des technologies et ne doivent pas être interprétées comme des déclarations de fait. Gartner décline toute garantie, expresse ou implicite, concernant cette publication, y compris toute garantie de qualité marchande ou d’adéquation à un usage particulier.
Prochain épisode de la série : pourquoi la visibilité de l'identité revêt une telle importance lorsque les humains, les machines et les agents d'IA interagissent tous au sein d'un même environnement.
Questions fréquemment posées
Les agents d'IA devraient-ils disposer de leur propre identité et de leur propre système d'autorisations ?
Oui. Un agent fonctionnant sous un compte utilisateur hérite de toutes les autorisations dont dispose cette personne, et ses actions sont enregistrées sous son nom. Une identité distincte vous permet de limiter les autorisations à la tâche concernée, de désigner un responsable et d'examiner l'activité de l'agent selon ses propres critères.
Quel est le risque lié au fait de laisser un agent IA utiliser les identifiants d'un employé ?
Trois risques se cumulent. L'agent dispose presque toujours de privilèges excessifs, car il reçoit l'ensemble des autorisations de l'employé pour une tâche qui ne nécessite qu'un seul système. La piste d'audit perd de sa fiabilité, car il est impossible de distinguer les actions humaines de celles de l'agent. Et le principe de non-répudiation est compromis, car il est impossible de prouver lequel des deux a effectué une action donnée.
Qu'est-ce que l'identité d'un agent d'IA ?
Il s'agit d'une entrée distincte pour un agent IA dans votre environnement de gestion des identités et des accès, dotée de son propre identifiant, de ses propres informations d'authentification, de son propriétaire et de ses autorisations, indépendamment de tout compte humain. Elle existe afin que l'activité de l'agent puisse être autorisée, enregistrée et révoquée indépendamment des personnes pour lesquelles l'agent travaille.
En quoi la gestion des identités non humaines diffère-t-elle de la gestion traditionnelle des identités et des accès (IAM) ?
Le modèle IAM traditionnel part du principe qu’une personne dispose d’un intitulé de poste, d’un responsable et de responsabilités stables ; l’accès est donc accordé une seule fois et réexaminé périodiquement. Les identités non humaines n’ont pas de rôle professionnel, peuvent être bien plus nombreuses que les employés et peuvent avoir besoin d’un accès pendant quelques secondes plutôt que pendant des années. Cela oriente le modèle vers des identifiants à courte durée de vie et une autorisation à l’exécution, plutôt que vers des autorisations permanentes.
Combien de temps l'accès d'un agent IA doit-il être valable ?
En règle générale, sa durée ne doit pas dépasser celle de la tâche. Alors qu'un compte humain conserve ses identifiants pendant plusieurs mois, un agent peut se voir attribuer des identifiants qui expirent à la fin de la tâche, ce qui supprime l'autorisation permanente dont un pirate pourrait autrement tirer parti.
