MCP et Sécurité des Agents IA : Comment le Protocole a Créé une Nouvelle Surface d'Attaque

Le Model Context Protocol (MCP) a rendu les agents IA modulaires : une interface standard unique pour se connecter à n'importe quel outil et service. Mais derrière cette unification se cache un problème systémique — chaque nouveau serveur MCP élargit la zone de confiance de l'agent et crée un point d'attaque potentiel.

Pourquoi MCP a créé de nouvelles vulnérabilités

Les grands modèles de langage n'ont pas de frontière architecturale entre les « données » et les « instructions ». Tout ce qui entre dans le contexte du modèle est potentiellement exécutable. MCP ne résout pas ce problème ; il le met à l'échelle : un agent peut maintenant avoir des dizaines d'outils connectés, et chacun élargit la surface d'attaque.

La normalisation de MCP signifie qu'un attaquant qui obtient le contrôle d'un serveur ou peut injecter des données dans ses réponses influence potentiellement toute la chaîne d'actions de l'agent.

Trois classes principales de menaces dans l'écosystème MCP :

• Tool poisoning — la description de l'outil dans le serveur MCP contient des instructions cachées qui modifient le comportement de l'agent lors de l'appel
• Indirect prompt injection — les instructions malveillantes sont cachées dans un document, une entrée de base de données ou une page web que l'agent lit lors d'une tâche
• Sampling abuse — manipulation de la façon dont l'agent demande de nouvelles inférences au modèle, ce qui permet de contourner les restrictions du prompt système

Même un PDF « inoffensif », une description d'outil ou une chaîne de base de données peuvent contenir des commandes que l'agent exécutera aux côtés d'outils légitimes.

Ce que les tests pratiques ont révélé

Ces vulnérabilités ne sont pas théoriques. Un chercheur a effectué des tests sur un banc d'essai MCP spécialement configuré et vulnérable, et a confirmé l'exécution réelle de commandes injectées. Parmi les scénarios documentés figurent l'interception d'appels d'outils via des réponses de serveur MCP spécialement formulées et l'exécution d'instructions cachées à partir de documents texte transmis à l'agent en tant que « données ».

«

Chaque serveur MCP auquel vous faites confiance élargit la zone de confiance de tout votre système — non seulement avec ses propres outils, mais avec tout ce qu'il peut livrer à l'agent en tant que données. »

Le scanner BarkingDog, développé par l'auteur, détecte les appels d'outils suspects en temps réel — l'un des rares outils de détection pratiques disponibles pour les équipes de sécurité aujourd'hui.

Comment l'industrie essaie de résoudre le problème

Les fournisseurs d'infrastructure IA se déplacent simultanément dans plusieurs directions :

• MCP Gateways — une couche proxy qui filtre et contrôle les appels d'outils avant qu'ils ne parviennent à l'agent ; certaines solutions ajoutent des journaux d'audit complets des interactions
• Sandboxing — isolement de l'exécution du serveur MCP avec accès restreint au système de fichiers, au réseau et aux ressources système
• Architectures OAuth — autorisation explicite de chaque outil avec des droits d'accès minimes ; chaque serveur MCP ne reçoit que les autorisations réellement nécessaires pour une tâche spécifique

Pour l'instant, toutes ces solutions sont partielles. Le problème fondamental est architecturale : tant que les modèles de langage n'apprennent pas à distinguer entre le plan de données et le plan de contrôle au niveau du traitement du contexte, toute donnée entrante reste potentiellement exécutable.

Ce que cela signifie

MCP est devenu le standard de facto pour les agents IA, et la question de sa sécurité est passée du domaine académique au domaine pratique. Les développeurs qui déploient des agents avec des serveurs MCP devraient traiter chaque outil connecté comme un tiers de confiance — avec audit obligatoire, isolement et le principe du moindre privilège à chaque appel.