MCP Server Protection devient une catégorie de produit : le test buy-vs-build des 12 contrôles

Le 14 octobre 2026, Radware (NASDAQ: RDWR) a lancé Model Context Protocol (MCP) Server Protection — le premier produit de défense MCP conçu sur mesure issu d'un fournisseur de sécurité réseau coté. Le lancement cite le State of Model Context Protocol in Software 2026 de Stacklok comme cadre de marché : près de la moitié des entreprises de logiciels interrogées font tourner des serveurs MCP en production, 19 % en production large. Un fournisseur coté ne produit pas une surface de sécurité vide. Dans le même temps, le registre des attaques s'allonge : le propre MCP Server de Splunk a divulgué CVE-2026-76286 en octobre — une SSRF qui remet le jeton d'authentification Splunk de l'utilisateur à toute URL vers laquelle pointe la configuration de l'outil personnalisé. La question des responsables d'ingénierie n'est donc plus « devons-nous durcir nos serveurs MCP » — la check-list des 12 contrôles y a déjà répondu. La question est désormais : qu'acheter de la protection MCP ferme-t-il réellement, et que laisse-t-il ouvert ?

Cet article mappe les cinq groupes de capacités annoncés de Radware sur la référence des 12 contrôles. Le décompte : 3 contrôles se ferment au bord du réseau, 5 obtiennent une couverture partielle, et 4 — les contrôles de couche application qui décident si une brèche est bruyante ou silencieuse — restent à construire par vous-même, dans chaque déploiement, avec ou sans le produit. La matrice de décision qui suit est le livrable.

Deux marqueurs d'honnêteté avant la matrice, car tous deux comptent pour la lecture. D'abord, les capacités du produit sont des affirmations d'intention de design tirées d'un communiqué — chacune est formulée comme « conçu pour », et le webinar du 3 décembre de Radware est le lieu de vérification, pas l'annonce. Ensuite, le mappage ci-dessous porte sur la liste de capacités annoncée : une hypothèse testable sur ce qu'un produit de couche réseau peut voir, pas une revue des comportements livrés. Faites courir votre propre trafic contre votre propre preuve de durcissement avant d'ajouter n'importe quel produit à un bon de commande.

Points clés

• Radware (NASDAQ: RDWR) a lancé le 14 octobre 2026 une MCP Server Protection conçue sur mesure — le premier produit de défense MCP d'un fournisseur de sécurité réseau coté, citant l'enquête State of MCP 2026 de Stacklok : près de la moitié des entreprises de logiciels font tourner des serveurs MCP en production, 19 % en production large.
• Splunk a divulgué CVE-2026-76286 dans son propre MCP Server le 7 octobre 2026 (CWE-918, CVSS 5.3, corrigé en 1.2.1) — une SSRF qui envoie le jeton de plateforme de l'utilisateur en cours d'exécution vers l'URL configurée d'un outil API personnalisé ; il rejoint un registre qui détient déjà le premier CVSS 10.0 de l'écosystème (CVE-2026-16496) et deux inscriptions CISA KEV.
• Face à la référence de durcissement des 12 contrôles, un produit MCP de couche réseau ferme 3 contrôles — isolation réseau, flooding et DoS, découverte des serveurs fantômes — et laisse 4 contrôles de couche application (provenance, durcissement STDIO, frontière de contexte, kill switch) à l'opérateur, dans chaque déploiement.
• Les 5 lignes partielles sont de la détection, pas de l'exécution — la détection des attaques d'authentification, la surveillance d'identité d'agents et la télémétrie d'audit au point réseau ne remplacent pas le déploiement OAuth, le cycle de vie des identités, ni le registre d'audit immuable par appel.
• Les 12 contrôles font aussi office de RFP — la liste annoncée de Radware revendique la visibilité sur les outils et ressources exposés mais pas la détection de drift de tools/list, si bien que le contrôle fingerprint-and-diff qui attrape le poisoning de métadonnées de classe Deadbugz reste sur la liste de construction de l'opérateur.

Un fournisseur coté construit là où la demande est mesurable

Les catégories de produits de sécurité se forment quand quatre préconditions sont réunies en même temps : les risques sont énumérés, les attaques sont spécifiques, les incidents ont des noms, et la demande est mesurable. Ce mois-ci, MCP a franchi les quatre lignes d'un coup :

