Copilot, Cursor, MCP : les nouveaux angles morts de la sécurité des entreprises !

Pourquoi la visibilité devient le premier défi des RSSI face à l’IA agentique ?

Pendant des années, les équipes de cybersécurité ont appris à protéger les postes de travail, les applications, les accès, le réseau et les flux web. EDR, XDR, pare-feu, proxies, filtrage web, contrôle des accès : les briques de défense se sont progressivement renforcées autour d’un principe simple, détecter et contrôler ce qui s’exécute dans le système d’information.

Mais l’adoption massive de l’intelligence artificielle change la nature du problème.

Avec l’arrivée de Copilot, Cursor, Claude Code, des agents IA, des extensions navigateur, des plugins IDE, des packages open source, des modèles locaux ou encore des serveurs MCP, une nouvelle couche logicielle s’installe sur les endpoints. Elle ne ressemble pas toujours à une application traditionnelle. Elle n’est pas toujours distribuée comme un logiciel classique. Et surtout, elle peut désormais agir pour le compte de l’utilisateur.

Cette évolution crée un nouveau défi pour les RSSI, DSI et CTO : avant même de sécuriser l’usage de l’IA, encore faut-il savoir ce qui est réellement présent, actif, connecté et capable d’agir dans l’environnement.

"Le premier risque aujourd’hui n’est pas seulement l’usage de l’IA. C’est l’absence de visibilité sur les composants IA déjà utilisés dans l’entreprise.", Eric Bohec, CTO Group Nomios

L’endpoint moderne ne se limite plus aux applications installées

Historiquement, la sécurité endpoint s’est construite autour d’objets relativement identifiables : exécutables, processus, applications installées, comportements malveillants, connexions réseau suspectes. Cette approche reste indispensable, mais elle ne couvre plus entièrement la réalité du poste de travail moderne.

Désormais, un endpoint peut héberger des extensions navigateur, des plugins d’environnement de développement, des packages open source, des modèles IA, des agents autonomes, des composants MCP.

Ces composants sont souvent installés depuis des sources légitimes : marketplaces, registres de packages, dépôts open source, extensions d’IDE ou navigateurs. Ils ne ressemblent donc pas toujours à des menaces. Ils peuvent être utiles, populaires, productifs, parfois même indispensables aux équipes métiers ou développeurs.

Mais c’est précisément ce qui crée l’angle mort.

Un composant peut être légitime à l’installation, puis devenir risqué après une mise à jour, un changement de propriétaire, une dépendance compromise ou une mauvaise configuration.

C’est précisément là que les outils historiques atteignent leurs limites : les EDR et XDR restent essentiels, mais ils ont été conçus pour détecter des comportements système ou malware. La nouvelle question est différente : quels agents, quelles extensions, quels packages et quels outils IA sont réellement capables d’interagir avec nos données et nos environnements ?

Les agents IA ne consultent plus seulement l’information, ils agissent

La vraie rupture ne vient pas uniquement de l’intelligence artificielle en tant que technologie. Elle vient de l’agentification de l’IA.

Un chatbot répond à une question. Un agent IA peut aller plus loin : lire un contexte, appeler un outil, interagir avec une API, produire du code, modifier un fichier, déclencher une action, utiliser une extension ou s’appuyer sur un serveur MCP.

Cette capacité d’action change profondément la gouvernance.

Une application SaaS classique peut être analysée sous l’angle des accès, des données hébergées, des flux et des droits utilisateurs. Un agent IA ajoute plusieurs dimensions supplémentaires : autonomie, raisonnement, usage d’outils externes, contexte conversationnel, mémoire éventuelle, dépendances logicielles, capacité à agir pour le compte d’un utilisateur.

C’est ce qui rend le sujet plus complexe. Un agent n’est pas seulement un logiciel. C’est un acteur numérique qui combine accès, contexte, décision et action.

Le modèle de gouvernance interne doit avoir plusieurs principes clés : un agent IA doit avoir un objectif clair, un propriétaire identifié, des droits minimaux, une supervision active et une validation humaine pour les actions à impact métier, sécurité, financier, légal ou client.

Cette évolution impose un changement de posture : gouverner une application consiste à contrôler ce à quoi elle accède. Gouverner un agent IA consiste aussi à comprendre ce qu’il peut décider, appeler, transformer ou déclencher.

Les risques difficiles à voir sans visibilité dédiée

