MCP et sécurité des agents IA : comment le protocole a ouvert une nouvelle surface d'attaque

Model Context Protocol (MCP) a rendu les agents IA modulaires : une interface standard unique permet de les connecter à n'importe quel outil ou service. Mais cette unification masque 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 « données » et « 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 démultiplie : un agent peut désormais disposer de dizaines d'outils connectés, et chacun élargit la surface d'attaque.

Avec la standardisation MCP, un attaquant qui prend le contrôle d'un seul serveur, ou qui parvient à injecter des données dans ses réponses, peut potentiellement influencer toute la chaîne d'actions de l'agent.

Trois grandes catégories de menaces dans l'écosystème MCP :

• Tool poisoning : la description d'un outil dans un serveur MCP contient des instructions cachées qui modifient le comportement de l'agent lors de l'appel
• Indirect prompt injection : des instructions malveillantes sont dissimulées dans un document, un enregistrement de base de données ou une page web que l'agent lit au cours de sa tâche
• Sampling abuse : la manipulation de la manière dont l'agent sollicite de nouvelles sorties auprès du modèle, ce qui permet de contourner les restrictions du prompt système

Même un PDF « inoffensif », une description d'outil ou une ligne de base de données peuvent contenir des commandes que l'agent exécutera au même titre que des instructions légitimes.

Ce qu'a montré la vérification pratique

Ces vulnérabilités n'ont rien de théorique. Un chercheur a mené des tests sur un banc d'essai MCP volontairement configuré pour être vulnérable et a constaté l'exécution effective de commandes injectées. Parmi les scénarios documentés : l'interception d'appels d'outils via des réponses de serveur MCP spécialement forgées, et l'exécution d'instructions cachées dans des documents texte transmis à l'agent en tant que « données ».

«

Chaque serveur MCP auquel vous faites confiance élargit la zone de confiance de tout le système, non seulement par ses outils, mais aussi par tout ce qu'il peut fournir à l'agent sous forme de données. »

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

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

Les fournisseurs d'infrastructure IA avancent sur plusieurs fronts à la fois :

• MCP Gateways : une couche proxy qui filtre et contrôle les appels d'outils avant qu'ils n'atteignent l'agent ; certaines solutions ajoutent un journal d'audit complet des interactions
• Sandboxing : l'isolation de l'exécution des serveurs MCP, avec un accès restreint au système de fichiers, au réseau et aux ressources système
• Architectures OAuth : une autorisation explicite de chaque outil avec des droits d'accès minimaux ; chaque serveur MCP ne reçoit que les permissions réellement nécessaires à la tâche concernée

Pour l'instant, toutes ces solutions restent partielles. Le problème de fond est architectural : tant que les modèles de langage ne sauront pas séparer data plane et control plane au niveau du traitement du contexte, toute donnée entrante restera potentiellement exécutable.

Ce que cela signifie

MCP s'est imposé comme le standard de facto des agents IA, et la question de sa sécurité est passée du terrain académique au terrain opérationnel. Les développeurs qui déploient des agents avec des serveurs MCP ont intérêt à traiter chaque outil connecté comme un tiers de confiance, avec audit obligatoire, isolation et principe du moindre privilège à chaque appel.