• Les risques sont énumérés. Le OWASP MCP Top 10 catalogue dix catégories nommées — de Token Mismanagement à Context Injection et Over-Sharing — en Beta v0.1.
• Les attaques sont spécifiques. Quatre classes d'attaque communautaires sont documentées avec un détail de niveau production : l'injection de commandes STDIO (OX Security, plus de 150M de téléchargements touchés), la porte dérobée MCP de Postmark (tool poisoning dans un paquet npm d'apparence légitime), le contournement du SHA-pinning, et le poisoning de métadonnées à porte d'exécution Deadbugz (23 pull requests en 74 minutes, définitions d'outils malveillantes qui n'apparaissent qu'après trois appels de confiance).
• Les incidents ont des noms et des numéros. CVE-2026-16496 a mis le premier CVSS 10.0 dans l'écosystème — un contournement de détournement de session dans le transport avec état du Terraform MCP Server. Deux CVE adjacents à MCP ont atteint le catalogue des Vulnérabilités Exploitées Connues de CISA, le second (CVE-2026-59822, CVSS 8.8) avec une échéance fédérale de remédiation au 16 septembre. Splunk a divulgué CVE-2026-76286 dans son propre MCP Server le 7 octobre, corrigé en 1.2.1. AgentCorruption de Zenity a montré le rayon d'impact de la plateforme gérée : une seule invite à un agent public a exposé des identifiants qui ont atteint tous les agents du compte AWS.
• La demande est mesurée. L'enquête de Stacklok place l'adoption là où les fournisseurs peuvent dimensionner un marché : près de la moitié des entreprises de logiciels interrogées en production, 19 % en production large — devant les cohortes de services financiers et de retail qu'elle a interrogées par la même méthode.

Les chiffres issus des scans ferment la boucle de l'urgence : 1,467 serveurs MCP publiquement accessibles sans aucune authentification (comptage corrigé de Trend Micro, 1,227 sur le transport SSE déprécié) et 82 % d'exposition path-traversal avec 8,5 % d'adoption OAuth sur 2,614 serveurs interrogés (Practical DevSecOps). Le CTO de Radware, David Aviv, a formulé la thèse du produit en une phrase : « Les organisations doivent savoir quels serveurs MCP elles ont, ce que ces serveurs exposent, quels agents les accèdent et si ces interactions sont sûres. » Cette phrase est, presque mot pour mot, les contrôles d'inventaire et de surveillance de drift de la check-list — désormais un pitch de produit.

Ce que le produit revendique — cinq groupes de capacités

L'annonce place Radware MCP Server Protection à côté de ses lignes existantes Agentic AI Protection et LLM Firewall, déployable comme service cloud (Cloud Application Protection Service) ou on-premises augmenté par le cloud sur Alteon et DefensePro, couvrant cloud public, cloud privé, Kubernetes et centres de données à base de matériel. Cinq groupes de capacités sont revendiqués :

1. Visibilité de surface d'attaque MCP — serveurs déployés, outils et ressources exposés, activité des agents, schémas d'usage, flux de communication.
2. Protection des attaques conscientes de MCP — abus de protocole, attaques d'authentification, énumération d'outils et de ressources, interactions MCP non autorisées, flooding d'outils piloté par l'IA, déni de service.
3. Gouvernance — évaluation de l'exposition, identification des faiblesses, application de politiques à l'échelle.
4. Surveillance de l'activité des agents — identités d'agents, schémas d'invocation d'outils, anomalies comportementales, tendances de consommation de ressources.
5. Souplesse de déploiement — service cloud, ou on-premises augmenté par le cloud sur Alteon et DefensePro.

Lisez cette liste contre le registre des attaques et la correspondance est réelle mais partielle. Le groupe de protection (2) nomme exactement les surfaces d'attaque visibles sur le fil : abus de protocole, énumération, flooding, déni de service — les mêmes classes que l'article MCP Paradox remonte au design frictionless du protocole. Ce qui manque à la liste est tout aussi informatif : rien ne revendique la détection de drift des définitions d'outils (la classe Deadbugz), rien ne revendique la provenance des paquets, rien ne revendique l'application de la fenêtre de contexte, rien ne revendique le kill switch. Ce sont les contrôles qui vivent avant et à l'intérieur du module — et ce sont ceux que la matrice de cet article note comme la charge de l'opérateur.

La CVE Splunk montre pourquoi la distinction importe en pratique. CVE-2026-76286 est un défaut de configuration d'outil : le MCP Server a envoyé le jeton d'authentification de plateforme de l'utilisateur en cours d'exécution vers l'URL configurée pour cet outil — et si un autre utilisateur contrôlait cette URL, il capturait le jeton et agissait comme l'utilisateur. Un contrôle réseau peut signaler la tentative de sortie après coup ; la correction est une règle de configuration déjà présente dans la référence des 12 contrôles — le serveur valide et possède chaque URL configurée par outil, et l'egress du module est borné avant que le jeton ne bouge (CWE-918, CVSS 5.3, corrigé en 1.2.1). La détection au bord et l'application dans la configuration sont deux contrôles différents, et un seul des deux empêche le jeton de sortir.

Le test buy-vs-build des 12 contrôles

La matrice ci-dessous est le livrable de travail de l'article. Le statut est noté contre les cinq groupes de capacités annoncés : Ferme signifie que la capacité annoncée couvre la classe d'attaque du contrôle au bord du réseau ; Partiel signifie que le produit voit ou détecte la surface pendant que l'application, le cycle de vie ou le registre autoritaire reste avec l'opérateur ; Non couvert signifie que la surface du contrôle est invisible à un outil de couche réseau par construction — pas nécessairement par la faute d'un produit quelconque.

#	Contrôle	Ce que le produit peut revendiquer couvrir	Statut	Ce qui reste avec vous
1	Migration SSE → Streamable HTTP	L'inventaire marque les serveurs SSE dépréciés	Partiel	La migration elle-même — un changement d'architecture, pas une règle de filtre
2	Isolation réseau et validation d'origine	Application de la frontière en L3–L7 (le terrain du fournisseur)	Ferme	La validation Host/Origin dans le SDK reste en couche application
3	Application d'OAuth 2.1 + OIDC	Détection des attaques d'authentification, des interactions non autorisées	Partiel	Émission de jetons, scopes, liaison d'audience RFC 8707 — le déploiement est à vous
4	Séparation d'identité des agents	Surveillance d'identité d'agents, anomalies comportementales	Partiel	Provisioning, attestation, cycle de vie de révocation (SCIM/SPIFFE) est à vous
5	Scan de tool poisoning / détection de drift	Abus de protocole et énumération sur le fil	Partiel	Scans au moment de l'approbation et fingerprinting post-installation de tools/list (classe Deadbugz) restent à vous
6	Provenance signée et AIBOM	—	Non couvert	Registre et chaîne d'approvisionnement npm : des attaques qui atterrissent avant que le serveur ne parle
7	Durcissement STDIO	—	Non couvert	Transport localhost entre client et sous-processus ; pas de trafic filaire à inspecter
8	Limitation de débit (flooding / DoS)	Flooding d'outils piloté par l'IA, déni de service	Ferme	Limites par outil et par agent au niveau du module, au-delà de la frontière
9	Frontière de contexte (OWASP MCP10)	—	Non couvert	Ce que le modèle lit dans la session n'est pas une donnée réseau
10	Kill-switch par module	—	Non couvert	Votre feature flag ; un blocage réseau est le confinement de dernier recours
11	Journal d'audit par appel	Télémétrie de flux et d'anomalies au point réseau	Partiel	Le JSON immuable autoritaire par appel — avec hachages d'entrée — est à vous
12	Détection de serveurs fantômes	Découverte de surface d'attaque des serveurs déployés	Ferme	Le vetting du registre et la politique de drift qui définissent « connu-bon »

Tally : 3 fermés, 5 partiels, 4 non couverts. La même structure vaut pour chaque fournisseur de cette catégorie émergente, car la répartition n'est pas une limitation du produit — c'est une frontière architecturale. La conclusion d'UpGuard selon laquelle un serveur MCP sur quinze est une imitation « lookalike » est invisible pour une frontière réseau si le lookalike est côté npm ; la charge utile Deadbugz arrive dans des réponses MCP légitimes qu'une sonde peut voir mais pas juger sémantiquement ; et la fenêtre de contexte du modèle est derrière chaque frontière qu'un produit réseau peut appliquer.

La matrice en une vue : trois bandes de couverture, les chiffres de marché derrière elles, et la règle RFP que le visuel porte :

Acheter les partiels reste rationnel — si vous les notez honnêtement

Les 5 lignes partielles sont là où les conversations d'achat dérivent. « Détection d'attaques d'authentification » ne signifie pas qu'OAuth 2.1 est déployé, et la surveillance d'identité d'agents ne signifie pas que les identités sont révocabiles. Les partiels ont une vraie valeur — la détection sans application est un fil de détresse, et un inventaire réseau qui fait sortir des serveurs que vous n'avez pas enregistrés est le recensement shadow-MCP le plus rapide que vous puissiez acheter. Notez-les comme couverture de détection, pas comme fermeture de contrôle :

• Les partiels C1/C3/C4 ne deviennent des contrôles complets que quand le travail de l'opérateur lui-même advient — la migration de transport, le déploiement OAuth, le cycle de vie des identités. La surveillance peut alimenter la file de remédiation ; elle ne peut pas être la remédiation.
• Le partiel C5 mérite une question RFP spécifique, car c'est la brèche de plus forte conséquence : le produit peut-il faire le diff des réponses tools/list d'un serveur dans le temps et alerter sur un drift sémantique ? L'annonce nomme la visibilité sur les outils et ressources exposés — elle ne revendique pas la détection de drift, et Deadbugz est conçu pour battre toute revue qui s'arrête avant un quatrième appel non diffé.
• Le partiel C11 coupe dans les deux sens : la télémétrie du point réseau alimente la détection d'anomalies que le module ne peut pas voir, mais le registre d'audit autoritaire — horodatage, ID d'agent, outil, hachage d'entrée, statut de sortie — doit être structuré, immuable, et sous votre contrôle. AgentCorruption est le contre-exemple qui tranche le pourquoi : après qu'un rôle par défaut de plateforme a exposé tous les agents du compte, « quel agent, quel outil, dont l'entrée » n'a pu être répondu qu'à partir des journaux que l'opérateur possédait.

La frontière buy-vs-build

Quatre règles se dégagent de la matrice :

1. Achetez la couche réseau quand votre exposition a la forme du réseau. Flooding, énumération, abus de protocole et une population de serveurs inconnue sont des problèmes visibles sur le fil, et un fournisseur issu du DDoS/WAF les opère comme un service. Si vous faites tourner un parc multi-locataires et multi-équipes d'agents sur une infrastructure partagée, cette couche est probablement la spécialité de quelqu'un d'autre.
2. Possédez les quatre contrôles de couche application quel que soit l'achat. Provenance (C6), durcissement STDIO (C7), bornage du contexte (C9) et le kill switch (C10) ne figurent cette semaine sur la liste revendiquée d'aucun fournisseur réseau, et ne s'achètent pas comme une gamme de produits du tout — ce sont des propriétés de la façon dont vos modules sont construits et opérés. Le MCP Module Code Standard est la référence côté construction pour les rendre applicables dans le module lui-même.
3. Transformez les 12 contrôles en RFP. Demandez à tout fournisseur potentiel de sécurité MCP des preuves face à la matrice, pas des affirmations : une démonstration de détection de drift contre le schéma Deadbugz, un enregistrement d'audit d'échantillon correspondant à votre schéma, et la portée exacte de « gouvernance » — application sur quoi, appliquée où. Ce que le fournisseur prouve se ferme ; ce qu'il ne peut pas reste sur votre liste de construction.
4. La moitié construction a une référence gratuite. Le Microsoft Agent Governance Toolkit livre une couverture 10/10 du OWASP MCP Top 10 (7 complète, 3 partielle avec feuille de route) comme runtime open-source — le complément non commercial d'un périmètre commercial. Le modèle de notation de la check-list (12/12 prêt pour la production ; en dessous de 8, ne pas exposer à la production) est la porte d'acceptation des deux moitiés.

Le motif se généralise au-delà de Radware : la vague Black Hat 2026 a déjà apporté la découverte de serveurs fantômes (Cyera Agent Guardian), la gouvernance d'identité (SailPoint) et la surveillance au niveau réseau (Check Point AI Network Firewall) — couverts dans le journal des mises à jour de la check-list parente — et des fournisseurs de passerelle comme TrueFoundry portent la moitié gouvernance. L'entrée de Radware met un fournisseur coté derrière le produit conçu sur mesure. La convergence de la catégorie est l'affaire du marché dorénavant ; les quatre contrôles qu'un produit réseau ne peut pas voir demeurent ceux de l'opérateur.

Lectures connexes

• Check-list de durcissement MCP : 1,467 serveurs exposés et les contrôles qui les ferment — l'article parent : les 12 contrôles sur cinq couches contre lesquels la matrice de cet article teste, plus le journal des mises à jour des CVE, inscriptions KEV et classes d'attaque.
• Le rôle par défaut, pas le modèle : comment une seule invite a pris le contrôle de tous les agents d'un compte AWS — l'incident de plateforme gérée qui définit l'exigence d'audit côté opérateur : un rôle d'exécution par défaut de plateforme, à la portée du compte entier, a défini le rayon d'impact.
• Deadbugz : la quatrième classe d'attaque MCP se cache jusqu'à ce que vous fassiez confiance — la classe de poisoning de métadonnées à porte d'exécution derrière la question RFP C5 de cet article : les scans au moment de l'approbation ne la voient pas, fingerprint-and-diff oui.

---

Une construction représentative : un distributeur de taille intermédiaire exposant un module MCP en production — un lecteur de catalogue NetSuite et un générateur de devis avec écriture retour dans l'ERP. La couche réseau (sous la forme de produit en laquelle le parc fait déjà confiance) découvre le module, surveille le trafic des agents et retient le flooding à la frontière. Les quatre contrôles de couche application sont construits dans le module avant le premier appel d'outil : provenance signée de l'artefact, aucun chemin contrôlé par l'utilisateur dans STDIO, contexte borné par outil, kill switch exercé une fois en staging. La phase Discovery d'une semaine produit l'inventaire des serveurs et la carte de score des 12 contrôles qui transforme la liste de capacités de n'importe quel fournisseur — celui-ci ou le suivant — en une réponse RFP vérifiable plutôt qu'une diapositive.

Discovery d'une semaine. Vous obtenez un inventaire de systèmes, une carte de flux de travail et un périmètre fixe — que vous construisiez avec nous ou non.