Passer au contenu principal
Image de blog pour comprendre l’IA fantôme dans votre environnement d’endpoints
Problème émergent

Comprendre l’IA fantôme dans votre environnement d’endpoints

L’IA générative et les grands modèles linguistiques en particulier ont atteint l’ adoption massive des consommateurs à partir de la fin 2022 et du début 2023, ChatGPT atteignant 100 millions d’utilisateurs plus rapidement que n’importe quelle application grand public de l’histoire.

Depuis lors, l’IA a progressé à un rythme effréné et semble désormais être intégrée à chaque outil, application et site Web, quelle que soit son utilité. Il existe des utilisations incroyables, puissantes et multipliant la force pour les technologies d’IA, mais l’expansion et l’adoption rapides posent des risques que la plupart des organisations n’étaient pas prêtes à gérer, en particulier lorsque les systèmes d’IA vont au-delà de l’expérimentation et de l’action, créant les conditions d ’une prolifération de l’IA agentique où l’autonomie et l’évolutivité dépassent la visibilité et le contrôle.

[Découvrez comment les développements récents de l’IA agentique font passer les systèmes autonomes des rôles de conseil à l’exécution directe, et ce qui modifie les demandes de gouvernance informatique]


Oui, l’IA est une nouvelle frontière audacieuse, mais la gestion et la visibilité des actifs continuent d’être la base d’une bonne sécurité et d’une bonne gestion des risques. Nous sommes allés au-delà du matériel, des systèmes d’exploitation et des logiciels installés et nous devons désormais prendre en compte des éléments tels que la nomenclature logicielle (SBOM), les écosystèmes de navigateurs, les environnements de développement intégrés (IDE), les logiciels en tant que service (SaaS) basés sur le cloud et toutes les façons dont l’IA peut apparaître dans votre organisation.

Passons en revue le paysage, les menaces et les composants de base dont vous avez besoin pour relever le défi.

Qu’est-ce que l’IA fantôme ?

La plupart des professionnels de la technologie, du service d’assistance à la direction, connaissent parfaitement « l’informatique fantôme », les logiciels et les appareils que les employés utilisent sans approbation formelle. Comme son prédécesseur, l’« IA fantôme » fait référence à la présence ou à l’utilisation d’outils, d’applications ou d’infrastructures d’IA sans la connaissance ou l’approbation des équipes informatiques ou de sécurité.

Dans la plupart des cas, l’utilisation de l’IA fantôme est inoffensive. La plupart des personnes souhaitent maximiser leur productivité avec une nouvelle technologie, ou peuvent-être utilisent-elles un outil qu’elles ne réalisent même pas avec des capacités d’IA intégrées. Le risque de l’IA fantôme n’est pas en présence d’outils d’IA seuls, c’est dans les connexions, les actions et le flux de données que vous n’avez peut-être pas de visibilité. De plus, contrairement à l’informatique fantôme, l’IA fantôme peut agir, décider et propager les risques de manière autonome.

Il existe un écart de visibilité significatif dans la couverture de l’IA fantôme :
les outils de sécurité traditionnels (DLP cloud, CASB, pare-feux) sont aveugles de l’IA locale. L’IA locale et basée sur le cloud nécessite différentes techniques de surveillance. Malheureusement, la vitesse d’exposition et d’adoption de l’IA dépasse notre capacité à gouverner et sécuriser.

Pour comprendre où se cache l’IA fantôme et pourquoi elle est si difficile à gérer, il est utile de connaître certaines des principales formes qu’elle prend dans les environnements d’entreprise aujourd’hui.

Le premier exemple est les modèles d’IA locaux où le modèle de langage d’IA s’exécute directement sur la machine d’un utilisateur ou un serveur interne plutôt que dans un service cloud tel que les navigateurs ou applications de ChatGPT, Copilot ou Claude.

Le second mécanisme est celui des agents d’IA qui étendent la capacité des LLM au-delà de la réponse aux questions et leur permettent d’effectuer des actions, de se connecter à d’autres outils et données, et d’opérer avec un certain degré d’autonomie. Les deux mécanismes comportent des risques, et les deux peuvent apparaître si vous les avez approuvés ou non.

Modèles locaux

L’attrait des modèles locaux se résume à un mot : la confidentialité.

