Sécuriser un serveur MCP : permissions, secrets et audit

Sécuriser un serveur MCP signifie réduire ce qu’il peut lire, faire et transmettre. Le protocole permet à un client d’IA de découvrir des outils et ressources, mais il ne choisit pas vos permissions à votre place. Un serveur trop large peut exposer des documents sensibles, utiliser un token puissant ou déclencher une action avec effet de bord. Le bon point de départ est un outil de lecture sur un environnement de test, pas une connexion générale à la production.

Ce guide propose une méthode concrète : définir le périmètre, limiter l’identité, valider les entrées, protéger les secrets, contrôler les sorties et préparer un audit. Il ne garantit pas qu’un serveur tiers est sûr. Chaque composant — client, serveur, API, base et fournisseur d’identité — doit être vérifié dans son contexte.

Ce que vous allez apprendre

Vous allez mettre en place les principaux garde-fous d’un serveur MCP : moindre privilège, outils spécialisés, validation runtime, logs utiles mais minimisés, tests de refus et retrait contrôlé. Vous saurez aussi reconnaître les situations qui exigent une revue de sécurité avant toute intégration.

Prérequis

Préparez un serveur MCP de démonstration, un environnement de test et une liste des données ou services concernés. Identifiez le propriétaire de chaque système et la procédure de révocation des secrets. Lisez la documentation du SDK et du client utilisés : les formats, transports et capacités évoluent.

Avant toute modification, écrivez le périmètre :

Capacité : recherche dans la documentation de test.
Données autorisées : trois documents fictifs.
Actions interdites : écriture, réseau externe, commande système.
Identité : aucune ou compte de test lecture seule.

Vérification : chaque capacité possède une donnée ou action justifiée. Si vous ne pouvez pas expliquer pourquoi un outil existe, il ne doit pas être activé.

1. Appliquer le moindre privilège

Le moindre privilège signifie que le serveur reçoit uniquement les droits nécessaires à son objectif. Un serveur de recherche documentaire n’a pas besoin d’accéder à tout le disque. Un serveur qui lit une API ne devrait pas utiliser un token administrateur. Un outil d’analyse de dépôt peut se limiter à un projet sandbox et à des opérations de lecture.

Séparez les environnements. Le pilote utilise des données de démonstration, des comptes dédiés et des permissions minimales. La production, les sauvegardes et les secrets restent hors de ce périmètre tant qu’une revue ne justifie pas une extension. Cette séparation réduit l’impact d’une erreur de configuration, d’un bug ou d’une instruction malveillante présente dans une ressource lue.

Vérification : avec l’identité du serveur, tentez une action explicitement interdite dans un environnement de test. Le refus attendu prouve mieux une permission limitée qu’une déclaration dans un README.

2. Préférer des outils spécialisés au SQL ou shell libre

Un outil nommé search_docs avec une entrée courte est plus simple à contrôler qu’un outil execute qui accepte une commande arbitraire. Un serveur MCP doit exposer la plus petite action utile : lire une ressource, rechercher une note, compter des éléments fictifs ou créer un brouillon dans un bac à sable.

Les outils génériques multiplient les chemins d’attaque. Une entrée peut contenir une commande inattendue, un chemin hors répertoire ou une requête coûteuse. Si un outil d’écriture est nécessaire, créez une tâche séparée : cible de test, confirmation humaine, validation métier, journalisation et retour arrière. Ne transformez pas un pilote de lecture en automate de production par commodité.

Vérification : listez les outils exposés et leur effet de bord. Un outil sans contrat précis doit être retiré ou placé en needs_review.

3. Valider les entrées au runtime

Les types de votre langage aident pendant le développement, mais les valeurs reçues par un serveur peuvent être absentes, trop longues ou mal formées. Définissez un schéma d’entrée : type, longueur, format, valeurs autorisées et limite de résultat. Refusez toute valeur qui sort du contrat plutôt que d’essayer de la corriger silencieusement.

Pour une recherche, limitez par exemple la taille du mot-clé et le nombre de résultats. Pour une ressource identifiée par un chemin, normalisez le chemin puis vérifiez qu’il reste dans un répertoire autorisé. Pour une action vers une API, validez les paramètres et appliquez l’autorisation côté service, pas uniquement dans le client.

Les messages d’erreur doivent être utiles sans révéler une stack trace, un chemin interne, un token ou une requête sensible. Conservez les détails techniques dans des logs contrôlés par les opérateurs.

Vérification : testez une entrée valide, une entrée vide, une valeur trop longue et une tentative de sortie de périmètre. Chaque rejet doit être explicite et sans fuite d’information.

4. Gérer les secrets comme des données à durée limitée

Un secret ne doit jamais être écrit dans le code, le manifeste de configuration partagé ou une conversation. Utilisez les mécanismes protégés de votre environnement et documentez seulement le nom de la variable :

MCP_SERVICE_TOKEN="remplacez-par-un-secret-local"

