Sécuriser un serveur MCP : la checklist avant connexion

Commencer par le périmètre réel

La première question n’est pas « ce serveur fonctionne-t-il ? », mais « que peut-il faire avec mes droits ? ». Listez les fichiers, API, comptes, bases de données et réseaux auxquels il peut accéder. Un outil apparemment simple peut devenir critique s’il hérite d’un jeton administrateur, d’un accès à tout le disque ou d’un réseau interne.

OWASP décrit plusieurs risques spécifiques aux écosystèmes MCP : descriptions d’outils malveillantes, changements de définition après approbation, permissions excessives, exfiltration de données et interactions dangereuses entre plusieurs serveurs. La checklist doit donc couvrir le code, les autorisations et la manière dont le modèle reçoit les données.

1. Vérifier la provenance avant l’installation

Identifiez l’éditeur, le dépôt source, la méthode d’installation et la version réellement exécutée. Évitez les commandes copiées depuis une source inconnue et vérifiez les noms de paquets : le typosquatting est particulièrement dangereux lorsque l’installation donne immédiatement accès à des secrets ou au système de fichiers.

Pour une dépendance critique, préférez une version figée ou un mécanisme permettant d’identifier précisément ce qui a été examiné. Une mise à jour peut être légitime tout en modifiant le comportement ou les définitions d’outils ; elle mérite donc la même attention qu’une nouvelle intégration.

• Dépôt et éditeur identifiables.
• Version ou révision connue.
• Dépendances et méthode d’installation examinées.
• Aucun secret placé directement dans la commande ou le dépôt.

2. Donner le minimum de droits

Chaque serveur doit recevoir uniquement les autorisations nécessaires à sa fonction. Un serveur qui lit un répertoire documentaire ne devrait pas obtenir l’accès à toute la machine. Un outil de consultation ne devrait pas recevoir un jeton qui permet aussi la suppression ou l’administration.

OWASP recommande des identifiants séparés par serveur, des portées étroites et des jetons courts lorsque l’architecture le permet. Cela limite l’impact d’un serveur compromis et évite qu’un outil généraliste devienne un point d’entrée vers plusieurs systèmes.

3. Contrôler authentification et autorisation

Pour un serveur distant qui expose des données ou des actions privées, vérifiez comment l’appelant est authentifié et comment chaque requête est autorisée. La révision MCP 2026-07-28 renforce plusieurs points du flux d’autorisation, notamment la validation de l’émetteur dans certains scénarios OAuth et l’isolation des informations d’enregistrement.

Un jeton d’accès MCP ne doit pas être traité comme un passe-partout pour les API en aval. Le serveur doit vérifier la destination et la portée du jeton, puis utiliser les mécanismes adaptés lorsqu’il appelle un autre service. Ne stockez pas des jetons longue durée dans un fichier de configuration synchronisé ou versionné.

4. Lire les descriptions d’outils comme du contenu non fiable

Les descriptions, paramètres et résultats d’outils peuvent être injectés dans le contexte du modèle. Un serveur malveillant peut tenter d’influencer le comportement de l’agent par des instructions cachées ou ambiguës. Cela signifie qu’une simple inspection du nom de l’outil ne suffit pas.

Examinez le schéma complet : nom, description, paramètres, annotations et effets attendus. Si votre client sait détecter les changements, demandez une nouvelle validation lorsqu’une définition d’outil évolue. Les annotations doivent aider l’interface, pas remplacer une politique d’autorisation exécutée dans du code fiable.

5. Valider les entrées et les sorties

Un argument proposé par un modèle doit être traité comme une entrée non fiable. Validez les chemins de fichiers, identifiants, URL, requêtes et formats avant exécution. Évitez les outils qui transforment directement une chaîne générée en commande shell. Pour un outil réseau, utilisez des règles explicites sur les destinations autorisées afin de limiter les risques de SSRF ou d’accès aux services internes.

Les sorties sont également non fiables. Une page web, un ticket ou un document peut contenir des instructions destinées à détourner l’agent. Structurez les données lorsque c’est possible et appliquez les décisions sensibles dans votre application, même si le modèle affirme qu’une action est sûre.

6. Isoler le serveur et réduire son environnement

Un serveur local lancé en stdio n’est pas exposé sur un port réseau, mais cela ne l’empêche pas de lire des fichiers ou d’ouvrir des connexions si le processus dispose de ces droits. Placez les intégrations non fiables dans un environnement restreint et ne montez que les répertoires indispensables.

Pour un serveur distant, limitez également le réseau sortant et les secrets disponibles au processus. L’objectif est simple : si le serveur est compromis, il ne doit pas automatiquement hériter de toutes les capacités de la machine ou du compte qui l’héberge.

7. Garder une confirmation humaine pour les actions à impact

Les suppressions, publications, paiements, modifications d’accès et envois externes ne devraient pas dépendre uniquement du jugement du modèle. Présentez l’action et ses paramètres à l’utilisateur, puis liez l’approbation à cette opération précise. Une confirmation générique donnée au début d’une session n’est pas équivalente à l’autorisation d’une action destructive.

OWASP recommande explicitement un contrôle humain pour les opérations sensibles. Cela ne signifie pas qu’un agent ne peut rien automatiser : les lectures à faible risque et les opérations réversibles peuvent avoir des politiques plus souples, tandis que les actions critiques gardent un verrou supplémentaire.

8. Journaliser sans recréer une fuite de données

Conservez suffisamment de traces pour comprendre quel outil a été appelé, par quel utilisateur et avec quel résultat de politique. En revanche, ne copiez pas systématiquement dans les journaux des secrets, des documents complets ou des données personnelles simplement parce qu’ils transitent par un outil.

Les limites de fréquence, délais d’exécution et budgets de ressources complètent cette visibilité. Un agent qui boucle sur un outil peut provoquer un déni de service ou une facture inattendue sans qu’il y ait une attaque traditionnelle.

9. Pour HTTP : TLS, origine et exposition réseau

Un serveur HTTP distant doit être servi sur TLS et n’exposer que les interfaces réellement nécessaires. Les recommandations OWASP pour MCP insistent aussi sur la validation de l’origine lorsque le contexte navigateur l’exige et sur la vérification des jetons pour le bon destinataire.

Un serveur prévu uniquement pour la machine locale ne devrait pas écouter automatiquement sur toutes les interfaces. De même, une passerelle publique ne doit pas transformer un service interne non authentifié en endpoint accessible depuis Internet.

La checklist avant de cliquer sur « Connecter »

Avant la première utilisation, vous devriez pouvoir répondre oui aux points ci-dessous. Si une réponse manque, réduisez le périmètre ou testez dans un environnement isolé avant d’ajouter des données réelles.

Sécuriser d’abord, connecter ensuite

MCP facilite l’interopérabilité, ce qui augmente aussi la vitesse à laquelle on peut brancher de nouveaux outils. La bonne réponse n’est pas de refuser toute intégration, mais de rendre la confiance explicite : source connue, droits minimaux, contrôles dans le code et isolation proportionnée au risque.

Si l’architecture elle-même n’est pas encore claire, commencez par notre guide sur le Model Context Protocol. Pour comparer ensuite plusieurs assistants ou clients, utilisez une grille reproductible comme celle de notre méthode d’évaluation des outils IA.