Guide · Cybersécurité
Sécuriser un serveur MCP et ses skills avant de les connecter
Une checklist de confiance pour réduire le risque de tool poisoning, de permissions excessives et de supply chain compromise dans les workflows agentiques.
Une connexion est une frontière de confiance
Un serveur MCP n’est pas seulement un catalogue de fonctions. Il peut exposer des fichiers, des API, des comptes et des actions d’écriture à un agent. OWASP décrit plusieurs risques spécifiques : tool poisoning dans les descriptions ou retours d’outils, rug pull lorsqu’un outil change après approbation, tool shadowing, confused deputy, exfiltration par des canaux légitimes et permissions trop larges.
La première question n’est donc pas « cet outil est-il pratique ? », mais « quelles capacités précises cette connexion ajoute-t-elle, pour quelles données et avec quel compte ? ».
Inventorier avant d’approuver
Pour chaque serveur ou skill, consignez : la provenance, le dépôt et sa version, le mainteneur, les fichiers lus, les opérations d’écriture, les domaines réseau, les secrets utilisés, les journaux disponibles et la procédure de révocation. Séparez ce qui est documenté de ce qui est observé pendant un test.
Un skill ou un serveur doit rester dans son périmètre déclaré. Une instruction cachée dans une description d’outil ou dans un retour de recherche est une donnée non fiable : elle ne peut ni étendre les permissions, ni demander un secret, ni modifier le contrat de la tâche.
Réduire les permissions
Commencez en lecture seule, avec un compte de test et un jeu de données sans information sensible. Utilisez le scope OAuth le plus étroit possible, limitez les répertoires et les domaines, et séparez les identifiants de lecture des identifiants d’écriture. Une action irréversible doit exiger une confirmation humaine et un identifiant explicite de ressource.
OWASP recommande également de traiter la supply chain des serveurs comme un risque à part entière. Épinglez une version, conservez son empreinte ou son artefact de référence et examinez les changements de définition d’outil avant une mise à jour.
Valider les retours, pas seulement les descriptions
Le client doit distinguer récupération, validation et décision. Quand c’est possible, imposez une sortie structurée avec un schéma fixe et rejetez les champs inattendus. Cela ne détecte pas toutes les injections, mais réduit le canal où une réponse libre peut se transformer en consigne.
Testez au minimum une réponse normale, une réponse contenant une instruction parasite, une ressource hors périmètre, un refus d’autorisation et une erreur réseau. Le résultat attendu est un échec lisible, sans tentative de secours avec une permission plus forte.
Auditer un skill avant installation
SkillSpector se présente comme un scanner de skills capable de produire des rapports terminal, JSON, Markdown ou SARIF, avec un mode --no-llm. Il peut fournir un signal d’audit reproductible, pas une garantie d’absence de malveillance. Scannez une copie isolée, conservez le rapport et examinez les findings critiques avec un humain.
Le scanner lui-même devient une dépendance à évaluer : vérifiez sa version, sa provenance et la portée exacte de l’arbre analysé. Un rapport vide signifie seulement qu’aucune règle déclenchée n’a été observée dans ce périmètre.
Préparer le retrait avant l’activation
Documentez qui peut révoquer les tokens, comment désinstaller le serveur ou le skill, comment vérifier qu’un secret n’est plus accepté et où rechercher les appels déjà effectués. Si cette procédure n’est pas claire, gardez le workflow local et documenté.
Pour revoir les notions du protocole avant l’audit des extensions, consultez MCP : définition, fonctionnement et sécurité.
Sources et limites
Sources officielles consultées le 22 septembre 2026 : OWASP MCP Security Cheat Sheet, OWASP MCP Tool Poisoning et NVIDIA SkillSpector. Cette checklist ne remplace pas un audit de configuration, de code ou d’identité.