Le risque d’identité caché de l’IA pour les MSP

Les organisations intègrent rapidement l’IA dans leurs opérations quotidiennes. Les équipes utilisent Microsoft Copilot et Gemini pour résumer les réunions, les développeurs accélèrent la livraison de logiciels avec des copilotes de codage et les équipes du service client déploient des chatbots alimentés par l’IA pour réduire les délais de réponse. Bien que ces initiatives soient abordées sous l’angle de la productivité et de l’innovation, elles remodèlent également les environnements d’identité des entreprises d’une manière qui passe souvent inaperçue.

Chaque déploiement d’IA repose sur un accès de confiance aux systèmes d’entreprise. Qu’un assistant d’IA se connecte à Microsoft 365, Salesforce, SharePoint ou à une base de connaissances interne, il s’authentifie, récupère des informations et effectue des actions à l’aide d’identifiants et de permissions qui doivent être accordés et gérés. Par conséquent, chaque déploiement introduit une nouvelle identité qui doit être sécurisée.

Lors des réunions avec les clients comme dans les échanges entre dirigeants, les conversations sur l’IA tournent généralement autour des gains de productivité, des politiques de gouvernance et de l’usage acceptable. Les identités créées pour prendre en charge ces technologies font l’objet de peu d’attention.

Alors, quelles nouvelles identités créons-nous au cours de ce processus ?

La réponse soulève des enjeux qui vont bien au-delà de l’adoption de l’IA.

Comment l’IA accroît la surface d’attaque des identités pour les MSP

Regardons ce qui se passe lorsqu’une entreprise déploie un nouvel outil d’IA :

Une équipe marketing connecte un assistant de rédaction basé sur l’IA à SharePoint. Une équipe commerciale active un assistant CRM alimenté par l’IA. Un responsable du service client lance un chatbot connecté à la documentation interne. L’équipe chargée des opérations automatise les flux de travail répétitifs grâce à une orchestration pilotée par l’IA.

Chaque déploiement semble être une amélioration de la productivité mise en place de manière isolée. Toutefois, du point de vue de la sécurité, les implications sont beaucoup plus profondes.

Chacune de ces solutions nécessite un accès de confiance afin d’accomplir les tâches pour lesquelles elle est conçue. Certaines s’authentifient via des connexions OAuth, tandis que d’autres s’appuient sur des clés API, des comptes de service, des identifiants machine ou des jetons d’accès. Chacune reçoit l’autorisation de récupérer des informations, d’interagir avec les applications métier et d’exécuter des actions au nom des utilisateurs. Prises individuellement, ces identités attirent rarement beaucoup d’attention. Ensemble, elles commencent à étendre ce que de nombreuses organisations ne mesurent jamais : leur surface d’attaque liée aux identités.

L’expansion rapide de l’IA au sein des entreprises rend cet enjeu difficile à ignorer. Selon le baromètre Work Trend Index 2025 de Microsoft, 82 % des dirigeants d’entreprise affirment qu’il s’agit d’une année charnière pour repenser les aspects fondamentaux de la stratégie et des opérations via l’IA. Le rapport a également révélé que 46 % des organisations utilisent déjà des agents d’IA pour automatiser entièrement des flux de travail ou des processus métier, ce qui illustre la rapidité avec laquelle l’IA passe de l’expérimentation aux opérations quotidiennes.

Ces chiffres reflètent bien plus qu’une utilisation accrue de l’IA.

Ils mettent en évidence un nombre croissant d’applications, de flux de travail et de processus automatisés nécessitant un accès de confiance au sein des environnements d’entreprise.

Pourquoi les identités non humaines (NHI) entraînent des risques cachés

Les programmes d’identité traditionnels ont été conçus autour des utilisateurs humains. Un salarié rejoint l’organisation, se voit ouvrir un compte, obtient un accès aux systèmes nécessaires et finit par se voir retirer cet accès lorsqu’il change de poste ou quitte l’entreprise. Bien que ce processus ne soit pas toujours fluide, il suit un cycle de vie prévisible avec une propriété définie.

Ce n’est pas le cas de l’IA.

Un assistant d’IA peut s’authentifier via un jeton OAuth. Une plateforme d’automatisation des flux de travail peut s’appuyer sur plusieurs comptes de service et clés API. Un agent autonome peut accéder à plusieurs applications d’entreprise en utilisant des identifiants machine qui fonctionnent en continu sans interaction humaine directe. Contrairement aux comptes des salariés, ces identités sont souvent créées instantanément lors de la configuration de l’application ou par des administrateurs, des développeurs et des utilisateurs de l’entreprise qui connectent des outils d’IA à des systèmes existants.

