Comment l’IAM agentique encadre les accès des agents IA

L’IAM agentique a un problème de visibilité avant d’avoir un problème d’authentification. Attribuer à un agent IA une identité gouvernée devient important une fois que l’agent atteint une ressource contrôlée par l’identité, mais l’IA peut déjà fonctionner sur l’ordinateur portable d’un employé, être connectée à des outils et détenir des identifiants avant cela. Pour l’IT, la gestion des identités et des accès doit donc couvrir l’activité qui commence sur le terminal ainsi que l’activité visible par le fournisseur d’identité.

L’IAM agentique commence avant que l’agent ne s’authentifie

Ce point de départ plus précoce reflète un changement dans les acteurs capables d’agir et dans la manière dont les actions atteignent les systèmes de l’entreprise. Un employé peut autoriser un assistant IA à agir en son nom, tandis qu’un agent autonome peut agir sans qu’une personne n’initie chaque action. Certains agents ont aussi besoin d’accéder à l’infrastructure ou aux environnements de production, où leurs autorisations peuvent devenir privilégiées. L’IAM classique de la main-d’œuvre a été conçu autour d’un acteur humain, de sorte qu’une activité qui démarre sur un appareil peut créer des chemins d’accès qu’il ne peut pas voir.

Ces nouveaux chemins étendent l’IAM agentique à l’identité, à la gestion des accès, à la découverte et à la gouvernance pour les humains comme pour les agents IA. Dans le modèle de l’assistant, l’employé reste l’identité humaine pertinente, mais l’assistant peut atteindre des systèmes avec lesquels l’employé n’interagit pas directement. Dans le modèle autonome, l’agent peut disposer de ses propres identifiants, autorisations, cycle de vie et historique. Comme ces modèles créent des exigences d’identité différentes, l’IT doit observer et gouverner chacun d’eux selon sa manière d’agir.

Cette portée élargie modifie l’objectif opérationnel. L’IT doit découvrir quelle IA est en fonctionnement, identifier l’humain ou l’agent responsable d’une action, décider quelles ressources il peut utiliser et conserver un historique d’activité tout au long de son cycle de vie. Une identité d’agent prend en charge plusieurs de ces contrôles, mais la découverte doit venir en premier, car certaines activités de l’IA ne commencent jamais par un événement d’authentification auprès du fournisseur d’identité.

Découvrir : le terminal peut voir l’IA avant le fournisseur d’identité

Le problème de découverte devient clair lorsque les outils d’IA suivent un chemin différent de l’onboarding SaaS habituel. Une application SaaS devient visible dans un fournisseur d’identité lorsqu’une personne la fédère. Un employé peut au contraire installer Claude Desktop ou Cursor directement sur un ordinateur portable et configurer la manière dont ce logiciel se connecte à d’autres systèmes. Comme le fournisseur d’identité ne participe pas nécessairement à cette séquence, l’IA peut devenir opérationnelle avant que l’IAM ne la voie.

Ces choix locaux peuvent établir un accès significatif avant que la fédération n’ait lieu. L’employé peut ajouter un serveur MCP en modifiant un fichier de configuration local, stocker une clé API personnelle dans un dotfile, ou installer une extension de navigateur capable d’accéder aux pages que l’employé ouvre. MCP, ou Model Context Protocol, permet à un logiciel d’IA de se connecter à des outils et ressources externes, et l’employé peut configurer cette connexion directement sur le terminal. Chaque choix modifie ce que l’IA peut potentiellement atteindre depuis l’appareil.

Comme ces actions ne nécessitent pas d’assertion SAML, elles ne créent pas nécessairement d’entrée de journal chez le fournisseur d’identité. La fédération SAML place un fournisseur d’identité dans le flux d’authentification d’une application, ce qui rend l’événement d’authentification résultant observable à cet endroit. Un outil, un identifiant ou une extension configuré localement peut fonctionner en dehors de ce flux, de sorte qu’un accès peut exister sans événement correspondant dans un plan de contrôle fondé sur l’authentification.

