Sécurité des serveurs MCP : comment identifier et atténuer les risques

Les serveurs MCP (Model Context Protocol) permettent aux grands modèles de langage (LLM) d’appeler des outils, d’interroger des sources de données et d’agir dans le monde réel. Mais ces capacités supplémentaires engendrent de nouveaux risques. Pour garantir la sécurité, le déploiement en production d’un MCP nécessite un plan de contrôle.

Cet article explique le fonctionnement du plan de contrôle dans la sécurité des serveurs MCP, la manière dont l’application des règles s’effectue au niveau de la couche d’exécution, ainsi que les contrôles relatifs à l’authentification et à l’autorisation MCP.

Pourquoi la sécurité MCP représente-t-elle un défi ?

Les modèles de sécurité traditionnels contrôlent le comportement humain. Une personne clique sur un bouton, et un « gardien de sécurité » numérique vérifie si cette action est autorisée. Avec le MCP, les bots IA prennent des décisions de manière autonome. Au lieu d’attendre qu’une personne autorise chaque action, l’IA agentique décide quels outils MCP utiliser et comment les enchaîner.

Les mots de passe et les clés numériques créent également des vulnérabilités. Ces secrets restent généralement verrouillés dans un stockage sécurisé, mais dans un système MCP, de nouveaux risques apparaissent : ces clés peuvent être exposées lorsqu’elles circulent pour aider l’IA agentique à accomplir ses tâches. Les agents IA changent de tâche et combinent les outils de manière imprévisible, ce qui signifie que la zone de danger évolue constamment. Les systèmes de sécurité MCP doivent vérifier en permanence l’identité de l’IA, définir des limites à ses accès et consigner chacun de ses mouvements afin de ne pas passer à côté de vulnérabilités importantes.

Comment les attaquants exploitent les serveurs MCP

Les risques liés aux vulnérabilités MCP se répartissent en plusieurs grandes classes, que l’on peut regrouper en quelques catégories en fonction de la stratégie d’attaque.

Les attaquants dont les exploits consistent à manipuler le comportement des agents s’appuient sur l’injection de commandes, l’empoisonnement d’outils et les attaques de type « confused deputy ». Ceux qui obtiennent un accès non autorisé optent généralement pour le transfert de jetons, le détournement de session et l’octroi de permissions excessives. Quant aux attaquants qui exploitent directement le serveur, ils recourent à l’injection de commandes et à la falsification de requêtes côté serveur (SSRF).

Une injection de prompt ressemble souvent, à première vue, à une saisie humaine normale. De même, une attaque de type « confused deputy » suit un flux OAuth légitime, mais saute ensuite l’étape de consentement. Et même dans le cas d’un « tool poisoning », le nom de l’outil reste le même, de sorte que l’agent continue de l’appeler comme si de rien n’était. Pour un outil de sécurité traditionnel, cela signifie qu’il n’y a aucune requête mal formée à bloquer ni aucun code d’état anormal à signaler. C’est précisément pour cette raison que l’attaque réussit.

Comment prévenir et atténuer les risques de sécurité liés au MCP

Pour prévenir et atténuer les vulnérabilités, les déploiements MCP en production nécessitent une couche d’orchestration qui contrôle les appels aux outils, isole les identifiants et consigne chaque exécution. Suivre les bonnes pratiques de sécurité MCP implique de mettre en place cette couche avant que les agents n’atteignent l’environnement de production.

Injection d’invite et de commande

Les attaquants mènent des attaques par injection d’invite en dissimulant des instructions malveillantes au sein du contenu que le LLM est déjà en train de lire. Il peut s’agir d’un document, d’une réponse API ou de la sortie d’un outil. Le modèle est généralement incapable de faire la différence entre une instruction réelle et une instruction implantée ; il suit donc les deux.

Solution : Considérer tout contenu externe comme non fiable avant qu’il n’atteigne le modèle. Ajouter des garde-fous pour vérifier l’intention de l’invite, encapsuler les entrées utilisateur dans des balises XML prédéfinies (par exemple <unsafe></unsafe>) afin de les séparer clairement du contenu légitime, et indiquer au LLM où se trouvent les requêtes potentiellement malveillantes.

