Le « S » de MCP signifie sécurité

• MCP est un protocole standard qui relie les LLM aux outils, mais il n’intègre pas la sécurité par défaut
• Il présente diverses vulnérabilités de sécurité, comme l’injection de commandes, l’empoisonnement d’outils et la falsification de définitions
• MCP ne dispose ni d’authentification, ni de chiffrement, ni de vérification d’intégrité, ce qui en fait une architecture difficile à considérer comme fiable
• À l’heure actuelle, le meilleur moyen de défense consiste à gagner en visibilité et en contrôle avec des outils comme ScanMCP

Qu’est-ce que MCP et pourquoi est-ce important

• MCP signifie Model Context Protocol et constitue un nouveau standard pour la manière dont des LLM comme Claude, GPT et Cursor s’intègrent aux outils et aux données
• Il fournit une méthode de connexion standardisée, au point d’être présenté comme un « USB-C pour les agents IA »
• Grâce à MCP, les agents IA peuvent assurer les fonctions suivantes
  • se connecter aux outils via une API standardisée
  • maintenir l’état de session
  • exécuter des commandes (avec un risque d’exécution trop libre)
  • partager du contexte entre workflows
• Mais la sécurité n’y est pas appliquée par défaut
• Il existe un risque d’ouvrir, à l’insu de l’utilisateur, des canaux latéraux permettant d’accéder au système

Principales vulnérabilités de sécurité observées dans MCP

• Vulnérabilité d’injection de commandes (recherche Equixly)

  • En 2025 encore, des cas d’exécution de code à distance (RCE) via injection de commandes se produisent
  • D’après l’enquête d’Equixly, plus de 43 % des implémentations de serveurs MCP utilisent des appels shell non sûrs
  • Un attaquant peut inclure des commandes shell dans les entrées d’un outil et exécuter du code à distance via un agent de confiance

• Empoisonnement d’outils (Tool Poisoning, Invariant Labs)

  • L’attaquant cache des instructions malveillantes dans la description de l’outil
  • Elles restent invisibles pour l’utilisateur, mais l’IA les perçoit et les exécute telles quelles
  • Un outil qui semble n’effectuer qu’un simple calcul peut en réalité lire des clés SSH ou des fichiers de configuration sensibles sur le système de l’utilisateur

• Redéfinition silencieuse d’outil (Rug Pull)

  • Un outil peut modifier sa propre définition après son installation
  • Un outil légitime au jour 1 peut devenir au jour 7 un collecteur de clés API au profit d’un attaquant
  • C’est une nouvelle forme de problème de sécurité de la supply chain, qui se produit à l’intérieur même du LLM

• Masquage d’outils entre serveurs

  • Lorsque plusieurs serveurs MCP sont connectés à un même agent, un serveur malveillant peut intercepter ou surcharger les appels destinés à un serveur de confiance
  • Cela peut notamment entraîner les problèmes suivants
    • envoi d’e-mails à un attaquant tout en prétendant les avoir envoyés à l’utilisateur
    • injection de logique cachée dans un outil
    • exfiltration de données encodées

Pourquoi MCP n’est pas encore sûr

• MCP privilégie les éléments suivants
  • ✅ intégration facile
  • ✅ interface unifiée
• Mais il lui manque les éléments suivants
  • ❌ aucun standard d’authentification
  • ❌ aucun chiffrement du contexte
  • ❌ impossible de vérifier l’intégrité des outils
• L’utilisateur ne peut pas savoir sur quelle description exacte l’agent s’appuie réellement pour utiliser un outil

Mesures de sécurité possibles pour les développeurs et les opérateurs de plateforme

• Développeurs

  • validation des entrées indispensable
  • figer les versions (pinning) des serveurs MCP et des outils
  • supprimer les informations sensibles des descriptions d’outils

• Opérateurs de plateforme

  • afficher à l’utilisateur l’ensemble des métadonnées des outils
  • utiliser des hash d’intégrité lors des mises à jour de serveurs
  • appliquer de façon obligatoire la sécurité des sessions

• Utilisateurs

  • ne pas se connecter à des serveurs MCP non fiables
  • surveiller les logs de session comme on le ferait en environnement de production
  • suivre de près les mises à jour d’outils suspectes

L’idée proposée par ScanMCP.com

• ScanMCP est présenté comme un scanner et un tableau de bord capables de
  • auditer les outils MCP connectés
  • détecter des risques tels que RCE, l’empoisonnement d’outils et les fuites de session
  • comparer et visualiser les informations vues par l’utilisateur par rapport à celles perçues par l’agent
• Cela peut être utile notamment pour
  • les équipes sécurité des plateformes d’agents
  • les startups d’infrastructure IA
  • les développeurs indépendants qui veulent créer des outils fondés sur la confiance

Réflexion finale

MCP est un protocole puissant, mais il est adopté trop vite alors que sa maturité en matière de sécurité API reste insuffisante
Tant qu’une approche secure-by-default n’est pas mise en place, des outils comme ScanMCP.com restent le meilleur moyen d’obtenir de la visibilité et du contrôle

• Conclusion : le « S » de MCP ne signifie pas Security. Pourtant, ce devrait être le cas

[GN⁺]

Commentaires Hacker News

