Serveur MCP : ce qu'il faut verrouiller avant de brancher l'IA sur vos outils

Brancher un assistant IA sur ses outils internes via un serveur MCP est devenu simple. C’est précisément ce qui rend le sujet délicat : la facilité de mise en œuvre masque un changement de nature dans ce qu’on accorde à la machine.

Tant qu’un assistant se contente de lire, une erreur produit une réponse fausse — désagréable, rarement grave. Dès qu’il peut agir, la même erreur envoie un message à un client, modifie un enregistrement comptable ou supprime un fichier. On ne parle plus d’un outil, on parle d’un accès au système d’information.

La bonne nouvelle, c’est que les attaques ne sont pas mystérieuses. La spécification du protocole publie une page dédiée aux bonnes pratiques de sécurité qui décrit les vecteurs connus et les contre-mesures exigées. Elle n’est pas indicative : elle emploie des « MUST ». Le problème n’est donc pas de savoir quoi faire, mais de vérifier que ça a été fait.

Le relais de jeton, l’anti-patron le plus courant#

C’est celui qu’on rencontre le plus souvent, parce qu’il paraît pratique. Le serveur MCP reçoit un jeton du client, ne vérifie pas à qui ce jeton était destiné, et le transmet tel quel au service en aval.

La spécification est catégorique : un serveur MCP ne doit accepter aucun jeton qui n’a pas été explicitement émis pour lui. Deux choses cassent quand on l’ignore.

D’abord les contrôles. Un serveur qui n’a pas validé l’audience d’un jeton laisse passer des jetons émis pour d’autres services ; les limites de débit, la validation des requêtes et la surveillance qui s’appuient sur l’identité de l’appelant deviennent contournables.

Ensuite la traçabilité, et c’est le point qui fait mal en cas d’incident. Les journaux du service final montrent une identité qui n’est pas celle de l’appelant réel. Vous savez qu’une action a eu lieu, vous ne savez pas qui l’a déclenchée. Une investigation devient alors un exercice d’archéologie.

Le député confus#

Le nom est ancien, le scénario reste d’actualité. Un serveur MCP qui sert de passerelle vers une API tierce agit comme un client OAuth unique, avec un identifiant client statique. S’il autorise par ailleurs les clients MCP à s’enregistrer dynamiquement, et qu’il ne demande pas de consentement pour chacun d’eux, l’attaque devient possible.

Le déroulé est le suivant. Un utilisateur s’authentifie une première fois, légitimement ; le serveur d’autorisation tiers dépose un cookie de consentement associé à l’identifiant statique. Plus tard, l’utilisateur clique sur un lien piégé contenant une adresse de redirection contrôlée par l’attaquant. Le cookie est toujours là, l’écran de consentement est donc sauté, et le code d’autorisation part chez l’attaquant.

La contre-mesure exigée tient en une phrase : le serveur MCP doit maintenir son propre registre de consentements, par client et par utilisateur, et le vérifier avant de rediriger vers le tiers. S’y ajoutent des exigences précises — validation stricte de l’adresse de redirection par comparaison exacte, sans jokers ; paramètre state aléatoire, stocké côté serveur seulement après approbation, à usage unique et à durée courte.

Ce dernier détail mérite qu’on s’y arrête, parce qu’il s’inverse facilement à l’implémentation : poser le cookie de session avant l’écran de consentement rend cet écran décoratif. L’attaquant le contourne en fabriquant sa propre requête d’autorisation.

La portée des permissions#

C’est l’endroit où les décisions de confort coûtent le plus cher, et c’est aussi le plus facile à corriger.

Un serveur MCP qui publie l’intégralité de ses portées, et un client qui les demande toutes d’emblée, produisent un jeton qui ouvre tout. Le jour où ce jeton fuit — journal trop bavard, poste compromis — le rayon d’action de l’incident est total. Et sa révocation casse tous les usages en même temps, ce qui pousse à repousser la révocation.

Le principe à appliquer est celui du privilège minimal, mais progressif : un socle réduit aux opérations de lecture et de découverte, puis une élévation ciblée au moment où une opération sensible est réellement tentée. Les portées globales du type *, all ou full-access sont à proscrire, de même que le regroupement de privilèges sans rapport « pour éviter d’avoir à redemander plus tard ».

C’est une règle que nous nous appliquons à nous-mêmes, y compris hors MCP. Sur nos propres déploiements, les jetons d’API sont créés sur mesure avec les seules permissions nécessaires — jamais la clé globale du compte, qui a l’avantage de toujours fonctionner et l’inconvénient de tout ouvrir quand elle fuit.

Les serveurs locaux, angle mort fréquent#

Un serveur MCP local est un binaire téléchargé puis exécuté sur le poste de l’utilisateur, avec les privilèges de ce dernier. C’est une catégorie à part, parce que la surface d’attaque n’est plus le réseau mais le poste lui-même.

Trois scénarios sont documentés : une commande de démarrage malveillante glissée dans une configuration, une charge malveillante embarquée dans le serveur lui-même, et l’accès à un serveur local resté à l’écoute sur la boucle locale. Dans les trois cas, le résultat est une exécution de code arbitraire sur le poste.

Les garde-fous attendus sont concrets : afficher la commande exacte avant exécution, sans troncature ; cloisonner l’exécution avec les mécanismes de la plateforme ; restreindre l’accès au système de fichiers et au réseau ; et, côté serveur, privilégier le transport stdio plutôt qu’une écoute HTTP, ou exiger un jeton d’autorisation si l’écoute est nécessaire.

En entreprise, cela se traduit surtout par une décision d’organisation : la liste des serveurs MCP autorisés sur les postes est une décision, pas une préférence individuelle.

Ce que nous mettons en place#

Nos déploiements suivent la même trame, quel que soit le client.

Un périmètre explicite par connecteur. Chaque outil exposé dispose de ses propres identifiants, restreints à ce qu’il doit faire, et révocables indépendamment. C’est ce qui rend la réversibilité réelle : on peut couper un connecteur sans éteindre l’ensemble.

Une journalisation d’audit des appels d’outils. Qui a demandé quoi, quel outil a été invoqué, avec quels arguments, et qu’a-t-il renvoyé. Sans cela, on ne sait pas répondre à la seule question qui compte après un incident.

Des garde-fous à l’exécution. Limite de débit, validation des arguments, et surtout distinction nette entre les opérations qui lisent et celles qui écrivent — les secondes méritent une confirmation explicite plutôt qu’un déclenchement silencieux.

Une origine autorisée et un cloisonnement réseau, pour que le serveur ne puisse atteindre que ce qu’il doit atteindre.

Aucun de ces points n’est spectaculaire, et c’est plutôt bon signe. Un serveur MCP bien fait ne se remarque pas : il expose peu, il trace tout, et il se débranche proprement le jour où l’on veut changer d’assistant.