Introduction

Le Model Context Protocol, ou MCP, définit une méthode structurée permettant à une application d'IA de se connecter à des capacités et à des données externes. Ses éléments centraux sont l'application hôte, un client MCP et un ou plusieurs serveurs MCP. L'hôte est le produit avec lequel l'utilisateur interagit, comme un IDE ou une application d'assistance. Il crée généralement une connexion client distincte pour chaque serveur afin que l'état du protocole, les capacités et les défaillances restent associés au serveur approprié.

Un serveur MCP expose des capacités au moyen d'opérations de protocole. Les outils sont des opérations exécutables qui peuvent interroger un service, modifier un enregistrement, envoyer un message ou produire un autre effet de bord. Les ressources représentent les données qu'un client peut récupérer, tandis que les prompts fournissent des modèles de prompts ou des schémas d'interaction réutilisables. Ces catégories sont utiles sur le plan architectural, mais aucune ne doit être considérée comme fiable simplement parce qu'elle est passée par MCP. La sécurité en production dépend de l'identité du propriétaire de chaque composant, des données qui traversent chaque connexion et du niveau d'autorité qu'une opération peut exercer.

Flux des requêtes et rôles des composants

Une interaction typique commence lorsque l'hôte établit une session avec un serveur MCP via un transport pris en charge. Le client et le serveur initialisent leur session de protocole et communiquent les capacités prises en charge. L'hôte peut ensuite découvrir les outils, ressources ou prompts disponibles et décider de la manière dont ces capacités doivent apparaître dans l'expérience utilisateur ou dans le contexte du modèle. Le transport exact peut varier entre les déploiements locaux et distants, mais les questions de confiance restent les mêmes.

Lorsqu'un modèle propose un appel d'outil, l'hôte ou le client doit appliquer la politique d'interaction et d'autorisation du produit avant de transmettre la requête. Le serveur valide à nouveau la requête et exécute l'opération à l'aide de ses propres identifiants et autorisations d'exécution. Le résultat revient par le serveur et le client jusqu'à l'hôte, où il peut être présenté à l'utilisateur ou ajouté au contexte du modèle. Cette validation répétée est intentionnelle : une politique côté client réduit les requêtes dangereuses, tandis que la validation côté serveur protège le serveur lorsqu'un autre client ou un message malformé l'atteint.

La lecture d'une ressource suit un chemin similaire, mais présente un profil de risque différent. Le serveur résout la ressource demandée et renvoie son contenu ou ses métadonnées. La lecture seule ne signifie pas qu'elle est inoffensive : une ressource peut contenir des informations confidentielles, des instructions malveillantes, des données personnelles ou du contenu obsolète. L'hôte doit préserver la provenance et appliquer des contrôles d'accès avant de présenter ou d'utiliser le contenu.

Frontières de confiance en développement

La première frontière se situe entre l’utilisateur et l’application hôte. L’hôte reçoit des requêtes en langage naturel, des résultats d’outils, le contenu de ressources et, éventuellement, des instructions provenant de systèmes externes. Un hôte de production ne doit pas supposer que toutes les instructions contenues dans les données récupérées représentent l’intention de l’utilisateur. Il lui faut des règles claires de confirmation, en particulier lorsqu’une action modifie des données, contacte un tiers, dépense de l’argent ou expose des secrets.

La deuxième frontière se situe entre le client MCP de l’hôte et le serveur. Un serveur peut être un processus local installé à partir d’un package, un service interne géré séparément ou un service distant exploité par une autre équipe. Ces choix de déploiement modifient le modèle d’authentification, d’isolation et de mise à jour. Un processus local peut tout de même lire des fichiers, hériter de variables d’environnement, accéder à des destinations réseau ou exécuter des dépendances vulnérables. Un serveur distant peut tout de même recevoir des arguments sensibles et renvoyer du contenu qui influence le modèle.

La troisième frontière se situe entre le serveur MCP et ses systèmes en aval. Le serveur peut appeler une base de données, une API cloud, un système de fichiers, un système de tickets ou une commande shell. L’authentification MCP n’autorise pas automatiquement ces actions en aval. Le serveur doit utiliser des identités de service aux privilèges strictement limités, des contrôles explicites des destinations, des délais d’expiration, des limites de débit et une autorisation propre à chaque opération. Un serveur capable d’émettre des requêtes administratives sans restriction est un composant à fort impact, même si son interface MCP n’expose que quelques outils.

Identité et autorisation en production

L’authentification répond à la question de savoir qui se connecte ; l’autorisation répond à celle de savoir ce que cette identité peut faire. Dans un déploiement de production, identifiez séparément, lorsque cela est possible, le contexte de l’hôte ou de l’utilisateur et le serveur MCP. Évitez d’utiliser un identifiant partagé par tous les clients et serveurs. La séparation des identités améliore la révocation, l’analyse des incidents, la limitation du débit et l’application du principe du moindre privilège. Les déploiements distants nécessitent également un transport sécurisé et une méthode définie de gestion des identifiants ; ceux-ci ne doivent pas être placés dans les arguments des outils ni renvoyés dans leurs résultats.

La négociation des capacités est utile pour la compatibilité, mais elle ne constitue pas une décision d’autorisation. Le fait qu’un serveur annonce qu’il prend en charge les outils ne signifie pas qu’un utilisateur donné peut invoquer tous les outils. L’autorisation doit être évaluée pour l’opération demandée, la cible, le tenant et la classification des données. Par exemple, un utilisateur peut être autorisé à lire une ressource de projet sans être autorisé à supprimer le projet, même lorsque les deux capacités sont exposées par le même serveur.