• Ce billet met en avant et cite les scénarios d’attaque décrits dans une note de sécurité publiée il y a quelques jours par Invariant Labs (empoisonnement d’outils, masquage d’outils, rug pull MCP). Je suis l’auteur de ce billet de blog

  • Contrairement à ce que beaucoup soupçonnent, le problème de sécurité des appels d’outils LLM de style MCP ne réside pas dans l’isolation entre différentes implémentations de serveurs MCP
  • Les implémentations de serveurs MCP exécutées en local doivent être vérifiées par le gestionnaire de paquets utilisé pour l’installation (les serveurs MCP distants sont en réalité encore plus difficiles à vérifier)
  • Le problème vient d’une forme particulière d’injection indirecte de prompt qui survient lorsque MCP est utilisé dans des systèmes agentiques
  • Comme l’agent inclut dans le même contexte les spécifications de tous les serveurs MCP installés, un serveur MCP non fiable peut facilement manipuler le comportement d’un autre serveur MCP, par exemple un serveur pouvant accéder à une base de données sensible. J’appelle cela le masquage d’outils
  • En outre, à cause de la nature dynamique de MCP, un serveur MCP peut modifier l’ensemble des outils qu’il fournit uniquement pour certains utilisateurs. Cela signifie qu’un serveur MCP peut devenir malveillant à tout moment
  • Les clients MCP actuels, Claude et Cursor, ne signalent pas ces changements, ce qui rend l’agent et l’utilisateur vulnérables
  • Si cela vous intéresse davantage, consultez [1] pour un billet de blog plus détaillé. Nous faisons de la recherche sur la sécurité des agents et travaillons dessus depuis longtemps chez Invariant
  • Nous avons également publié des extraits de code que tout le monde peut tester, y compris une attaque d’empoisonnement d’outils contre un serveur MCP WhatsApp populaire [2]

• Ces attaques sont surtout un autre exemple de problème du mauvais côté du sas de décompression. Elles ne franchissent pas de frontière de privilèges et font simplement de manière étrange ce qu’elles pouvaient déjà faire

  • Les serveurs MCP exécutent du code au niveau utilisateur, il n’est donc pas nécessaire de tromper une IA pour qu’elle lise des clés SSH. Ils peuvent simplement les lire
  • Le reste revient essentiellement aux mêmes reproches qu’on pourrait adresser à d’autres outils/écosystèmes de développement (NPM ou les extensions VS Code)

• Le défi consiste à imaginer une meilleure conception qui :

  • 1. dispose de normes de sécurité appropriées, afin que les gens n’écrivent pas des articles du type « le S signifie sécurité »
  • 2. permette aux programmes d’offrir le même ensemble de fonctionnalités que les MCP les plus utiles aujourd’hui, sans transformer les capacités automatiques en actions nécessitant une confirmation manuelle de l’utilisateur, ni, de manière générale, vider l’idée de son sens
  • 3. n’enferme pas tout dans une marketplace propriétaire avec des gatekeepers d’entreprise
  • J’aimerais voir des propositions, car jusqu’à présent je n’ai vu que des « MCP n’est pas sûr !!!111 » génériques et peu concrets. C’est particulièrement difficile quand les gens oublient que la sécurité et l’utilité sont des forces opposées

• Bon article, mais je me demande si tout cela n’a pas été généré par IA

  • La photo de profil semble générée par StableDiffusion, le compte a été créé aujourd’hui et il n’y a aucun article précédent
  • Je n’ai pas non plus trouvé d’autre référence à Elena Cross

• Le O signifie observabilité. Cette semaine, j’étais plongé jusqu’au cou dans l’exploration et l’écriture de serveurs MCP

  • La plupart des implémentations, y compris la mienne pour m’amuser, n’ont ni audit ni métriques. Claude enregistre la sortie des logs des serveurs MCP, mais c’est pour le débogage, pas pour le DevOps/SecOps
  • Culturellement, le problème décrit par l’OP est majeur pour les non-techniciens (les moldus). Dans les subreddits concernés, les gens s’amusent à exécuter des programmes MCP CLI sur leur machine
  • Les commentaires de l’OP sur la sécurité sont évidents pour les développeurs, mais ces utilisateurs n’ont aucune perspective sur le niveau de risque
  • Les gens découvrent Docker, et Claude inclut son usage dans les exemples. Mais la plupart téléchargent simplement un blob et l’exécutent. Les gens codent et lancent des serveurs MCP à l’aveugle
  • À mesure que MCP se répandra, les frameworks et outils évolueront pour prendre en charge la sécurité, l’observabilité, etc. C’est comme construire le Web au milieu des années 90
  • Sans rapport avec l’OP, mais pendant que je construisais cela, c’était très intéressant de taper quelque chose dans Claude Desktop et de déclencher des points d’arrêt dans VSCode

• Exact. J’ai eu la même pensée, même si je ne suis pas allé en profondeur quand j’ai publié la note

• Même si le logiciel utilisé n’est pas malveillant et qu’il est implémenté de manière sûre, comment vérifier qu’il est utilisé comme on le souhaite ?

  • Supposons qu’il y ait un serveur MCP capable de modifier le système de fichiers local et un autre capable de modifier des objets dans un stockage cloud. Comment l’utilisateur peut-il garantir que l’agent LLM fera le bon choix ?
  • On veut offrir beaucoup d’options sans surveiller chaque action, mais cela risque aussi de créer davantage de problèmes

• Plus de 43 % des implémentations de serveurs MCP testées par Equixly comportaient des appels shell non sécurisés

  • Comment peut-on tomber dans ce piège à chaque fois ?

• Je me demande ce qu’est MCP. J’ai essayé de lire la documentation plusieurs fois, mais je n’ai jamais compris quel problème cela résout. Principalement, qu’est-ce qui est spécifique aux agents IA et ne s’applique pas aux agents déterministes qui existent depuis des décennies ?

• Je supposais que l’objectif global de MCP était qu’Anthropic puisse espionner les prompts et les sorties afin de maximiser ses données d’entraînement. Je découvre seulement maintenant qu’il s’agit d’un middleware pour tous les modèles d’IA