Vos terminaux exécutent des agents d’IA invisibles pour vous

En quoi consiste la Shadow AI sur le terminal ?

La Shadow AI sur les terminaux désigne les logiciels d’IA locaux, les LLM et les intégrations serveur Model Context Protocol (MCP) déployés directement sur le matériel des collaborateurs sans achat formel, sans évaluation de sécurité ni gouvernance des identités. Si l’IA sur navigateur présente des risques de fuite de données, les agents d’IA sur terminal interagissent directement avec les systèmes de fichiers locaux et les systèmes SaaS via des serveurs MCP en arrière-plan.

Le risque ne concerne plus uniquement les agents qui se connectent via des navigateurs. Désormais, chaque collaborateur ou collaboratrice peut créer plusieurs agents d’IA sur son ordinateur portable. C’est tellement simple que ce n’est plus réservé aux fonctions techniques. N’importe qui peut le faire. 

Ces agents accélèrent considérablement la vitesse d’exécution, mais engendrent un problème d’identité complexe : aucune gestion centralisée de l’identité, aucune définition de périmètre, aucune traçabilité, aucun contrôle des accès. 

Comment les serveurs MCP élargissent la surface d’attaque des terminaux

Les agents d’IA n’agissent pas seuls. Pour accomplir une tâche utile, un agent doit pouvoir accéder à différents systèmes, ce qui, aujourd’hui, passe presque toujours par le serveur MCP. C’est le lien entre un agent et tout ce avec quoi il peut interagir.

Quelques clics suffisent pour connecter ces agents aux applications les plus sensibles de votre entreprise via un serveur MCP. L’agent réside sur l’appareil, mais il effectue des appels qui atteignent directement votre CRM, vos applications SaaS, votre infrastructure cloud et bien d’autres ressources.