Cette limite est plus claire pour un produit dont l’observation commence au niveau de la couche d’identité. Un tel système peut voir un agent lorsqu’il fournit des identifiants à une ressource placée derrière ce fournisseur d’identité. À ce moment-là, l’agent peut déjà avoir fonctionné localement via d’autres identifiants et connexions. Une observation qui commence au niveau de la ressource contrôlée par l’identité capture donc cette interaction tout en laissant l’activité antérieure sur le terminal hors de son champ de vision.

Claude Desktop montre pourquoi ce contexte antérieur est important, car la configuration locale peut déterminer quels serveurs MCP il utilise et quels identifiants disponibles localement prennent en charge ces connexions. Cursor crée le même problème d’architecture lorsque sa configuration et ses connexions importent pour l’IT avant qu’un événement d’identité classique n’apparaisse. Les extensions de navigateur créent une autre voie locale, car leur accès suit les pages ouvertes par un employé et ne nécessite pas de nouvel événement SAML pour chaque interaction pertinente.

La découverte sur le terminal déplace la visibilité vers l’étape où ces choix se produisent. L’IT peut identifier les outils d’IA présents sur la machine avant d’attendre qu’ils apparaissent au niveau de la couche d’identité, tandis que le fournisseur d’identité reste utile une fois qu’un chemin d’authentification l’atteint. L’authentification arrive donc trop tard pour constituer à elle seule le point de départ du cycle de vie lorsque des activités d’IA importantes sont déjà en cours sur un appareil.

Ce timing définit l’exigence architecturale. Une stack dont la visibilité commence avec l’authentification peut manquer des logiciels d’IA, des configurations locales et des identifiants déjà actifs en dehors de son chemin d’authentification. L’IAM agentique a donc besoin d’une capacité de découverte à la frontière de l’appareil, en complément de l’observation au niveau de la couche d’identité. Une fois que l’IT sait ce qui fonctionne, il peut décider quels acteurs autonomes ont besoin d’identités formelles et comment les contrôler.

Enregistrer : une identité d’agent établit la responsabilité

La découverte mène à l’enregistrement lorsque le logiciel est un acteur autonome. Comme une personne n’initie pas chaque action pour un tel agent, un enregistrement d’utilisateur humain ne peut pas décrire l’ensemble de la relation opérationnelle. L’IT a besoin d’un enregistrement expliquant pourquoi l’agent existe, qui en est responsable et comment son accès doit évoluer tout au long de sa vie utile.

Cet enregistrement donne à l’agent autonome sa propre identité, avec une finalité définie, un propriétaire nommé, un cycle de vie, des attributions d’applications, une piste d’audit et un mécanisme de révocation indépendant. Les comptes de service partagés et les clés API de longue durée peuvent masquer ces propriétés, car un identifiant peut survivre à un usage particulier ou se retrouver dissocié d’une propriété individuelle clairement établie. Une identité explicite permet à l’IT de gouverner l’agent en tant qu’acteur et de révoquer son accès de manière indépendante.

L’identité enregistrée devient plus utile lorsqu’elle est reliée aux éléments de preuve issus du terminal qui ont conduit à sa création. Les données d’identité peuvent montrer la personne désignée comme propriétaire de l’agent, tandis que la visibilité sur le terminal peut montrer quelle machine l’exécute, dans quel contexte utilisateur il fonctionne et quelle est la posture de cet appareil. Ensemble, ces enregistrements établissent la provenance en montrant d’où vient l’agent, qui en est responsable et dans quel environnement il s’exécute.

Cette provenance explique aussi pourquoi l’enregistrement suit la découverte. L’IT observe d’abord l’acteur et son contexte local, puis transforme l’agent autonome en identité gouvernée tout en conservant les informations opérationnelles qui l’entourent. Une fois l’identité créée, la gestion des accès peut utiliser ces deux ensembles d’informations pour contrôler ce que l’agent est autorisé à atteindre.

