GouvernanceMis à jour 2026-08-22 · Version 1.0

Qu'est-ce que la sécurité MCP ?

La sécurité MCP est ce qui empêche un serveur Model Context Protocol de devenir la porte d'entrée la plus facile dans un système. Le protocole standardise la manière dont les agents découvrent et appellent les outils ; il ne décide pas de qui peut les appeler, de ce qu'ils peuvent atteindre, ni de ce qui se passe lorsqu'une description d'outil devient hostile. Ces décisions incombent au serveur : authentification, validation de l'origine et du transport, outils à portée restreinte, limites de débit et piste d'audit.

Preuve: ProductionConfiance: ÉlevéSource: Système de productionSource: Expérience personnelleSource: Observation du secteur
Lisible par machine: JSON

Définition

La sécurité MCP est l'ensemble des contrôles appliqués à un serveur Model Context Protocol et à ses clients — authentification et autorisation, validation de l'origine et du transport, définition de la portée des outils, gestion des entrées et des sorties, limitation du débit et audit — afin que l'exposition de capacités à un agent d'IA n'expose pas les systèmes sous-jacents.

Points clés

  • Le MCP standardise la plomberie, pas la confiance : chaque serveur décide de sa propre posture.
  • La description d'un outil est une entrée non fiable pour le modèle — elle peut donner des instructions et peut changer après approbation.
  • Les serveurs stdio locaux et les serveurs HTTP distants ont des modèles de menace différents ; les erreurs dangereuses diffèrent.
  • Les vérifications d'origine et les limites de débit relèvent du serveur, car les clients ne sont pas sous votre contrôle.
  • Le 'lecture seule' est une propriété de l'implémentation, jamais du nom de l'outil.

Contexte

Le MCP offre à un agent un moyen uniforme de découvrir et d'invoquer des capacités. Cette uniformité constitue à la fois la valeur et le risque : un client peut être orienté vers de nombreux serveurs, et chaque serveur représente une nouvelle décision de confiance prise — en pratique — par quiconque a collé une URL dans un fichier de configuration.

Deux types de déploiement prédominent. Un serveur stdio local s'exécute avec les propres privilèges de l'utilisateur sur sa machine : il n'y a pas de frontière réseau, les questions portent donc sur ce qu'il peut lire et s'il communique avec l'extérieur. Un serveur HTTP distant est un point de terminaison public : les questions deviennent alors qui appelle, d'où, à quelle fréquence, et si un navigateur peut être trompé pour l'appeler au nom d'un utilisateur.

Nous exploitons un modèle de chaque type pour cette base de connaissances — un point de terminaison HTTP public et un package stdio publié — de sorte que les contrôles ci-dessous sont décrits tels qu'ils sont implémentés plutôt que sous forme de liste de contrôle générique.

Architecture

Déterminez d'abord le niveau d'exposition : accès public en lecture seule, accès authentifié ou local uniquement. Tout le reste découle de cette réponse, et la plupart des incidents proviennent d'un serveur qui n'a jamais franchi cette étape.

Validez le transport avant d'effectuer toute opération. Pour les serveurs HTTP, comparez l'en-tête Origin à une liste d'autorisation et rejetez les appels intersites initiés par le navigateur avant l'exécution d'un gestionnaire — le rebind DNS et les abus de type CSRF surviennent tous deux de cette manière.

Maintenez le serveur sans état (stateless) partout où le protocole le permet. L'absence de stockage de session élimine la fixation de session, la contamination entre requêtes et la fuite d'état entre les appelants.

Restreignez strictement la portée des outils. Un outil, une fonctionnalité, pas de verbes qui changent selon un argument — un outil de « requête » qui peut également écrire est une élévation de privilèges qui n'attend que le bon paramètre.

Limitez le débit par appelant et répondez avec un véritable code 429 et un en-tête Retry-After. Un agent qui réessaie constitue un trafic normal ; un agent qui réessaie sans limite est un outil de déni de service dirigé contre votre propre backend.

Enregistrez chaque appel avec suffisamment de structure pour reconstituer les abus — outil, résultat, latence, identité de l'appelant — et rien qui ne transforme le journal lui-même en faille de sécurité.

Traisez chaque résultat d'outil comme du contenu non approuvé lors du retour. Un serveur qui sert de proxy pour des données externes constitue, par construction, un canal d'injection de prompt indirect.

Composants

Authentification : aucune pour les données de lecture véritablement publiques, un jeton ou OAuth pour tout le reste — avec une décision documentée, car l'absence d'authentification doit être un choix et non un oubli.Validation de l'origine et de l'hôte pour les serveurs distants, dérivée du trafic mesuré plutôt que supposée à partir des valeurs par défaut d'une application web.Autorisation par outil : ce que cet appelant est autorisé à invoquer, et non pas seulement s'il est autorisé à se connecter.Validation des entrées à la limite de l'outil, avec la même rigeur que pour une API publique — car c'est exactement ce dont il s'agit.Mise en forme des sorties : renvoyez le strict minimum requis par l'appelant ; ne transmettez jamais directement les charges utiles brutes en amont.Limitation du débit et quotas, avec des en-têtes suffisamment précis pour que les clients bien configurés ralentissent d'eux-mêmes.Journaux d'audit et métriques, conservés suffisamment longtemps pour permettre les investigations et suffisamment agrégés pour être stockés en toute sécurité.Hygiène de la chaîne d'approvisionnement pour le serveur lui-même : dépendances figées, mises à jour examinées, provenance publiée afin que les clients puissent vérifier qu'ils communiquent bien avec le serveur que vous avez construit.