Créez des identités dédiées au serveur, avec une portée et une durée adaptées. Documentez le propriétaire, le service cible, les droits et la procédure de rotation. Si un secret apparaît dans une sortie, considérez-le comme divulgué : révoquez-le, cherchez les emplacements accessibles et remplacez-le. Le supprimer d’un fichier ne le rend pas secret à nouveau.

Vérification : recherchez les motifs de secret dans le dépôt et les logs de test. Une occurrence inattendue doit être investiguée avant de continuer.

5. Traiter les ressources et prompts comme non fiables

Un serveur MCP peut retourner une issue, un document, un message ou une ligne de base qui contient une instruction hostile. Ce contenu peut demander à l’assistant d’ignorer les règles, d’ouvrir un fichier ou d’exécuter une commande. Il reste une donnée : il ne peut pas élever le niveau de permission ni modifier le périmètre de la tâche.

Construisez le client et les procédures humaines de manière à demander une confirmation pour les effets de bord. Affichez le nom de l’outil, ses paramètres et sa cible avant l’exécution lorsque c’est possible. Ne cachez pas les appels derrière une étiquette vague telle que « améliorer le contexte ».

Vérification : introduisez un texte de démonstration qui demande une action hors périmètre. Le système et l’opérateur doivent l’ignorer comme instruction et conserver les règles de sécurité.

6. Journaliser pour l’audit, sans tout collecter

Les logs utiles enregistrent l’heure, l’outil appelé, l’identité de service, le résultat synthétique et une erreur contrôlée. Ils ne doivent pas contenir le mot de passe, le token ou l’intégralité d’une donnée personnelle. Définissez la durée de conservation, les personnes qui peuvent les lire et la procédure de suppression conforme à votre politique.

Surveillez les signaux simples : augmentation d’erreurs, appels vers un outil inattendu, volume de données anormal ou tentatives répétées d’entrée invalide. Un log n’est pas une protection active, mais il donne une trace pour enquêter et améliorer les limites.

Vérification : générez une erreur de test et relisez le log. Il doit permettre de comprendre l’échec sans révéler de secret ni de contenu complet.

7. Préparer le retrait et la revue

Un serveur MCP doit pouvoir être désactivé rapidement : retirer sa configuration du client, arrêter son processus, révoquer son secret et désactiver son compte de service. Documentez ces étapes avant d’élargir l’accès. Si le serveur est utilisé en production, prévoyez aussi qui décide de l’arrêt et comment informer les utilisateurs concernés.

Avant une intégration durable, faites une revue : source et version du serveur, dépendances, données, identité, outils, tests de refus, logs et plan de maintenance. Une question sans réponse devient un risque à traiter, pas une note de bas de page à ignorer.

Problèmes fréquents et solutions

Le serveur a besoin de tous les fichiers pour fonctionner

Revenez au besoin. Isolez un répertoire, créez une ressource indexée ou choisissez un outil différent. Un accès complet est rarement nécessaire à un pilote utile.

Les erreurs sont difficiles à diagnostiquer sans logs détaillés

Ajoutez un identifiant de corrélation et des métadonnées limitées, pas le contenu intégral des requêtes ou des secrets. Testez le diagnostic avec des données fictives.

Une action d’écriture semble indispensable

Créez une capacité séparée avec une cible sandbox, une confirmation humaine et des autorisations dédiées. Ne l’ajoutez pas au même outil que la lecture.

FAQ

Un serveur MCP doit-il être accessible depuis Internet ?

Non. Un serveur local ou interne peut suffire. Toute exposition réseau doit répondre à un besoin précis et recevoir des contrôles adaptés.

Comment limiter une base connectée à MCP ?

Utilisez une base de test ou des vues dédiées, un rôle lecture seule et des outils qui n’acceptent pas de SQL arbitraire.

Les types TypeScript protègent-ils les entrées ?

Non à l’exécution. Ajoutez une validation runtime et des tests d’entrées invalides.

Que faire si un secret apparaît dans un log ?

Traitez-le comme exposé : révoquez-le, évaluez sa diffusion, corrigez le log et remplacez l’identifiant avec une portée réduite.

À quelle fréquence auditer le serveur ?

Après un changement de capacités, de dépendance, de permissions ou de données, et selon la politique de sécurité de votre organisation.

Conclusion

Un serveur MCP sûr est petit, explicite et réversible. Limitez les droits, validez chaque entrée, protégez les secrets, contrôlez les effets de bord et gardez une trace d’audit. Cette méthode rend l’intégration IA plus utile sans transformer un outil de contexte en accès non maîtrisé.

Pour replacer ces contrôles dans le fonctionnement du protocole, consultez MCP : définition, fonctionnement et sécurité.

Sources et limites

• Model Context Protocol — security best practices : principes de sécurité MCP.
• OWASP — Input Validation Cheat Sheet : validation d’entrée.
• OWASP — Secrets Management Cheat Sheet : gestion de secrets.
• OWASP — Logging Cheat Sheet : journalisation de sécurité.

Les contrôles doivent être adaptés au transport, au SDK, aux outils exposés et aux exigences légales de votre organisation. Ce guide ne remplace pas un audit formel.