Lorsque vous utilisez un service d’IA basé sur le cloud comme ChatGPT, Gemini ou Microsoft Copilot, vos invites et les données que vous partagez voyagent vers des serveurs appartenant à un tiers. Ces données peuvent être utilisées pour entraîner de futurs modèles, stockées de manière à ce que vous ne puissiez pas auditer, ou dans certains cas exposées par inadvertance, par exemple lorsque ChatGPT a introduit une fonctionnalité de « partage » dans 2023 avec une case à cocher pour rendre les chats détectables par les moteurs de recherche. Des milliers d’utilisateurs ont activé la fonctionnalité sans se rendre compte de ce qu’ils faisaient, et les conversations « privées » sont devenues des succès Google.

L’exécution locale d’un modèle signifie que vos données ne quittent jamais votre machine ou votre réseau interne, ce qui semble être exactement la bonne réponse pour les organisations qui traitent des documents sensibles, opèrent dans des secteurs réglementés ou prennent en charge des environnements où l’accès à Internet externe n’est pas possible.

Ça me semble génial, n’est-ce pas ? Pas si rapide. L’installation locale ne signifie pas automatiquement privée. En juillet 2025, Trend Micro a découvert plus de 10 000 serveurs exécutant Ollama, un outil open source populaire pour exécuter des modèles d’IA localement, qui ont été exposés publiquement sans authentification requise.

Un serveur de modèle local mal configuré peut être interrogé par toute personne qui peut l’atteindre, ce qui signifie qu’un attaquant peut le sonder pour obtenir des informations, extraire des données ou l’utiliser comme pied-à-terre dans le réseau plus large, sans jamais avoir d’accès physique à la machine sur laquelle il s’exécute.

Les modèles locaux sont généralement plus petits et formés sur moins de données que leurs homologues cloud, ce qui signifie qu’ils ont plus de lacunes dans leurs connaissances et qu’ils sont plus susceptibles de combler ces lacunes avec des informations qui semblent plausibles, mais qui sont incorrectes, ce que l’industrie appelle l’hallucination.

Pour une utilisation individuelle, une mauvaise réponse en toute confiance est un inconvénient. Mais lorsque les résultats locaux de l’IA se transforment en dépôts réglementaires, analyses financières, documents juridiques ou communications avec les clients, les enjeux changent complètement. Un cadre qui ne sait pas qu’un résumé a été généré par l’IA n’a aucune raison de le vérifier, et au moment où l’erreur apparaît, le document peut déjà être signé, envoyé ou soumis.

Les modèles locaux ont des cas d’ utilisation légitimes et précieux, mais « local » n’est pas un synonyme de « sûr ». Savoir ce qui est installé, où il s’exécute et s’ il est configuré de manière sécurisée sont les exigences de base pour les utiliser de manière responsable à l’échelle de l’ entreprise.

Agents

Les agents d’IA vont au-delà de la réponse aux questions. Lorsqu’un modèle linguistique de grande taille comme ChatGPT répond aux invites, un agent peut prendre des mesures : écrire et exécuter du code, mettre à jour des enregistrements dans votre CRM, gérer votre calendrier ou envoyer des communications en votre nom. Cette capacité est ce qui les rend puissants et ce qui les rend risqués.

Le risque provient de la manière dont les agents obtiennent leurs permissions. Un agent hérite de l’accès de l’utilisateur qui l’installe. Si cet utilisateur est un développeur disposant de droits d’administration locaux, d’informations d’identification de base de données et de clés API, l’agent dispose également de tout cela.

Il s’agit de l’équivalent de l’IA d’une attaque en dehors des terres : aucun logiciel malveillant n’est requis, seul un accès légitime est utilisé d’une manière que personne n’avait anticipée. Il n’existe actuellement aucune norme à l’échelle de l’entreprise pour savoir quand un agent doit faire une pause et demander une approbation humaine avant d’agir, et la plupart des outils nécessitent des permissions à configurer par utilisateur, ce qui rend la gouvernance à l’échelle de la flotte presque impossible aujourd’hui.

Cet écart est déjà exploité au niveau du modèle. Un article de recherche de 2025 Lupinacci et al. a révélé que 100 % des modèles d’IA testés appliquaient des normes de sécurité plus contraignantes lors de la réception d’instructions d’autres agents d’IA que d’un humain.

Un agent compromis dans un workflow multi-agents peut transmettre des instructions malveillantes à d’autres agents qui seraient bloqués si un humain les envoyait. Les chercheurs appellent cela une vulnérabilité « escalade des privilèges d’agent d’IA » intégrée aux architectures LLM actuelles.

Protocole de contexte du modèle (MCP)

