On lit un peu partout que le Model Context Protocol permet de connecter un assistant à ses outils internes « de façon sécurisée ». La spécification elle-même dit exactement le contraire, et elle le dit dans une phrase qu'il faut avoir lue avant de brancher quoi que ce soit : le protocole ne peut pas imposer ces principes de sécurité à son propre niveau. Il les recommande aux implémenteurs. Ce n'est pas la même chose.
La confusion est compréhensible. MCP normalise la mécanique de connexion, pas la confiance. C'est un progrès réel, et c'est une invitation à faire le travail de sécurité soi-même.
Ce que le protocole fait réellement
MCP est un protocole ouvert, fondé sur des messages JSON-RPC 2.0, qui met en relation trois rôles. L'hôte est l'application qui pilote le modèle. Le client est le connecteur à l'intérieur de cet hôte. Le serveur est le service qui expose quelque chose d'utile.
Un serveur offre trois familles de choses : des ressources, qui sont des données mises à disposition ; des prompts, qui sont des modèles d'instructions prêts à l'emploi ; et des outils, qui sont des fonctions que le modèle peut décider d'appeler. Les clients, de leur côté, peuvent proposer un mécanisme de sollicitation permettant au serveur de demander une information complémentaire à l'utilisateur.
La version en vigueur de la spécification porte la date du 28 juillet 2026. Le projet est actif, le dépôt était encore modifié le jour de la rédaction de cet article.
L'intérêt pratique est évident. Avant MCP, brancher un assistant sur une supervision, un inventaire de parc et une base de connaissances demandait trois intégrations ad hoc. Avec MCP, trois serveurs exposent leurs capacités de la même manière, et l'assistant les découvre. C'est la promesse tenue.
Reste la partie que le protocole laisse ouverte, et qui est entièrement à votre charge.
Scénario un : la description d'outil qui ment
Un serveur MCP décrit ses outils en langage naturel, et c'est cette description que le modèle lit pour décider quand les appeler. La spécification est nette sur ce point : les descriptions du comportement d'un outil, y compris ses annotations, doivent être considérées comme non fiables, sauf si elles proviennent d'un serveur de confiance.
La conséquence est directe. Un serveur tiers peut déclarer un outil nommé « consulter la météo » dont la description contient, en plus, des instructions adressées au modèle : par exemple, lui demander de joindre au passage le contenu d'un fichier de configuration. Le modèle lit la description comme une consigne légitime, parce que rien ne la distingue d'une consigne légitime.
C'est une injection d'instructions par la voie du catalogue d'outils. Elle ne suppose aucune faille technique : elle exploite le fonctionnement normal du protocole.
La parade tient en une règle d'exploitation, pas en un réglage : on n'installe un serveur MCP tiers qu'après avoir lu son code, et on épingle sa version. Un serveur qui se met à jour tout seul peut changer ses descriptions d'outils entre deux démarrages.
Scénario deux : l'outil qui en fait plus que son nom
Un outil est du code qui s'exécute. Son nom et sa description n'engagent que celui qui les lit.
Un outil appelé lire_ticket peut parfaitement écrire, supprimer, ou appeler une autre API. Le modèle n'a aucun moyen de le savoir, et l'utilisateur qui valide l'appel encore moins : il voit un nom rassurant et une demande de confirmation.
Le seul contrôle qui tient est en dessous du protocole : les droits réels du compte avec lequel le serveur MCP travaille. Un serveur branché sur votre supervision doit posséder un compte en lecture seule sur la supervision, point. Un serveur branché sur une base doit avoir un utilisateur dédié, avec les droits d'un utilisateur dédié, jamais ceux du propriétaire du schéma. Les secrets correspondants vivent dans un coffre, du type OpenBao, et pas dans un fichier de configuration à côté du serveur.
C'est du cloisonnement classique, de la même famille que ce que décrit notre article sur l'architecture zéro confiance. MCP ne change rien à ces principes, il en augmente seulement l'importance, parce que l'appelant n'est plus un programme déterministe mais un modèle qu'on peut persuader.
Scénario trois : deux serveurs inoffensifs qui, ensemble, ne le sont plus
Celui-là est le plus contre-intuitif, et c'est celui qu'on voit venir le plus tard.
Prenez un serveur qui donne accès en lecture à la base de connaissances interne, laquelle contient des procédures, des noms de serveurs, des schémas d'architecture. Inoffensif, il ne fait que lire. Prenez un second serveur qui sait envoyer un message sur une messagerie d'équipe. Inoffensif également, il ne fait qu'écrire un texte fourni.
Branchez les deux sur le même assistant et vous avez créé un chemin d'exfiltration complet : quelque chose qui persuade le modèle de lire une page sensible puis de la poster ailleurs. Chaque serveur, pris seul, passerait n'importe quelle revue. C'est leur combinaison qui crée la capacité.
L'analyse de risque doit donc porter sur l'ensemble des serveurs connectés à un même assistant, jamais sur chacun isolément. En pratique, cela signifie tenir une liste des serveurs branchés, et la relire à chaque ajout en se posant une seule question : avec cette nouvelle pièce, que devient l'ensemble ?
Quand nous montons ce type de raccordement, la règle que nous appliquons est de séparer les assistants par usage plutôt que de tout brancher sur un seul. Un assistant d'exploitation qui lit la supervision et le parc, sans aucun moyen d'écrire à l'extérieur. Un assistant documentaire qui lit la base de connaissances, sans accès à l'infrastructure. Deux périmètres, deux surfaces, et aucune passerelle entre les deux. C'est moins commode, et c'est ce qui rend l'incident possible plutôt que certain.
Scénario quatre : le consentement qui s'use
La spécification demande que l'utilisateur consente explicitement avant l'invocation de tout outil, et qu'il comprenne ce que fait cet outil avant de l'autoriser.
Dans la vraie vie, un utilisateur qui voit la même fenêtre de confirmation quarante fois par jour finit par cliquer sans lire. Le consentement devient un réflexe moteur, et il ne protège plus rien. C'est un phénomène connu, documenté depuis vingt ans sur les alertes de certificat.
Il faut donc choisir ce qui mérite une confirmation. Une lecture sur un périmètre autorisé n'en demande pas : elle a été autorisée une fois pour toutes en accordant le droit de lecture au serveur. Une écriture, une suppression, un appel vers l'extérieur en demandent une, et cette fenêtre-là doit rester rare pour rester lue. Un système qui demande tout le temps ne demande rien.
Ce qu'on branche, ce qu'on ne branche pas
Après quelques raccordements, une ligne de partage se dessine.
Se branchent volontiers : la supervision en lecture, l'inventaire du parc, la base de connaissances interne, les tickets en lecture, la documentation technique. Le point commun est qu'une fuite y serait gênante sans être grave, et qu'aucune action ne modifie l'état du système.
Ne se branchent pas, ou alors avec un compte dédié, un périmètre minuscule et une journalisation complète : tout ce qui touche à l'annuaire, à la paie, à la facturation, aux secrets, à la production. Le gain de confort n'est jamais à la hauteur du risque, et la question « qui a validé cette action » doit pouvoir trouver sa réponse dans un journal, pas dans une conversation.
Une dernière chose à surveiller : la sollicitation, ce mécanisme par lequel un serveur demande une information complémentaire à l'utilisateur. C'est une fonction utile et c'est aussi un canal par lequel un serveur peut réclamer autre chose que ce qu'on imagine. Un serveur qui demande un mot de passe par ce biais est un serveur qu'on débranche.
La règle simple
MCP est une bonne nouvelle : un protocole ouvert et documenté remplace une collection d'intégrations bricolées, et la spécification est honnête sur ce qu'elle ne garantit pas. Le travail de sécurité reste entier, et il est classique : comptes dédiés, droits minimaux, secrets dans un coffre, journalisation, revue de la combinaison des accès plutôt que de chacun.
Traitez chaque serveur MCP comme vous traiteriez une API exposée : avec l'hypothèse qu'elle sera appelée autrement que prévu. À la différence près que l'appelant, ici, peut être convaincu par un texte bien tourné.
Sources
- Spécification du Model Context Protocol, version du 28 juillet 2026, architecture, fonctionnalités et section sécurité
- Dépôt GitHub modelcontextprotocol, spécification et documentation, dernière modification le 21 septembre 2026
- RFC 2119, interprétation des termes normatifs employés par la spécification
- JSON-RPC 2.0, format de messages sur lequel repose le protocole