Un grand nombre de ces identités existent en dehors des processus déjà mis en place par les organisations pour encadrer les employés. Certaines restent actives alors qu’elles ne sont plus nécessaires depuis longtemps, car leur suppression peut perturber les flux de travail ou rompre les intégrations. Au fil du temps, les organisations accumulent des centaines, voire des milliers d’identités qui ne sont pas liées à une personne, mais qui disposent pourtant d’un accès légitime aux principaux systèmes d’entreprise.

Les professionnels de la sécurité les regroupent sous l’appellation d’identités non humaines (NHI) : des identités numériques employées par les applications, les services, les charges de travail et les processus automatisés, par opposition aux employés. Bien que ce terme puisse être inconnu pour certaines organisations, le concept, lui, ne l’est pas. Chaque clé API, connexion OAuth, compte de service, identifiant machine et agent d’IA agissant au nom d’un utilisateur représente une identité disposant d’un accès privilégié qui doit être gérée tout au long de son cycle de vie.

Le nombre de NHI n’est pas figé. Chaque nouveau déploiement de l’IA, flux de travail automatisé et intégration de système introduit des identifiants, des comptes de service et des identités machines qui doivent être gérés et encadrés. À mesure que les applications, les flux de travail et les systèmes deviennent de plus en plus interconnectés, le maintien de la visibilité est de plus en plus difficile.

Ce n’est pas simplement un problème d’inventaire. C’est un problème de visibilité et de contrôle.

Les organisations ne peuvent pas protéger efficacement des identités dont elles ignorent l’existence, examiner régulièrement des autorisations qu’elles ne peuvent pas voir ou supprimer des accès dont elles n’ont pas connaissance.

Malheureusement, les attaquants n’ont pas à se soucier de cette limitation.

Pourquoi les attaquants ciblent les identités machines non gérées

Les cybercriminels ne font pas de distinction entre les identités humaines et machines. Ils cherchent simplement la voie le plus rapide pour accéder aux systèmes à forte valeur et aux données sensibles.

Pendant des années, les campagnes d’hameçonnage et le vol d’identifiants ciblaient principalement les employés, car les comptes d’utilisateurs représentaient la voie la plus directe vers l’environnement d’une organisation. Cette réalité n’a pas changé, mais le nombre de points d’entrée potentiels, si.

Aujourd’hui, les attaquants exploitent de plus en plus les clés API, les comptes de service, les jetons d’accès et les identifiants machine, car ces identités fonctionnent souvent avec des autorisations étendues, des accès permanents et beaucoup moins de surveillance que les comptes utilisateurs classiques. Contrairement à un compte d’employé, un compte de service ne remettra pas en question une requête inattendue, une clé API ne signalera pas d’activité suspecte et un agent d’IA ne pourra pas reconnaître qu’il interagit avec un système malveillant. Si ces identités sont compromises, elles fournissent souvent aux attaquants exactement ce dont ils ont besoin : un accès légitime.

Selon le Threat Detection Report de 2025 de Red Canary, les attaques basées sur l’identité ont augmenté de 850 % par rapport à 2024 et ont représenté 53 % du volume global de détection en 2025, ce qui illustre la dépendance croissante des attaquants au vol d’identifiants et aux techniques d’attaque basées sur l’identité.

Chaque nouveau déploiement d’IA introduit une autre identité machine, un autre compte de service ou un autre identifiant au sein de l’environnement.

L’enjeu n’est pas simplement la multiplication des identités. Le problème, c’est que bon nombre de ces identités reçoivent des autorisations qui dépassent le cadre nécessaire, restent actives plus longtemps que prévu ou fonctionnent sans surveillance continue. Pris individuellement, ces problèmes peuvent paraître insignifiants. Or, ensemble, ils créent un groupe croissant d’identités de confiance que les attaquants peuvent exploiter.

Plus les organisations choisissent de déployer des outils d’automatisation, plus il devient crucial de comprendre non seulement qui a accès aux systèmes critiques, mais aussi ce qui y a accès.

Pourquoi la sécurité des identités IA est essentielle pour les MSP

Pour la plupart des organisations, la gestion de cet écosystème d’identités en pleine croissance ne représente pas seulement un enjeu technique ; c’est un défi de visibilité.

De nombreuses entreprises ne savent tout simplement pas combien de NHI ont été déployées dans leurs environnements, à quels systèmes elles peuvent accéder ou si ces autorisations sont encore nécessaires. Les initiatives en matière d’IA sont souvent menées par des départements, des unités commerciales ou des développeurs individuels afin de répondre à un besoin immédiat. La gouvernance des identités à long terme fait rarement l’objet d’une discussion.

