Série d'entretiens avec Kevin Paige, RSSI chez ConductorOne

Kevin PaigePaige, RSSI de ConductorOne, est un cadre chevronné en cybersécurité, fort de plus de trente ans d'expérience au sein d'organismes gouvernementaux, d'entreprises technologiques et de startups à forte croissance. Basé dans la région de la baie de San Francisco, il dirige la stratégie de sécurité des identités de l'entreprise et conseille les organisations sur la sécurité et la gouvernance des effectifs modernes. Auparavant, Paige a occupé le poste de RSSI chez Uptycs, Flexport et MuleSoft, où il a contribué à la mise en place et au développement de programmes de sécurité lors de périodes de forte croissance. En début de carrière, il a occupé des postes de direction en sécurité et en infrastructure chez Salesforce et xMatters, et a servi dans l'armée de terre et l'armée de l'air américaines. Parallèlement à ses fonctions opérationnelles, il est actif dans l'écosystème des startups de cybersécurité en tant que conseiller et investisseur.

Chef d'orchestre Cette plateforme de gouvernance des identités et de gestion des accès est conçue pour les environnements cloud et hybrides modernes. Sa technologie offre une visibilité unifiée sur les identités et les permissions des applications, de l'infrastructure et des systèmes sur site, permettant aux organisations d'automatiser les revues d'accès, d'appliquer le principe du moindre privilège et de réduire les risques de sécurité liés à l'identité. En combinant l'analyse des identités et les flux de travail automatisés, la plateforme aide les équipes de sécurité à gérer les accès à grande échelle tout en améliorant la conformité et l'efficacité opérationnelle.

Vous avez mené une longue carrière, des opérations cybernétiques militaires au sein de l'US Air Force à des postes de direction en sécurité d'entreprise dans des sociétés comme MuleSoft, Flexport et Salesforce, et vous êtes actuellement RSSI chez ConductorOne. Comment votre vision de la sécurité des identités a-t-elle évolué au fil de ces expériences, et pourquoi pensez-vous que l'identité est devenue l'un des enjeux majeurs de la cybersécurité moderne ?

Dans l'armée de l'air, la gestion des identités était bien plus simple : niveau d'habilitation, nécessité d'en connaître, pare-feu, et le tour était joué. Chez MuleSoft, l'enjeu était l'échelle : provisionner des milliers d'utilisateurs sur des centaines d'applications SaaS sans créer de failles de sécurité. Chez Flexport, le périmètre a complètement disparu et l'identité était le seul contrôle encore fonctionnel, quel que soit l'endroit où se trouvait l'utilisateur.

Chez ConductorOne, l'identité connaît actuellement sa transformation la plus profonde. Elle ne se limite plus aux personnes ; elle englobe désormais les machines, les API, les comptes de service et les agents d'IA agissant de manière autonome. Les outils utilisés par la plupart des organisations ont été conçus pour un monde qui n'existe plus.

L'identité est un enjeu crucial car elle a des répercussions sur tous les aspects. Vous pouvez avoir la meilleure sécurité des terminaux et la meilleure segmentation du réseau au monde ; si un utilisateur dispose d'un accès non autorisé, tout cela n'a aucune importance.

Votre prochain rapport sur l'avenir de l'identité révèle que 95 % des entreprises affirment que des agents d'IA effectuent déjà des tâches informatiques ou de sécurité autonomes. Quelles sont les tâches concrètes réalisées par ces agents aujourd'hui, et à quelle vitesse prévoyez-vous que leur niveau d'autonomie augmentera ?

Ce qui m'a surpris, ce n'est pas l'adoption en elle-même, mais sa rapidité. L'an dernier, 96 % prévoyaient de déployer des agents. Cette année, 95 % l'ont déjà fait. Il ne s'agit pas d'une progression graduelle, mais d'un franchissement brutal d'un seuil critique.

