Quelle identité utilise un agent IA quand il agit dans le SI ?
Trois modèles coexistent aujourd’hui : l’agent emprunte les droits de la personne qui l’a déclenché, il partage un compte de service avec d’autres traitements, ou il dispose d’une identité qui n’appartient qu’à lui. Les deux premiers sont les plus rapides à mettre en place, et les seuls qui rendent la traçabilité impossible.
Une identité d’agent est un principal distinct dans l’annuaire : un compte qui n’appartient ni à un collaborateur ni à une application, doté de ses propres identifiants, d’un responsable désigné, d’une finalité déclarée, d’un périmètre d’accès et d’une durée de vie. Ce sont ces attributs, et non l’identifiant lui-même, qui décident de ce que l’entreprise saura de ses agents.
Dans un système d’information ordinaire, l’identité est une notion stable. Un collaborateur possède un compte, ce compte porte des droits, ces droits s’accordent, se modifient et se révoquent, et chaque action se rattache à quelqu’un. Un agent met ce modèle en défaut sur deux points : l’étendue des droits qu’il mobilise, et la lisibilité de ce qu’il a fait.
Le raisonnement de l’héritage paraît pourtant logique : si un collaborateur peut consulter un document, son assistant devrait pouvoir le consulter pour lui. Il devient problématique pour deux raisons distinctes. La première tient au périmètre : un collaborateur accumule au fil des projets et des changements de poste des permissions dont la mission de l’agent n’a aucun besoin, et les lui transmettre en bloc élargit inutilement sa surface d’action. La seconde tient à la lecture des traces : si une modification apparaît dans le CRM sous l’identité du collaborateur, plus rien ne distingue ce qu’il a fait lui-même de ce que son agent a fait pour lui.
Le compte de service mutualisé échoue autrement, et de façon moins visible. Il donne bien à l’agent une identité non humaine, mais partagée : plusieurs agents, parfois plusieurs équipes et plusieurs traitements automatisés, s’authentifient avec le même secret. Le périmètre de ce compte devient l’union de tous leurs besoins, personne ne peut le réduire sans risquer d’en casser un autre, et une trace indique seulement qu’un compte technique a agi. C’est le modèle le plus coûteux à démêler, précisément parce qu’il a l’air propre : aucun agent ne circule sous l’identité d’un humain.
L’identité de l’agent relève donc de l’architecture, pas du détail d’implémentation.
L’identité d’agent devient une catégorie à part entière dans l’IAM
Microsoft Entra Agent ID est passé en disponibilité générale. Microsoft le présente comme une couche de gestion des identités et des accès conçue spécifiquement pour les agents IA, destinée à les authentifier, les autoriser, les gouverner et les protéger à l’échelle de l’entreprise. Cette disponibilité générale porte sur le socle : une partie des expériences d’administration, dont l’assistant de création d’identités dans le centre d’administration Entra, reste annoncée en préversion.
Le glissement est notable. Les agents cessent d’être vus comme des fonctionnalités à l’intérieur d’applications pour devenir des entités auxquelles on peut rattacher une identité propre, et donc des permissions, des règles de sécurité et une responsabilité.
La conséquence pratique se lit dans les réglages. Un agent qui agit pour le compte d’un utilisateur (on behalf of) et un agent qui agit de sa propre initiative sont désormais traités comme deux situations distinctes, avec des attributions d’accès et des politiques d’accès conditionnel séparées. L’outillage acte ainsi ce que l’organisation doit acter aussi : l’autonomie ne change pas seulement le volume de droits d’un agent, elle change la nature de son identité.
Nous prenons cet exemple parce qu’il est documenté publiquement et donc vérifiable, non parce qu’il constituerait la seule réponse possible. Le problème posé par l’identité des agents dépasse un éditeur, et le raisonnement qui suit vaut quel que soit l’outillage retenu.
Un identifiant ne suffit pas, il faut savoir qui répond de l’agent
Attribuer un identifiant unique à chaque agent est la partie facile. Ce qui compte est ce que l’organisation sait de cet identifiant : qui en est responsable, pour quelle finalité l’agent a été créé, quelles ressources il peut consulter, quelles actions il peut effectuer, combien de temps il doit rester actif, et dans quelles circonstances ses accès doivent être retirés.
Le modèle de Microsoft répond à cette question par des relations administratives attachées à chaque identité d’agent, réparties entre trois rôles distincts. Le propriétaire est l’administrateur technique : il installe l’identité, la configure et gère ses secrets d’authentification. Le sponsor porte la responsabilité métier : il répond de la finalité de l’agent et des décisions de cycle de vie, revues d’accès et maintien en service compris, sans disposer pour autant des droits d’administration techniques. Le manager, enfin, rattache l’agent à la hiérarchie de l’organisation et peut demander des accès pour lui, sans pouvoir le modifier ni le supprimer.
Le détail le plus instructif se trouve dans les contraintes de création. Un sponsor est obligatoire dès la création d’une identité d’agent, alors que le propriétaire et le manager restent facultatifs. Un agent peut donc exister sans administrateur technique désigné, mais pas sans responsable métier identifié. Nous y voyons le bon arbitrage : la défaillance à redouter n’est pas l’absence de compétence technique, qui finit toujours par se voir, mais l’absence de quelqu’un capable de dire pourquoi cet agent existe encore. C’est exactement la chaîne de responsabilité sur laquelle repose la gouvernance des agents IA.
Ce que l’identité rend possible : le moindre privilège, puis l’audit
Prenons un agent chargé de préparer les rendez-vous commerciaux du lendemain. Sa mission suppose de lire quelques événements du calendrier, certaines informations du CRM et les documents liés aux comptes concernés. Elle ne suppose ni de modifier toutes les opportunités, ni d’exporter la base clients, ni d’écrire à l’extérieur de l’entreprise. Avec une identité propre, ce périmètre se décrit et s’applique réellement ; sans elle, il reste une intention. L’identité est en cela le préalable des ce qu’il faut verrouiller avant d’ouvrir un accès, moindre privilège, isolation d’exécution, validation humaine ou révocation d’urgence : chacun d’eux suppose que l’on sache de quel agent on parle. La frontière entre les deux sujets tient en une phrase. La sécurité décide des contrôles à poser sur un agent ; l’identité décide de ce qu’est cet agent, de son attribution à sa révocation.
Le raisonnement change d’échelle dès qu’un agent est autorisé à engager une dépense. Son identité doit alors porter, en plus d’un périmètre d’accès, un mandat que le tiers exécutant la transaction puisse vérifier : savoir qui est l’agent ne suffit plus, il faut pouvoir établir au nom de qui il engage l’entreprise et dans quelles limites.
Le second bénéfice apparaît après coup, au moment où l’on cherche à comprendre. Si tous les agents partagent des comptes techniques génériques, une trace indique seulement qu’une application a agi. Si chacun possède son identité, la reconstitution devient possible : agent X, pour l’utilisateur Y, action Z, sur la ressource W, à l’heure T. Cette chaîne devient déterminante à mesure que les agents se multiplient dans le SI, faute de quoi l’entreprise fabrique une nouvelle génération de comptes techniques dont plus personne ne sait qui les utilise.
Cycle de vie : que deviennent les accès d’un agent oublié ?
Un collaborateur change de poste. Un projet s’arrête. Une application est remplacée. Un agent expérimental n’intéresse plus personne. Que deviennent ses accès ?
Ils lui survivent. Tant qu’aucune procédure ne les retire, l’identité reste active, ses jetons restent valides et ses permissions restent accordées, jusqu’à ce qu’une revue d’accès les retrouve ou qu’un incident les révèle.
Les entreprises connaissent déjà ce problème avec les comptes de service oubliés. Les agents peuvent l’amplifier, précisément parce que leur création devient facile et décentralisée : ce qui s’obtient en quelques minutes se multiplie sans qu’aucune revue ne suive, et une partie de ce parc rejoint directement les agents que la DSI n’a jamais référencés. L’identité agentique doit donc embarquer un cycle complet, de la création à la révocation, en passant par l’attribution d’un responsable et une revue périodique des permissions.
Le point de rupture le plus prévisible est le départ de ce responsable. Microsoft documente à ce titre des flux de cycle de vie qui réattribuent le parrainage lorsqu’un sponsor change de fonction ou quitte l’organisation, avec pour objectif explicite d’éviter les agents orphelins. La suppression elle-même y est traitée comme un processus plutôt que comme un geste : nettoyage en cascade des objets rattachés à l’identité, et suppression réversible pendant une fenêtre donnée avant l’effacement définitif. L’outillage confirme ici le diagnostic : authentifier un agent aujourd’hui est le problème facile, savoir qui en répondra dans six mois est le problème réel.
Après les personnes et les applications, une troisième population d’identités
Les annuaires d’entreprise ont longtemps distingué deux populations : les personnes, et les identités techniques rattachées à des applications. Le vocabulaire IAM range ces dernières parmi les identités non humaines, catégorie longtemps réduite aux comptes de service et aux identifiants applicatifs. Les agents s’y ajoutent sans s’y ranger proprement. Ils empruntent aux comptes de service leur caractère non humain, mais ils agissent tantôt pour un utilisateur, tantôt pour une équipe, tantôt pour un processus, et pour des durées qui vont de l’appel ponctuel au service permanent. Ils peuvent surtout déléguer à d’autres agents, ce qui déplace la question : il ne suffit plus de savoir quels droits détient un agent, il faut savoir jusqu’où ces droits se propagent. C’est le sujet des architectures multi-agents et du protocole A2A.
À retenir
La question technique en recouvre une plus élémentaire :
Si un agent peut agir dans votre entreprise, êtes-vous capable de dire précisément qui il est, pourquoi il dispose de ses droits, et ce qu’il en a fait ?
À mesure que l’autonomie progresse, cette capacité cesse d’être un confort d’exploitation pour devenir une condition d’industrialisation.
