Sécurité, autorisations et moindre privilège

Bienvenue

Un serveur MCPMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire n'est pas un simple connecteur passif. C'est un programme qui reçoit des instructions d'un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire — instructions elles-mêmes dérivées d'un texte fourni par un utilisateur, un document, une page web — et qui les traduit en actions réelles : lire un fichier, exécuter une requête SQL, appeler une API, écrire sur un disque. Dès que cette chaîne existe, la question n'est plus « est-ce que ça marche ? » mais « qu'est-ce que ce serveur peut faire de pire, et qui décide qu'il le fasse ? ».

Ce chapitre traite la sécurité des déploiements MCP comme un sujet d'ingénierie à part entière, pas comme une case à cocher après coup. Vous verrez la surface d'attaque réelle des serveurs MCP, les techniques de confinement qui la réduisent, et les pratiques de revue qui permettent de faire confiance — ou non — à un serveur tiers.

Un serveur MCP hérite silencieusement des permissions du processus qui l'exécute. Si ce processus tourne avec votre compte utilisateur complet, le serveur a accès à tout ce que vous avez le droit de faire — pas seulement à ce que son outil est censé faire.

La surface d'attaque réelle

Contrairement à une API REST classique où le client compose des requêtes explicites, un serveur MCP est piloté par un modèle qui génère lui-même les paramètres d'appel à partir d'un contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire en langage naturel. Ce contexte peut contenir du texte non maîtrisé : un ticket support rédigé par un client, le contenu d'une page web, un fichier importé. C'est ce déplacement — de « l'utilisateur choisit l'action » à « le modèle choisit l'action à partir d'un texte » — qui ouvre la plupart des vecteurs suivants.

Abus d'outil (tool abuse)

Un outil exposé sans contrainte de paramètres fait ce qu'on lui demande, y compris ce qu'on ne voulait pas qu'il fasse. Un outil run_query(sql) qui accepte n'importe quelle chaîne SQL n'est pas un outil de lecture de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire : c'est un accès administrateur à la base, déguisé. Si une instruction malveillante s'immisce dans le contexte du modèle — par exemple via un document que l'agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire doit résumer et qui contient une injection de promptInjection de promptCybersécuritéAttaque visant à détourner un LLM en insérant des instructions malveillantes dans le contexte (entrée utilisateur, document RAG, etc.).Voir dans le glossaire — le modèle peut être amené à appeler cet outil avec une requête DROP TABLE ou une extraction massive de données.

Path traversal

Un outil de type read_file(path) ou write_file(path, content) qui ne valide pas le chemin fourni permet de sortir du répertoire de travail prévu avec des séquences ../../../etc/passwd, ou pire, d'écrire dans des fichiers système ou des scripts de démarrage. C'est une classe de vulnérabilité vieille de plusieurs décennies, mais elle réapparaît systématiquement dans les serveurs MCP écrits rapidement, car le chemin arrive comme un simple argument de chaîne de caractères fourni par le modèle.

SSRF (Server-Side Request Forgery)

Un outil qui accepte une URL — pour aller chercher une page, appeler un webhook, interroger une API — peut être détourné pour faire émettre des requêtes depuis le réseau interne de l'entreprise vers des cibles que l'attaquant ne pourrait pas atteindre directement : métadonnées cloud (169.254.169.254), services internes non authentifiés, portsportRéseauxNuméro sur 16 bits qui désigne l'application destinataire sur une machine. Les ports 0 à 1023 sont réservés aux services système, comme 443 pour HTTPS.Voir dans le glossaire de debug. Le serveur MCP devient un relais involontaire.

Exfiltration de données

C'est le risque composite : un serveur qui a legitimement accès à des données sensibles (CRM, code source, emails) et qui dispose aussi d'un outil de sortie (envoi HTTP, écriture de fichier partagé, publication). Une instruction injectée peut combiner lecture et exfiltration en une seule chaîne d'appels, sans qu'aucune étape individuelle ne semble anormale.