Empoisonnement des outils et intégrité de la chaîne d’approvisionnement

Dans le cadre de l’empoisonnement des outils, les attaquants modifient le fonctionnement d’un outil tout en conservant son nom. L’agent continue d’appeler cet outil malveillant car il est amené à croire qu’il le reconnaît. Cela s’apparente davantage à une attaque de la chaîne d’approvisionnement visant le contexte de l’agent qu’à un « jailbreak » classique effectué par un utilisateur.

Solution : l’enregistrement dynamique constitue la voie la plus risquée, car un attaquant peut l’utiliser pour remplacer un serveur approuvé. Vérifiez les définitions des outils avant leur chargement en les signant, en verrouillant les versions des serveurs et en revoyant vos paramètres de configuration pour l’enregistrement dynamique.

Délimitation des capacités et exposition des outils selon le principe du moindre privilège

La vulnérabilité de sécurité la plus courante liée au protocole de contexte de modèle réside dans les jetons sur-alloués. Même sans plan sophistiqué derrière, cette approche peut causer d’importants dommages, comme le vol d’informations sensibles.

Solution : commencez par un accès en lecture seule et limitez les identifiants strictement à ce dont chacun a réellement besoin.

Comment appliquer l’authentification et limiter la portée des jetons

Lorsqu’il est mal configuré, le MCP a tendance à présenter des failles et à laisser entrer les attaquants. La plupart des problèmes proviennent de trois sources principales liées aux exigences d’authentification. Celles-ci sont à leur tour liées à des schémas d’attaque spécifiques que les outils de sécurité, ainsi que les équipes informatiques qui les utilisent, doivent apprendre à identifier.

Voici comment atténuer les risques liés à l’authentification dans le cadre du MCP.

OAuth 2.1 et sécurité du transport

OAuth 2.1 offre aux serveurs MCP un moyen standard de vérifier l’identité de l’appelant d’un outil avant son exécution. Il accepte les jetons émis par un serveur d’autorisation et vérifie que chacun d’entre eux est valide, n’a pas expiré et a été émis spécifiquement pour ce terminal.

Solution : toutes les URL liées à OAuth doivent utiliser le protocole HTTPS en production, car les connexions HTTP non sécurisées exposent les jetons en transit.

Problème du « confused deputy »

Le problème du « confused deputy » survient lorsqu’un proxy MCP partage le même identifiant de client qu’un serveur d’autorisation tiers. Un attaquant peut alors inciter un utilisateur à cliquer sur un lien malveillant qui exploite des sessions de consentement précédemment enregistrées. Cela permet de contourner l’écran de consentement et d’envoyer un code d’autorisation à l’attaquant.

Solution : la spécification MCP doit exiger que le serveur proxy tienne à jour un registre des consentements par client. Il doit valider les identifiants de ressources uniformes (URI) de redirection par correspondance exacte de chaînes de caractères avant de les transmettre au serveur d’autorisation tiers, et rejeter la requête si l’URI de redirection change.

Transfert de jeton

Le transfert de jeton présente un risque similaire à celui de la stratégie du « confused deputy ». Si un serveur accepte des jetons qui ne lui ont pas été directement délivrés, il ne peut pas confirmer avec précision l’identité de l’auteur de la requête ni suivre les actions qu’il effectue. Cela complique la surveillance, l’audit et la conformité.

Solution : les serveurs MCP ne doivent accepter que les jetons qui leur sont spécifiquement destinés et rejeter tous les autres.

Réduction de la portée

Lorsque l’on accorde trop de pouvoirs à une clé numérique, les abus et le vol peuvent causer des dommages considérables. L’octroi d’un accès trop large aggrave les vulnérabilités, engendre une confusion supplémentaire et rend plus difficile le suivi des actions de chacun.

Solution : ne jamais accorder un accès complet dès le départ. N’accorder davantage d’accès que lorsqu’une tâche spécifique l’exige.