Les agents gèrent les flux de travail du service d'assistance, le tri des alertes, les vérifications d'accès, le provisionnement et, dans certains cas, la résolution automatisée des problèmes. Ce que l'on ignore souvent : 64 % des organisations autorisent déjà les agents à agir de manière autonome, avec une simple vérification a posteriori. L'agent agit d'abord, un humain vérifie ensuite, si vérification il y a.

Les agents qui assurent aujourd'hui le support technique seront amenés à prendre des décisions en matière de sécurité d'ici un an. La question n'est pas de savoir si leur autonomie augmente, mais si la gouvernance suit le même rythme. Or, ce n'est pas le cas actuellement.

Le rapport met en lumière l'essor des identités non humaines, notamment les interfaces de programmation d'applications (API), les bots et les agents d'IA. Pourquoi ces identités de machines se développent-elles si rapidement et pourquoi tant d'organisations peinent-elles encore à les gérer efficacement ?

Trois forces convergentes. L'adoption du cloud et du SaaS implique que chaque intégration nécessite sa propre identité. Le DevOps génère des identités machine à grande échelle : chaque pipeline, conteneur et microservice. Et les agents d'IA ajoutent une toute nouvelle catégorie qui, au-delà de la simple gestion des accès, les utilise pour prendre des décisions.

Les organisations rencontrent des difficultés car les outils n'ont pas été conçus pour cela. La gestion des identités et des accès (IAM) traditionnelle suppose une personne qui se connecte et se déconnecte. Or, les identités non humaines fonctionnent en continu, ne répondent pas à l'authentification multifacteur (MFA), possèdent souvent des identifiants persistants et accumulent des privilèges car leurs accès ne sont pas contrôlés comme ceux d'un humain.

Il y a aussi un problème de propriété. Lorsqu'un développeur crée un compte de service et change d'équipe, à qui appartient-il ? Souvent, à personne. Des études sectorielles montrent que 97 % des NHI disposent de privilèges excessifs. Ce n'est pas un problème d'outils, mais un problème de gouvernance.

Près de la moitié des entreprises affirment que les identités non humaines sont désormais plus nombreuses que les utilisateurs humains, pourtant seul un faible pourcentage d'entre elles dispose d'une visibilité complète sur les ressources auxquelles ces identités peuvent accéder. Quels risques encourus par les organisations perdent cette visibilité sur ces identités automatisées ?

Trois niveaux. Premièrement, les identifiants compromis. Les systèmes d'information non bancaires utilisent souvent des clés API à longue durée de vie ou des jetons statiques qui ne sont pas renouvelés. Un attaquant disposant de l'un de ces identifiants bénéficie d'un accès persistant qui ne déclenche pas les mêmes alertes qu'un compte humain compromis.

Deuxièmement, l'accumulation de privilèges. Les intégrations qui disposaient initialement d'un accès en lecture obtiennent discrètement un accès en écriture. Personne ne supprime les anciennes permissions car personne ne vérifie l'identité des machines.

Troisièmement — et ce phénomène se développe rapidement —, les agents d'IA amplifient ces deux risques. Un compte de service compromis avec un accès en lecture à une base de données est problématique. Un agent d'IA disposant du même accès et capable de résumer, de partager et d'agir de manière autonome sur les informations qu'il lit est exponentiellement pire.

Notre rapport constate que la visibilité de l'assurance maladie nationale est en réalité en baisse, passant de 30 % à 22 % d'une année sur l'autre. Les organisations découvrent le problème plus vite qu'elles ne peuvent le résoudre.

De nombreuses entreprises perçoivent l'IA comme un accélérateur de productivité, mais vos recherches suggèrent qu'elle peut aussi, insidieusement, accroître la surface d'attaque. Comment l'adoption d'outils et d'agents d'IA crée-t-elle de nouveaux risques de sécurité liés à l'identité ?

Le risque le plus immédiat est l'octroi accidentel d'autorisations excessives. Les équipes déploient un agent d'IA pour un flux de travail spécifique, mais lui accordent un accès plus étendu que nécessaire, car la gestion des autorisations pour les machines est plus complexe que pour les humains. L'agent ne se contente pas de consulter les tickets d'assistance ; il a accès à l'intégralité de la base de données clients.

