Anthropic a introduit le Model Context Protocol (MCP) le 25 novembre 2024 sous le nom de « un standard ouvert qui permet aux développeurs d'établir des connexions bidirectionnelles sécurisées entre leurs sources de données et les outils basés sur l'IA ». En pratique, MCP permet à un assistant IA d'appeler des programmes locaux, appelés serveurs MCP, qui lisent des fichiers, interrogent des bases de données ou accèdent au Web en son nom. C’est vraiment utile, et c’est aussi un nouveau type de surface d’attaque : le modèle décide quel outil appeler en fonction du texte qu’il lit, et il ne peut pas toujours distinguer vos instructions de celles de quelqu’un d’autre.
Comment fonctionne réellement un serveur MCP
La spécification MCP définit deux transports. Sur stdio, « le client lance le serveur MCP en tant que sous-processus » et les deux discutent via l'entrée et la sortie standard. Sur Streamable HTTP (qui a remplacé le transport HTTP+SSE d'origine de la spécification de novembre 2024), le serveur s'exécute comme son propre processus local et le client lui envoie des requêtes HTTP, recevant éventuellement un flux d'événements envoyés par le serveur (Spécification MCP, transports). Quoi qu'il en soit, un serveur MCP local s'exécute généralement avec les mêmes autorisations de fichiers et de réseau que la personne qui l'a démarré, car rien dans le protocole n'exige le contraire.
La spécification elle-même signale directement le risque de la variante HTTP : elle exige que les serveurs valident l'en-tête Origin, recommande la liaison à 127.0.0.1 plutôt qu'à 0.0.0.0 lors de l'exécution locale et appelle à l'authentification à chaque connexion, avertissant que sans cela, "les attaquants pourraient utiliser la reliaison DNS pour interagir avec les serveurs MCP locaux à partir de sites Web distants".
Le mécanisme : un député déboussolé
Le nom classique de ce mode de défaillance est problème d'adjoint confus : « un programme informatique trompé par un autre programme (avec moins de privilèges ou moins de droits) qui abuse de son autorité. » Un agent IA ayant accès à l'outil MCP est un adjoint doté d'une réelle autorité - pour lire vos fichiers, faire des requêtes réseau - agissant sur des instructions pouvant provenir d'un contenu qu'il lui a uniquement été demandé de résumer ou d'analyser. Lorsque ce contenu contient ses propres instructions, l’agent peut les suivre à la place ou en plus des vôtres. C'est ce que la classe de risques Top 10 pour les applications LLM de l'OWASP appelle l'injection rapide et l'agence excessive : OWASP : Top 10 pour les candidatures LLM ; OWASP LLM01 : 2025, injection rapide.
Un cas démontré : le serveur GitHub MCP
Ce n’est pas théorique. Le 26 mai 2025, Laboratoires invariants signalés a effectué une preuve de concept sur le serveur officiel GitHub MCP, qui comptait à l'époque environ 14 000 étoiles GitHub. Leur configuration : un agent ayant accès à un référentiel public et privé a été invité à examiner les problèmes ouverts sur le référentiel public. Un problème contrefait dans le dépôt public contenait des instructions cachées ; l'agent, le lisant dans le cadre de sa tâche normale, les a suivis et, au cours de la démonstration, a ensuite exposé les détails du référentiel privé, y compris les informations que les chercheurs décrivent comme personnelles, au fil de discussion contrôlé par l'attaquant. Invariant Labs a clairement indiqué qu'il s'agissait d'une preuve de concept démontrée sur les référentiels de test, et non d'une attaque observée dans la nature, et que « il ne s'agit pas d'une faille dans le code du serveur GitHub MCP lui-même, mais plutôt d'un problème architectural fondamental qui doit être résolu au niveau du système d'agent. » Le modèle utilisé lors de la démonstration était le Claude 4 Opus.
Le trio mortel
Le 16 juin 2025, Simon Willison a nommé le modèle derrière des cas comme celui-ci le « tiercé trio mortel » : un agent qui a (1) accès à des données privées, (2) exposition à du contenu non fiable et (3) un moyen de communiquer en externe. « Si votre agent combine ces trois fonctionnalités, un attaquant peut facilement le tromper pour qu'il accède à vos données privées et les envoie à cet attaquant. » Il nomme spécifiquement MCP comme contributeur : « Le problème avec Model Context Protocol — MCP — est qu'il encourage les utilisateurs à mélanger et assortir des outils provenant de différentes sources qui peuvent faire différentes choses », ce qui permet de se retrouver facilement avec les trois propriétés actives dans une seule session sans le décider.
Pourquoi c'est difficile à voir pour les outils de point de terminaison
Du point de vue du système d'exploitation, rien d'inhabituel ne s'est produit dans le cas de GitHub MCP : une application signée et fiable a lu du texte et a effectué une requête réseau via un processus d'assistance local pour lequel elle a été configurée. Il n'y a aucun binaire malveillant à signaler et aucun exploit d'un bogue de sécurité mémoire. La requête qui compte – celle qui exécute les données – a la même forme que n’importe quel autre outil que l’agent appelle correctement cent fois par jour.
Qu'est-ce qui réduit réellement le risque
- Donnez à chaque serveur MCP les outils et la portée de fichiers les plus restreints dont il a besoin, et non un accès étendu au système de fichiers ou au shell, de sorte qu'un appel d'outil piraté ait moins à faire.
- Traitez tout contenu qu'un agent lit hors de votre contrôle (problèmes, pages Web, fichiers téléchargés) comme une entrée non fiable, la même discipline que vous appliqueriez à la saisie utilisateur dans n'importe quel autre système.
- Suivez les instructions au niveau du transport fournies par la spécification MCP elle-même : liez les serveurs locaux à localhost, exigez une authentification, validez l'en-tête Origin.
- Surveillez ou contrôlez l'étape que partage chaque version de cette attaque : la connexion sortante qui transporterait les données vers l'attaquant. Cette étape se produit une fois que le modèle a déjà été trompé, c'est pourquoi il s'agit de l'endroit le plus fiable pour l'attraper.
Le rôle de FireAI et de HisnLabs
The step an injected agent cannot skip is the outbound connection that carries your data out, which is exactly what a per-app firewall like FireAI is built to see and stop, whether the process asking to connect is a familiar app or an MCP server it has never seen before.
FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction Autopilot) sur du trafic réel, sans que rien ne quitte votre Mac.
Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.