Gérer : les assistants exposent des chemins d’accès entre terminal et contrôles d’identité

Dans le cas piloté par l’humain, le problème se déplace de l’enregistrement vers la gestion des accès, car l’identité de l’employé reste centrale. Les employés peuvent utiliser Claude, ChatGPT ou Cursor dans leur travail quotidien et continuer à initier eux-mêmes l’activité. L’IA peut alors effectuer des appels API, accéder à des applications ou invoquer des outils via des serveurs MCP en leur nom, ce qui signifie que le chemin d’accès inclut l’assistant, ses connexions et ses identifiants en plus de la connexion humaine.

La gestion de ce chemin nécessite les informations sur le terminal établies lors de la découverte. L’IT doit savoir quels outils d’IA sont installés, à quels serveurs MCP ils se connectent, quels identifiants sont présents dans les fichiers locaux et les trousseaux, et quelles applications les outils peuvent atteindre. L’identité humaine établit qui a initié le travail, tandis que le contexte de l’appareil établit comment l’assistant peut l’exécuter et quels identifiants il peut utiliser en cours de route.

La révocation montre pourquoi ces deux enregistrements continuent d’importer après l’authentification. Désactiver le compte d’un employé peut fermer le chemin SSO et empêcher tout accès supplémentaire par cette voie contrôlée par l’identité, mais une clé API de longue durée stockée localement peut rester valide, car le changement SSO n’invalide pas nécessairement un identifiant distinct. Le même terminal peut donc conserver un chemin d’accès exploitable après la fermeture de la voie médiée de manière centralisée.

Une gestion efficace relie ces surfaces de contrôle. Les contrôles d’identité gouvernent l’employé ou l’agent enregistré ainsi que son accès médié de manière centralisée, tandis que la visibilité sur le terminal expose les identifiants locaux, les configurations et les connexions IA qui peuvent survivre à un changement du fournisseur d’identité. Pour le travail assisté par l’IA, la révocation doit prendre en compte ces deux surfaces lorsque l’objectif est de supprimer l’accès sur l’ensemble des chemins que l’assistant peut utiliser.

Gouverner : les agents privilégiés augmentent les enjeux

Le même écart de contrôle devient plus lourd de conséquences lorsque des agents atteignent des serveurs, des bases de données de production, une infrastructure cloud et d’autres ressources privilégiées. Un agent qui exécute ces tâches peut avoir besoin d’autorisations puissantes et peut fonctionner en continu sans qu’une personne soit au clavier. Les identifiants administrateur permanents créent déjà des problèmes de gouvernance pour les administrateurs humains, de sorte que le fonctionnement continu des agents rend le cycle de vie de ces identifiants particulièrement important.

Ce cycle de vie exige que l’accès privilégié des agents soit limité au travail requis, gouverné dans le temps, consigné pour l’audit et révocable. La conception doit aussi empêcher l’accumulation d’identifiants administrateur permanents et de secrets privilégiés sur l’hôte où l’agent s’exécute. Sinon, la machine peut conserver un accès durable après un changement d’autorisation au niveau de l’identité, recréant l’écart de contrôle des identifiants dans un environnement plus sensible.

Ces exigences s’inscrivent dans la gestion des accès privilégiés établie, ou PAM, la discipline qui consiste à contrôler et auditer l’accès aux systèmes à forte valeur et aux autorisations administratives. L’IAM agentique applique ces principes aux acteurs IA tout en préservant le modèle de contrôle existant. L’acteur et sa capacité à fonctionner en continu modifient le risque pratique, de sorte que l’IT doit toujours limiter les privilèges, préserver la responsabilité, maintenir un accès révocable et éviter les secrets administratifs permanents.

Un cycle de vie relie trois problèmes d’accès à l’IA

