Les définitions d'outils MCP comme surface d'attaque : descriptions empoisonnées, usurpation et changements silencieux

Objectif

Traiter la liste d'outils qu'un serveur MCP renvoie comme une entrée non fiable, et détecter quand elle tente d'influencer l'agent ou change après avoir été approuvée.

Prérequis

Un client ou une passerelle où les définitions d'outils peuvent être journalisées avant d'atteindre le modèle ; une liste des serveurs approuvés.

Étapes

1. Lire la position de la spécification : les outils portent un nom, une description, un schéma d'entrée, un schéma de sortie optionnel et des annotations optionnelles, et les clients DOIVENT considérer les annotations d'outils comme non fiables à moins qu'elles ne proviennent de serveurs de confiance. Appliquer la même posture aux descriptions, que le modèle lit comme de la prose.
2. Au moment de l'approbation, stocker un hachage de la définition complète de chaque outil (nom, description, schémas, annotations) par serveur.
3. À chaque connexion, et chaque fois que le serveur envoie une notification de changement de liste, recalculer les hachages. Si une définition a changé, suspendre les outils du serveur jusqu'à ce qu'une personne revoie le diff.
4. Revoir les descriptions à la recherche d'instructions visant le modèle plutôt que la personne : demandes de lire des fichiers sans rapport avec le but de l'outil, d'inclure des données supplémentaires dans les arguments, de préférer cet outil à celui d'un autre serveur, ou de garder quelque chose secret vis-à-vis de la personne.
5. Détecter l'usurpation : deux serveurs exposant des outils aux noms identiques ou prêtant à confusion, ou la description d'un serveur faisant référence aux outils d'un autre serveur. Préfixer les noms d'outils par le serveur dans le client.
6. Vérifier que ce que fait un outil correspond à ses annotations ; un outil annoté comme lecture seule mais qui produit des effets d'écriture est une raison de retirer le serveur.
7. Montrer à la personne le nom du serveur et les arguments exacts avant un appel à effets de bord, pas seulement l'auto-description de l'outil.

Résultat attendu

Les changements de définitions d'outils deviennent des événements visibles au lieu de mises à jour silencieuses ; une description qui tente d'orienter le modèle est repérée en revue plutôt que lors d'un incident.

Limites et base de vérification

Le hachage détecte le changement, pas l'intention ; une définition malveillante dès le départ requiert la revue de l'étape 4. Un serveur peut quand même se comporter différemment au moment de l'appel par rapport à ce que dit sa description — les définitions ne contraignent rien côté serveur. Les serveurs locaux s'exécutent avec les privilèges de la personne ; les recommandations de sécurité MCP traitent la compromission d'un serveur local comme un risque distinct.