Il y a ensuite l'injection de messages. Les agents traitant des entrées externes peuvent être manipulés pour effectuer des actions non prévues. Si l'agent dispose d'un accès étendu, un message spécialement conçu transforme un assistant utile en un outil d'exfiltration de données.

Troisièmement, il y a l'IA fantôme. Gartner indique que plus de 50 % de l'utilisation de l'IA en entreprise est non autorisée. Chaque connexion non autorisée crée de nouvelles identités et des surfaces d'attaque invisibles pour l'équipe de sécurité.

J'en ai été témoin : quelqu'un a donné accès à un agent aux systèmes internes, et quelques jours plus tard, quelqu'un l'a incité à révéler la rémunération et le calendrier des congés du PDG. L'agent a fonctionné comme prévu. Le problème venait du modèle d'accès.

La gestion des identités et des accès s'est traditionnellement concentrée sur la connexion des employés aux systèmes. Comment la gouvernance des identités doit-elle évoluer maintenant que des agents logiciels autonomes interagissent de plus en plus avec l'infrastructure et prennent des décisions ?

Le changement fondamental réside dans le passage d'une gouvernance périodique à une gouvernance continue. La gouvernance traditionnelle repose sur des examens trimestriels et des recertifications annuelles. Les agents d'IA fonctionnent 24 h/24 et 7 j/7, prennent des milliers de décisions entre deux cycles d'examen et peuvent modifier leur comportement suite à une mise à jour du modèle. Lorsqu'un examen trimestriel détecte un agent aux privilèges excessifs, le mal est déjà fait.

Trois éléments doivent changer. La gouvernance doit être continue : l’évaluation des accès doit se faire en temps réel, et non selon un calendrier prédéfini. Elle doit être axée sur des politiques plutôt que sur les rôles : des politiques dynamiques adaptées à des tâches spécifiques, et non des attributions de rôles statiques. Enfin, elle doit être entièrement auditable : chaque action d’un agent doit être consignée et traçable jusqu’à l’auteur de l’autorisation.

La gouvernance des identités doit fonctionner à la vitesse de la machine pour contrôler des acteurs fonctionnant eux aussi à la vitesse de la machine. C'est dans ce décalage que réside le risque.

ConductorOne décrit sa plateforme comme aidant les organisations à sécuriser conjointement les identités humaines et machine. D'un point de vue technique, quelles modifications sont nécessaires au niveau de l'infrastructure d'identité pour sécuriser correctement les agents d'IA opérant au sein d'environnements d'entreprise ?

Le changement majeur réside dans l'unification. La plupart des organisations gèrent les identités humaines via leur système de gestion des identités (IDP) et les identités des machines grâce à un ensemble disparate de gestionnaires de secrets et de processus manuels. Les agents d'IA comblent l'écart entre ces deux mondes.

Trois conditions sont nécessaires. Chaque agent d'IA doit posséder une identité propre et dédiée, avec son propre cycle de vie et son historique d'audit. Il ne s'agit ni d'un compte de service partagé, ni d'identifiants de développeur. Ces identités doivent disposer d'un accès limité et limité aux besoins spécifiques de chaque tâche, révoqué une fois celle-ci terminée. Enfin, les organisations doivent surveiller en permanence l'utilisation réelle de ces accès par les agents, et non seulement ce qu'ils sont autorisés à faire.

Chez ConductorOne, nous gérons les identités humaines et non humaines via une plateforme unique. C'est la voie que suit le secteur : 45 % des entreprises utilisent déjà des outils IAM pour la gouvernance des identités non humaines, et 45 % supplémentaires prévoient de le faire d'ici un an. La gouvernance des identités exclusivement humaines est vouée à disparaître.

Certaines organisations tentent de gérer les risques liés à l'IA en restreignant, voire en interdisant totalement, les outils d'IA. Au vu de ce que vous observez dans les entreprises, cette approche est-elle réaliste, ou ne fait-elle que déplacer l'utilisation de l'IA vers des environnements non gérés et moins visibles ?