Pour les MSP, c’est là que l’expertise devient un facteur de différenciation.

Historiquement, les MSP ont aidé les clients à protéger les terminaux, à gérer l’infrastructure et à déployer des solutions de cybersécurité. À mesure que les clients intégreront l’IA dans leurs opérations, ils s’appuieront sur des conseillers de confiance pour assurer une meilleure gouvernance des identifiants, des autorisations et des identités machines que ces technologies introduisent.

Pour aider les clients à aborder cette transition, il convient de commencer par une série de questions différentes :

• Quelles applications d’IA ont actuellement accès aux systèmes critiques de l’entreprise ?
• Quels comptes de service et clés API sont encore activement requis ?
• À qui appartient chaque identité machine ?
• Les autorisations sont-elles conformes aux principes du moindre privilège ?
• Comment les identifiants sont-ils renouvelés, surveillés et protégés ?

En engageant ces discussions et en y revenant à mesure que les environnements d’IA évoluent, les MSP passent du rôle de fournisseur technologique à celui de conseiller stratégique. En aidant leurs clients à gouverner les identités liées à l’IA, les MSP peuvent minimiser les risques à long terme tout en permettant une adoption responsable de l’IA.

Comment KeeperMSP peut aider les clients à bâtir une base d’IA sécurisée

Comprendre le problème n’est que la première étape. Aider les clients à le résoudre exige de disposer des bonnes bases en matière de sécurité des identités.

Pour les MSP, cela signifie accompagner les clients dans la mise en œuvre d’un cadre permettant de gouverner les accès privilégiés de manière cohérente, pour les identités humaines comme pour les identités machines. Cela signifie sécuriser les identifiants, imposer un accès de moindre privilège, protéger les secrets, surveiller les sessions privilégiées et maintenir une visibilité tout au long du cycle de vie des identités.

Plutôt que de traiter l’accès lié à l’IA comme un enjeu de sécurité distinct, les MSP devraient encourager leurs clients à l’intégrer dans leur stratégie globale de sécurité des identités. Que l’accès appartienne à un salarié, une application, un agent d’IA ou un flux de travail automatisé, les mêmes principes fondamentaux doivent s’appliquer : vérification des accès, application du principe du moindre privilège, protection des identifiants et surveillance continue de l’activité. Une approche unifiée réduit la complexité tout en garantissant que les clients maintiennent des contrôles de sécurité cohérents à mesure que leurs environnements continuent d’évoluer.

La plateforme KeeperMSP a été conçue pour relever ces défis. Grâce à son architecture de sécurité zero knowledge, ses fonctionnalités de gestion des mots de passe d’entreprise, de gestion des accès privilégiés (PAM), de gestion des secrets et d’accès distant sécurisé, Keeper permet aux fournisseurs d’aider les clients à sécuriser les identifiants, les secrets et les voies d’accès privilégié que les attaquants adorent cibler. Au lieu de s’appuyer sur des outils distincts, les MSP peuvent gérer à la fois les identités humaines et machines grâce à une plateforme unique reposant sur des principes zero trust et une gouvernance continue des accès.

Pour les MSP, la valeur va bien au-delà de la technologie. Cette approche offre la visibilité, le contrôle et l’évolutivité nécessaires pour aider les clients à adopter l’IA sans que leur surface d’attaque liée à l’identité ne dépasse leur stratégie de sécurité.

Chaque déploiement d’IA crée de nouveaux risques de sécurité liés aux identités

Chaque déploiement d’IA étend l’écosystème d’identités d’une organisation et, avec lui, la responsabilité de gérer et d’encadrer chaque nouvelle identité avec la même rigueur que ses homologues humains. Les organisations qui font rapidement le rapprochement seront mieux positionnées pour innover sans accroître inutilement leur surface d’attaque.

Pour les MSP, aider leurs entreprises gérées à comprendre et gouverner ces identités représente bien plus qu’un nouveau déploiement technologique. Cela place les MSP à la pointe de l’une des évolutions les plus importantes en matière de cybersécurité depuis le passage au cloud. En aidant leurs clients à relever les défis créés par l’IA, les MSP peuvent renforcer leur rôle de conseillers indispensables tout en permettant aux organisations de suivre le rythme de l’innovation sans compromettre la visibilité ni le contrôle.

Chaque déploiement d’IA introduit bien plus qu’une nouvelle capacité : il s’accompagne d’une identité supplémentaire à sécuriser.

Découvrez le Programme de partenariat de Keeper pour les MSP et comment il aide les MSP à faire face à l’empreinte croissante de l’IA en matière d’identités.