9 septembre 2026
Accorder à un agent IA un accès illimité au 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 qu’il soit nécessaire de procéder à un nouvel examen de sécurité fastidieux. Le problème apparaît dès que l'agent commence à agir, et 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 l'agent qui a effectué ces opérations. La responsabilité devient aléatoire, et l'agent dispose discrètement d'un accès bien plus étendu que ne l'exige sa mission.
Attribuer à chaque agent sa propre identité constitue la bonne mesure corrective, et c'est la première des deux. Une identité distincte permet de déterminer quel agent a agi. Elle ne permet pas de déterminer si un responsable humain a approuvé l'action de cet agent. Ce deuxième problème persiste même avec un programme d'identification bien géré, et c'est celui-là qui entraîne des conséquences juridiques et financières.
Le « Hype Cycle™ 2026 de Gartner® consacré à 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. »
Les identifiants uniques, les identifiants à portée limitée et une piste d'audit permettant d'attribuer les actions à leur auteur sont autant de propriétés d'attribution. Elles permettent de déterminer quel agent a agi et sous quelle autorité, ce qui est une question distincte de celle de savoir si une personne identifiée a approuvé l'action qu'il a menée.
Les identifiants empruntés et la sécurité des comptes de service créent un angle mort
Les premiers projets d'IA ont tendance à s'appuyer sur les ressources déjà disponibles :
- Un assistant interne peut se voir attribuer des autorisations excessives si son accès délégué n'est pas explicitement restreint.
- Un workflow passe 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.
Ces configurations entraînent différents risques : accès excessifs, attribution ambiguë ou identifiants persistants. L'agent peut se voir attribuer davantage d'autorisations que ne l'exige sa tâche. La frontière entre l'activité humaine et celle de l'agent peut s'estomper lorsque les identifiants sont partagés. 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 compromet également la non-répudiation – une fonctionnalité de sécurité qui prouve qu’une personne spécifique a envoyé un message ou effectué une transaction, et ne peut par la suite nier l’avoir fait. 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 risquée consistant à déployer des agents d’IA en tant que 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. »
Il s'agit là d'erreurs d'attribution, et une identité distincte constitue le remède approprié à ces problèmes.
En quoi consiste un changement d'identité distinct ?
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élibérément restreint d’autorisations approuvées en son nom par ce propriétaire. Elle peut être désactivée sans perturber l’employé ou l’équipe qui se trouve derrière. L’authentification de l’agent IA devient alors un événement distinct que l’on peut 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 celle de tout utilisateur humain.
La réattribution mérite une attention particulière. Réaffecter un mandataire à un autre mandant ou propriétaire constitue un changement d’identité plutôt qu’une simple mise à jour d’un champ ; elle devrait donc nécessiter une nouvelle vérification de l’identité de la personne qui en assume désormais la responsabilité. Un registre de propriété pouvant être modifié sans redéfinir qui a accepté d’assumer le risque expose la relation à des litiges.
Cela se rapproche davantage du fonctionnement prévu du modèle « Zero Trust », dans lequel une authentification antérieure n’est pas considérée comme une preuve irréfutable de quoi que ce soit. Le cas « agentic » pousse cette logique encore plus loin : une authentification antérieure ne prouve pas non plus qu’une personne ait approuvé ce qui va se passer ensuite.
Les agents IA ont-ils besoin d'un accès permanent ?
Souvent, oui. L'accès des utilisateurs est généralement lié à un poste, car les responsabilités perdurent. Certains agents fonctionnent de la même manière. Un agent de rapprochement qui s’exécute chaque nuit, ou un agent de service traitant une file d’attente en continu, a besoin d’une autorisation permanente pour être utile. D’autres ont besoin de bien moins : extraire une facture, la faire correspondre à un bon de commande, renvoyer le résultat. Il serait indéfendable d’accorder à l’un ou l’autre de ces types d’agents l’ensemble des autorisations d’un employé. Des identifiants à durée de vie limitée sont utiles dans les deux cas, bien qu’ils réduisent la marge de manœuvre pour les abus plutôt que de l’éliminer complètement, et que l’expiration ne supprime pas en soi l’autorisation sous-jacente.
Le rapport décrit ainsi un profil d’innovation connexe : « 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) 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 point aveugle critique qui sape la plupart des stratégies « zero trust ». »
Nous conservons les autorisations persistantes et posons une question différente à leur sujet. Non pas pendant combien de temps un agent détient une autorité, mais qui la lui a accordée. Chaque ensemble d’autorisations doit être approuvé par une personne identifiée, sur la base de preuves que l’agent n’aurait pas pu produire lui-même. Un agent capable de produire, de reproduire ou de satisfaire à ces preuves peut, en réalité, s’approuver lui-même.
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 répond 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 prévues par l’agent au regard de cette intention. »
L’intention déduite constitue un élément utile pour une décision d’accès. Elle ne constitue pas une autorisation. L’intention captée à partir d’une conversation reste une description élaborée dans le contexte propre à l’agent ; ainsi, un agent mal aligné ou soumis à une injection de prompt peut la façonner. L’évaluation de l’intention permet de restreindre l’action d’un agent dans les limites d’une autorisation accordée par quelqu’un. Établir que l’autorisation a bien été accordée constitue une étape distincte. À ce stade, trois contrôles sont déjà pleinement opérationnels, et chacun présente la même limite :
- La vérification de l'identité d'une personne permet de déterminer qui elle est. Elle ne permet pas de déterminer ce à quoi elle a consenti.
- Déduire l'intention permet de déterminer ce que semblait être la demande. Cela ne prouve pas pour autant que la personne ait vu l'action qui en a résulté.
- La définition restrictive de la portée détermine ce que l'agent peut atteindre. Elle ne signifie pas pour autant que cette action spécifique était voulue.
Ce dont les actions aux conséquences les plus importantes ont besoin, c’est d’un lien entre trois éléments : une personne vérifiée, l’agent agissant en son nom, et l’action ou l’autorisation spécifique que cette personne a approuvée. L’action doit donc être mise en attente avant de prendre effet. C’est la couche de contrôle, et non l’agent, qui doit présenter la nature de l’action et ses limites, et la décision doit être renvoyée hors bande, directement à cette couche de contrôle, via un canal sur lequel l’agent proposant l’action n’intervient pas. Nous qualifions les preuves fournies à l’appui de cette décision de « résistantes aux agents » : l’agent ne peut ni les générer, ni les rejouer, ni les obtenir en recrutant un deuxième agent sur un autre appareil. La solution iProov Dynamic Liveness les fournit, en établissant la présence d’un être humain authentique au moment de l’approbation et liée à l’action précise. Nous avons détaillé le fonctionnement de cette délégation dans un article distinct consacré à l’autorisation humaine vérifiée dans l’IA agentique.
Commencez par distinguer les personnes des agents, puis apportez la preuve de l’autorisation
Les agents ne doivent pas être des extensions invisibles du compte d’un employé. Il faut attribuer à chacun d’entre eux sa propre identité, 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.
Il faut ensuite déterminer quelles actions ne peuvent être menées sur la seule base d’une délégation d’autorité, car c’est là qu’une preuve plus solide s’avère payante. Les organisations limitent généralement les agents à des tâches aux conséquences minimes, non pas parce que l’agent ne peut pas en faire plus, mais parce qu’elles ne peuvent pas apporter la preuve d’une approbation humaine pour toute tâche plus importante. Une preuve d’approbation qu’aucun agent ne peut fournir permet de lever cette limite. Le lancement de paiements, les changements de bénéficiaire, l’attribution de rôles privilégiés et les modifications des autorisations d’un agent peuvent tous être automatisés jusqu’au stade de l’approbation, où ils sont mis en attente en vue d’une authentification renforcée, puis validés sur présentation d’un justificatif mentionnant le nom de l’approbateur, l’action, les paramètres qui lui ont été présentés et une durée de validité à usage unique. Les frictions se concentrent sur quelques moments critiques, tandis que le travail de routine entre ces étapes se déroule sans interruption.
Les preuves d’autorisation ne pouvant être reconstituées a posteriori, le lien entre une décision humaine et l’action qu’elle autorise doit être défini avant le déploiement des agents. Ces étapes exigent un effort en début de projet, mais elles permettent d’éviter un problème bien plus grave par la suite : des milliers d’agents autonomes fonctionnant avec des identifiants partagés ou insuffisamment contrôlés, prenant des décisions lourdes de conséquences dont on ne peut attribuer la responsabilité à aucune personne identifiable.
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.
