ShareLock : le poisoning à seuil disperse un payload MCP sur plusieurs outils

De quoi s’agit-il ?

Le 25 juin 2026, Liwei Liu, Tianzhu Han, Zijian Liu, Zishu Dong et Na Ruan ont publié ShareLock: A Stealthy Multi-Tool Threshold Poisoning Attack Against MCP sur arXiv. L’article met en lumière un angle mort dans la défense de l’écosystème Model Context Protocol (MCP) contre le tool poisoning : presque tous les scanners inspectent une description d’outil à la fois, et ShareLock montre comment faire passer un payload sous cette hypothèse précise.

Les attaques de tool poisoning classiques insèrent une instruction malveillante en clair dans la description d’un seul outil, que l’agent lit puis exécute. C’est efficace mais fragile : une chaîne malveillante monolithique est exactement ce que la revue manuelle et les détecteurs automatiques cherchent à repérer. L’apport de ShareLock est de supprimer ce point de détection unique. Les auteurs rapportent un taux de réussite moyen supérieur à 90 % sur plusieurs LLM grand public et deux clients MCP différents, tout en surpassant nettement le poisoning mono-outil face à la détection basée sur les descriptions. Il s’agit d’un travail académique décrivant une classe d’attaque et ses défenses ; aucun payload opérationnel n’est reproduit ici.

Comment ça marche

ShareLock emprunte une idée à la cryptographie : le partage de secret à seuil de Shamir. Un secret est découpé en n parts telles que k d’entre elles suffisent à le reconstruire, mais que tout sous-ensemble plus petit ne révèle rien — pas même partiellement. ShareLock traite l’instruction malveillante comme ce secret et répartit des parts d’apparence anodine sur plusieurs descriptions d’outils, sur un ou plusieurs serveurs MCP.

La conséquence est ce qui rend l’attaque furtive : sous le seuil, les parts offrent une confidentialité informatiquement inconditionnelle. Prise isolément, chaque description d’outil empoisonnée est réellement inoffensive — il n’y a aucune instruction cachée à y trouver, car une part unique n’en contient mathématiquement aucune. Un scanner par outil, un juge LLM examinant les descriptions une à une ou un auditeur humain faisant des sondages n’y voient rien d’actionnable.

instruction malveillante  ──►  découpée en parts  s1 … sn   (Shamir, seuil k)

   description outil A  ⊃  s1     ← anodine isolément
   description outil B  ⊃  s2     ← anodine isolément
   description outil C  ⊃  s3     ← anodine isolément
        …                          (moins de k parts ne révèlent rien)

   [déclencheur de reconstruction furtif planté lors d'une mise à jour serveur]
        ▼
   l'agent agrège ≥ k parts  ──►  reconstruit l'instruction cachée  ──►  action

La reconstruction est différée. Les auteurs décrivent le fait de planter un déclencheur de reconstruction furtif lors d’une mise à jour de serveur de routine — les parts restent dormantes dans les outils jusqu’à ce que le déclencheur amène l’agent à en agréger au moins k, moment où l’instruction cachée se réassemble et provoque une compromission d’actifs système ou de données privées. L’évaluation couvre quatre scénarios multi-outils et deux clients MCP, et c’est la combinaison d’outils, et non l’un d’eux, qui est dangereuse.

Pourquoi c’est important

MCP incite les agents à charger de nombreux outils, souvent depuis plusieurs serveurs, et la communauté a surtout répondu par une hygiène par outil : scanner chaque description, filtrer chaque serveur, juger chaque outil. ShareLock montre qu’une stratégie de détection cantonnée aux outils individuels peut être irréprochable sur chacun d’eux tout en restant aveugle à l’ensemble. La surface d’attaque, c’est l’ensemble des outils installés et la manière dont l’agent les compose — une propriété qu’aucun contrôle mono-outil ne peut observer.

La tolérance aux pannes est le point le plus gênant. Comme la reconstruction ne nécessite que k parts sur n, un auditeur qui retire ou corrige un outil empoisonné n’a pas forcément neutralisé l’attaque, tant que le seuil reste atteignable. Cela rapproche la défense MCP du même terrain que les serveurs MCP malveillants au-delà du tool poisoning et les rug pulls de description d’outil : la menace réside dans les relations et le changement dans le temps, pas dans une chaîne statique.

Défenses

Pour les équipes qui exploitent des clients MCP ou curent des registres d’outils, la leçon est d’élargir l’unité d’analyse.

Analyser les outils ensemble, pas seulement un par un. Une détection qui note chaque description isolément est précisément ce que ShareLock est conçu pour déjouer. Évaluez l’ensemble conjoint des outils installés — corrélations inter-outils, jetons inhabituels partagés, descriptions qui n’ont de sens qu’agrégées — plutôt que de supposer que la propreté par outil se compose en sécurité globale.

Traiter les mises à jour de serveur comme un événement de sécurité. Le déclencheur de reconstruction est planté lors d’une mise à jour : figez les descriptions d’outils sur un hash revu, faites le diff de chaque changement et réauditez l’ensemble complet des outils — pas seulement celui qui a changé — avant d’accorder votre confiance.

Contraindre et observer au niveau de l’action. Comme le payload ne compte qu’au moment où il devient action, maintenez les défenses classiques du flux de contrôle : permissions d’outils au moindre privilège, confirmation humaine pour les opérations sensibles, et supervision d’exécution qui signale un agent faisant quelque chose qu’aucun objet déclaré d’outil ne justifie.

Réduire et vérifier la provenance de la surface d’outils. Moins d’outils issus de moins d’éditeurs de confiance abaisse les chances d’atteindre un seuil de reconstruction ; exigez des descriptions d’outils signées et à provenance tracée pour que des parts ne puissent pas être discrètement dispersées sur une marketplace.

Statut

Élément	Détail
Divulgation	Préprint arXiv 2606.27027 v1, soumis le 25 juin 2026 (CC BY-NC-SA 4.0), 16 pages
Classe	Technique d’attaque — poisoning à seuil multi-outils des descriptions d’outils MCP via le partage de secret de Shamir
Mécanisme	Instruction malveillante découpée en parts anodines ; déclencheur de reconstruction planté lors d’une mise à jour serveur
Évaluation	Quatre scénarios multi-outils · deux clients MCP · LLM grand public
Résultat rapporté	Taux de réussite moyen > 90 % ; surpasse le poisoning mono-outil face à la détection basée sur les descriptions
Faille défensive centrale	Les scanners par outil ne peuvent voir un payload qui n’existe que dans l’agrégat d’au moins k outils