Anthropic a créé une norme ouverte appelée Model Context Protocol (MCP) pour donner aux outils d’IA un moyen de se connecter à d’autres outils, sources de données et systèmes. Pensez-y comme un câble USB-C : au lieu que chaque appareil ait besoin de son propre connecteur propriétaire, MCP offre à l’IA un moyen standardisé unique d’interagir avec votre boîte aux lettres, votre système de fichiers, votre navigateur, votre base de données et tout ce qui expose une interface compatible.

Cette standardisation est également ce qui fait de MCP un risque important pour l’entreprise. Les serveurs MCP peuvent être installés directement dans des outils de développement tels que VSCode ou Cursor avec peu ou pas de visibilité de la part des équipes informatiques ou de sécurité. Ils héritent des permissions de la personne qui les installe, et comme de nombreux développeurs sont des administrateurs locaux avec des informations d’identification, des clés d’API et des jetons déjà sur leurs machines, un serveur MCP compromis n’a pas besoin de faire grand-chose pour avoir un accès étendu. Il s’agit d’un « MCP fantôme », un sous-composant de l’IA fantôme qui porte un rayon d’explosion surdimensionné.

La surface d’attaque est multifacette et un sujet pour des analyses plus approfondies sur diverses techniques, mais certains exemples comprennent :

  • Intoxication des outils, où les attaquants intègrent des instructions malveillantes dans les descriptions d’ outils à l’aide de caractères invisibles pour les humains, mais lisibles par l’IA, ce qui entraîne des mesures que l’utilisateur n’avait jamais prévues.
  • Les extractions de tapis, où un outil MCP légitime est mis à jour silencieusement après l’installation pour réacheminer le trafic ou consigner des données sensibles vers un serveur tiers, sans modification visible pour l’utilisateur.
  • L’observation d’outils entre serveurs, où un serveur malveillant s’injecte dans un serveur légitime. En 2025, les attaquants ont ombragé le serveur MCP officiel WhatsApp et l’ont utilisé pour exfiltrer silencieusement des historiques de chat entiers.
  • Une compromission de la chaîne d’approvisionnement, où un serveur malveillant est le produit dès le premier jour, publiée dans un registre non vérifié et installée par un utilisateur qui n’ avait aucune raison de le suspecter . Sans processus de vérification  standard pour les serveurs MCP, il s’agit de l’un des vecteurs les plus probables pour la plupart des organisations.
  • Le détournement de session, illustré par CVE-2025-6514, une vulnérabilité OAuth critique dans un composant MCP largement utilisé qui a permis aux attaquants d’ obtenir un accès persistant à environ 437 000 environnements de développement.

Il y a désormais plus de 15 000 serveurs MCP dans la nature. Avec ce volume de nouveaux développements et l’absence de normes de sécurité matures en place, le nombre de CVE augmente rapidement. Cet écosystème est précoce, largement non régi et activement interrogé.

Informations Tanium et risques réels

En septembre 2025, un acteur malveillant parrainé par l’État chinois a utilisé Claude Code, l’agent de codage IA d’Anthropic, pour effectuer de manière autonome la reconnaissance, exploiter les vulnérabilités et exfiltrer les données d’environ 30 organisations.

L’IA a exécuté de manière indépendante environ 80 à 90  % des opérations tactiques. Ce même mois, les chercheurs ont démontré une attaque sans clic contre la fonctionnalité Deep Research de ChatGPT : un e-mail unique contenant une injection d’invite cachée a exfiltré silencieusement les données Gmail avec un taux de réussite de 100  %, ne nécessitant aucune action de la victime.

Sur le front de la chaîne d’approvisionnement, une campagne appelée GlassWorm a distribué des extensions malveillantes via le marché OpenVSX, accumulant plus de 10 000 téléchargements. Les extensions utilisaient des caractères Unicode invisibles pour masquer leur code et acheminaient les données volées via une infrastructure de commande et de contrôle de la blockchain Solana, deux techniques spécifiquement conçues pour échapper à la détection.

Dans chaque incident, les organisations n’avaient aucune visibilité sur les conditions qui ont rendu l’attaque possible.

L’étude Tanium Guardian donne un aperçu de la portée de l’IA fantôme dans les entreprises. Nous examinons deux dimensions : les artefacts de modèle d’IA local sur les endpoints (par ex., fichiers de modèle et chemins d’infrastructure) et les configurations de serveur MCP (quels outils MCP sont présents et où).

Ce que nous voyons est une histoire claire : l’IA fantôme est déjà présente dans une part significative d’environnements, et les artefacts de modèle local et l’adoption du MCP sont concentrés de manière importante pour la visibilité et la politique.

