12/11/2026
Cybersecurity Insights
Agents IA : quand les machines deviennent des identités
Les agents IA peuvent désormais accéder à des applications, interroger des données, appeler des APIs et exécuter des actions de manière autonome.
À mesure qu’ils deviennent de véritables acteurs du système d’information, de nouvelles questions se posent : comment les identifier, contrôler leurs accès et s’assurer qu’ils n’agissent que dans le cadre qui leur a été défini ? Pour l’IAM (Identity Acces Management), l’enjeu est désormais d’intégrer ces nouveaux acteurs numériques à une gouvernance qui reste, elle, fondamentalement humaine.
Il y a encore peu de temps, l’intelligence artificielle en entreprise était principalement associée à des assistants conversationnels. Un collaborateur posait une question. L’IA produisait une réponse. Le collaborateur restait maître de l’action. Avec l’arrivée des agents IA, cette frontière évolue.
Un agent peut recevoir un objectif, rechercher les informations nécessaires, utiliser différents outils, appeler des APIs et enchaîner plusieurs actions pour atteindre le résultat attendu. Il peut, par exemple, consulter un référentiel RH, créer un ticket dans un outil ITSM, interroger une application métier puis déclencher une étape d’un workflow. L’IA ne se contente donc plus d’assister le collaborateur : elle commence à agir dans le système d’information.
Cette évolution ouvre des perspectives considérables en matière d’automatisation et de productivité. Mais elle introduit également une nouvelle catégorie d’acteurs numériques, capables d’accéder à des ressources et de réaliser des opérations sans intervention humaine systématique.
Si les collaborateurs disposent d’une identité numérique qui permet de déterminer qui ils sont, ce qu’ils peuvent faire et à quelles ressources ils peuvent accéder, comment devons-nous gérer l’identité d’un agent IA ?
Un agent IA n’est pas simplement une application
Avant d’aller plus loin, une distinction est nécessaire. Un chatbot répond à une sollicitation. Un agent IA, lui, poursuit un objectif et peut décider des actions nécessaires pour l’atteindre, dans les limites qui lui ont été données.
Prenons un exemple :
Un collaborateur demande à un assistant : « Prépare l’arrivée de ce nouveau collaborateur. »
Un chatbot pourrait expliquer les différentes étapes à suivre.
Un agent IA pourrait, lui, consulter le SIRH, récupérer les informations nécessaires, créer une demande dans l’ITSM, déclencher un workflow de provisioning et vérifier que les comptes nécessaires ont bien été créés.
À partir de ce moment, l’agent possède une caractéristique essentielle : il agit.
Il devient donc nécessaire de pouvoir l’identifier techniquement, de déterminer les ressources auxquelles il peut accéder et de tracer les actions qu’il réalise.
C’est ce qui rapproche les agents IA de la notion d’identité non humaine. (NHI – Non-Human Identity).
Cette catégorie n’est d’ailleurs pas nouvelle. Elle englobe déjà les comptes techniques, comptes de service, applications, bots et autres identités machines.
Mais les agents IA introduisent une complexité supplémentaire : ils peuvent être capables de déterminer eux-mêmes quelles actions effectuer pour atteindre un objectif. Dès lors, quel agent agit, pour quel objectif, avec quelles capacités, dans quelles limites et sous la responsabilité de qui ?
L’agent IA doit avoir un Product Leader
Cette première notion est fondamentale.
Comme pour n’importe quelle application déployée au sein de l’entreprise, un agent IA ne devrait pas apparaître dans le système d’information sans responsable clairement identifié.
Il doit notamment disposer d’un Product Leader, c’est-à-dire d’une personne humaine responsable de son usage et de sa finalité.
Le Product Leader n’est pas nécessairement le développeur de l’agent. Son rôle est avant tout de définir pourquoi l’agent existe, ce qu’il doit faire et ce qu’il ne doit pas faire. Il doit notamment être responsable :
- de la spécialisation de l’agent
- de la définition de ses cas d’usage
- de son périmètre fonctionnel
- des actions que l’agent est autorisé à réaliser
- des actions qui lui sont interdites
- des données auxquelles il peut accéder
- des applications et APIs qu’il peut utiliser
- de la revue régulière de ces éléments
De l’assistant au collaborateur numérique
Les usages possibles des agents IA sont nombreux.
Dans le support aux collaborateurs, un agent peut rechercher une procédure, analyser une demande et créer automatiquement un ticket.
Dans l’automatisation des processus, il peut récupérer des informations dans plusieurs applications, effectuer des contrôles puis déclencher une action.
Dans les métiers spécialisés, il peut être conçu pour analyser des contrats, assister une équipe commerciale, préparer des éléments financiers ou contribuer à une analyse de cybersécurité.
Dans le développement, il peut analyser du code, créer une branche, lancer des tests et proposer une correction.
Enfin, plusieurs agents peuvent être amenés à collaborer entre eux : un agent spécialisé dans les achats peut solliciter un agent financier, qui lui-même peut faire appel à un agent de conformité.
Ces usages présentent un point commun : l’agent doit accéder à des ressources de l’entreprise. Et dès qu’un acteur accède à une ressource, la question de l’identité et des autorisations se pose.
Plus l’agent est autonome, plus le contrôle de son identité devient critique
Le premier risque est celui des privilèges excessifs.
Un agent disposant de droits trop larges pourrait accéder à des données ou réaliser des actions qui dépassent largement sa mission initiale.
Un agent chargé de préparer l’arrivée d’un collaborateur doit-il pouvoir modifier directement les droits administrateurs dans l’annuaire ? Évidemment non.
La difficulté est de traduire précisément la mission fonctionnelle de l’agent en capacités techniques contrôlables.
Vient ensuite le risque de prolifération.
Une entreprise peut rapidement multiplier les agents : un agent RH, un agent finance, un agent commercial, plusieurs agents de développement, des agents créés pour des besoins ponctuels…
Sans inventaire centralisé, il devient difficile de savoir combien d’agents existent réellement, lesquels sont actifs et quels accès leur ont été attribués.
Le risque est alors proche de celui que l’IAM connaît déjà avec les comptes techniques : des identités dont le propriétaire, la finalité ou les droits deviennent progressivement inconnus.
Mais les agents IA ajoutent une dimension supplémentaire : leur capacité d’action peut rendre les conséquences d’une compromission beaucoup plus rapides.
Un agent compromis disposant d’un accès au CRM, à une base documentaire et à plusieurs APIs pourrait potentiellement enchaîner des opérations à une vitesse impossible à reproduire manuellement.
Enfin, se pose la question de la traçabilité.
Lorsqu’un agent modifie une donnée, crée un compte ou déclenche un processus, l’entreprise doit pouvoir répondre à plusieurs questions que nous nous posons déjà dans le cadre de l’IAM traditionnel :
- Qui es-tu ? → Identification et authentification.
- À quoi as-tu accès ? → Autorisation et contrôle d’accès.
- Qui t’a donné ces droits ? → Gouvernance et validation.
- En as-tu encore besoin ? → Revue des habilitations.
- Qui est responsable de toi ? → Product Leader et ownership.
- Que s’est-il passé ? → Journalisation et audit.
- Quand dois-tu disparaître ? → Gestion du cycle de vie.
L’enjeu consiste alors à étendre les principes de gouvernance existants aux identités non humaines et aux agents IA, en tenant compte de leurs spécificités. Cela implique notamment de gérer leur cycle de vie de bout en bout : création, approbation, attribution des droits, évolution, revue, suspension et suppression.
Le principe du moindre privilège doit également devenir la règle : un agent ne doit disposer que des capacités strictement nécessaires à la réalisation de sa mission.
La gestion des secrets est tout aussi importante. Les clés API, certificats, tokens et autres credentials utilisés par les agents doivent être protégés, renouvelés et révoqués lorsque cela est nécessaire.
Enfin, l’approche Zero Trust trouve ici un nouveau terrain d’application : le fait qu’un agent soit interne à l’entreprise ou qu’il ait été créé par une équipe de confiance ne doit pas suffire à lui accorder automatiquement des droits.
Un marché qui commence à se structurer
Face à cette évolution, plusieurs catégories d’acteurs cherchent aujourd’hui à répondre au problème.
Les plateformes IAM traditionnelles, comme Microsoft Entra, Okta, SailPoint, Saviynt ou Ping Identity, étendent progressivement leurs capacités aux identités non humaines et aux agents.
Microsoft propose par exemple Entra Agent ID, destiné à fournir une identité aux agents et à intégrer leur gestion dans les mécanismes existants d’identité et d’accès.
D’autres acteurs se sont historiquement spécialisés dans les identités non humaines, avec des offres autour de la découverte des comptes techniques, des secrets, des credentials et de leurs relations avec les applications.
Le PAM conserve également un rôle important lorsqu’un agent doit accéder à des comptes privilégiés. CyberArk, Delinea ou BeyondTrust permettent notamment de contrôler et de sécuriser l’utilisation de privilèges élevés.
Enfin, les solutions de gestion des secrets, telles que HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault, permettent de protéger les credentials utilisés par les applications et les agents.
Une nouvelle catégorie apparaît désormais autour des notions d’Agent Identity, d’Agent Governance, d’Agent Security ou d’AI Runtime Security.
Le marché reste cependant en construction.
L’enjeu pour les entreprises n’est pas nécessairement de choisir immédiatement une nouvelle plateforme dédiée, mais d’identifier comment intégrer la gouvernance des agents dans leur architecture de sécurité existante.
Que mettre en place dès aujourd’hui ?
Il est possible d’anticiper cette évolution sans attendre que le marché se stabilise.
Première étape : inventorier. L’entreprise doit savoir quels agents sont utilisés, où ils sont déployés et à quelles ressources ils ont accès.
Deuxième étape : responsabiliser. Chaque agent doit avoir un Product Leader humain clairement identifié, responsable de sa finalité, de ses usages et de son périmètre d’action.
Troisième étape : définir les capacités. Il faut documenter précisément ce que l’agent peut faire, les applications qu’il peut appeler, les données qu’il peut consulter et les actions qu’il peut déclencher.
Quatrième étape : appliquer le moindre privilège. Les droits doivent être limités à ce qui est nécessaire à la mission de l’agent.
Cinquième étape : intégrer l’agent au cycle IAM. Création, approbation, modification, revue et suppression doivent progressivement devenir des processus gouvernés.
Sixième étape : tracer. Chaque action significative doit pouvoir être attribuée à l’agent et, lorsque cela est pertinent, à l’utilisateur à l’origine de la demande.
Septième étape : prévoir la révocation. Une organisation doit pouvoir désactiver rapidement un agent, ses accès et ses credentials en cas de compromission ou de fin d’utilisation.
Ces principes permettent d’éviter un scénario particulièrement risqué : une multiplication rapide des agents IA sans capacité équivalente à les inventorier, les gouverner et les contrôler.
Conclusion : gouverner les agents sans leur déléguer la gouvernance
L’entreprise agentique est en train de modifier profondément la manière dont le système d’information est utilisé.
Demain, les collaborateurs ne seront plus les seuls acteurs capables de consulter des données, d’appeler des APIs ou d’exécuter des processus. Des agents IA réaliseront eux aussi ces opérations, parfois de manière autonome et à grande échelle.
Cette évolution élargit le périmètre de l’IAM.
Les agents devront disposer d’une identité, de droits maîtrisés, d’un cycle de vie, d’une traçabilité et d’un propriétaire humain clairement identifié.
Le Product Leader joue ici un rôle essentiel : l’agent peut être autonome dans l’exécution, mais sa finalité, ses usages et les limites de ses actions doivent rester définis et assumés par un humain.
L’enjeu n’est donc pas de donner une identité aux agents pour les rendre autonomes, mais de leur donner juste assez d’identité, de droits et de liberté pour accomplir leur mission — et pas davantage.
Dans l’entreprise agentique, l’IAM devra répondre à la question : « Qui a autorisé cet agent à agir, dans quel but et jusqu’où peut-il aller ? »
