Serveurs MCP : guide de sécurité essentiel pour les RSSI

Vos développeurs installent des serveurs MCP en quelques minutes, avec un simple copier-coller. Votre équipe sécurité n’en a probablement aucun inventaire. C’est un problème urgent.

Ce qu’est un serveur MCP — et pourquoi c’est différent de tout ce que vous connaissez

MCP (Model Context Protocol) est le USB-C des agents IA. C’est un standard qui permet aux modèles de langage — Claude, GPT, Gemini, ou n’importe quel modèle hébergé dans votre datacenter — de se connecter à des outils et des sources de données sans avoir à coder une intégration spécifique pour chacun.

Les cibles les plus courantes : dépôts de code (GitHub, GitLab), bases de données (Postgres, MySQL, Snowflake), fournisseurs cloud (AWS, Azure, GCP), outils de ticketing (Jira, Linear), plateformes d’observabilité (Grafana, Datadog), systèmes de paiement (Stripe) et systèmes de fichiers internes. Un seul serveur MCP peut interconnecter plusieurs de ces systèmes simultanément.

Ce qui le différencie fondamentalement de tout éditeur SaaS évalué jusqu’ici : un serveur MCP est une surface d’action, pas une source de données passive. Quand un développeur en installe un, il donne au modèle de langage une main directe dans un système — une main qui peut lire, écrire, appeler des APIs et enchaîner des actions sans nécessairement demander confirmation à chaque étape.

Trois propriétés rendent cette situation particulièrement risquée :

• Accès système direct. Les serveurs MCP s’exécutent avec l’identité et les credentials de l’utilisateur qui les a lancés — souvent un développeur disposant d’accès larges à la production. Pas d’intermédiaire, pas de rate-limiting, pas d’approbation humaine par défaut.
• Définitions d’outils dynamiques. Les capacités peuvent évoluer après l’installation. Un outil inoffensif le jour 1 peut silencieusement ajouter une fonction envoyer_email le jour 7. Vos revues trimestrielles de fournisseurs ne détecteront pas cette dérive.
• Exécution médiée par le LLM. Le modèle décide quand et comment invoquer chaque outil selon des instructions en langage naturel — qui peuvent provenir de documents non fiables. Les descriptions d’outils sont visibles par le modèle mais invisibles pour l’utilisateur final, ce qui en fait un emplacement idéal pour les attaques par injection de prompts.

Trois risques à présenter au conseil d’administration

Exfiltration de données. Un agent IA peut recevoir des instructions — via un document lu, un ticket traité, un dépôt indexé — pour copier silencieusement des données là où elles ne devraient pas aller. En mai 2025, Invariant Labs a documenté une attaque par injection sur le serveur MCP GitHub : du contenu malveillant dans une issue publique a convaincu un agent de divulguer le contenu de dépôts privés (données salariales comprises) dans un nouveau pull request public. Impact : élevé. Détection : difficile.

Substitution dans la chaîne d’approvisionnement. Vous avez approuvé un outil lundi. Vendredi, il change silencieusement de comportement — sans que personne dans votre équipe ne soit averti. Les chercheurs de Knostic ont trouvé 1 862 serveurs MCP exposés sur l’internet public sans aucune authentification fin 2025. Astrix Security signale que 43 % des serveurs MCP open source contiennent des vulnérabilités d’injection de commandes. CVE-2025-6514 à lui seul a touché plus de 437 000 environnements de développement.

Exposition réglementaire. DORA, NIS2 et l’AI Act européen exigent tous de démontrer un contrôle sur les outils tiers connectés aux processus métier critiques. Un serveur MCP non géré est, par définition, un tiers ICT non géré — une anomalie qu’aucun auditeur ne manquera. Le rapport IBM 2025 sur le coût des violations de données chiffre la prime liée à l’« IA fantôme » à 670 000 dollars supplémentaires. Seulement 17 % des organisations surveillent actuellement les interactions entre agents.