La combinaison d'un outil de lecture large et d'un outil de sortie réseau est presque toujours plus dangereuse que la somme de ses parties. Auditez les chaînes d'appels possibles, pas seulement chaque outil isolément.

Le principe de moindre privilège appliqué à MCP

Le moindre privilège n'est pas une posture abstraite : c'est une série de décisions concrètes à prendre à chaque niveau du système.

Allowlists d'outils et de ressources

Un client MCP ne devrait jamais exposer au modèle l'intégralité des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire d'un serveur par défaut. Une allowlist explicite — la liste des outils réellement nécessaires à la tâche en cours — réduit mécaniquement la surface d'attaque. Si l'agent doit seulement lire des tickets support, il n'a aucune raison d'avoir accès à un outil delete_customer.

Le même principe s'applique aux ressources exposées par un serveur : un serveur de fichiers ne devrait racine que sur le répertoire strictement utile, jamais sur / ou sur le répertoire personnel de l'utilisateur.

Scopes et jetons à portée réduite

Quand un serveur MCP s'authentifie auprès d'une API tierce (CRM, cloud, base de données), le jeton utilisé doit porter les scopes minimaux nécessaires à ses outils déclarés. Un serveur qui expose uniquement des outils de lecture ne devrait jamais détenir un jeton avec droit d'écriture — même si, en pratique, aucun de ses outils actuels ne l'utilise. Un jeton trop large devient dangereux le jour où un bug, une régression ou une injection de promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire contourne la logique applicative.

Confirmation humaine pour les actions destructrices

Toute action qui supprime, modifie irréversiblement ou envoie des données vers l'extérieur devrait passer par un point de confirmation explicite, visible par un humain, avant exécution — pas seulement une trace de log après coup. Beaucoup de clients MCP (IDE, orchestrateurs d'agents) proposent ce mécanisme nativement : l'appel d'outil est affiché avec ses paramètres et attend une validation. Désactiver cette confirmation pour aller plus vite est une décision de sécurité, pas un simple confort — elle doit être prise consciemment, jamais par défaut.

Un serveur MCP connecté à un espace de billetterie expose un outil close_ticket(id, reason). Sans confirmation, un agent chargé de « nettoyer les tickets obsolètes » peut, sur la foi d'une instruction ambiguë glissée dans un ticket, fermer en masse des dizaines de tickets encore actifs. Avec confirmation humaine par lot proposé, l'opérateur voit la liste avant validation et peut interrompre l'opération.

Gestion des secrets

Un serveur MCP a presque toujours besoin d'au moins un secret : clé d'API, jeton OAuth, chaîne de connexion à une base. La façon dont ce secret est stocké et transmis détermine une bonne partie du risque résiduel.

• Jamais dans le code ni dans la configuration versionnée. Un fichier mcp.json commité avec une clé en clair finit tôt ou tard dans un historique git public ou un dépôt partagé trop largement.
• Variables d'environnement injectées au lancement, idéalement via un gestionnaire de secrets (vault, coffre-fort du fournisseur cloud, gestionnaire de secrets système) plutôt que dans un .env versionné.
• Rotation régulière et révocation rapide. Un secret compromis doit pouvoir être invalidé en quelques minutes, ce qui suppose de ne jamais partager un même jeton entre plusieurs serveurs ou usages.
• Scopes dédiés par serveur. Un jeton unique réutilisé par cinq serveurs MCP différents multiplie la surface de compromission : si l'un des cinq est vulnérable, les quatre autres sont exposés par ricochet.

Les logs d'appels d'outils sont indispensables pour l'audit, mais ils ne doivent jamais contenir la valeur des secrets ni des données personnelles sensibles en clair. Masquez systématiquement les champs identifiés comme sensibles avant écriture du log.

Isolation process et conteneur

Même avec des outils bien conçus, un serveur MCP reste un programme tiers exécuté localement ou sur une infrastructure partagée. L'isoler réduit l'impact d'une faille non encore découverte.

Isolation process

