Un serveur MCP local est-il dangereux ?

Il tourne avec les droits de votre compte et peut exécuter du code sur votre machine. La documentation conseille de n'installer que des serveurs de confiance, de lire la commande exacte avant de l'accepter et, côté client, de lancer les serveurs dans un environnement isolé.

Les annotations d'un outil MCP sont-elles fiables ?

Non : la spécification demande aux clients de les considérer comme non fiables, sauf si elles viennent d'un serveur de confiance.

Sécurité des serveurs MCP : risques et parades

Un serveur MCP (Model Context Protocol) donne à un modèle d'IA accès à des données et à des actions : c'est sa force et son risque. La spécification le dit sans détour : les outils représentent une exécution de code arbitraire. Les risques principaux sont l'injection de prompt, les serveurs locaux malveillants, la transmission de jetons, les requêtes forcées vers le réseau interne et les droits trop larges. Voici chaque risque et la parade décrite dans la documentation officielle, lue le 15/11/2026.

Les principes posés par la spécification

Consentement et contrôle : l'utilisateur consent explicitement à chaque accès aux données et à chaque opération, et garde la main sur ce qui est partagé.
Confidentialité : l'hôte obtient l'accord de l'utilisateur avant d'exposer ses données à un serveur, et ne les transmet pas ailleurs sans accord.
Sûreté des outils : l'hôte obtient l'accord explicite de l'utilisateur avant d'appeler un outil. Les descriptions de comportement, comme les annotations, sont tenues pour non fiables si le serveur n'est pas de confiance.

MCP ne peut pas imposer ces principes au niveau du protocole : c'est à chaque implémentation de les respecter.

Les risques, un par un

Risque	Ce qui se passe	Parade officielle
Injection de prompt	Un contenu récupéré par un outil contient des instructions que le modèle suit	Ne connecter que des serveurs de confiance, surtout s'ils lisent du contenu extérieur ; confirmation humaine avant les actions
Serveur local compromis	Une commande de démarrage ou un paquet malveillant exécute du code avec vos droits	Afficher la commande complète, exiger un accord explicite, isoler (bac à sable), restreindre fichiers et réseau
Transmission de jeton	Le serveur accepte un jeton émis pour un autre service et le relaie	Interdit : le serveur n'accepte que les jetons émis pour lui
Député confus	Un serveur relais OAuth (standard de délégation d'accès) réutilise un consentement déjà donné au profit d'un attaquant	Consentement par client, vérification exacte de l'adresse de retour, paramètre `state` à usage unique
SSRF (falsification de requête côté serveur)	Un serveur malveillant fait visiter au client des adresses internes, dont les métadonnées du cloud	HTTPS obligatoire, blocage des plages d'adresses privées, proxy de sortie
Vol d'identifiant d'état	Un attaquant devine l'identifiant d'un panier ou d'un traitement et agit sur l'état d'un autre	Identifiants aléatoires, liés côté serveur à l'utilisateur authentifié
URL d'autorisation piégée	Une adresse `javascript:` ou une commande glissée dans l'adresse	N'accepter que `https://` (et `http://` en local), ne jamais ouvrir une adresse par le shell
Droits trop larges	Un jeton volé ouvre tout (`files:`, `admin:`)	Droits minimaux au départ, élévation au cas par cas

Pour qui écrit un serveur

La spécification des outils impose aux serveurs de :

valider toutes les entrées des outils ;
mettre en place des contrôles d'accès ;
limiter le nombre d'appels ;
nettoyer les sorties.

Et pour un serveur HTTP : valider l'en-tête Origin (réponse 403 si elle est invalide), n'écouter que sur 127.0.0.1 en local, authentifier toutes les connexions. Un serveur prévu pour le poste de l'utilisateur gagne à utiliser stdio, qui limite l'accès au seul client qui l'a lancé. Ne marquez jamais un paramètre sensible (mot de passe, clé, donnée personnelle) avec x-mcp-header : il serait recopié dans un en-tête visible des intermédiaires réseau.

Pour qui intègre un client

La spécification recommande aux clients de :

demander confirmation pour les opérations sensibles ;
montrer à l'utilisateur les paramètres envoyés avant l'appel, pour éviter une fuite de données ;
valider les résultats avant de les passer au modèle ;
fixer un délai maximal aux appels ;
journaliser l'utilisation des outils pour l'audit.

Pour qui installe des serveurs

Les conseils des éditeurs vont dans le même sens. La documentation de Claude Code demande de vérifier que l'on fait confiance à chaque serveur avant de le connecter, car un serveur qui récupère du contenu extérieur expose à l'injection de prompt. Le centre d'aide de Claude ajoute : ne connecter que des serveurs de confiance, relire les permissions demandées, se méfier des injections, et garder en tête qu'un serveur peut modifier le comportement de ses outils sans prévenir.

Une liste de contrôle simple avant d'ajouter un serveur :

Qui l'édite ? Le code ou le paquet est-il public et maintenu ?
Quelle commande exacte va s'exécuter, avec quels arguments ?
À quels dossiers, quelles données, quels comptes a-t-il accès ?
Lit-il du contenu venu de l'extérieur (pages web, courriels, tickets) ? Si oui, attention à l'injection.
Ses outils d'écriture demandent-ils une confirmation ? Pouvez-vous les désactiver ?

En entreprise

La sécurité se joue aussi à l'échelle de l'organisation : liste des serveurs autorisés, autorisation centralisée par le fournisseur d'identité, registre privé. Voir MCP en entreprise et, pour le détail des jetons, MCP distant et OAuth.