Ce que Tanium observe

L’étude de Tanium Guardian montre une histoire familière : une forte augmentation de l’adoption de l’IA dans les entreprises, avec un environnement sur trois montrant déjà au moins un endpoint avec des fichiers de modèle d’IA indexés et près de la moitié avec au moins un endpoint où un serveur MCP est configuré.

La présence de l’IA sur l’endpoint n’est plus la question ouverte. C’est là, et c’est en pleine croissance. La question ouverte est de savoir si cette présence est autorisée, régie et comprise.

En pratique, ce que nous voyons a tendance à se diviser en deux modèles : certaines organisations semblent déployer l’IA de manière coordonnée ; d’autres, l’adoption ressemble plus à un ralentissement, le type de modèle qui pourrait signaler l’IA fantôme, avec des outils et des intégrations qui apparaissent sans une main centrale claire sur le tiller.

Du côté du modèle local, les artefacts racontent leur propre histoire. Les fichiers GGUF (style Lama et similaire) pointent vers le LLM local et l’outil d’intégration tel qu’Ollama. Les agents de sécurité s’affichent là où Hugging Face et PyTorch sont en jeu, typiques de la synthèse des conversations, des modèles affinés et le reste. PMML se tourne vers l’ancienne pile d’apprentissage automatique traditionnelle telle que SAS, R, sklearn et d’autres outils d’analyse. Il ne s’agit donc pas seulement de « quelqu’un a dirigé Ollama », c’est un mélange de LLM locaux, de Deep Learning moderne et de ML classique.

Du côté MCP, l’image est tout aussi occupée. Près de 400 serveurs MCP distincts nommés apparaissent de manière cohérente sur des millions d’endpoints, et une fragmentation de serveurs ponctuels ou de niche qui pourrait justifier une enquête plus approfondie. Les noms qui s’élèvent au sommet lisent comme un qui est-qui de la manière dont l’entreprise est menée et sont corrélés à certains des outils d’entreprise les plus populaires sur le marché.

Ces outils sont peu susceptibles d’être de l’« IA parallèle », mais ce sont les outils que les équipes intègrent à leurs workflows assistés par l’IA. La question pour la sécurité et la gouvernance est de savoir si ce câblage est visible et surveillé de manière appropriée. Les attaquants chercheront des opportunités de se faire passer pour des outils de fournisseur légitimes, alors restez vigilant.

Le risque réel n’est pas toujours « nous avons de nouveaux outils d’IA dans notre organisation ». C’est « nous n’avons pas examiné et validé les outils d’IA dans notre organisation. » L’écart entre ces deux domaines est l’endroit où la gouvernance doit être appliquée, et ce rapidement.

Comment Tanium aide

Sans visibilité sur les outils d’IA en cours d’exécution, où ils s’exécutent et comment ils sont configurés, les organisations ne peuvent pas prendre de décisions éclairées en matière de gouvernance ou de risque.

Tanium Guardian Spotlight : les outils d’IA offrent aux équipes de sécurité une vue centralisée au niveau des endpoints de l’IA fantôme dans l’ensemble de l’environnement.

Le tableau de bord découvre et stocke :

  • Serveurs MCP configurés : nombre et type (HTTP, SSE, STDIO) de serveurs MCP dans les IDE de développeurs, plus les IDE qui en disposent
  • Gestionnaires de modèles locaux : applications telles qu’Ollama, LM Studio et GPT4All ; utilisation au cours des 90 derniers jours ; et (avec Index/SBOM) installations basées sur AppImage et conteneur
  • Fichiers de modèle d’IA : fichiers de modèle distincts détectés via Tanium Index (par ex. GGUF, SafeTensors), avec chemin et contexte de dénomination
  • OpenClaw : endpoints avec OpenClaw en cours d’exécution, pour l’évaluation de l’exposition à ses risques connus

Les équipes peuvent utiliser le résumé exécutif pour la portée, la section MCP pour aligner les serveurs sur la politique et les tendances d’utilisation pour séparer les outils installés des outils en utilisation active. La capacité complète utilise Tanium Index, SBOM, Asset Software Inventory and Usage et Threat Response.

Pour plus de détails, reportez-vous aux Notes de publication de Guardian Spotlight : AI Tools et à la conférence Tech Talk sur la visibilité et les risques liés aux outils d’IA.

Références

Rapports Shadow AI

Sécurité MCP

Renseignements sur les menaces

Détection LLM locale

Chaîne d’approvisionnement

IA diverses, malveillantes et risquées

Risques et sécurité liés à l’IA