Lorsqu’une entreprise déploie ou tolère l’usage de Copilot, Cursor, Claude Code ou d’outils similaires, les risques ne sont pas toujours spectaculaires au départ. Ils se présentent souvent sous la forme d’usages pratiques, rapides, productifs.

Un développeur installe une extension d’IDE pour accélérer son travail. Un collaborateur utilise un assistant IA pour résumer des documents. Une équipe teste un agent connecté à un référentiel interne. Un outil s’appuie sur un package open source ou un serveur MCP pour enrichir ses capacités.

Pris individuellement, chaque usage peut sembler acceptable. Mais sans inventaire global, l’entreprise perd rapidement la compréhension de ce qui se passe réellement.

Les risques les plus difficiles à identifier sont notamment :

• la prompt injection, lorsque du contenu malveillant influence le comportement d’un modèle ou d’un agent ;
• les appels vers des services externes, parfois non validés par l’entreprise ;
• les dépendances logicielles non maîtrisées, notamment packages open source, plugins ou extensions ;
• les accès excessifs, lorsque l’agent ou l’outil dispose de droits supérieurs à son besoin réel ;
• l’exfiltration de données, par exemple de code source, configurations, secrets ou informations client ;
• les agents ou serveurs MCP non contrôlés, actifs sans gouvernance ni supervision.

Le sujet n’est donc pas de diaboliser ces outils : le risque ne vient pas du fait qu’un collaborateur utilise l’IA. Le risque apparaît quand l’entreprise ne sait plus quels outils sont utilisés, quelles données sont exposées, quels services sont appelés et quelles actions peuvent être exécutées.

Pourquoi la visibilité devient le préalable à toute gouvernance IA ?

Beaucoup d’organisations abordent la gouvernance de l’IA par les règles : politique d’usage, charte interne, validation des outils, formation, principes de confidentialité. Ces éléments sont nécessaires. Mais ils deviennent insuffisants si l’entreprise ne dispose pas d’une vision opérationnelle de ce qui est réellement déployé.

Un RSSI doit pouvoir répondre à des questions simples, mais souvent difficiles aujourd’hui :

• Quels agents IA sont actifs dans l’environnement ?
• Quels collaborateurs utilisent des extensions IA ou des plugins de développement ?
• Quels packages, modèles ou MCP sont présents sur les endpoints ?
• Quelles données ces composants peuvent-ils lire ?
• Quels services externes contactent-ils ?
• Quelles actions peuvent-ils exécuter ?
• Quels éléments sont approuvés, tolérés, à risque ou interdits ?

La visibilité est donc la première brique, pas la dernière : on ne peut pas décider ce qui est acceptable si l’on ne sait pas ce qui existe. L’inventaire n’est pas un exercice administratif. C’est la base de la maîtrise du risque IA.

Encadrer l’innovation, pas la freiner

Le réflexe naturel face à une nouvelle surface d’attaque pourrait être de bloquer. Bloquer les outils, les extensions, les agents, les usages non validés. Mais cette approche est rarement durable.

Les outils IA apportent déjà des gains réels de productivité, en particulier pour les développeurs, les équipes IT, les analystes sécurité, les fonctions support ou les métiers. Les interdire sans alternative revient souvent à déplacer le problème vers le Shadow AI.

L’enjeu est donc différent : rendre l’adoption maîtrisable à grande échelle.

Cela suppose de passer d’une logique binaire, autoriser ou interdire, à une logique de gouvernance dynamique :

• découvrir ce qui existe ;
• qualifier le niveau de risque ;
• comprendre les accès et les comportements ;
• appliquer des règles proportionnées ;
• bloquer uniquement ce qui est dangereux ;
• accompagner les usages légitimes ;
• conserver des traces exploitables en cas d’incident.

C’est le bon équilibre : le rôle de la sécurité n’est pas de ralentir l’IA. Il est de créer les conditions de confiance qui permettent de l’utiliser plus largement, plus vite et avec moins de risque.

« On ne peut pas gouverner ce que l’on ne voit pas. Avant de sécuriser les agents IA, il faut comprendre ce qu’ils font réellement. », Eric Bohec, CTO Group Nomios

Et c’est probablement là que se joue la prochaine étape de la cybersécurité d’entreprise : non plus seulement protéger les utilisateurs et les applications, mais aussi cartographier, comprendre et gouverner les nouveaux acteurs numériques qui agissent désormais à leurs côtés.