Sécurité MCP : risques réels et règles à appliquer en entreprise

Connecter une IA à vos outils par MCP crée quatre risques concrets : un contenu piégé qui détourne l'IA (injection de consignes), une IA qui dispose de plus de droits qu'il ne faut, un serveur malveillant ou compromis, et des jetons d'accès mal protégés. La parade tient en quelques règles : serveurs de confiance uniquement, droits minimaux, validation humaine avant toute action qui modifie quelque chose, secrets hors du code, journal des appels. La spécification MCP le dit elle-même : le protocole ne peut pas imposer ces protections, c'est aux applications et aux équipes de les mettre en place¹.

Quels sont les vrais risques ?

Un contenu piégé qui donne des ordres à l'IA

L'injection de consignes (« prompt injection ») est le premier risque du classement OWASP 2025 des applications à base de modèles de langage². Avec MCP, elle est souvent indirecte : l'IA lit un e-mail, une fiche CRM, un commentaire ou une page web qui contient des instructions cachées, puis les suit avec les outils dont elle dispose. OpenAI souligne que ce risque est particulièrement élevé quand le modèle a accès à des serveurs MCP capables de lire des données sensibles ou d'agir³.

Une IA qui a trop de pouvoir

OWASP appelle ce risque « agentivité excessive » : trop d'outils, trop de droits, trop d'autonomie². Un serveur WordPress branché avec un compte administrateur peut supprimer des pages ; un serveur CRM en écriture peut modifier des milliers de fiches. L'erreur n'a pas besoin d'être malveillante : une consigne mal comprise suffit.

Un serveur malveillant ou compromis

Un serveur local s'exécute avec les droits de votre compte : une commande de lancement piégée dans une configuration peut exfiltrer des fichiers ou détruire des données⁴. Côté distant, un serveur malveillant peut exfiltrer tout ce qui entre dans le contexte du modèle³. La spécification demande aussi de considérer comme non fiables les descriptions d'outils qui ne viennent pas d'un serveur de confiance¹. Les dépendances (paquets npm ou pip) font partie de cette chaîne d'approvisionnement.

Des jetons trop larges ou mal gérés

Un jeton d'accès doté de droits étendus, s'il fuit, ouvre tout ce qu'il couvre. Les bonnes pratiques officielles interdisent aussi le « token passthrough » : un serveur MCP ne doit accepter que des jetons émis pour lui, jamais relayer tel quel un jeton destiné à un autre service⁴.

Quelles règles appliquer avant la mise en production ?

1. N'installer que des serveurs de confiance, de préférence publiés par l'éditeur du service ; lire la commande exacte avant d'ajouter un serveur local³⁴.
2. Droits minimaux : un jeton ou un compte dédié par serveur, en lecture seule si l'usage est du reporting, avec des permissions (scopes) limitées à ce que l'outil fait. Certains serveurs le prévoient, comme l'option --read-only du serveur GitHub⁵.
3. Garder la validation humaine : la spécification exige le consentement explicite de l'utilisateur avant l'exécution d'un outil¹ ; dans l'API d'OpenAI, l'approbation est demandée par défaut et peut être désactivée outil par outil³. Ne la désactivez que pour des outils de lecture. Pour la publication, faites créer des brouillons que quelqu'un valide.
4. Secrets hors du code : variables d'environnement ou gestionnaire de secrets, jamais de clé dans un dépôt Git ou un fichier partagé.
5. Serveur distant : HTTPS, authentification OAuth, contrôle que chaque jeton a bien été émis pour ce serveur⁴. Serveur local : préférer le transport stdio à un port HTTP ouvert sur la machine⁴.
6. Journaliser chaque appel : outil, paramètres, résultat, utilisateur, heure (sans mot de passe ni jeton dans les journaux).
7. Tester sur un environnement de test (site de préproduction, compte CRM de démonstration) avant de brancher la production.

Que dit le RGPD ?

Dès qu'un serveur MCP fait passer des données personnelles (contacts, e-mails, identifiants d'utilisateurs) dans une conversation avec un modèle hébergé, ces données sont traitées par le fournisseur du modèle. Les règles habituelles s'appliquent⁶ :

• une base légale pour le traitement (article 6) et la minimisation des données (article 5) : ne faire lire à l'IA que ce qui est nécessaire ;
• un contrat de sous-traitance avec le fournisseur du modèle et des serveurs distants (article 28) ;
• des garanties si les données quittent l'Espace économique européen (chapitre V) ;
• l'inscription du traitement au registre (article 30) ;
• une analyse d'impact obligatoire, et non simplement recommandée, lorsque le traitement est susceptible d'engendrer un risque élevé pour les personnes (article 35)⁷.

Ce point est de l'information, pas un avis juridique : faites valider le déploiement par votre délégué à la protection des données ou votre conseil.

Pour la mise en place technique, voir notre tutoriel de création de serveur MCP et notre explication du fonctionnement d'un serveur MCP. Notre équipe d'automatisation et d'agents IA peut auditer ou concevoir une intégration MCP avec ces garde-fous.