Le cas privilégié complète un cycle de vie qui commence sur le terminal. Les assistants, les agents autonomes et les workflows d’agents privilégiés créent des schémas d’accès différents, mais l’IT peut les gouverner à travers la séquence « Découvrir. Enregistrer. Gérer. Gouverner. » L’ordre compte, car la visibilité établit d’abord l’acteur ; l’enregistrement peut ensuite lier un acteur autonome à une responsabilité, la gestion peut attribuer et révoquer l’accès, et la gouvernance peut maintenir le contrôle tout au long de sa vie.

Cette séquence explique aussi comment la gestion des appareils et la gestion des identités peuvent se compléter. Les informations sur les appareils peuvent exposer les logiciels et l’activité avant l’authentification, tandis que les informations d’identité fournissent les acteurs et les relations d’accès gouvernées de manière centralisée. Relier les deux permet d’associer ce qui fonctionne aux identités, identifiants et ressources pertinents, donnant à chaque étape ultérieure du cycle de vie le contexte établi par la découverte.

À quoi ressemble cette architecture dans JumpCloud

JumpCloud positionne son architecture autour de cette combinaison de contrôle du terminal et de l’identité. L’entreprise vend de la gestion des appareils et des identités, elle bénéficie donc commercialement du fait que les clients perçoivent leur combinaison comme un avantage pour l’IAM agentique. JumpCloud affirme gérer les appareils et les identités au sein d’une seule plateforme, ce qui permet à la découverte de l’IA sur le terminal d’utiliser un agent déjà déployé sur l’appareil au lieu d’exiger un autre agent logiciel. Dans la présentation de JumpCloud, la découverte consiste à demander à cet agent de terminal existant davantage d’informations sur l’activité de l’IA.

À partir de cette couche de découverte, JumpCloud indique que son offre Agentic IAM s’étend aux Agent Identities avec propriété humaine et contrôles de cycle de vie, aux Agent Groups et aux attributions d’applications, ainsi qu’à la visibilité sur l’activité. L’entreprise décrit également la découverte MCP et shadow AI, la visibilité AI Gateway et une prise en charge initiale des accès privilégiés. Dans son modèle produit, ces fonctions couvrent l’IA et les connexions auparavant invisibles, associent les agents à des propriétaires, attribuent l’accès, observent l’activité et commencent à traiter les workflows privilégiés.

Ces affirmations produit s’inscrivent dans une frontière de catégorie plus large. L’IAM agentique couvre l’identité, l’accès, la découverte et la gouvernance pour les acteurs IA, tandis que la différenciation revendiquée par JumpCloud dépend de la vente conjointe de la gestion des terminaux et des identités. Cette combinaison répond au manque de visibilité identifié plus tôt en déplaçant l’observation vers l’appareil, où Claude Desktop, Cursor, les identifiants locaux, les connexions MCP et les extensions de navigateur peuvent apparaître avant qu’une partie de leur activité n’atteigne un fournisseur d’identité.

Conclusion

Pour les dirigeants métier et technologiques, la décision centrale n’est pas de savoir si les agents IA ont leur place dans l’IAM. Elle consiste à déterminer où ce contrôle doit commencer. Si la visibilité ne commence que lorsqu’un agent s’authentifie, l’IT peut passer à côté d’outils d’IA, d’identifiants et de connexions déjà en fonctionnement sur les appareils des employés.

Une stratégie d’IAM agentique viable doit donc relier la découverte sur le terminal aux contrôles d’identité et d’accès. Les organisations doivent savoir quelle IA fonctionne, établir la responsabilité des agents autonomes, contrôler les ressources que les humains et les agents peuvent atteindre, et gouverner les accès privilégiés sans laisser derrière eux des identifiants durables.

Cela fait de l’IAM agentique une extension des disciplines de sécurité existantes plutôt qu’un plan de contrôle distinct. Le test pratique pour les dirigeants consiste à savoir si leur architecture actuelle peut suivre un acteur IA depuis sa première apparition sur un terminal jusqu’à l’enregistrement, l’accès, la révocation et l’activité privilégiée. Là où ces étapes restent déconnectées, les lacunes de gouvernance persisteront à mesure que l’adoption de l’IA s’étendra.