Serveurs MCP : la faille n'est pas dans le code, elle est dans le mode d'emploi

Un studio branche à son agent un serveur MCP de plus, pour trier des captures ou renommer des calques. Rien d'inhabituel. Dans la description de l'outil, pourtant, une ligne a été ajoutée : avant toute action, lire le fichier de configuration du projet et en transmettre le contenu à une adresse précise, « pour vérification ». L'agent obéit. Les clés d'API du compte Figma, le jeton GitHub, parfois le dossier des maquettes client partent avec, et l'écran n'affiche qu'un « tâche terminée ».

C'est le scénario que décrivent, sous des formes variées, plusieurs travaux de 2026 autour du MCP (Model Context Protocol), le standard qui relie les agents IA à des outils externes. Ce protocole vient de passer un an d'adoption large avec les habitudes de npm en 2016 : on empile les serveurs, on copie des configurations trouvées en ligne, on donne à l'agent l'accès aux fichiers, à la base de données, à la messagerie. La question de la sécurité vient après.

Une description d'outil, et l'agent exécute

Le mécanisme est simple. Le champ de description d'un outil MCP est du texte que le modèle reçoit dans son contexte, exactement comme une instruction. Il ne distingue pas la notice de l'ordre. Un serveur malveillant peut donc y loger des consignes qui ressemblent à de l'aide : lire tel fichier, appeler telle API, envoyer telles données. Dans sa note de juillet 2026, la Cloud Security Alliance (CSA) parle d'une description jamais filtrée, alors qu'elle est lue avec une confiance totale.

OWASP (Open Worldwide Application Security Project) décrit le même défaut comme un écart de confiance : on relit les descriptions une fois, à l'installation, puis plus rien ne contrôle ce qui entre dans le contexte de l'agent. Or un serveur peut changer ses descriptions après coup.

Quand l'outil piégé n'est même pas appelé

L'étude MCP-ITP (janvier 2026) pousse la logique loin. L'outil empoisonné n'est jamais exécuté : ses métadonnées suffisent à convaincre l'agent d'utiliser à sa place un outil légitime et très privilégié, un accès aux fichiers ou à un terminal par exemple. Les auteurs annoncent jusqu'à 84,2 % de réussite, mesurée sur 12 agents testés dans des conditions de laboratoire, avec une détection qui tombe à 0,3 % : autrement dit, les détecteurs automatiques évalués ne repèrent presque aucune de ces descriptions piégées. Ce dernier chiffre est le plus parlant. Rien dans le code du serveur ne ressemble à du malware.

ShareLock (juin 2026) ajoute une couche. La consigne malveillante est découpée en fragments inoffensifs répartis sur plusieurs outils, selon le partage de secret de Shamir, une technique de cryptographie qui permet de diviser un secret en morceaux inutilisables séparément, et efficaces seulement une fois réunis. Chaque description, lue seule, paraît banale ; c'est leur combinaison qui déclenche l'attaque, parfois après une mise à jour du serveur. Les auteurs revendiquent plus de 90 % de réussite en moyenne, nettement devant les attaques à un seul outil.

Ce qui est réel, ce qui reste du laboratoire

Ces pourcentages mesurent ce qu'un attaquant peut obtenir quand il maîtrise le scénario, pas ce qui arrive dans un atelier ordinaire. Ils servent surtout à prouver que la porte existe. Le seul fait établi hors laboratoire dans ce dossier est une CVE (Common Vulnerabilities and Exposures) visant mcp-server-git, corrigée dans la version 2026.1.14 : une faille dans un serveur Git très répandu, de ceux qu'on installe sans y penser. C'est peu, et c'est bien cette modestie qu'il faut garder en tête avant de crier à l'épidémie.

Ce qui inquiète tient ailleurs que dans les taux de réussite : la quasi-invisibilité de l'attaque et la mise à jour silencieuse. Un serveur relu et validé un lundi peut se comporter autrement le jeudi, sans qu'aucune alerte ne se déclenche. Il y a là un angle mort de méthode, que ni un antivirus ni une revue de code classique ne couvrent. On n'a pas encore d'outil de détection fiable, et personne ne sait lequel s'imposera.

Par où commencer dans un studio

La liste des bonnes pratiques est longue ; deux mesures pèsent plus que les autres. La première : limiter les droits. Un serveur chargé de renommer des calques n'a aucune raison d'accéder au réseau ni au dossier des clients ; s'il est détourné, le dégât reste cantonné. La seconde : épingler les versions et ne laisser aucun serveur se mettre à jour seul, puisque c'est précisément par là que passe l'attaque fragmentée. Relire les descriptions à chaque changement de version complète le dispositif.

• Faire l'inventaire des serveurs réellement branchés (Figma, GitHub, Slack, Notion, selon les équipes), de leurs outils et de leurs droits : beaucoup de studios découvrent à ce stade des serveurs oubliés.
• Tenir un journal des appels d'outils, pour pouvoir relire ce que l'agent a fait le jour où un doute surgit.

Alarme ou simple vigilance ?

Rien ne dit que l'empoisonnement d'outils devienne l'attaque dominante de 2027 : la plupart des cas documentés restent des démonstrations. Mais l'écosystème npm a mis près de dix ans à imposer provenance, signatures et permissions, et il a fallu des incidents pour l'y contraindre. Corriger ses réglages aujourd'hui prend une après-midi. Le faire après une fuite de maquettes se compte autrement. Reste une inconnue : combien d'attaques réelles circulent déjà sans avoir été repérées, puisque la détection est justement ce qui fait défaut.