Sur un poste de travail, exécuter chaque serveur MCP dans son propre processus, avec un utilisateur système dédié aux droits restreints, limite déjà beaucoup de dégâts potentiels : pas d'accès au répertoire personnel complet, pas de droits d'administration, pas de capacité à modifier les fichiers d'autres applications.

Conteneurisation

Pour des déploiements plus sérieux — équipe, production, serveur partagé — la conteneurisation (Docker ou équivalent) apporte un confinement plus net :

• système de fichiers en lecture seule sauf répertoires explicitement montés ;
• réseau sortant restreint à une allowlist d'hôtes, sans accès aux plages d'adresses internes sensibles ;
• pas de capacités Linux superflues (--cap-drop=ALL puis ajout ciblé si nécessaire) ;
• limites de ressources (CPU, mémoire) pour éviter qu'un outil mal maîtrisé ne consomme tout le nœud.

Un conteneur bien confiné empêche un serveur compromis de sortir de son périmètre, mais il n'empêche pas ce serveur d'abuser des permissions qu'on lui a explicitement données à l'intérieur de ce périmètre. Les deux défenses sont complémentaires, pas substituables.

Revue de code des serveurs MCP

Installer un serveur MCP tiers revient à accepter d'exécuter du code écrit par quelqu'un d'autre, avec les permissions que vous lui accordez. Avant intégration dans un flux de production, une revue minimale devrait couvrir :

1. Origine et maintenance. Le dépôt est-il actif, l'organisation identifiable, les dépendances à jour ? Un serveur abandonné ou opaque est un risque en soi.
2. Définition des outils. Chaque outil déclare-t-il un schéma de paramètres strict (types, formats, contraintes) plutôt qu'un champ libre string fourre-tout ?
3. Gestion des chemins et des commandes. Recherchez toute construction de chemin de fichier ou de commande shell à partir d'une entrée non validée — c'est la source la plus fréquente de path traversal et d'injection de commande.
4. Appels réseau sortants. Le serveur limite-t-il ses destinations, ou accepte-t-il n'importe quelle URL fournie par le modèle sans restriction ?
5. Gestion des erreurs et des logs. Les messages d'erreur exposent-ils des informations internes (chemins système, structure de base de données, traces complètes) qui faciliteraient une attaque ultérieure ?
6. Dépendances tierces. Une vulnérabilité connue dans une bibliothèque utilisée par le serveur devient une vulnérabilité du serveur lui-même.

Un serveur MCP largement téléchargé n'a pas nécessairement fait l'objet d'une revue de sécurité sérieuse. Le nombre d'installations mesure l'adoption, pas l'audit.

Checklist avant mise en production

• Chaque outil expose un schéma de paramètres strict, sans champ texte libre permettant d'injecter des chemins ou des commandes arbitraires.
• Le client n'active que les outils réellement nécessaires à la tâche (allowlist), pas l'ensemble du serveur par défaut.
• Les jetons utilisés par le serveur portent des scopes minimaux et sont dédiés à cet usage.
• Les actions destructrices ou irréversibles déclenchent une confirmation humaine visible, jamais une exécution silencieuse.
• Aucun secret n'apparaît dans le code source, la configuration versionnée ou les logs.
• Le serveur tourne dans un processus ou un conteneur isolé, avec accès filesystem et réseau restreints.
• Le code du serveur — et ses dépendances — a fait l'objet d'une revue avant intégration, avec un point d'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire explicite sur la construction de chemins, de commandes et de requêtes.
• Un mécanisme de journalisation trace les appels d'outils sans stocker de secrets ni de données personnelles en clair.

Ces huit points ne couvrent pas tous les cas particuliers d'un déploiement donné, mais ils forment une base commune raisonnable pour tout serveur MCP amené à toucher des données réelles ou à déclencher des actions dans des systèmes de production. La sécurité d'un déploiement MCP se construit couche par couche — validation des paramètres, scopes réduits, isolation, confirmation humaine — plutôt qu'à travers un seul mécanisme jugé suffisant. C'est cette superposition de défenses indépendantes qui limite l'impact d'une faille inévitablement découverte tôt ou tard sur l'une d'entre elles.