Le schéma commun aux trois cas : l’attaquant n’a pas besoin de franchir votre périmètre. Les instructions malveillantes arrivent comme du contenu ordinaire par des canaux légitimes et sont exécutées par des outils que votre organisation a délibérément installés. Le rayon d’impact est entièrement défini par les privilèges que vous avez accordés.

Ce qu’il faut demander avant d’approuver un serveur MCP

Votre programme de gestion des risques tiers suppose un éditeur SaaS, un contrat et un cycle de révision trimestriel. MCP remet en cause ces trois postulats. Voici ce qui compte vraiment :

Provenance et chaîne d’approvisionnement

• Qui maintient ce serveur, et chaque version est-elle associée à un hash cryptographique ?
• A-t-il fait l’objet d’une analyse indépendante — SAST, analyse de contamination, scan de la chaîne logistique ?
• Quelle est la politique de divulgation des vulnérabilités et le SLA de correctifs ?

Accès et permissions

• À quels systèmes peut-il accéder ? Listez-les. « Dépend de la configuration » n’est pas une réponse acceptable.
• Nécessite-t-il des credentials persistants, ou peut-il utiliser des tokens à courte durée de vie et à portée limitée ?
• L’accès peut-il être restreint par utilisateur ou par session ?

Comportement à l’exécution

• Les définitions d’outils peuvent-elles changer après l’installation ? Si oui, y a-t-il une détection automatique de dérive ?
• Effectue-t-il des appels réseau sortants, et vers quels endpoints spécifiques ?
• Peut-il déclencher des actions d’écriture ou destructrices sans confirmation explicite de l’utilisateur ?

Gouvernance et conformité

• Génère-t-il des journaux d’audit structurés adaptés aux reportings DORA ?
• La résidence des données est-elle documentée pour les flux de données UE ?
• Y a-t-il un contact sécurité nommé avec un security.txt public ?

Un serveur incapable de répondre à tout cela ne devrait pas être approuvé pour un système traitant des données réglementées, des credentials de production ou des communications clients. Et cette liste ne périme pas — répétez-la à chaque mise à jour majeure de version.

Un programme de 90 jours pour passer de zéro à défendable

Seulement 38 % des organisations surveillent actuellement le trafic IA de bout en bout. Voici un programme concret pour reprendre le contrôle.

Jours 1-30 — Découverte. Émettez une politique écrite : aucun nouveau serveur MCP connecté en production pendant cette phase. Inventoriez les outils de développement (Cursor, Claude Desktop, VS Code Copilot, Cline, agents personnalisés). Ajoutez les serveurs MCP à votre CMDB comme nouvelle classe d’actifs, liés à l’utilisateur installateur et au processus métier. Croisez avec les logs de trafic sortant pour identifier les serveurs non déclarés. Livrable : inventaire validé avec propriétaire, éditeur, version et étiquette de classification des données par entrée.

Jours 31-60 — Analyse. Exécutez un pipeline de certification sur chaque serveur : SAST, analyse de contamination, supply chain, scan de secrets. Scorez chacun. Classifiez par rayon d’impact — Niveau 1 (production + données réglementées), Niveau 2 (production), Niveau 3 (sandbox uniquement). Livrable : catalogue scoré avec plan de remédiation pour tout ce qui est en-dessous d’une certification de sécurité de base.

Jours 61-90 — Application. Déployez une couche d’exécution validant les hashs cryptographiques et le niveau de certification avant qu’un outil ne soit exposé à un modèle. Connectez les événements d’exécution à votre SIEM pour les reportings d’incidents conformes DORA. Définissez des seuils d’alerte pour les nouveaux endpoints, les nouvelles définitions d’outils et les anomalies de volume de données sortantes. Livrable : document de politique + enforcement runtime + rapport 90 jours pour le conseil démontrant la couverture des contrôles.

Ce qu’il faut retenir

Le centre de gravité du risque MCP n’est pas la sécurité réseau — c’est le principe de moindre privilège, la traçabilité de la provenance et l’attestation à l’exécution. Une organisation qui maîtrise ces trois dimensions peut gérer le reste. Celle qui en néglige une aura bien du mal à expliquer à un régulateur pourquoi elle ne savait pas ce que faisaient ses agents IA.