Sécurité MCP : la vraie question n'est pas quelles attaques existent, mais où placer les défenses

De quoi s’agit-il ?

MCP-DPT est une taxonomie de placement des défenses pour le Model Context Protocol, publiée sur arXiv (2604.07551) le 8 avril 2026. La majorité des travaux sur la sécurité MCP sont jusqu’ici centrés sur l’attaque : ils décrivent comment fonctionnent le tool poisoning, les rug pulls ou le tool shadowing, et à quelle fréquence ils réussissent. MCP-DPT pose une question différente, plus opérationnelle — vu la conception multi-acteurs et à confiance distribuée de MCP, où chaque défense doit-elle être appliquée, et quel acteur en est responsable ?

Le constat central de l’article, après cartographie des défenses académiques et industrielles existantes, est sans détour : la protection est « inégale et majoritairement centrée sur l’outil, avec des lacunes persistantes au niveau de l’orchestration hôte, du transport et de la chaîne d’approvisionnement ». Autrement dit, le domaine a accumulé les mesures sur la couche la plus facile à raisonner — l’outil — tandis que les couches structurellement critiques restent peu défendues. Les auteurs soutiennent que ces lacunes sont structurelles — un défaut d’alignement architectural — plutôt que des bugs d’implémentation isolés. Cela prolonge une série de travaux sur la menace MCP, dont les vecteurs d’attaque par sampling MCP d’Unit 42 (décembre 2025), les considérations de conception sécurité MCP de la NSA, et la taxonomie de menaces MCP-38.

Comment ça marche

MCP est un protocole hôte–client–serveur : une application hôte orchestre un LLM, un client MCP parle le protocole, et des serveurs MCP exploités indépendamment exposent des outils. MCP-DPT décompose cela en six couches, chacune étant une frontière de confiance détenue par un acteur différent :

1. Fournisseur de modèle / Alignement LLM — le comportement de refus et de raisonnement du modèle lui-même.
2. Hôte / Application MCP — orchestration, demandes d’approbation, assemblage du contexte.
3. Client / SDK MCP — analyse du protocole, gestion des paramètres, état de session.
4. Serveur MCP / Exécution d’outils — là où le code de l’outil s’exécute réellement.
5. Transport / Réseau — le canal : authentification, liaison de session, protection contre le rejeu et la falsification.
6. Registre / Marketplace & Chaîne d’approvisionnement — découverte, publication, mises à jour, nommage.

Pour chaque attaque, l’article identifie une couche de défense primaire — « la première frontière architecturale où une prévention significative peut être appliquée avec une autorité et une visibilité suffisantes » — et une couche secondaire de repli. Si un seul contrôle ne suffit jamais, c’est à cause de la forme même du protocole : une attaque peut entrer à une couche mais ne devenir observable ou stoppable qu’à une autre. Un registre ne peut inspecter que des métadonnées statiques au moment de la soumission, mais le comportement d’un outil malveillant peut ne se manifester qu’à l’exécution, dans l’hôte. Défendre uniquement l’outil laisse donc une fenêtre ouverte à chaque autre frontière.

Quand les auteurs catégorisent ensuite les défenses réelles (statiques/pré-exécution, runtime/comportementales, isolation/architecture, et au niveau décisionnel) et recensent l’outillage déployé, la carte de couverture ressort déséquilibrée : les mesures se concentrent sur l’inspection des outils et des prompts, tandis que le transport, l’orchestration hôte et la gouvernance registre/chaîne d’approvisionnement sont minces. Aucun exploit ni payload n’est nécessaire pour en voir la conséquence — c’est une lacune de couverture, pas une nouvelle attaque.

Pourquoi c’est important

Si vous faites tourner des agents via MCP, la leçon pratique est qu’acheter un scanner d’outils n’est pas une stratégie de sécurité MCP. Un scanner qui inspecte les descriptions d’outils à l’installation ne fait rien contre un transport sans liaison de session, un hôte qui approuve automatiquement les appels d’outils, ou un registre qui laisse un attaquant squatter un nom de serveur puis pousser une mise à jour malveillante (un « rug pull »). Ce sont des acteurs et des couches différents.

Le cadrage « structurel, pas accidentel » fixe aussi les attentes. Comme aucun acteur ne contrôle l’ensemble de la pile MCP, la sécurité est nécessairement un problème de responsabilité partagée — plus proche de l’IAM cloud que du patch d’une bibliothèque. Les équipes qui supposent que le protocole ou un fournisseur unique « gère la sécurité » sont précisément celles que l’analyse de couverture prédit comme exposées aux couches hôte, transport et chaîne d’approvisionnement.

Défenses

Utilisez le modèle en couches comme une check-list, et placez chaque contrôle à son point d’application primaire plutôt que d’espérer que la couche outil rattrape tout.

• Orchestration hôte (la couche la plus négligée). Exigez une approbation humaine explicite pour les appels d’outils à fort impact, appliquez le moindre privilège par outil, et isolez la sortie d’outil non fiable des instructions de confiance dans le contexte. N’approuvez pas automatiquement.
• Transport / réseau. Utilisez des canaux authentifiés et à intégrité protégée, avec liaison de session et protection contre le rejeu. Traitez « MCP suppose un canal fiable » comme une vulnérabilité, pas comme une hypothèse.
• Registre / chaîne d’approvisionnement. Épinglez les identités et versions de serveurs, vérifiez la provenance, et réévaluez les outils à chaque mise à jour — pas seulement à la première installation — pour détecter rug pulls et squat de noms. La revue de métadonnées statiques à la soumission est nécessaire mais pas suffisante.
• Serveur / exécution d’outils. Mettez l’exécution des outils en bac à sable, limitez l’accès au système de fichiers et la sortie réseau, et validez les paramètres contre un schéma avant exécution.
• Défense en profondeur, par conception. Pour chaque attaque qui vous concerne, demandez : quelle est la première couche capable de l’arrêter avec assez d’autorité, et quelle est la couche de repli ? Affectez un responsable à chacune. Un contrôle qui ne se déclenche qu’une fois le dommage en aval est une défense secondaire, pas primaire.

Statut

Couche	Acteur typique	Couverture selon MCP-DPT
Fournisseur de modèle / alignement	Éditeur du modèle	Partielle (refus seulement)
Hôte / application MCP	Intégrateur	Sous-protégée
Client / SDK MCP	Mainteneur du SDK	Inégale
Serveur MCP / exécution d’outils	Auteur de l’outil	Surreprésentée (centrée outil)
Transport / réseau	Intégrateur / infra	Sous-protégée
Registre / chaîne d’approvisionnement	Écosystème / registre	Sous-protégée

L’article est une taxonomie et une analyse de couverture, pas une divulgation de vulnérabilité — il n’y a rien à patcher ni de payload à retenir. Sa valeur tient au recadrage : les faiblesses récurrentes de MCP se lisent mieux comme des défenses mal placées, et la correction consiste à appliquer chaque contrôle à la couche qui en est réellement propriétaire. Publié le 8 avril 2026 ; les classes d’attaques qu’il organise (tool poisoning, shadowing, rug pulls, falsification de transport, squat de registre) sont toutes déjà documentées dans la littérature publique sur la sécurité MCP.