Le Model Context Protocol (MCP) devient rapidement un standard commun pour connecter les AI agents aux données et outils d’entreprise. Il remplace les intégrations ad hoc, spécifiques à chaque outil, par une interface partagée permettant aux agents d’appeler des serveurs externes, de récupérer du contexte et d’exécuter des actions. Mais chaque serveur MCP auquel un agent s’adresse constitue une nouvelle frontière de confiance. Des incidents de sécurité récents — notamment un package npm malveillant qui usurpait un service d’email légitime et la divulgation de vulnérabilités dans les SDK officiels de MCP — montrent ce qui se passe lorsque les équipes traitent les serveurs MCP comme des composants plug-and-play.
La sécurité MCP signifie traiter chaque serveur comme non fiable par défaut, vérifier sa source, limiter la portée des outils, isoler l’exécution, journaliser les actions et gouverner le déploiement avec une politique explicite. Si votre équipe traverse le parcours plus large du pilote à la production décrit dans IA agentique en production, la sécurité MCP est la couche qui détermine si votre agent peut toucher en toute sécurité aux données d’entreprise une fois arrivé.
Points clés à retenir
- MCP transforme chaque serveur externe en une nouvelle frontière de confiance. Les intégrations MCP ouvertes par défaut peuvent exposer des données d’entreprise au-delà de la portée prévue de l’agent.
- Les principaux risques 2026 incluent l’empoisonnement d’outils, l’injection de prompt via les réponses des serveurs MCP, les attaques rug-pull et supply-chain, les portées d’outils excessivement larges, et les défaillances de validation OAuth ou des jetons.
- Les meilleures pratiques de sécurité MCP couvrent la vérification et l’épinglage de version des serveurs, les portées d’outils au moindre privilège, le sandboxing de l’exécution, la journalisation d’audit complète, et l’approbation humain-dans-la-boucle pour les actions sensibles.
- La gouvernance d’entreprise comble le fossé : politique écrite, classification des données et contrôles pouvant soutenir l’alignement avec ISO/IEC 27001:2022 et SOC 2 — mais qui n’établissent pas à eux seuls la conformité.
- Les serveurs MCP distants authentifiés sont souvent plus faciles à gouverner lorsqu’ils sont combinés avec la segmentation réseau, l’autorisation à portée limitée, le contrôle de sortie et la journalisation centralisée. Distant n’est pas automatiquement plus sûr ; c’est plus sûr uniquement lorsque ces contrôles sont en place.
Qu’est-ce que le Model Context Protocol (MCP) ?
Le Model Context Protocol est un protocole ouvert qui standardise la manière dont les applications LLM se connectent à des sources de données et outils externes. Selon la spécification officielle du Model Context Protocol, MCP définit trois rôles : les hôtes (applications qui gèrent les agents), les clients (entités à l’intérieur de l’hôte qui se connectent aux serveurs) et les serveurs (programmes qui exposent des outils, des ressources et des prompts). MCP est un protocole ouvert initialement introduit par Anthropic, comme décrit dans la présentation du Model Context Protocol par Anthropic. Il n’appartient pas exclusivement à un seul fournisseur.
Pourquoi les équipes vont au-delà des intégrations d’outils ad hoc
Avant MCP, connecter un agent à une base de données, un CRM ou un stockage de fichiers signifiait écrire une intégration personnalisée par outil. MCP remplace cela par un protocole partagé où tout client compatible MCP peut appeler n’importe quel serveur. Les avantages — intégration plus rapide, serveurs réutilisables, portabilité des modèles — sont réels, mais cette même facilité élargit la surface d’attaque. Quand un développeur peut installer un serveur MCP en quelques secondes, la question passe de « pouvons-nous construire cela ? » à « devons-nous confier nos données à ce serveur ? »
Ce que MCP sécurise — et ne sécurise pas — par défaut
MCP standardise la communication entre clients et serveurs. Il ne sécurise pas l’intégration complète. Les éléments suivants restent la responsabilité de l’hôte et du client : la confiance du serveur, l’autorisation, le consentement, la validation des sorties et les contrôles d’exécution (sandboxing, limitation de débit, isolation). La spécification note que les descriptions et annotations d’outils doivent être considérées comme non fiables sauf si elles proviennent d’un serveur de confiance. MCP vous donne une manière standard de vous connecter — pas une garantie que ce à quoi vous vous connectez est sûr.
Pourquoi la sécurité MCP compte maintenant
Un serveur MCP détient souvent des identifiants pour une base de données, un système de fichiers, un fournisseur d’email ou une API métier. Si le serveur est compromis, sur-permissionné ou malveillant, la surface de fuite de données s’étend à tout ce que ces identifiants peuvent atteindre.
| Dimension | Intégration ad hoc | Intégration basée sur MCP |
|---|---|---|
| Frontière de confiance | Une intégration personnalisée par outil | Une frontière standard par serveur, réutilisée entre agents |
| Portée des permissions | Définie par intégration, souvent revue | Souvent héritée des valeurs par défaut du serveur, facilement sur-dimensionnée |
| Auditabilité | Journalisation personnalisée par intégration | Appels standardisés, mais la journalisation doit encore être configurée |
| Risque de supply chain | Limité aux dépendances choisies | Tout serveur installable devient une dépendance potentielle |
MCP rend trivial l’ajout de nouveaux serveurs, et chacun étend la frontière. De nombreux pilotes exécutent des serveurs locaux avec les paramètres par défaut — aucune authentification, aucun journal d’audit, aucun identifiant à portée limitée — ce qui convient pour une démo mais pas lorsque l’agent touche à de vraies données clients.
Incidents, vulnérabilités et motifs d’attaque de sécurité MCP documentés
Toutes les préoccupations de sécurité MCP ne sont pas identiques. Certaines sont des incidents réels confirmés. D’autres sont des vulnérabilités divulguées corrigées avant toute exploitation connue. D’autres encore sont des démonstrations de recherche. Cette section distingue les trois.
Incident confirmé : package npm malveillant postmark-mcp
En septembre 2025, un package npm tiers malveillant appelé postmark-mcp a usurpé Postmark, un service de délivrance d’emails. Il ne s’agissait pas d’un package Postmark officiel — Postmark n’avait pas publié son serveur MCP officiel sur npm avant cet incident. Selon l’avis de sécurité officiel de Postmark, le package a construit sa confiance sur 15 versions, puis a ajouté une backdoor dans la version 1.0.16 qui mettait secrètement en copie cachée (BCC) les emails sortants vers un serveur externe. L’analyse du package malveillant par Koi Security a rapporté environ 1 500 téléchargements hebdomadaires ; la destination BCC cachée attribuée à Koi Security était une adresse au domaine giftshop.club.
Il s’agissait d’un véritable package malveillant et d’un incident de supply chain logiciel, et non d’une compromission de la plateforme officielle de Postmark. L’API et les services légitimes de Postmark n’ont pas été compromis et sont restés non affectés. L’incident illustre le risque de supply chain, le risque de permissions excessives, l’échec de vérification des serveurs et le risque de changement de version. Le motif s’apparente à un rug-pull ; « rug pull » est utilisé ici comme description du motif, et non comme classification propre à Postmark.
Vulnérabilités divulguées : CVE-2025-66414 et CVE-2025-66416
Deux vulnérabilités divulguées dans les SDK officiels de MCP mettent en évidence des risques au niveau de l’implémentation. Ce sont des vulnérabilités d’implémentation divulguées, et non des brèches réelles confirmées, sans preuve publique d’exploitation en milieu naturel.
CVE-2025-66414 — SDK TypeScript. Avant la version 1.24.0, le SDK TypeScript de MCP n’activait pas la protection contre le DNS rebinding par défaut pour les serveurs HTTP. Lorsqu’un serveur s’exécutait sur localhost sans authentification en utilisant StreamableHTTPServerTransport ou SSEServerTransport, et que enableDnsRebindingProtection n’était pas activé, un site web malveillant pouvait contourner la politique de même origine et invoquer des outils ou ressources exposés. N’affecte pas le transport stdio. Corrigé dans la version 1.24.0. Voir l’avis GitHub pour CVE-2025-66414 et l’enregistrement NVD pour CVE-2025-66414.
CVE-2025-66416 — SDK Python. Avant la version 1.23.0, le SDK Python de MCP (mcp sur PyPI) n’activait pas la protection contre le DNS rebinding par défaut pour les serveurs HTTP. Lorsqu’un serveur s’exécutait sur localhost sans authentification en utilisant FastMCP avec HTTP streamable ou SSE, et que TransportSecuritySettings n’était pas configuré, un site web malveillant pouvait contourner la politique de même origine et invoquer des outils ou ressources exposés. N’affecte pas le transport stdio. Corrigé dans la version 1.23.0. Voir l’avis GitHub pour CVE-2025-66416 et l’enregistrement NVD pour CVE-2025-66416.
Les deux avis notent que l’exécution locale de serveurs MCP HTTP sans authentification n’est pas recommandée. Les configurations affectées sont spécifiques : le transport stdio et les serveurs authentifiés n’étaient pas affectés.
Démonstrations de recherche et motifs d’attaque théoriques
Des chercheurs en sécurité ont démontré des motifs d’attaque illustrant comment MCP peut être abusé. Ce sont des preuves de concept, et non des incidents réels confirmés. Les motifs d’attaque MCP documentés montrent que des instructions malveillantes peuvent être intégrées dans des descriptions d’outils visibles par le modèle mais non évidentes pour l’utilisateur, poussant l’agent à effectuer des actions que l’utilisateur n’a jamais approuvées. Ils montrent également comment un serveur initialement inoffensif pouvait ensuite introduire une injection de prompt indirecte via les données renvoyées, manipulant le comportement d’un agent sans exploiter directement le modèle.
Principaux risques de sécurité MCP en 2026
Empoisonnement d’outils et serveurs MCP malveillants
L’empoisonnement d’outils se produit lorsqu’un serveur intègre des instructions malveillantes dans des descriptions d’outils ou des métadonnées que le modèle lit mais que l’utilisateur ne voit pas. L’agent peut suivre ces instructions et effectuer des actions hors de l’intention de l’utilisateur. L’incident postmark-mcp est un cas confirmé de serveur malveillant usurpant un projet légitime.
Injection de prompt via les réponses des serveurs MCP
Un serveur MCP renvoie des données — contenus de fichiers, lignes de base de données, réponses d’API. Si ces données contiennent des instructions, l’agent peut les traiter comme des commandes. Comme l’agent fait confiance au serveur en tant que source de données, le contenu renvoyé devient une surface d’injection à moins que l’hôte ne le valide et ne l’isole. Pour un traitement plus approfondi, voir Sécurité LLM pour l’IA agentique.
Risques de rug-pull et de supply chain tierce
Un rug-pull se produit lorsqu’un serveur initialement sûr change de comportement après une mise à jour. Le risque de supply chain s’étend aux dépendances, aux packages transitifs et aux serveurs non maintenus. Les agents appellent les outils automatiquement et fréquemment, de sorte que le rayon d’impact d’un serveur compromis est plus large qu’une dépendance de bibliothèque typique.
Portées d’outils excessivement larges et exposition d’identifiants
Les serveurs se voient souvent accorder des permissions plus larges que nécessaire. Lorsque des identifiants transitent par un serveur compromis ou sur-permissionné, l’exposition s’étend à tout ce que ces identifiants peuvent atteindre. Le moindre privilège est le contrôle qui limite les dégâts lorsqu’un serveur dysfonctionne.
OAuth, validation de jetons et défaillances d’autorisation
L’autorisation MCP pour les serveurs distants HTTP suit les conventions OAuth 2.1, comme décrit dans le guide d’autorisation MCP. L’autorisation protège les ressources et opérations sensibles exposées par les serveurs MCP. OAuth n’est pas une garantie de sécurité automatique : les implémentations doivent valider l’audience, l’émetteur, l’expiration et les portées du jeton ; les jetons doivent être à courte durée et stockés de manière sécurisée ; les flux de production doivent utiliser HTTPS ; les identifiants, en-têtes d’autorisation, jetons et codes d’autorisation ne doivent pas être écrits dans les journaux ; et les portées fourre-tout doivent être évitées au profit de portées au moindre privilège par outil. MCP n’implémente pas OAuth de manière sécurisée pour les développeurs. Pour des conseils plus larges sur le passage de jetons, les risques de substitué confondu, SSRF et la minimisation des portées, voir les meilleures pratiques de sécurité MCP.
Meilleures pratiques de sécurité MCP
Vérifier et épingler chaque serveur MCP
Traitez tout serveur MCP comme un logiciel non fiable : confirmez que l’éditeur est officiel, examinez les permissions demandées, lisez le code source ou un audit de confiance, épinglez une version spécifique et privilégiez les serveurs d’organisations en lesquelles vous avez confiance. L’incident postmark-mcp en est l’exemple à méditer.
Appliquer le moindre privilège sur les portées d’outils
Accordez à chaque serveur l’accès minimal requis. Séparez les portées de lecture et d’écriture. Utilisez des identifiants à portée limitée plutôt que des jetons administrateur partagés. Si un serveur est compromis, les dégâts sont limités à la portée restreinte qui lui a été accordée.
Sandboxer et isoler l’exécution des serveurs MCP
Exécutez les serveurs MCP dans des environnements isolés — conteneurs, VMs ou segments réseau séparés — et non directement sur l’hôte. Ne partagez pas de systèmes de fichiers ou d’identifiants entre serveurs. Le sandboxing réduit le rayon d’impact, passant de « le serveur peut tout atteindre » à « le serveur ne peut atteindre que ce qui lui a été explicitement autorisé ».
Journalisation d’audit et observabilité des agents
Journalisez les identités authentifiées, les portées accordées, les appels d’outils, les entrées et sorties assainies, les décisions de politique, les événements d’approbation, les erreurs et les résultats finaux des actions. Les identifiants, jetons et données personnelles sensibles ne doivent pas apparaître dans les journaux. Le journal est ce qui permet à une équipe de reconstituer les événements, de prouver la conformité et de détecter les anomalies avant qu’elles ne deviennent des incidents.
Humain-dans-la-boucle pour les actions sensibles
Exigez une approbation humaine pour les actions à impact réel : écriture dans des bases de données de production, envoi d’emails externes, appels à des API payantes, modification d’enregistrements clients. Les seuils doivent être basés sur la classification des données — les données publiques peuvent ne nécessiter aucune approbation, tandis que les données confidentielles et restreintes exigent une validation explicite.
Cadre de gouvernance d’entreprise des AI agents
Politique, propriété et flux d’approbation
La gouvernance commence par une politique écrite : qui peut approuver un nouveau serveur MCP, quelle revue est requise, qui possède chaque déploiement d’agent. Sans propriété explicite, les développeurs installent des serveurs de manière ad hoc et les équipes sécurité ne les découvrent qu’après un incident. Un flux simple — proposer, examiner, approuver, déployer — arrête la plupart des risques de supply chain avant la production.
Classification des données et contrôles de résidence
Classifiez les données comme publiques, internes, confidentielles ou restreintes, et déterminez quelles classes un agent et ses serveurs peuvent toucher. Appliquez des contrôles de résidence lorsque requis : les données soumises aux réglementations européennes ou américaines ne doivent pas transiter par des serveurs hors de la région appropriée.
Alignement de l’usage de MCP avec ISO/IEC 27001:2022 et SOC 2
Les contrôles de sécurité MCP peuvent soutenir l’alignement avec ISO/IEC 27001:2022 et SOC 2, mais la mise en œuvre de ces contrôles seule n’établit pas la conformité. La vérification des serveurs correspond à la gestion des risques fournisseurs ; le moindre privilège correspond au contrôle d’accès ; la journalisation d’audit correspond à la supervision ; l’humain-dans-la-boucle correspond à la gestion des changements. La conformité complète nécessite le système de management global, l’évaluation des risques, l’audit interne et la certification externe.
Modèles d’architecture d’intégration IA sécurisée
Serveurs MCP locaux vs distants
Les serveurs locaux s’exécutent sur le même hôte — simples pour le développement, mais ils partagent le système de fichiers et le réseau, augmentant le rayon d’impact. Les serveurs distants s’exécutent séparément, peuvent être authentifiés et sont plus faciles à auditer. Distant n’est pas automatiquement plus sûr : un serveur distant non authentifié sur l’internet ouvert est pire qu’un serveur local correctement configuré. Les serveurs distants authentifiés sont souvent plus faciles à gouverner lorsqu’ils sont combinés avec la segmentation réseau, l’autorisation à portée limitée, le contrôle de sortie et la journalisation centralisée.
OAuth et connexions MCP authentifiées
L’autorisation MCP pour les serveurs distants HTTP suit les conventions OAuth 2.1. Utilisez des jetons à portée limitée, à courte durée et rotatifs, stockés de manière sécurisée. Validez l’audience, l’émetteur, l’expiration et les portées du jeton à chaque requête. N’écrivez pas les identifiants, en-têtes d’autorisation, jetons ou codes d’autorisation dans les journaux. Évitez les portées fourre-tout ; accordez des portées au moindre privilège par outil. Les flux de production doivent utiliser HTTPS. MCP n’implémente pas OAuth de manière sécurisée pour vous — voir le guide d’autorisation MCP et les meilleures pratiques de sécurité MCP pour les exigences au niveau du protocole et des conseils plus larges sur le passage de jetons, les risques de substitué confondu et la minimisation des portées.
Segmentation réseau et contrôles de sortie
Placez les serveurs MCP dans des sous-réseaux privés avec un contrôle de sortie maîtrisé. Restreignez le trafic sortant à une liste d’autorisation d’adresses IP et de domaines. Cela limite les chemins d’exfiltration si un serveur est compromis — le même principe que HDWEBSOFT utilise pour l’email sortant via une NAT Gateway avec liste d’autorisation IP. Pour un contexte plus large sur l’intégration IA sécurisée, voir nos services de développement IA et services de cybersécurité.
Un flux de déploiement MCP axé sur la sécurité
Un déploiement MCP défendable suit un flux reproductible : auditer le serveur (confirmer la source, examiner les permissions, lire le code), limiter les permissions (moindre privilège par outil, identifiants à portée limitée), isoler l’exécution (conteneur ou segment réseau séparé), observer le comportement (journaliser les identités, portées, appels d’outils, entrées/sorties assainies, décisions de politique, approbations, erreurs, résultats) et appliquer une supervision humaine (approbation pour les actions sensibles selon la classification des données).
HDWEBSOFT applique ce flux dans ses missions clients impliquant des AI agents et des données d’entreprise. En tant que partenaire de développement logiciel certifié ISO 9001 et ISO/IEC 27001, HDWEBSOFT traite la sécurité comme une porte de validation, et non comme une simple checklist finale. L’objectif n’est pas de ralentir les équipes ; c’est de s’assurer que lorsqu’un agent atteint la production, la couche MCP n’est pas ce qui casse.
Conclusion
MCP est la bonne direction pour connecter les AI agents aux données d’entreprise. Un protocole partagé vaut mieux qu’un enchevêtrement d’intégrations personnalisées. Mais la sécurité MCP n’est pas automatique. Chaque serveur est une frontière de confiance, chaque portée d’outil est un rayon d’impact potentiel, et chaque mise à jour est une occasion de changement de comportement. Les équipes qui livrent en toute sécurité vérifient les serveurs, appliquent le moindre privilège, isolent l’exécution, journalisent ce qui compte et maintiennent l’humain dans la boucle.
Si votre équipe connecte des AI agents à des données d’entreprise via MCP, l’étape à plus forte valeur ajoutée est une revue indépendante avant la production. Demandez un audit de sécurité et d’architecture IA pour identifier les failles dans la vérification des serveurs, les portées d’outils, l’autorisation, la journalisation et la gouvernance — et obtenir un plan de remédiation concret avant qu’un incident ne l’impose.
FAQ
Qu’est-ce que la sécurité MCP ?
La sécurité MCP est la pratique de protection des AI agents qui se connectent à des données et outils externes via le Model Context Protocol. Elle couvre la vérification des serveurs, les portées d’outils au moindre privilège, l’isolation de l’exécution, la journalisation d’audit, les contrôles humain-dans-la-boucle et la gouvernance d’entreprise des intégrations basées sur MCP.
Quels sont les risques de sécurité les plus courants des serveurs MCP ?
Les risques de sécurité MCP les plus courants incluent l’empoisonnement d’outils par des serveurs malveillants, l’injection de prompt transmise via les réponses des serveurs MCP, les attaques de type rug-pull et supply-chain tierces, les portées d’outils excessivement larges avec exposition d’identifiants, et les défaillances de validation OAuth ou des jetons dans les déploiements authentifiés.
Comment sécuriser un serveur MCP en production ?
Sécurisez un serveur MCP en production en vérifiant et en épinglant chaque serveur, en appliquant des portées d’outils au moindre privilège, en sandboxant l’exécution du serveur, en journalisant les identités authentifiées et les appels d’outils, en appliquant une approbation humain-dans-la-boucle pour les actions sensibles, et en alignant le déploiement avec la gouvernance d’entreprise et les contrôles de conformité.
Le Model Context Protocol est-il sûr pour les AI agents d’entreprise ?
MCP est sûr pour les AI agents d’entreprise lorsque les équipes traitent chaque serveur MCP comme une nouvelle frontière de confiance et appliquent des contrôles de sécurité explicites. MCP standardise la communication entre clients et serveurs, mais la confiance du serveur, l’autorisation, la validation des sorties et les contrôles d’exécution restent la responsabilité de l’hôte et du client.
Comment la sécurité MCP soutient-elle la conformité ISO/IEC 27001:2022 ou SOC 2 ?
Les contrôles de sécurité MCP peuvent soutenir l’alignement avec ISO/IEC 27001:2022 et SOC 2 en associant la vérification des serveurs, l’accès au moindre privilège, la journalisation d’audit et la gestion des risques fournisseurs aux catégories de contrôles existantes. La mise en œuvre de ces contrôles seule n’établit pas la conformité ; les organisations doivent également compléter le système de management global et les exigences d’audit.
Quand devons-nous réaliser un audit de sécurité et d’architecture IA ?
Réalisez un audit de sécurité et d’architecture IA avant de promouvoir un AI agent en production, après un incident de sécurité ou un quasi-incident, lors de la connexion d’agents à de nouvelles sources de données sensibles, et chaque fois qu’un nouveau serveur MCP est introduit dans un flux de production.
