La sécurité MCP empêche que les outils auxquels votre agent IA accède via le Model Context Protocol (MCP) se retournent contre vous. Chaque connexion passe par un programme appelé serveur MCP, si bien que la moindre faille ou instruction dissimulée qui s’y trouve devient votre problème. Parmi les principaux risques figurent les commandes cachées dans les réponses d’un outil, les modifications malveillantes après approbation et les requêtes envoyées n’importe où sans contrôle.
Vos développeurs peuvent brancher un nouvel outil sur votre IA en un après-midi, souvent à l’aide d’un serveur copié depuis GitHub que personne d’autre n’a examiné. Dès lors, ce code partage l’accès de votre agent aux données et aux actions. En 2026, même Google et JPMorgan Chase ont dû corriger la même faille dans un logiciel MCP conçu par leurs propres ingénieurs, et quelqu’un a tenté de glisser un serveur malveillant dans 23 projets d’IA en 74 minutes.
Lors des tests d’agents d’IA, les spécialistes de QAwerk sondent chaque connexion comme le ferait un intrus. Nos Bug Crawls, où nous testons des applications populaires et publions nos découvertes, montrent pourquoi c’est important. Sur Otter.ai, un assistant de réunion doté d’IA, une seule question saisie a suffi pour que le chatbot liste ses outils internes et leurs paramètres, offrant à un attaquant une carte des cibles à viser. Tout ce que contient cet article provient de ce travail, pour que vous sachiez quoi demander avant que votre agent ne se connecte à son prochain serveur.
Que protège la sécurité MCP ?
La sécurité MCP protège les données, les actions et les identifiants que votre agent obtient grâce à chaque connexion. Concrètement, MCP est une norme ouverte qui permet à l’IA de se connecter à des outils externes de manière unifiée. Par exemple, dès que vous ajoutez un serveur de calendrier, votre agent peut soudain lire vos réunions, envoyer des invitations et agir avec les identifiants du compte.
Chaque nouveau serveur MCP peut donner à votre agent trois types d’accès :
- Données : Tout ce que le serveur peut lire, des fiches clients aux documents internes
- Actions : Tout ce que le serveur permet à l’agent de faire, comme envoyer des messages, modifier des fiches ou exécuter des commandes
- Identifiants : Les mots de passe et clés d’accès que le serveur détient pour atteindre d’autres systèmes
Quiconque contrôle un serveur, ou glisse des instructions dans ses réponses, peut atteindre ces trois éléments par l’intermédiaire de votre agent. La quantité d’accès qu’un agent devrait avoir sur l’ensemble de ses outils est une question plus large, traitée dans notre article sur la sécurité de l’IA agentique.
Quels risques de sécurité MCP chaque nouveau serveur apporte-t-il ?
La plupart des risques de sécurité MCP proviennent d’un serveur auquel votre équipe a fait confiance sans le vérifier. L’Open Worldwide Application Security Project (OWASP), une organisation à but non lucratif dont les listes de contrôle sont largement utilisées dans le secteur, publie désormais un top 10 dédié à MCP, encore en version bêta. La plupart des risques ci-dessous figurent sur cette liste :
- Des ordres cachés dans les réponses des outils : Un agent lit tout ce qu’un serveur lui renvoie, qu’il s’agisse d’une page web, d’un e-mail ou d’une entrée de base de données. Si un attaquant a placé des instructions dans ce contenu, l’agent peut les suivre comme si elles venaient de vous. Cette attaque s’appelle l’injection de prompt indirecte, et les réponses des outils sont l’une de ses portes d’entrée les plus faciles.
- Des serveurs qui changent après approbation : Un serveur peut réussir l’examen le premier jour, puis réécrire ses propres instructions plus tard. La section sur l’empoisonnement d’outils MCP ci-dessous explique comment fonctionne cette ruse.
- Des serveurs qui appellent n’importe quelle adresse : De nombreux serveurs téléchargent des pages ou appellent d’autres services pour le compte de l’agent. Sans contrôle de la destination, un attaquant peut amener l’agent à faire contacter des systèmes internes par le serveur.
- Des connexions trop puissantes : Un serveur conçu pour lire des fichiers peut aussi être capable de les supprimer ou de les envoyer ailleurs. Les agents prennent le chemin le plus court qu’une connexion autorise, comme l’a appris un développeur lorsqu’un assistant de réservation doté d’IA a annulé la réservation d’un autre membre pour libérer une place à un cours de sport.
- Des serveurs inconnus : Les développeurs ajoutent parfois des serveurs de leur propre initiative, sans prévenir la personne qui approuve les outils. L’OWASP les appelle des serveurs MCP fantômes (shadow MCP servers), et personne ne peut vérifier une connexion dont il ignore l’existence.
- Aucune trace des appels d’outils : Sans journaux, personne ne peut savoir après coup ce que l’agent a demandé à un serveur ni ce qui lui a été renvoyé.
Comment une instruction cachée circule entre les agents
Les ordres cachés dans les réponses des outils deviennent plus difficiles à retracer lorsque les agents travaillent en équipe. De nombreux produits utilisent un agent orchestrateur, un coordinateur qui divise une tâche et confie chaque partie à un sous-agent spécialisé. Le chercheur en sécurité indépendant Syed Anas Mohiuddin appelle l’attaque qui en découle « protocol pivoting ». La chaîne se déroule en trois étapes :
- Un attaquant place du texte dans un contenu qu’un outil MCP va renvoyer. Le texte est rédigé pour ressembler à une demande de tâche, dans le format que les agents utilisent pour communiquer entre eux.
- L’agent orchestrateur lit la réponse de l’outil et transmet la tâche. Pour l’orchestrateur, la demande piégée ressemble à du travail ordinaire.
- Un sous-agent exécute la tâche. Comme la demande provient de l’orchestrateur, le sous-agent n’a aucune raison de s’interroger sur l’origine de l’ordre.
À la dernière étape, aucun agent de la chaîne ne peut savoir qu’un acteur extérieur a rédigé l’instruction. Les transmissions échouent aussi de bien d’autres façons, comme le montre notre analyse consacrée aux tests de systèmes d’IA multi-agents.
Empoisonnement d’outils MCP : quand un serveur de confiance change d’avis
L’empoisonnement d’outils MCP (MCP tool poisoning) est une attaque qui cache des instructions dans les descriptions d’un serveur, ces courtes notes qui indiquent à un agent quand et comment utiliser chaque fonction. Les humains les lisent rarement, mais l’IA traite chaque ligne comme une consigne. Des notes empoisonnées peuvent donc orienter l’agent vers des secrets ou modifier le comportement d’autres outils.
L’une des variantes les plus difficiles à repérer est la version différée, dans laquelle un serveur se comporte bien pendant l’examen, obtient l’approbation et ne réécrit ses propres descriptions qu’ensuite. Le 10 août 2026, quelqu’un a tenté exactement cela à grande échelle. Lors d’une campagne signalée par la société Pillar Security, 23 pull requests, c’est-à-dire des propositions de modification du code d’un projet, sont arrivées dans 23 projets d’IA sur GitHub en 74 minutes. Chaque proposition visait à ajouter le même serveur MCP malveillant.
Selon le bilan trimestriel des exploits publié par l’OWASP, le serveur s’est comporté normalement lors de ses trois premiers appels d’outils. Après le troisième appel, il a réécrit ses propres descriptions d’outils pour orienter l’agent connecté vers les fichiers les plus précieux de l’ordinateur d’un développeur :
- Les clés SSH, qui ouvrent l’accès aux serveurs distants
- Les identifiants de connexion aux comptes cloud Amazon Web Services
- L’historique des commandes saisies sur l’ordinateur, qui contient parfois des mots de passe
- Le fichier de configuration qui pilote les clusters de serveurs Kubernetes d’une entreprise
Le serveur n’a jamais ouvert ces fichiers directement. Il s’est servi de l’agent de confiance pour les collecter et a tenté de dissimuler cette activité aux personnes qui exploitaient le système.
Aucune des pull requests n’a été fusionnée, et l’OWASP ne signale aucune compromission confirmée. Un serveur qui réussit une inspection peut néanmoins devenir hostile plus tard. Pour s’en prémunir, l’OWASP conseille d’enregistrer les descriptions d’outils de chaque serveur au moment de l’approbation et d’exiger un nouvel examen à chaque modification.
Pourquoi Google et JPMorgan Chase ont livré la même faille MCP
De nombreux serveurs MCP récupèrent des pages web ou appellent d’autres services à n’importe quelle adresse fournie par l’agent. Si le serveur ne vérifie jamais la destination, quiconque oriente l’agent peut atteindre des systèmes censés rester privés, comme le réseau interne d’une entreprise. Cette faiblesse s’appelle la falsification de requête côté serveur (SSRF).
En 2026, Google, JPMorgan Chase, Weaviate, l’agence numérique de l’État français et la municipalité d’une ville indonésienne ont tous commis cette erreur, car vérifier chaque requête sortante est une étape facile à sauter. Le chercheur en sécurité Syed Anas Mohiuddin l’a signalée aux cinq équipes, qui ne partagent ni code ni propriétaires, et toutes l’ont corrigée depuis :
- Google : MCP Toolbox for Databases, dont la gravité est jugée élevée, à 8,0 sur 10 (CVE-2026-14540)
- JPMorgan Chase : Un serveur open source de recherche dans la documentation
- Weaviate : Le connecteur de l’éditeur de bases de données vers les services Google
- DINUM (direction interministérielle du numérique) : Le serveur officiel de la plateforme nationale des données ouvertes
- Tangerang (une municipalité indonésienne) : Un serveur de surveillance de la sécurité qui affirmait protéger contre la SSRF, mais ne bloquait que les adresses numériques brutes
Selon TNW, cinq autres serveurs MCP gérés par un organisme fédéral américain, dont un dédié aux demandes de prestations des anciens combattants (Veterans Affairs), attendaient toujours des correctifs en octobre. Aucune exposition de données n’a été confirmée.
Même un serveur signé par une grande marque doit voir ses requêtes sortantes testées avant que votre agent ne s’y fie.
Ce qu’il faut vérifier avant que votre agent n’utilise un serveur MCP
Une bonne sécurité MCP consiste à traiter chaque serveur comme n’importe quel code externe dont dépend votre produit. Ce que vous pouvez vérifier varie selon la provenance :
Qui corrige une faille
Vos développeurs, selon votre calendrier
L’auteur d’origine, si le projet est toujours actif
Comment les modifications vous parviennent
Votre propre processus de mise en production
Des mises à jour automatiques qui peuvent s’installer sans être lues
Ce que vous pouvez inspecter
Tout le code et chaque description d’outil
Uniquement ce que l’auteur a publié
Ce qui pose généralement problème
Des raccourcis sous la pression des délais, comme des contrôles d’adresse omis
Des instructions cachées ou des changements après approbation
Ce qu’il faut tester en premier
Les requêtes sortantes du serveur et les actions qu’il autorise
Les descriptions d’outils et les changements entre versions
Dans les deux cas, chacune des affirmations suivantes doit être vraie avant que votre agent ne commence à utiliser le serveur :
- Vous savez qui maintient le serveur. Un responsable identifié, des mises à jour récentes et un moyen de signaler les problèmes garantissent que les correctifs vous parviendront réellement.
- Le serveur n’atteint que les adresses dont il a besoin. Lors des tests d’API, les requêtes vers des systèmes internes et des destinations inattendues doivent échouer à chaque fois.
- La connexion n’accorde que ce que la tâche exige. Un agent de support qui consulte des commandes ne peut pas émettre de remboursements, et l’accès en lecture seule est la règle partout où c’est possible.
- Le serveur dispose de ses propres identifiants restreints. Ses clés d’accès expirent rapidement et n’ouvrent rien au-delà de sa mission.
- Les descriptions d’outils sont enregistrées lors de l’approbation. Toute modification ultérieure déclenche un nouvel examen avant que l’agent n’utilise à nouveau le serveur.
- Les réponses des outils sont traitées comme des informations, jamais comme des ordres. Les testeurs ont placé des instructions dans le contenu renvoyé par le serveur et ont confirmé que l’agent les ignore.
- Une personne approuve les actions à risque. L’agent ne peut pas effectuer de paiements, supprimer des fiches ni écrire à des clients tant qu’un membre de votre équipe n’a pas donné son accord.
- Chaque appel d’outil est journalisé. Vous pouvez voir après coup ce que l’agent a demandé et ce qui lui a été renvoyé.
- Une personne extérieure à l’équipe de développement a testé la connexion. Les développeurs confirment qu’un serveur fonctionne, tandis qu’un testeur indépendant vérifie son comportement quand quelqu’un essaie de le mettre en défaut.
Lorsqu’une connexion touche aux données clients ou à l’argent, cette liste devient le périmètre de départ d’un test d’intrusion IA. Dans ce type de test, des spécialistes attaquent l’agent et ses serveurs comme le ferait un véritable intrus. Nos ingénieurs cartographient chaque serveur que votre agent peut appeler, testent chacun d’eux au regard de tous les points ci-dessus et remettent à votre équipe un rapport sur ce qui tient et ce qui doit être corrigé avant le lancement.
Vous ne savez pas à quel point les connexions de votre agent sont sûres ? Parlez à notre équipe sécurité.
FAQ
MCP est-il sécurisé ?
La sécurité MCP dépend des serveurs que vous ajoutez, car MCP n’est qu’une norme commune qui permet aux agents IA d’utiliser des outils externes. Le protocole ne vérifie pas si un outil connecté est honnête ou bien conçu. Cette tâche revient à l’équipe qui approuve chaque connexion, si bien qu’un agent n’est jamais plus sûr que le serveur le moins testé dont il dépend.
Faut-il utiliser des serveurs MCP tiers ?
Oui, à condition d’évaluer un serveur MCP tiers comme vous évalueriez un nouveau fournisseur de logiciels. Recherchez un mainteneur actif, un historique public de correctifs et une documentation claire de ce à quoi il peut accéder. Accordez le plus petit ensemble d’autorisations qui permet encore d’accomplir la tâche, et réexaminez la configuration après chaque mise à jour, car un serveur approuvé peut changer de comportement par la suite.
Comment sécuriser un serveur MCP ?
Sécuriser un serveur MCP exige plusieurs couches de protection, dont trois comptent le plus. Commencez par limiter l’accès, afin que la connexion n’atteigne que les systèmes et les actions dont sa mission a besoin, avec des clés qui expirent rapidement. La journalisation de chaque requête et de chaque réponse permet ensuite à votre équipe de voir exactement ce qu’a fait l’agent IA. La dernière couche est un test externe, au cours duquel des spécialistes tentent de glisser des commandes cachées dans les données renvoyées par le serveur.
Renforcez dès maintenant la sécurité de votre application web
