Sécuriser MCP en entreprise : risques et bonnes pratiques pour les DSI

MCP (Model Context Protocol) permet à un agent IA d'utiliser les outils et les données de l'entreprise : messagerie, fichiers, logiciels métier. Chaque serveur MCP autorisé est une nouvelle porte d'entrée vers le système d'information. Il se sécurise comme un logiciel tiers : une liste des serveurs autorisés, des droits minimaux, une identité par agent et une trace de chaque appel.

MCP (Model Context Protocol) : définition en deux minutes

MCP est un protocole ouvert qui standardise la façon dont un assistant ou un agent IA se connecte à des outils et à des sources de données. D'un côté, le client MCP : l'assistant, l'agent ou l'outil de développement. De l'autre, les serveurs MCP, qui exposent chacun des outils : lire un agenda, chercher dans une base documentaire, créer un ticket, interroger un CRM.

Avant MCP, chaque connexion entre un modèle et un outil demandait un développement spécifique. Avec MCP, un même serveur peut servir plusieurs assistants. C'est ce qui explique son adoption rapide, et c'est aussi ce qui en fait un sujet de sécurité : brancher un serveur MCP, c'est donner à un agent la capacité d'agir.

Un serveur MCP peut tourner à distance, accessible par le réseau, ou en local, directement sur le poste de l'utilisateur. Pour les serveurs distants, la spécification prévoit une autorisation fondée sur OAuth 2.1, qui reste facultative.

Pourquoi MCP ouvre une nouvelle surface d'attaque

Un agent connecté par MCP réunit ce qui, pris séparément, est déjà sensible : il lit des contenus qu'il ne maîtrise pas (e-mails, documents, pages web), il a accès aux données de l'entreprise et il peut agir. Une consigne malveillante glissée dans un document peut donc se transformer en action réelle : envoyer un fichier, modifier un enregistrement. L'OWASP classe l'injection de consignes en tête des risques des applications à base de modèles de langage, et l'autonomie excessive (des droits et des fonctions trop larges laissés à l'agent) en sixième position, dans son classement 2025.

S'y ajoute un risque de chaîne d'approvisionnement : beaucoup de serveurs MCP sont publiés en open source et s'installent en une ligne de commande, parfois directement sur les postes, sans passer par l'équipe informatique.

Les principaux risques

Des serveurs MCP non vérifiés

Un serveur local est un programme qui s'exécute sur le poste avec les droits de l'utilisateur. La spécification MCP décrit les scénarios à craindre : une commande de démarrage piégée dans une configuration, un serveur qui contient lui-même du code malveillant, ou un serveur local laissé ouvert et joignable par d'autres programmes. Conséquences possibles : exécution de commandes, vol de fichiers (clés de connexion comprises), perte de données.

Des droits trop larges

Un jeton qui donne accès à tous les fichiers ou à toute une base de données transforme le moindre vol de jeton en fuite massive. La spécification recommande de commencer avec un jeu de droits minimal, en lecture, d'élever les droits au cas par cas quand une opération sensible l'exige, et de proscrire les droits « tout accès ».

L'injection de consignes

L'agent fait confiance aux descriptions des outils et aux contenus qu'il lit. Une description trompeuse ou un document piégé peut l'amener à appeler un outil qu'il n'aurait pas dû appeler, ou à transmettre des données à l'extérieur.

Le « député confus » et les jetons transmis sans contrôle

Certains serveurs MCP servent d'intermédiaires vers une application tierce. Mal conçus, ils peuvent permettre à un client malveillant d'obtenir un accès au nom d'un utilisateur sans son consentement : c'est le problème du « député confus » décrit par la spécification. Autre pratique à proscrire : un serveur qui accepte un jeton qui ne lui était pas destiné et le transmet tel quel à une autre application. La spécification l'interdit : un serveur MCP ne doit accepter que des jetons émis pour lui.

L'absence de traces

Si un serveur relaie des jetons sans les vérifier, ou si personne ne journalise les appels d'outils, il devient impossible de savoir qui a fait quoi en cas d'incident. La spécification souligne que ces pratiques compliquent l'enquête et l'audit.

Les bonnes pratiques

Tenir une liste des serveurs MCP autorisés

Comme pour les extensions de navigateur ou les applications tierces : une liste des serveurs approuvés, avec leur éditeur, leur version, leurs droits et leur responsable. Tout le reste est bloqué. Pour un serveur public, vérifiez sa provenance et lisez la commande exacte qu'il exécutera avant de l'autoriser ; la spécification impose d'ailleurs aux clients MCP d'afficher cette commande en entier et de demander une approbation explicite.