La fondation OWASP répertorie le « MCP tool poisoning » (empoisonnement de l'outil MCP) comme un vecteur d’attaque critique, en précisant que, les descriptions des outils étant généralement examinées uniquement lors de la connexion initiale, un serveur MCP compromis ou contrôlé par un attaquant peut modifier les métadonnées des outils à l’exécution. Une fois la connexion établie, les définitions d’outils modifiées sont chargées dans la fenêtre de contexte du modèle afin de détourner l’exécution et d’extraire des données.

En cas d’incident, votre équipe sécurité peut-elle identifier ces agents, savoir qui en est responsable et déterminer à quelles applications et données ils ont accès ? Beaucoup n’y parviennent pas.

Et si vous ne pouvez pas répondre à cette question, vous ne pourrez pas non plus répondre à la première question du plan d’action pour l'entreprise agentique sécurisée: où sont mes agents ?

Multipliez cela sur chaque appareil, et l’exposition s’accroît rapidement.

Comment les agents IA non surveillés contournent les contrôles de sécurité d'entreprise ?

Les agents d’IA locaux contournent les contrôles de sécurité d’entreprise en utilisant des connexions MCP non vérifiées, en héritant des autorisations des utilisateurs humains sans identités d’agent distinctes, en conservant un accès permanent et en effectuant des modifications d’outils à l’exécution, le tout sans générer de journaux d’audit centralisés pour l’équipe IT.

Derrière ces vulnérabilités se trouve une seule cause profonde : un manque de visibilité sur les terminaux. Lorsque les équipes sécurité ne peuvent pas voir les agents d’IA ni les serveurs MCP auxquels ils se connectent, les frameworks standard de gestion des identités et des accès présentent des lacunes. 

Voici les cinq principales méthodes permettant aux agents de contourner vos contrôles.

1. Les serveurs MCP connectent des agents à des systèmes métier à votre insu

Créer et connecter des serveurs MCP qui accèdent à des systèmes sensibles est relativement simple, et leur utilisation se résume à exécuter une seule commande dans le terminal. Connecter un agent terminal non approuvé à vos applications, par exemple à votre tenant Snowflake, ne prend que quelques minutes. Cet agent d’IA réside désormais dans votre système le plus sensible et peut interroger toutes les tables auxquelles il a accès, sans que vous ayez à l’approuver ni même en être informé.

La promesse de productivité incite vos collaborateurs et collaboratrices à connecter ces serveurs à des agents d’IA sans prendre en compte les conséquences en matière de sécurité.  

Lorsque les mesures de sécurité ne suivent pas le rythme, des connexions critiques restent sans surveillance ni contrôle. Cela signifie qu’une connexion à vos données les plus sensibles peut rester active indéfiniment, sans qu’aucune personne ne soit responsable de ce à quoi elle accède et sans aucun historique à consulter lorsque, tôt ou tard, un incident survient. C’est une brèche sur le point de se produire.

2. Les données circulent entre des systèmes qui n’ont jamais été examinés de manière centralisée

Un agent déplace des données en fonction de sa propre évaluation de ce qui est utile pour la tâche en cours. Cette évaluation ne prend pas en compte la classification de vos données, les règles de résidence, ni qui est autorisé à voir quoi. Personne n’a validé cette décision. Aucune politique ne définit ce à quoi l’agent peut accéder, si bien qu’il se retrouve connecté à plusieurs systèmes en même temps, et c’est cette combinaison qui crée le risque. 

Par exemple, le même agent capable de lire des données client peut également envoyer des e-mails à n’importe qui. Voici à quoi ressemblent des autorisations étendues, qui permettent à vos agents d’accéder à plus de données que nécessaire pour effectuer une seule action. Résultat : un seul prompt compromis suffit à déclencher une brèche majeure.

3. Les agents agissent via l’accès d’une autre personne, sans identité propre

Les agents s’authentifient généralement auprès des systèmes via une autorisation OAuth ou une clé API enregistrée dans le fichier de configuration du serveur MCP. Une fois que c’est en place, il n’existe pas de méthode fiable pour déterminer si une action provient de la personne ou de l’agent agissant en son nom. Ils sont liés entre eux sous une même identité. Ainsi, lorsque quelque chose ne fonctionne pas, vous ne pouvez pas répondre à la première question que tout le monde posera : s’agissait-il de la personne ou de l’agent ?

Par exemple, l’agent d’un employé du service comptable met à jour un enregistrement de paiement à un fournisseur pendant la nuit. Le journal indique que la modification provient des identifiants de l’employé, mais il est impossible de savoir si l’employé ou son agent en est à l’origine, ni si cette action a été vérifiée.

Répondre à la question de savoir qui est intervenu implique d’extraire les journaux de chaque système avec lequel l’agent a interagi, puis de recouper manuellement les horodatages entre des formats qui n’ont jamais été conçus pour communiquer entre eux. Ce qui devrait prendre quelques minutes se transforme en plusieurs jours passés à reconstituer une seule action sur différents systèmes déconnectés.

4. Les agents demandent l’autorisation une seule fois et obtiennent un accès permanent

Il y a encore quelques mois, la plupart d’entre nous se méfiaient encore de ce que faisaient les agents d’IA. Nous nous arrêtions et vérifiions chaque fois qu’un agent avait besoin d’autorisations supplémentaires ou souhaitait faire appel à une API système. Désormais, nous les laissons fonctionner de manière autonome. Les outils agentiques lancent des modes automatiques dans lesquels l’agent poursuit son travail de manière autonome via des appels d’outils, selon des règles d’autorisation et de refus que vous configurez une seule fois.

Prenons cet exemple : une personne salariée confie à son agent une tâche complexe et de longue durée, puis la programme pour qu’elle s’exécute automatiquement. À un certain moment, l’agent décide de manière autonome que modifier des enregistrements dans Salesforce ou Snowflake est la meilleure façon d’accomplir la tâche, et il le fait. La personne salariée n’a jamais approuvé cette action précise et il est possible qu’elle ne se rende même pas compte que cela s’est produit. Personne n’examine la modification tant qu’une anomalie ne survient ou qu’un problème n’apparaît.

5. Le serveur MCP accorde aux agents un accès que vous ne contrôlez pas

Un serveur MCP fournit à votre agent une liste d’outils, chacun accompagné d’une description expliquant quand et comment l’utiliser. La personne qui a développé ce serveur a rédigé ces descriptions, et non vos équipes informatiques et de sécurité. Votre utilisateur a vu un nom dans un menu et a cliqué sur « Approuver », sans vérifier qui avait créé le serveur ni ce qu’il exécute.

Et les descriptions ne sont pas figées. Si la personne responsable du serveur MCP modifie une description, change une autorisation ou ajoute un outil, votre agent en bénéficie automatiquement, sans nouvelle validation ni réexamen. Ce qui fonctionnait lundi ne correspond pas forcément à ce qui fonctionne vendredi.

Voici un exemple : une personne salariée ajoute un outil pour son agent. Le propriétaire du serveur MCP déploie une mise à jour qui modifie son comportement. Lors de sa prochaine connexion, l’agent bénéficie de la nouvelle fonctionnalité sans alerte ni seconde validation.

Comment les équipes sécurité peuvent détecter et sécuriser la Shadow AI sur les terminaux avec Okta for AI Agents

Vous ne pouvez pas définir le périmètre, examiner ni révoquer un agent que vous n’avez jamais identifié, et vous ne pouvez pas accorder une confiance totale à un agent qui n’a pas été intégré à la gouvernance des identités. 

Okta for AI Agents est conçu pour combler cette lacune.

1. Découverte des terminaux : voir chaque agent et serveur MCP en cours d’exécution sur le terminal

Okta s’intègre aux capteurs de terminaux existants, désormais compatibles avec CrowdStrike Falcon EDR, afin de détecter les agents d’IA et les serveurs MCP connectés. Aucun agent supplémentaire sur les terminaux n’est requis. Cela étend la couverture de découverte d’Okta aux agents qui s’exécutent en dehors du navigateur et qui ne seraient pas autrement détectés via les autorisations OAuth. Okta Verify est la prochaine source que nous mettons en ligne, de sorte que la découverte sur les terminaux ne dépende d’aucun EDR en particulier, avec une prise en charge prévue pour d’autres plateformes EDR par la suite.

2. S’enregistrer en tant qu’identités de premier ordre : inscription centralisée dans l’annuaire

Les agents sont inscrits dans Universal Directory aux côtés de vos autres identités non humaines, de vos agents d’IA et même de vos identités humaines. Chaque agent reçoit une identité unique. Avec cette solution, vous pouvez définir à quoi cet agent peut accéder et obtenir une piste d’audit complète.

3. Cartographie et corrélation des identités : lier les agents à leurs propriétaires humains

Les agents découverts sont associés au compte humain authentifié concerné, offrant aux équipes sécurité une visibilité complète sur les entités humaines et non humaines en un seul endroit. Cette correspondance reste valable en cas de changement : lorsque les propriétaires changent de rôle ou quittent l’entreprise, et lorsque de nouveaux sous-agents sont créés dans une chaîne de délégation, le contexte de propriété reste corrélé au lieu de se perdre.

4. Autorisation à l’exécution : application de la politique au moment de l’action

Appliquez la politique d’accès à chaque exécution d’un appel d’outil, et non uniquement lors de la configuration, avec Agent Gateway. Les agents ne détiennent que des tokens à durée de vie limitée plutôt que des identifiants permanents, et l’accès peut être révoqué instantanément au niveau de la passerelle, sans attendre la prochaine revue des accès pour détecter les changements.

5. Gouvernance continue des accès : revues des accès et révocation des accès

Effectuer des évaluations d’accès périodiques incluant les agents ainsi que les identités humaines, afin que les équipes sécurité puissent démontrer aux auditeurs que chaque accès d’agent a été examiné et validé. Et lorsqu’un agent dévie ou est compromis, un mécanisme d’arrêt d’urgence le désactive et met fin à tout nouvel accès sur tous les systèmes connectés auxquels il est relié.

Reprendre le contrôle de l’IA de votre entreprise

Lisez le plan d'action pour l'entreprise agentique sécurisée afin d’en savoir plus sur la montée en puissance sécurisée de votre IA d’entreprise.

Disponibilité : la fonctionnalité Shadow AI Agent Discovery for Endpoints est désormais disponible en Early Access pour les clients Identity Security Posture Management et Okta for AI Agents via l’intégration CrowdStrike Falcon EDR. Si vous utilisez déjà CrowdStrike, le capteur dont vous disposez fait office de source et aucun nouvel élément n’est installé sur le terminal.

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é. Pour obtenir de tels conseils, il vous revient de vous adresser à vos propres conseillers professionnels en matière de sécurité, confidentialité ou conformité. Toute mention de produits, fonctions, fonctionnalités ou certifications futurs dans cet article de blog revêt un caractère purement informatif. Ces éléments ne constituent pas des engagements et ne doivent pas être considérés comme un facteur déterminant dans les décisions d’achat. © Okta, Inc. et/ou ses affiliés 2026.