Avantages

  • Un serveur MCP bien délimité présente une surface d'attaque plus restreinte que l'intégration ad hoc qu'il remplace : un seul protocole, un seul point d'audit, un seul endroit pour révoquer les accès.
  • L'absence d'état et la spécialisation étroite des outils facilitent l'analyse du serveur — l'évaluation de sécurité tient sur une seule page.
  • Les erreurs standardisées et les en-têtes de limitation de débit rendent le comportement des clients prévisible, ce qui constitue en soi une propriété défensive.
  • Puisque tout franchit une seule et même frontière, la mesure est immédiate : l'utilisation normale et les abus apparaissent dans les mêmes journaux et se distinguent facilement.

Risques

  • Changements de comportement d'outils (« tool rug pulls ») : un serveur qui se comporte correctement au moment de l'approbation et modifie la description de ses outils plus tard, une fois que le client a cessé de vérifier.
  • Serveurs locaux trop permissifs : un serveur stdio détenant le système de fichiers et les identifiants de l'utilisateur offre une capacité d'agent complète sans aucune frontière réseau pour l'intercepter.
  • Député confus (« confused deputy ») : le serveur détient des identifiants que l'appelant n'a pas, de sorte que quiconque y accède hérite de sa portée.
  • Exposition publique silencieuse : un serveur distant déployé sans authentification, sans vérification d'origine et sans limitation de débit est facilement détectable et exposé aux abus.
  • Relais d'injection : la sortie d'un outil provenant de sources tierces est transmise au modèle comme s'il s'agissait d'une instruction de confiance.

Outils et technologies

La spécification MCP et ses directives de sécurité de transport — la référence à laquelle chaque serveur devrait pouvoir se conformer.Listes d'autorisation d'origine et configuration CORS appliquées avant l'exécution du code de l'application.Stockages de limitation de débit (Redis ou équivalent) indexés par un hachage de l'identité de l'appelant plutôt que par une adresse IP brute.Journaux de requêtes structurés et métriques de latence, afin que les abus et les coûts soient visibles dans la même vue.Le Top 10 OWASP pour les applications LLM, pour les catégories d'injection et d'agentivité excessive que les serveurs MCP amplifient.Inscriptions au registre et publications signées, afin que les clients puissent vérifier que le serveur qu'ils installent est bien celui que vous avez livré.

Exemples

  • Cette base de connaissances expose un point de terminaison HTTP MCP public en lecture seule. Elle est sans état par conception, de sorte qu'aucune session ne peut être fixée ou rejouée ; les outils ne renvoient que du contenu publié ; et chaque appel est limité en débit par appelant haché avec un véritable code 429 et un en-tête Retry-After.
  • Avant d'écrire une règle d'origine (Origin) pour ce point de terminaison, nous avons d'abord mesuré son propre trafic : presque toutes les requêtes ne comportaient aucun en-tête Origin, aucune ne comportait la valeur null, et chaque requête qui en comportait un provenait de ce site. La règle déployée suit cette mesure — rejeter les appels provenant de navigateurs tiers, autoriser le trafic d'agents sans en-tête qui constitue l'audience réelle — plutôt que d'appliquer une politique copiée par défaut depuis une application web.
  • Le package stdio publié pour cette même base de connaissances s'exécute localement sans identifiants ni accès au système de fichiers, car il n'a besoin que d'un appel sortant vers le point de terminaison public. Un serveur local qui n'a besoin de rien ne doit rien recevoir.

FAQ

Le protocole MCP rend-il les agents plus ou moins sûrs ?
Plus sûr par intégration, plus risqué globalement. Un seul protocole signifie un seul endroit pour examiner et révoquer les accès — mais cela réduit également le coût de connexion d'un agent à un autre système, et chaque connexion représente une nouvelle décision de confiance à prendre.
Ai-je besoin d'une authentification sur un serveur en lecture seule ?
Pas nécessairement, si les données sont véritablement publiques. Vous avez tout de même besoin d'une limitation de débit et d'une piste d'audit : public ne signifie pas gratuit, et un point de terminaison public non limité est un amplificateur dirigé contre votre propre infrastructure.
Pourquoi vérifier l'en-tête Origin si les agents n'en envoient pas ?
Précisément parce qu'ils n'en envoient pas. Le trafic sans en-tête constitue l'audience légitime ; une requête qui comporte une origine (Origin) étrangère provient d'un navigateur agissant pour le compte de quelqu'un d'autre, ce qui est exactement le cas qu'il convient de rejeter.
Qu'est-ce qu'un changement de comportement d'outil (« tool rug pull ») et comment s'en prémunir ?
Il s'agit d'un serveur qui présente des descriptions d'outils inoffensives lorsque l'utilisateur l'approuve, puis les modifie par la suite. Les défenses consistent à figer la version du serveur, à revalider les descriptions lorsqu'elles changent et à ne pas accorder à un serveur distant des capacités que vous n'accorderiez pas à une dépendance de code.

Références