Sécurité MCP : menaces, audit et durcissement du Model Context Protocol

Le Model Context Protocol (MCP) est un protocole ouvert qui permet à une application d'IA de se connecter à des outils et à des sources de données via des serveurs standardisés. La sécurité MCP consiste à contrôler ce que ces serveurs peuvent faire, ce qu'ils peuvent faire croire au modèle et avec quels droits ils agissent. Un serveur MCP est à la fois du code exécuté, un fournisseur de texte lu par le modèle et un détenteur d'identifiants : chacun de ces rôles est une surface d'attaque.

Qu'est-ce que le Model Context Protocol et pourquoi pose-t-il des questions de sécurité ?

MCP est un protocole qui standardise la façon dont un client (un assistant, un IDE, un agent) découvre et appelle les outils, ressources et prompts exposés par un serveur. Il pose des questions de sécurité parce qu'il met côte à côte du code tiers, du texte tiers et des identifiants, avec un modèle de langage qui décide de ce qu'il faut appeler.

Un serveur MCP expose des outils (fonctions que le modèle peut appeler), des ressources (données lisibles) et des prompts (modèles d'instructions). Le client transmet au modèle la description des outils ; le modèle choisit lesquels appeler et avec quels arguments ; le client exécute l'appel, éventuellement après confirmation de l'utilisateur. La spécification elle-même recommande qu'un humain puisse refuser les appels d'outils, ce qui montre que la validation est une barrière de sécurité centrale.

Les serveurs tournent soit en local (sur le poste de l'utilisateur, avec ses droits), soit à distance (avec authentification OAuth). Dans les deux cas, ils servent de pont entre un modèle manipulable et des systèmes réels. C'est ce qui fait de MCP un sujet central pour tout audit d'agent ; voyez notre page sur la sécurité des agents IA pour le cadre général.

Quel est le modèle de menace d'un déploiement MCP ?

Le modèle de menace MCP repose sur trois acteurs non fiables : le contenu que le modèle lit, le serveur lui-même et le réseau ou le poste qui l'héberge. Un attaquant peut passer par n'importe lequel pour obtenir des actions que l'utilisateur n'a pas voulues.

On distingue quatre frontières à examiner :

• Entre le modèle et le contenu : tout texte renvoyé par un outil ou une ressource peut contenir une injection de prompt.
• Entre le client et le serveur : description des outils, schémas, authentification, jetons, transport.
• Entre le serveur et les systèmes en aval : API, bases de données, fichiers, shell, avec les droits que le serveur détient.
• Entre plusieurs serveurs : un serveur peut influencer la façon dont le modèle utilise les autres, puisque tout converge dans le même contexte.

Le projet OWASP MCP Top 10 et le guide de test OWASP MCP Security Testing Guide organisent ces risques en catégories. Le guide compte 79 tests répartis en dix-neuf familles, de la découverte à la gouvernance en passant par l'authentification, les outils, la chaîne d'approvisionnement et les secrets.

Qu'est-ce que l'empoisonnement d'outils (tool poisoning) ?

L'empoisonnement d'outils consiste à cacher des instructions malveillantes dans la description ou le schéma d'un outil MCP. Le modèle lit ces descriptions comme du contexte de confiance, alors que l'interface n'en montre souvent qu'un résumé à l'utilisateur. Invariant Labs a décrit cette attaque en 2025 : une description peut demander au modèle de lire un fichier sensible ou d'ajouter des données à ses appels, sans que l'utilisateur le remarque.

L'attaque est efficace parce qu'elle ne nécessite aucune interaction avec la victime au moment de l'appel : l'instruction est présente dès que l'outil est chargé. Les champs à inspecter ne se limitent pas à la description : noms de paramètres, valeurs par défaut, schémas et messages d'erreur peuvent aussi porter du texte hostile. Le catalogue de tests OWASP couvre ces cas dans les familles « Tool Security » et « Prompt and Instruction ».

Que sont le rug pull et l'usurpation entre outils (tool shadowing) ?

Un rug pull MCP désigne un serveur qui se comporte correctement à l'installation puis modifie ensuite la description ou le comportement de ses outils, après que l'utilisateur l'a approuvé. Le tool shadowing désigne un serveur malveillant dont la description d'outil influence la façon dont le modèle utilise les outils d'un autre serveur, par exemple pour rediriger les destinataires d'un e-mail envoyé par un serveur de confiance.

Invariant Labs a documenté ces deux variantes dans son alerte sur le tool poisoning. Le rug pull exploite l'absence de vérification d'intégrité entre le moment de l'approbation et celui de l'usage. Le shadowing exploite le fait que tous les serveurs partagent un seul contexte : un serveur sans accès direct à vos données peut malgré tout diriger l'usage d'un serveur qui, lui, y accède. Les parades sont l'épinglage des versions, la détection des changements de définition d'outils et la séparation stricte des serveurs selon leur niveau de confiance.

Quels risques posent les droits OAuth trop larges et le token passthrough ?

Des périmètres OAuth trop larges donnent au serveur, et donc à un attaquant qui le détourne, bien plus de droits que la tâche n'en exige. Le token passthrough est un anti-modèle où un serveur MCP accepte des jetons qui n'ont pas été émis pour lui, puis les retransmet à une API en aval. La spécification MCP l'interdit explicitement : un serveur ne doit accepter que des jetons émis pour lui.

Le guide de bonnes pratiques de sécurité de MCP consacre une section à chaque risque : confused deputy, token passthrough, SSRF, détournement de session, compromission d'un serveur local et minimisation des périmètres (scope minimization). Pour les périmètres, la règle est de demander le minimum au départ, puis d'élever les droits de façon progressive quand une opération précise l'exige, plutôt que d'accorder d'emblée des jokers du type « accès complet ».

Le token passthrough casse la traçabilité et les contrôles : l'API en aval ne sait plus quel client a réellement agi, et un jeton volé sur le serveur devient utilisable ailleurs. La spécification d'autorisation MCP s'appuie sur OAuth 2.1 et sur les indicateurs de ressource pour lier un jeton à son destinataire.

Qu'est-ce que le problème du confused deputy dans MCP ?

Le confused deputy survient quand un serveur MCP agit avec ses propres privilèges pour le compte d'un utilisateur sans vérifier que celui-ci y a droit. Le cas typique concerne un serveur proxy qui utilise un identifiant client OAuth statique auprès d'un fournisseur tiers : si le consentement n'est pas demandé pour chaque client, un attaquant peut obtenir un code d'autorisation à l'insu de la victime.

La parade décrite par la documentation MCP est de recueillir un consentement explicite de l'utilisateur pour chaque client enregistré avant de transmettre la demande au fournisseur tiers, de valider strictement les URI de redirection et de lier l'état OAuth à la session. Dans un audit, on vérifie aussi que les droits utilisés par le serveur sont ceux de l'utilisateur et non un compte de service omnipotent.

Pourquoi l'injection de commandes dans les serveurs MCP est-elle fréquente ?

Beaucoup de serveurs MCP transforment les arguments choisis par le modèle en commandes système, requêtes SQL, chemins de fichiers ou requêtes HTTP. Si ces arguments ne sont pas validés, une injection de prompt devient une injection de commande, une traversée de répertoires ou une SSRF. Le modèle devient alors le vecteur qui apporte la charge utile à une faille classique.

Ce chemin est bien documenté dans notre veille : voyez l'article sur une injection de commandes via MCP dans LiteLLM et celui sur une faille OAuth dans le SDK Python MCP. Le catalogue de tests couvre la validation des paramètres, la traversée de chemins, le rendu des sorties et les protections SSRF pour les outils qui effectuent des requêtes HTTP. Le serveur doit traiter chaque argument comme hostile, même s'il vient du modèle.

Comment la chaîne d'approvisionnement des serveurs MCP est-elle attaquée ?

Un serveur MCP installé depuis un registre public est du code tiers exécuté avec vos droits : il subit donc les mêmes risques que n'importe quelle dépendance, avec une aggravation, puisqu'il reçoit aussi la confiance du modèle. L'OWASP traite la chaîne d'approvisionnement des applications LLM dans LLM03:2025.

Les scénarios à couvrir sont l'usurpation de nom (typosquatting), la compromission d'un mainteneur, la mise à jour automatique qui introduit du code malveillant et les serveurs publiés sans provenance vérifiable. Notre veille documente un cas concret avec le ver npm lié au paquet postmark-mcp. Les mesures de base : inventaire des serveurs autorisés, versions épinglées, vérification de la provenance, revue du code avant approbation, désactivation des mises à jour silencieuses. Notre article sur l'audit MCP d'une base de données montre ces contrôles sur un cas pratique.

Comment auditer un serveur MCP ?

Auditer un serveur MCP revient à parcourir ses outils, ses droits et sa chaîne d'authentification en tentant de les détourner de façon contrôlée. La liste ci-dessous reprend les familles du guide de test OWASP, que nous avons associées à notre méthode ; elle résume le catalogue plutôt que de le reproduire.

1. Découverte. Identifier les serveurs, énumérer les outils, ressources et prompts, cartographier les frontières de confiance et les flux de contexte sensibles.
2. Configuration et déploiement. Exposition d'un serveur local (écoute sur toutes les interfaces), mode debug, messages d'erreur détaillés, permissions de fichiers, transport non chiffré.
3. Authentification. Serveur accessible sans authentification, jetons faibles, réutilisation des identifiants entre outils, jetons expirés ou révoqués encore acceptés.
4. Autorisation. Droits excessifs des outils, contournement de l'approbation utilisateur, accès entre utilisateurs, élévation par enchaînement d'outils, sortie du périmètre de travail.
5. Sécurité des outils. Empoisonnement de description, manipulation de schéma, exécution dangereuse, injection de commandes dans les paramètres, chaînage d'outils à risque, validation humaine des outils sensibles.
6. Ressources et données. Exposition de ressources sensibles, énumération, fuite de secrets, accès non autorisé aux fichiers.
7. Instructions et contexte. Injection de prompt directe et indirecte par les ressources, empoisonnement de mémoire, priorité accordée au contexte non fiable, partage excessif de contexte.
8. Entrées et sorties. Validation des paramètres, traversée de chemins, rendu non sûr, données sensibles dans les sorties.
9. Passerelle et sortie réseau. Liste d'autorisation des destinations, protection SSRF, limitation de débit.
10. Secrets. Secrets dans la configuration et l'environnement, stockage et rotation des jetons, masquage dans les journaux.
11. Journalisation et détection. Traçabilité des appels d'outils, journaux des approbations, détection des tentatives d'injection, reconstitution d'incident.
12. Chaîne d'approvisionnement et gouvernance. Provenance, dépendances vulnérables, installation de serveurs malveillants, mises à jour automatiques, inventaire et registre de serveurs approuvés.

Les tests de priorité maximale pour un agent sont ceux qui relient le modèle à une action : contournement de l'approbation, empoisonnement de descriptions, chaînage d'outils dangereux, injection indirecte, exfiltration par sortie réseau. C'est là que notre Red Team Agent Express concentre l'effort.

Comment auditer la configuration d'un client MCP ?

Côté client, l'audit porte sur ce que l'utilisateur ou l'organisation a branché et sur les garde-fous de l'application. Un client mal configuré annule la sécurité d'un serveur bien conçu.

• Inventaire. Quels serveurs sont connectés, par qui, avec quels identifiants, locaux ou distants ?
• Approbation. Les appels d'outils à effet de bord demandent-ils une confirmation qui montre les arguments réels ? Le mode « tout autoriser » est-il désactivé ?
• Changements. Le client signale-t-il quand la description d'un outil change après approbation ?
• Isolation. Les serveurs de niveaux de confiance différents partagent-ils le même contexte ? Un serveur non fiable peut-il être associé à un serveur qui accède à des données sensibles ?
• Droits du poste. Les serveurs locaux tournent-ils dans un conteneur ou un bac à sable avec le minimum de droits, plutôt qu'avec les droits complets de l'utilisateur ?
• Politique d'organisation. Existe-t-il une liste de serveurs approuvés, une exception documentée et une preuve de conformité ?

Comment durcir un déploiement MCP ?

Le durcissement s'appuie sur la réduction des droits, l'authentification correcte et le contrôle humain. Les mesures suivantes reprennent les recommandations du guide de bonnes pratiques de MCP et de nos missions.

• Appliquer le moindre privilège : un outil, un périmètre étroit, un identifiant distinct.
• Utiliser OAuth conformément à la spécification, valider l'audience des jetons et refuser tout token passthrough.
• Exécuter les serveurs locaux dans un bac à sable avec un système de fichiers et un réseau restreints.
• Valider chaque paramètre côté serveur, avec des schémas stricts, et filtrer la sortie réseau par liste d'autorisation.
• Exiger une validation humaine pour toute action irréversible ou sortante, avec affichage des arguments réels.
• Épingler les versions, vérifier la provenance, suivre les changements de définitions d'outils.
• Journaliser les appels et les approbations sans y écrire de secrets.
• Séparer les serveurs selon leur niveau de confiance et éviter de combiner données privées, contenu non fiable et canal de sortie.

Notre futur Shield, une couche logicielle entre l'agent et ses outils qui appliquera une politique d'actions autorisées, vise précisément ce dernier point. Il est en développement et n'est pas disponible aujourd'hui.

Comment CleanIssue audite-t-il un périmètre MCP ?

Nous testons les serveurs et les clients MCP en conditions réelles, depuis les entrées non fiables jusqu'aux actions et aux données qui en sortent, avec des preuves rejouables. Le Red Team Agent Express coûte 1 900 € pour 5 jours et couvre un agent ; un périmètre MCP plus large relève du Red Team sur mesure, sur devis.

Le premier contact est un rendez-vous découverte gratuit de 30 minutes. Pour la partie méthode, voyez notre approche et notre page sur le red team d'agents IA. Pour comprendre comment une instruction hostile arrive jusqu'à vos outils, lisez notre page sur l'injection de prompt, ainsi que l'article sur le détournement d'un agent via un commentaire de pull request et un serveur MCP.