De nombreuses équipes qui déploient des agents d’IA ont accepté un compromis en matière de sécurité sans en avoir pleinement conscience. Ils ont attribué à l’agent un compte de service, peut-être une clé API partagée ; un élément disposant de droits suffisants pour accomplir sa tâche, stocké dans un fichier de configuration ou une variable d’environnement. sa solution est à toute épreuve. L’agent appelle les bonnes API, les démonstrations se déroulent sans accroc et le projet est livré.
Ce qu’ils ont réellement fait, c’est recréer le problème du compte de service, sauf que désormais le principal fonctionne de manière autonome, rapidement, et que son « jugement » peut être influencé par n’importe quel texte lu dans une invite.
Je souhaite présenter un argument précis : la gestion de l’accès des agents d’IA n’est pas un problème nouveau nécessitant de nouveaux outils. Les outils de gestion des accès à privilèges (PAM) dont vous disposez déjà — accès en flux tendu (JIT), enregistrement de session, application du principe du moindre privilège et pistes d’audit — prennent tous une importance accrue, et non l’inverse. Ce qui doit évoluer, en revanche, c’est le modèle d’identité, et cette évolution a des répercussions sur les architectures PAM réellement adaptées à cette mission.
Le problème lié au traitement d’un agent comme un compte de service
Un compte de service est une identité statique. Il dispose d’identifiants et d’autorisations, et en cas de problème, le journal d’audit indique quel compte a effectué quelle action. La correction est claire : remplacez l’identifiant, réduisez les autorisations, puis poursuivez.
Un agent d’IA est un type de principal différent. Il existe plusieurs raisons pour lesquelles cela ne correspond pas parfaitement au modèle de compte de service :
Elle fonctionne pour le compte d’un utilisateur humain
Lorsque l’analyste de votre centre des opérations de sécurité (SOC) demande à un agent d’examiner un serveur de production, l’agent n’agit pas de sa propre initiative ; il exécute une instruction provenant d’une personne précise. L’identité de cette personne doit figurer dans l’enregistrement d’accès. Un compte de service ne comporte pas ce contexte. « L’agent a accédé au serveur » est une affirmation moins précise que « L’agent de Jason a accédé au serveur, à la suite d’une session initiée par Jason à 18 h 51 après avoir terminé la MFA. »
Ses instructions peuvent être modifiées
Un compte de service exécute uniquement ce qui est défini dans son code. Un agent d’IA traite le langage naturel, ce qui signifie qu’une consigne suffisamment élaborée peut donner l’impression que presque toute action constitue une suite logique. La frontière de sécurité qui protège un compte de service — le code lui-même — ne s’applique pas de la même manière. La solution consiste à ajouter des couches de contrôle autour de l’agent qui n’évaluent pas l’intention et ne sont pas contournées par une entrée manipulée.
Les identifiants statiques constituent un point de défaillance unique à grande échelle
À mesure que les agents se multiplient, le périmètre d’impact d’un identifiant partagé s’étend avec chaque agent qui l’utilise. Un seul fichier de configuration compromis n’expose pas uniquement un service ; il met en danger l’ensemble des systèmes auxquels l’identifiant donne accès, sur chaque agent qui l’utilise.
La réponse n’est ni un framework d’agent sophistiqué ni un nouveau type de clé API. C’est la même réponse que PAM a donnée pour l’accès à Privileged Access humain : ne délivrez jamais d’identifiants permanents. Accordez l’accès en flux tendu (JIT), limitez-le à la session, consignez les actions effectuées et ne laissez rien à dérober à la fin de la session.
Gouvernance des agents IA en pratique : cas d’usage de workflow SOC
Plus tôt cette année, j’ai conçu une démo fonctionnelle d’un workflow SOC assisté par l’IA, permettant à un analyste sécurité, via une interface de chat, de demander à un agent d’enquêter sur un serveur de production hébergé sur notre infrastructure de laboratoire. L’agent ne disposait d’aucun identifiant permanent pour l’environnement de production.
Nous avons enregistré la session de bout en bout. Lorsque l’analyste a initié la session, voici la séquence des événements qui s’est déroulée :
- L’analyste s’est authentifié via Okta avec MFA – une véritable assertion d’identité, et non un token de service.
- L’agent a effectué un transfert de token OAuth 2.0 (RFC 8693), qui correspond à l’étape de délégation produisant un token contenant à la fois l’identité de la personne (sub = firstname.lastname@com.com) et celle de l’agent (cid = ag_ir_forensic_7f3a2). Les deux présents, aucun omis. La présence humaine était nécessaire pour que ce token existe.
- Okta Privileged Access (OPA) a validé le token auprès du connecteur de charge de travail et de la politique configurés afin de confirmer que l’agent était autorisé à accéder à cette catégorie de serveur dans ces conditions.
- OPA a émis un certificat SSH de courte durée via le client PAM, qui a reçu une charge utile chiffrée, a établi la connexion par l’intermédiaire de la Gateway OPA et a effectué le déchiffrement à cet endroit. L’agent n’a jamais détenu d’identifiant lisible.
- L’agent s’est connecté via l’Okta Privileged Access Gateway, qui constitue le seul accès réseau à l’environnement de production. Les hôtes de production n’étaient pas directement accessibles depuis le calcul de l’agent ; la gateway constituait le seul point d’accès, et uniquement pour les sessions conformes à la politique.
Temps total écoulé entre le navigateur de l’analyste et l’ouverture d’un shell sécurisé sur un serveur de production : 37 secondes.
L’agent a détecté un reverse shell dès la première commande, a exécuté nc en tant que root, puis a établi une connexion vers une adresse IP externe. C’est le cas d’usage : rapide, maîtrisé et entièrement audité.
Comment l’accès JIT élimine les privilèges permanents pour les agents IA
Quelques éléments de ce flux méritent d’être examinés de plus près. Tout d’abord, l’accès JIT fonctionne ici à deux niveaux :
- OPA a émis un certificat SSH éphémère limité à cette session.
- OPA a également créé un compte OS local sur l’hôte de production pour cette session, qui a été supprimé à la fin de la session. Aucun compte persistant n’était présent sur l’hôte en attente de compromission.
Application du Principe du moindre privilège avec des politiques sudo dynamiques
L’application de sudo à l’exécution mérite une mention particulière en tant que contrôle répondant à la principale préoccupation liée aux agents en production : les récits qui circulent sur des agents devenant incontrôlables, supprimant des bases de données et écrasant des fichiers. Ces scénarios nécessitent un accès en écriture. Notre agent d’investigation avait besoin d’un accès en production, mais fonctionnait en mode lecture seule, et la politique sudo centralisée d’OPA imposait cette restriction au niveau du système d’exploitation — ni via une invite système, ni par la logique de l’application, ni selon le propre jugement de l’agent concernant ce qui est approprié.
Mais la politique n’a pas seulement bloqué les comportements destructeurs. Elle a appliqué la limite précise des actions que cet agent aurait dû effectuer, ce qui est important même pour les opérations de lecture. Lors des tests, le raisonnement propre du LLM a systématiquement détecté les demandes adressées à l’agent visant à lire /etc/shadow ; cela était suffisamment évident pour que la limite souple soit respectée.
Cependant, demander à l’agent d’analyser la cartographie mémoire d’un processus était différent. Comme cette demande était plausible d’un point de vue forensique et non destructive, après quelques tentatives, la couche de raisonnement de l’agent a accepté de l’exécuter. La politique sudo d’OPA l’a tout de même bloqué. L’essentiel n’est pas que le LLM ait échoué ; c’est que la politique ne repose pas sur le fait que le LLM donne la bonne réponse. La personne qui a conçu l'offre packagée sudo a réfléchi avec soin à ce qu’un analyste SOC devrait ou ne devrait pas pouvoir consulter. Ce jugement est appliqué à l’exécution, quelle que soit l’évaluation de l’agent quant à ce qui est raisonnable.
Intégrer l’identité humaine dans le journal d’audit PAM
La piste d’audit est également importante ici. L’Okta System Log contient sept événements pour cette session, depuis la connexion SSO de l’analyste jusqu’à la connexion SSH au serveur de production. Chaque événement est lié. L’identifiant utilisateur humain est présent tout au long de la chaîne.
Le WorkloadPrincipal dans les événements PAM n’est pas simplement « un agent », il s’agit de opa://pam-fbach/IR-Forensic-Agent/firstname.lastname@com.com (l’équipe responsable de cet agent, le contexte de politique sous lequel il a été exécuté, ainsi que la personne ayant autorisé son utilisation). Les trois réunis dans un seul champ de journal PAM. L’adresse e‑mail de l’utilisateur figure dans l’enregistrement PAM car elle était présente dans le token et provenait du même système d’identité qui a authentifié l’analyste initialement.
Voilà l’histoire de la responsabilisation. Il ne s’agit pas de « un agent a accédé au serveur », mais plutôt de : « l’agent de Firstname a accédé au serveur, voici le certificat utilisé, voici l’enregistrement de la session, voici chaque token de la chaîne qui l’a autorisé. »
Pourquoi la base IdP n’est pas facultative
C’est ici que je souhaite formuler un argument plus précis à l’intention des architectes sécurité qui évaluent les fournisseurs de PAM.
De nombreux fournisseurs de solutions PAM pour les entreprises prennent en charge l’authentification par JSON Web Token (JWT). Nombreux sont ceux qui prennent en charge l’authentification JWT/OIDC et vous permettent d’associer des revendications à des politiques. Cela fonctionne, mais « accepter le JWT » et « comprendre nativement l’identité » ne sont pas la même chose.
Lorsque le fournisseur d’identité (IdP) et la solution PAM sont intégrés à la même plateforme, certains éléments diffèrent structurellement :
- L’inscription de l’agent réside dans l’IdP : Le connecteur de charge de travail d’OPA s’associe à l’
cidde l’agent — il ne s’agit pas d’une chaîne dans un fichier de configuration de politique, mais d’une référence active à un principal enregistré. Le déprovisioning de l’agent dans Okta résilie l’accès. - La piste d’audit constitue un flux unique : L’événement SSO de l’analyste, l’octroi du token, la délivrance des identifiants PAM, la connexion SSH : tous figurent dans l’Okta System Log, consultables ensemble. Avec un fournisseur PAM distinct, vous devez combiner deux systèmes d’audit pour reconstituer les événements.
- L’identité humaine dans l’enregistrement PAM n’est pas une revendication mappée ayant survécu à un transfert : il s’agit de la même identité authentifiée au début de la chaîne, qui ne quitte jamais la frontière de confiance de la plateforme.
Pour l’accès privilégié humain, l’intégration IdP‑PAM était pratique, car elle permettait le SSO dans votre console PAM et éventuellement le provisionnement SCIM. Cependant, pour l’accès des agents d’IA, il s’agit d’une question d’architecture. La traçabilité repose sur l’intégrité de l’identité humaine tout au long de son parcours, de l’authentification à la délégation puis à l’accès, chaque frontière de confiance franchie représentant un risque de perte, de mauvaise association ou d’absence de journal.
Cette préoccupation architecturale ne concerne pas uniquement l’accès à privilèges à l’infrastructure.
Le workflow SOC décrit ci-dessus n’est pas une intégration ponctuelle, car il représente une déclinaison d’une architecture plus large. Okta for AI Agents répond à trois questions que chaque équipe sécurité déployant des agents se pose : Où sont mes agents ? À quoi peuvent-ils se connecter ? Que peuvent-ils faire ?
Okta Privileged Access est la réponse que nous apportons à la troisième question pour les cibles les plus sensibles : l’infrastructure de production, les systèmes sensibles et tout environnement où un agent compromission ou manipulé pourrait causer de réels dommages. Les mêmes principes qui régissent le couple (humain, agent) dans le flux OPA — à savoir le rattachement du contexte utilisateur à chaque action, des périmètres de moindre privilège, des identifiants éphémères et une traçabilité immuable — s’appliquent également aux serveurs MCP, aux API SaaS, aux appels entre agents et aux connexions de service authentifiées. L’accès par agent à un serveur de production est précisément le cas où une erreur peut coûter le plus cher, c’est pourquoi il est essentiel de mettre en place une base IdP-PAM avant que le nombre d’agents ne devienne difficile à gérer.
Points à retenir
Les agents d’IA sont les nouveaux principaux à privilèges dans l’infrastructure des entreprises. Le modèle de menace est bien connu : identifiants permanents, comptes surdotés en privilèges, absence de piste d’audit. La différence avec les agents est que ces problèmes surviennent plus rapidement et sont plus difficiles à détecter.
Les éléments fondamentaux sur lesquels repose la gestion des accès à privilèges, tels que l’accès JIT, l’enregistrement de session, la gestion sécurisée des identifiants, l’application des politiques et les contrôles d’élévation des privilèges, ne perdent pas de leur pertinence lorsque le principal est une IA. Ils deviennent l’élément qui permet de déployer l’accès agentique en toute sécurité dès le départ.
Ce qui doit évoluer, c’est le modèle d’identité. Le principal est désormais une paire (humain, agent). Les deux identités doivent figurer dans l’enregistrement. Reconstituer la traçabilité a posteriori, comme « à qui appartenait cet agent, et qui lʼa autorisé ? » nécessite que la plateforme comprenne cette association dès le départ, sans la reconstituer à partir des journaux de deux systèmes distincts.
Si votre architecture PAM actuelle considère l’accès des agents comme un problème de compte de service, il est pertinent de se demander si elle a été conçue pour un environnement où le principal possède deux identités, fonctionne de manière autonome et requiert un système de gouvernance qui ne se fie pas uniquement à ses déclarations concernant les actions à effectuer.
Le contenu de ce document revêt un caractère purement informatif et ne constitue pas des conseils juridiques, commerciaux ou en matière de confidentialité, sécurité ou conformité. © Okta, Inc. et/ou ses filiales.