Donner le minimum de droits, et les étendre au besoin

Lecture seule par défaut, droits d'écriture demandés au moment où une opération le nécessite, accès limités dans le temps.

Donner une identité à chaque agent

Un agent ne doit pas emprunter le compte d'un collaborateur ni un compte de service partagé. Dans un environnement Microsoft, Entra Agent ID donne à chaque agent sa propre identité, ses droits et un responsable humain : voir notre guide sur l'identité des agents IA avec Microsoft Entra Agent ID. Côté serveur, chaque jeton doit être émis pour ce serveur précis, ce que la spécification impose.

Isoler les serveurs locaux

Exécutez les serveurs locaux dans un environnement isolé (conteneur, bac à sable), avec un accès restreint au disque et au réseau. Préférez une communication locale directe avec le client ou une connexion protégée par jeton, plutôt qu'un port ouvert sur le poste.

Garder une validation humaine pour les actions sensibles

Paiement, suppression, envoi de données à l'extérieur, modification de droits : ces actions passent par une validation humaine. C'est aussi la position de l'ANSSI, qui recommande de ne pas confier à un système d'IA des actions critiques sur le système d'information sans contrôle humain, et de limiter les actions automatiques déclenchées à partir de contenus non maîtrisés.

Journaliser chaque appel d'outil

Quel agent, quel serveur, quel outil, quels paramètres, pour quel utilisateur, avec quel résultat. L'ANSSI recommande de journaliser l'ensemble des traitements réalisés au sein du système d'IA. Ces traces servent ensuite à superviser les agents en production.

Risque, mesure, qui s'en charge

Un serveur MCP se traite comme n'importe quel logiciel tiers qui reçoit des accès. On l'inventorie, on limite ses droits et on garde les traces.

MCP, RGPD et gouvernance

Un serveur MCP qui donne à un agent l'accès à des données personnelles (clients, salariés) crée ou modifie un traitement : il doit apparaître dans le registre des traitements, avec sa finalité et les données concernées. Si le serveur est fourni par un tiers qui traite ces données pour vous, ce tiers est un sous-traitant au sens du RGPD : il faut un contrat qui encadre le traitement et savoir où les données sont hébergées.

La gouvernance répond à une question simple : qui décide qu'un serveur MCP peut être utilisé, et qui en répond ? Nous détaillons ce cadre dans notre article sur la gouvernance des agents IA.

Qui peut vous accompagner

Sécuriser MCP fait partie d'un chantier plus large : concevoir, sécuriser et faire fonctionner l'infrastructure sur laquelle tournent les agents. C'est le rôle d'un opérateur d'infrastructure agentique. IT Systèmes, partenaire Microsoft depuis 2010, accompagne les PME et les ETI sur ce sujet : voir notre offre d'opérateur d'infrastructure IA agentique. Pour la conception de l'ensemble, voir comment assembler l'infrastructure d'un agent IA et comment sécuriser un projet d'agent IA en entreprise. Avant d'ouvrir un serveur MCP sur le réseau, un test d'intrusion permet de vérifier ses protections.

Frequently asked questions

C'est quoi un MCP ?

MCP (Model Context Protocol) est un protocole ouvert qui permet à un assistant ou à un agent IA de se connecter à des outils et à des sources de données : messagerie, fichiers, logiciels métier. Un serveur MCP expose des outils, un client MCP (l'agent) les utilise.

Comment fonctionne l'authentification MCP ?

Pour les serveurs accessibles par le réseau, la spécification s'appuie sur OAuth 2.1 : le client obtient auprès d'un serveur d'autorisation un jeton émis pour ce serveur MCP précis, et le serveur vérifie qu'il en est bien le destinataire. L'autorisation reste facultative dans la spécification ; pour les serveurs locaux, les identifiants viennent de l'environnement.

MCP est-il sécurisé ?

La spécification décrit des mesures de sécurité, mais leur mise en œuvre dépend de chaque serveur et de chaque client. Un serveur mal conçu ou installé sans contrôle reste un risque : la sécurité vient des règles posées par l'entreprise.

Faut-il autoriser les serveurs MCP publics dans l'entreprise ?

Pas sans contrôle. Un serveur public peut être utile, mais il s'exécute avec des droits réels : vérifiez sa provenance, lisez la commande qu'il exécute, isolez-le et ajoutez-le à la liste des serveurs autorisés avant tout usage.

Qui est responsable d'un serveur MCP en entreprise ?

Chaque serveur autorisé doit avoir un responsable nommé, qui répond de ses droits, de ses mises à jour et de ses journaux. L'équipe informatique tient la liste des serveurs ; le métier qui utilise l'agent valide les accès.