Aller au contenu

Serveurs MCP : brancher un agent sur vos outils sans lui ouvrir toutes les portes

Un serveur MCP donne à un agent IA l’accès à un outil : messagerie, tickets, code, base de données. Ce qu’il lui donne vraiment, les attaques déjà documentées, et les règles à poser avant de le brancher.

Par Publié le 3 octobre 2026

Un serveur MCP est un programme qui donne à un agent IA l’accès à un outil : votre messagerie, vos tickets, un dépôt de code, une base de données. MCP (Model Context Protocol) est le standard ouvert qui fixe la façon dont les applications d’IA et ces serveurs se parlent ; on le compare souvent à une prise USB-C pour l’IA. Brancher un serveur est simple, et c’est précisément pour cela qu’il faut décider avant ce que l’agent pourra faire.

D’où vient MCP et qui le maintient ?

Anthropic a publié MCP en code ouvert le 25 novembre 2024. Le 9 décembre 2025, il l’a confié à l’Agentic AI Foundation, une fondation rattachée à la Linux Foundation et cofondée avec Block et OpenAI. Anthropic recensait alors plus de 10 000 serveurs MCP publics actifs. Un registre officiel des serveurs est ouvert en préversion depuis septembre 2025, et la version de la spécification en vigueur date du 28 juillet 2026.

Ce qu’un serveur MCP donne vraiment à l’agent

Un serveur expose trois types d’éléments : des outils, c’est-à-dire des actions que l’agent peut déclencher (envoyer un message, créer un ticket, modifier un fichier) ; des ressources, des données qu’il peut lire ; et des modèles de consignes. Ce sont les outils qui portent le risque : chacun est une action réelle, exécutée avec les droits du jeton que le serveur détient.

Un serveur local tourne sur le poste de l’utilisateur, avec ses droits et souvent ses identifiants. Un serveur distant est partagé et appelé par le web ; la spécification recommande alors OAuth pour l’authentification.

Les risques déjà documentés

  • Des instructions cachées dans les outils. En avril 2025, Invariant Labs a décrit le « tool poisoning » : des consignes malveillantes glissées dans la description d’un outil, invisibles pour l’utilisateur mais lues par le modèle.
  • Des contenus piégés. En mai 2025, la même équipe a montré qu’un ticket malveillant dans un dépôt public pouvait conduire un agent connecté par MCP à divulguer des données de dépôts privés : c’est une injection de prompt indirecte.
  • De faux serveurs. En septembre 2025, un paquet npm qui se faisait passer pour le serveur MCP du service d’envoi de courriels Postmark copiait en secret les messages vers une adresse extérieure. Postmark a confirmé n’y avoir jamais été associé.
  • Des failles dans les serveurs eux-mêmes. En 2025, des vulnérabilités critiques ont été publiées pour des composants très utilisés, dont l’outil mcp-remote et le serveur de fichiers officiel.
  • Des accès trop larges. Une étude d’Astrix Security (octobre 2025) sur plus de 5 200 serveurs en code ouvert relève que 53 % reposent sur des clés d’API statiques ou des jetons personnels, et à peine 8,5 % sur OAuth.

L’OWASP a classé ces risques : sa liste de décembre 2025 pour les applications agentiques compte l’usage abusif des outils et les vulnérabilités de la chaîne d’approvisionnement, et un projet de liste dédiée à MCP, encore en version bêta, cite les serveurs installés sans validation (« shadow MCP »).

Les règles à poser

  • Une liste de serveurs autorisés : installés depuis la source officielle de l’éditeur, en version figée, comme toute dépendance logicielle ; tout le reste est bloqué.
  • Des droits au strict nécessaire : un jeton propre à chaque serveur, limité à ce qu’il doit faire, jamais le jeton personnel d’un administrateur. La spécification interdit d’ailleurs à un serveur d’accepter un jeton qui n’a pas été émis pour lui.
  • Une personne dans la boucle : la spécification demande que l’utilisateur puisse toujours refuser l’appel d’un outil. Lire peut rester automatique ; envoyer, modifier ou supprimer attend une validation.
  • Des descriptions d’outils traitées comme non fiables : c’est ce que demande la spécification pour tout serveur qui n’est pas de confiance. On les relit à l’ajout et à chaque mise à jour.
  • Un journal de chaque appel : quel agent, quel outil, quels paramètres, quel résultat.
  • L’isolation des serveurs locaux : dans un conteneur ou un bac à sable, sans accès au reste du poste.

Serveur local ou distant : ce qui change

Le serveur local est simple à essayer, mais il hérite des droits du poste et de ses secrets : une faille ou un faux serveur compromet la machine. Le serveur distant demande plus de mise en place, mais se gouverne mieux : une authentification centrale, des droits gérés au même endroit, un journal unique. Pour une équipe, on privilégie des serveurs distants, publiés dans un catalogue interne validé.

Construire vos propres serveurs MCP

Pour vos outils internes, un serveur maison expose exactement ce que l’agent doit pouvoir faire, et rien d’autre :

  • des outils de lecture d’abord, les actions d’écriture ensuite ;
  • des outils séparés pour lire et pour agir, avec des droits distincts ;
  • des paramètres vérifiés par le serveur, pas uniquement par le modèle ;
  • une authentification OAuth, un journal, et des tests avec des contenus piégés.

C’est ce qu’on met en place dans une plateforme agentique, avec les garde-fous de notre offre Des agents IA sous contrôle. Voir aussi nos articles sur la sécurité des agents IA et sur le déploiement des agents de code, et la page L’IA agentique sous votre contrôle.

Questions fréquentes

MCP, c’est quoi ?

Un standard ouvert qui permet de connecter une application d’IA, comme un agent, à des systèmes extérieurs (outils, données, services) d’une façon commune à tous les éditeurs.

Un serveur MCP est-il sûr ?

Ni plus ni moins que son code, sa provenance et les droits qu’on lui donne. Un serveur officiel, en version figée, avec un jeton limité et une validation humaine des actions sensibles, présente un risque maîtrisé ; un paquet trouvé au hasard avec un jeton d’administrateur, non.

Qui maintient le protocole aujourd’hui ?

Depuis décembre 2025, l’Agentic AI Foundation, rattachée à la Linux Foundation, avec les mêmes règles de gouvernance qu’avant le transfert.

Faut-il un serveur MCP par outil ?

En général, un serveur par service connecté. Moins il y a de serveurs, plus la surface d’attaque est réduite : on n’ajoute un serveur que pour un usage précis.

Sources

Faits et chiffres vérifiés le 3 octobre 2026.