Ça pousse le système à la clandestinité. À chaque fois. Je l'ai constaté à chaque vague technologique : BYOD, cloud, SaaS. Quand les services de sécurité disent non, les gens ne s'arrêtent pas. Ils cessent simplement de communiquer avec eux.

Gartner indique que l'IA parallèle représente plus de 50 % de l'utilisation de l'IA en entreprise. Interdire l'IA n'élimine pas le risque ; cela supprime la visibilité. Et on ne peut pas sécuriser ce qu'on ne voit pas.

La meilleure approche : simplifier au maximum l’accès sécurisé. Si l’adoption de l’IA encadrée est rapide et simple, les utilisateurs l’adopteront. Si l’approbation prend six semaines, ils créeront un compte personnel pendant leur pause déjeuner.

Interdire l'IA en 2026, c'est comme interdire le cloud en 2016. Vous ne prévenez pas le risque, vous vous assurez simplement de ne pas le voir venir.

À mesure que les systèmes d'IA gagnent en autonomie, la frontière entre automatisation et autorité s'estompe. Comment les organisations doivent-elles envisager la gouvernance, les approbations et le contrôle lorsque des agents d'IA sont capables d'entreprendre des actions opérationnelles ?

Privilégiez la délégation à l'automatisation. Déléguer, c'est définir le périmètre du projet, responsabiliser la personne et contrôler son travail. Ce principe s'applique également aux agents.

Cela implique une autonomie à plusieurs niveaux. Les tâches répétitives à faible risque (réinitialisation de mots de passe, acheminement des tickets) s'exécutent de manière autonome avec journalisation. Les actions à risque moyen (modifications de la configuration de sécurité, accès privilégié) nécessitent une approbation humaine ou une notification en temps réel. Les actions à haut risque (données sensibles, accès privilégié, modifications irréversibles) requièrent une autorisation explicite avant toute intervention de l'agent.

Chaque agent a également besoin d'un responsable humain pour assumer la responsabilité de ses actions. Sans cette chaîne de commandement, les agents opèrent dans un vide de gouvernance où personne n'est tenu de répondre des conséquences.

Notre rapport révèle que seulement 19 % des entreprises appliquent en continu des politiques de sécurité aux agents. Autrement dit, 81 % se contentent d'autorisations statiques et espèrent le pire. Ce n'est pas de la gouvernance.

Quelles sont, pour les 12 à 24 prochains mois, les mesures les plus importantes que les responsables de la sécurité devraient prendre pour préparer leurs cadres d'identité et d'accès à un monde où les agents d'IA fonctionnent comme des identités numériques complètes au sein de l'entreprise ?

Cinq priorités.

Tout d'abord, il faut gagner en visibilité. La plupart des organisations ignorent le nombre d'identités non humaines qu'elles gèrent. On ne peut gouverner ce qu'on ne voit pas.

Deuxièmement, traitez chaque agent IA comme un utilisateur : identité dédiée, permissions limitées, rotation des identifiants, vérification des accès. Si vous n’accorderiez pas à un administrateur humain un accès complet à toutes les ressources, ne l’accordez pas à un agent.

Troisièmement, il faut passer d'une gouvernance périodique à une gouvernance continue. Les évaluations trimestrielles ne permettent pas de suivre le rythme des agents qui modifient leur comportement en quelques secondes.

Quatrièmement, élaborez votre cadre de politiques dès maintenant, avant d'avoir des centaines d'agents. Définissez les limites d'autonomie, les exigences d'approbation et la responsabilité tant que la situation reste gérable.

Cinquièmement, unifier la gouvernance entre les identités humaines et non humaines. Les systèmes séparés créent des lacunes.

Les gagnants ne seront pas les organisations qui auront déployé le plus d'IA, mais celles qui auront mis en place une gouvernance des identités capable de fonctionner à la vitesse des machines.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter Chef d'orchestre.