Les schémas d’outils contribuent à limiter les entrées, mais un schéma ne constitue pas une politique de sécurité complète. Le serveur doit valider les types, les plages de valeurs, les longueurs, les identifiants et les relations entre les champs. Il doit rejeter les destinations inattendues, les chemins de fichiers dangereux, les références de tenant invalides et les requêtes qui dépassent le périmètre d’autorisation de l’appelant. Pour les actions à fort impact, l’hôte peut exiger l’approbation explicite de l’utilisateur et afficher la cible, l’effet prévu et les paramètres importants avant l’exécution. L’approbation doit être liée à l’action spécifique et non être traitée comme une autorisation permanente.

Contrôles opérationnels et gestion des défaillances

L’exploitation en production nécessite une visibilité sur l’ensemble du cheminement de la requête. Enregistrez l’identité à l’origine de la requête, le serveur qui l’a traitée, l’outil ou la ressource sélectionné, le résultat de l’autorisation et le résultat de l’opération en aval. Masquez les secrets et les données personnelles superflues. Corrélez les journaux du client, du serveur et des systèmes en aval à l’aide d’un identifiant de requête, tout en reconnaissant que les journaux deviennent eux-mêmes des actifs sensibles nécessitant des contrôles d’accès et des règles de conservation.

Concevez le système pour gérer les défaillances partielles. Un serveur peut être indisponible, une API en aval peut dépasser son délai d’attente, une réponse peut dépasser les limites de taille ou un outil peut renvoyer une erreur après avoir créé un effet de bord. L’hôte doit communiquer clairement l’incertitude et ne doit pas réessayer automatiquement les opérations non idempotentes sans politique définie. Les serveurs doivent utiliser des délais d’expiration plafonnés, une concurrence contrôlée, des limites de taille des réponses et une gestion prévisible des erreurs. Des disjoncteurs ou des limites de débit peuvent être appropriés pour les dépendances coûteuses ou fragiles.

Traitez les mises à jour et la configuration comme faisant partie du modèle de confiance. Épinglez les versions des serveurs ou examinez-les, vérifiez la source et l’intégrité des artefacts de déploiement, gérez les secrets en dehors du code source et limitez l’environnement hérité par les processus locaux. Testez le comportement des outils avec des entrées malformées, des cibles non autorisées, des résultats surdimensionnés, des injections de prompt dans les ressources et des défaillances des systèmes en aval. L’examen de sécurité doit porter sur les autorisations effectives de l’environnement d’exécution, et pas uniquement sur les noms et descriptions exposés par le serveur MCP.

Erreurs courantes et revue pratique

Une erreur fréquente consiste à considérer les descriptions des outils comme un contrat de sécurité. Les descriptions sont utiles pour la découverte, mais un serveur compromis ou mal maintenu peut décrire une opération dangereuse avec un langage inoffensif. Examinez l'implémentation, les autorisations de l'identité, les destinations réseau, les flux de données et le comportement en matière d'approbation. La même prudence s'applique aux modèles de prompt et aux métadonnées des ressources : ils peuvent influencer le comportement du modèle, mais ne confèrent pas d'autorité.

Une autre erreur consiste à considérer une configuration de développement locale comme un modèle de confiance de production. Les développeurs exécutent souvent un serveur avec un accès étendu au système de fichiers, des identifiants personnels, un accès sortant illimité au réseau et des journaux détaillés. En production, ces paramètres par défaut doivent être remplacés par une identité d'exécution dédiée, un répertoire de travail restreint, un nombre réduit de variables d'environnement, des règles de sortie explicites et une gestion contrôlée des données. Testez le déploiement avec les autorisations que la production accordera réellement.

Lors d'une revue, suivez une opération de lecture représentative et une opération d'écriture représentative, depuis la requête de l'utilisateur jusqu'à l'effet en aval. Pour chaque étape, identifiez l'identité, la validation des entrées, la classification des données, l'exigence d'approbation, le délai d'expiration, l'événement d'audit et le comportement en cas d'échec. Si une étape ne peut pas être expliquée avec précision, la limite n'est pas encore définie de manière opérationnelle. Cette méthode produit des actions correctives concrètes au lieu de s'appuyer sur une affirmation générale selon laquelle le serveur MCP est digne de confiance.

Résumé

MCP sépare l'expérience hôte des fonctionnalités fournies par le serveur, mais n'efface pas les limites de sécurité qui les séparent. L'hôte gère l'interaction avec l'utilisateur et les sessions client ; le serveur valide les requêtes et implémente les outils, les ressources et les prompts ; les systèmes en aval restent des autorités distinctes, avec leurs propres autorisations et modes de défaillance.

En production, concentrez-vous sur une identité explicite, le principe du moindre privilège, la validation côté serveur, l'approbation de l'utilisateur pour les actions ayant des conséquences, le traitement attentif du contenu récupéré, l'exécution limitée et des pistes d'audit utiles. La négociation des capacités favorise l'interopérabilité, tandis que l'autorisation détermine ce qui peut réellement se produire. L'objectif pratique n'est pas de considérer MCP comme un tout digne ou indigne de confiance, mais de documenter chaque limite et d'appliquer des contrôles adaptés aux données et à l'autorité qui la franchissent.