MCP Server Protection ya es una categoría de producto: la prueba buy-vs-build de 12 controles

El 14 de octubre de 2026, Radware (NASDAQ: RDWR) lanzó Model Context Protocol (MCP) Server Protection — el primer producto de defensa MCP construido a propósito de un proveedor de seguridad de red cotizado en bolsa. El lanzamiento cita State of Model Context Protocol in Software 2026 de Stacklok como su marco de mercado: casi la mitad de las empresas de software encuestadas ejecutan servidores MCP en producción, y un 19% en producción amplia. Un proveedor cotizado no productiza una superficie de seguridad que esté vacía. Al mismo tiempo, el registro de ataques sigue llenándose: el propio MCP Server de Splunk publicó CVE-2026-76286 en octubre — un SSRF que entrega el token de autenticación de Splunk del usuario a la URL a la que apunte la configuración de la herramienta personalizada. Así que la pregunta para los líderes de ingeniería ya no es «¿debemos endurecer nuestros servidores MCP?» — el checklist de 12 controles ya zanjó eso. La pregunta es ahora: qué cierra realmente comprar protección MCP, y qué deja abierto.

Este artículo mapea los cinco grupos de capacidades anunciados por Radware contra la línea base de 12 controles. El recuento: 3 controles se cierran en el borde de red, 5 obtienen cobertura parcial y 4 — los controles de capa de aplicación que deciden si una brecha es ruidosa o silenciosa — siguen siendo suyos para construir, en cada despliegue, con o sin el producto. La matriz de decisión de abajo es el artefacto.

Dos marcadores de honestidad antes de la matriz, porque ambos importan al leerla. Primero, las capacidades del producto son afirmaciones de intención de diseño procedentes de un comunicado de prensa — cada una se formula como «diseñado para», y el webinar del 3 de diciembre de Radware es el lugar de verificación, no el anuncio. Segundo, el mapeo de abajo es contra la lista de capacidades anunciada; es una hipótesis comprobable sobre lo que un producto de capa de red puede ver, no una revisión del comportamiento entregado. Ejecute su propio tráfico contra su propia evidencia de endurecimiento antes de añadir el producto de nadie a una orden de compra.

Conclusiones clave

• Radware (NASDAQ: RDWR) lanzó el 14 de octubre de 2026 una MCP Server Protection construida a propósito — el primer producto de defensa MCP de un proveedor de seguridad de red cotizado, citando la encuesta State of MCP 2026 de Stacklok: casi la mitad de las empresas de software ejecutan servidores MCP en producción, un 19% en producción amplia.
• Splunk divulgó CVE-2026-76286 en su propio MCP Server el 7 de octubre de 2026 (CWE-918, CVSS 5.3, corregido en 1.2.1) — un SSRF que envía el token de plataforma del usuario en ejecución a la URL configurada de una herramienta API personalizada; se une a un registro que ya contiene el primer CVSS 10.0 del ecosistema (CVE-2026-16496) y dos listados en CISA KEV.
• Contra la línea base de endurecimiento de 12 controles, un producto MCP de capa de red cierra 3 controles — aislamiento de red, flooding y DoS, descubrimiento de servidores sombra — y deja 4 controles de capa de aplicación (procedencia, endurecimiento STDIO, frontera de contexto, kill switch) al operador en cada despliegue.
• Las 5 filas parciales son detección, no aplicación — la detección de ataques de autenticación, la monitorización de identidad de agentes y la telemetría de auditoría en el punto de red no sustituyen el despliegue de OAuth, el ciclo de vida de identidades ni el registro de auditoría inmutable por llamada.
• Los 12 controles doblan como el RFP — la lista anunciada de Radware afirma visibilidad de herramientas y recursos expuestos pero no detección de drift de tools/list, así que el control de fingerprint-and-diff que atrapa el envenenamiento de metadata clase Deadbugz sigue en la lista de construcción del operador.

Un proveedor cotizado construye donde están las afirmaciones de demanda

Las categorías de productos de seguridad se forman cuando cuatro precondiciones se cumplen a la vez: los riesgos están enumerados, los ataques son específicos, los incidentes tienen nombre y la demanda es medible. MCP cruzó las cuatro líneas a la vez este mes:

• Los riesgos están enumerados. El OWASP MCP Top 10 cataloga diez categorías con nombre — de Token Mismanagement a Context Injection y Over-Sharing — en Beta v0.1.
• Los ataques son específicos. Cuatro clases de ataque comunitarias están documentadas con detalle de producción: la inyección de comandos STDIO (OX Security, más de 150M de descargas afectadas), la puerta trasera del MCP de Postmark (tool poisoning en un paquete npm de aspecto legítimo), el bypass de SHA-pinning y el envenenamiento de metadata runtime-gated Deadbugz (23 pull requests en 74 minutos, definiciones de herramienta maliciosas que solo aparecen tras tres llamadas de confianza).
• Los incidentes tienen nombre y número. CVE-2026-16496 puso el primer CVSS 10.0 del ecosistema — un bypass de secuestro de sesión en el transporte con estado del Terraform MCP Server. Dos CVE adyacentes a MCP alcanzaron el catálogo de Vulnerabilidades Explotadas Conocidas de CISA, el segundo (CVE-2026-59822, CVSS 8.8) con una fecha límite federal de remediación del 16 de septiembre. Splunk divulgó CVE-2026-76286 en su propio MCP Server el 7 de octubre, corregido en 1.2.1. El AgentCorruption de Zenity mostró el radio de impacto de la plataforma gestionada: un prompt a un agente público expuso credenciales que alcanzaron cada agente de la cuenta de AWS.
• La demanda está medida. La encuesta de Stacklok sitúa la adopción donde los proveedores pueden dimensionar un mercado: casi la mitad de las empresas de software encuestadas en producción, un 19% en producción amplia — por delante de las cohortes de servicios financieros y retail que encuestó con el mismo método.

Los números de escaneo cierran el círculo de la urgencia: 1,467 servidores MCP públicamente accesibles sin autenticación (recuento corregido de Trend Micro, 1,227 en el transporte SSE obsoleto) y 82% de exposición path-traversal con 8.5% de adopción OAuth entre 2,614 servidores encuestados (Practical DevSecOps). El CTO de Radware, David Aviv, formuló la tesis del producto en una frase: «Las organizaciones necesitan saber qué servidores MCP tienen, qué exponen esos servidores, qué agentes los acceden y si esas interacciones son seguras». Esa frase es, casi palabra por palabra, los controles de inventario y de monitoreo de drift del checklist — ahora un pitch de producto.

Lo que afirma el producto — cinco grupos de capacidades

El anuncio sitúa Radware MCP Server Protection junto a sus líneas existentes Agentic AI Protection y LLM Firewall, desplegable como servicio en la nube (Cloud Application Protection Service) u on-premises aumentado por nube sobre Alteon y DefensePro, en nube pública, nube privada, Kubernetes y centros de datos basados en hardware. Se afirman cinco grupos de capacidades:

1. Visibilidad de superficie de ataque MCP — servidores desplegados, herramientas y recursos expuestos, actividad de agentes, patrones de uso, flujos de comunicación.
2. Protección de ataques MCP-aware — abuso de protocolo, ataques de autenticación, enumeración de herramientas y recursos, interacciones MCP no autorizadas, flooding de herramientas impulsado por IA, denegación de servicio.
3. Gobernanza — evaluación de exposición, identificación de debilidades, aplicación de políticas a escala.
4. Monitorización de actividad de agentes — identidades de agentes, patrones de invocación de herramientas, anomalías de comportamiento, tendencias de consumo de recursos.
5. Flexibilidad de despliegue — servicio en la nube, u on-premises aumentado por nube sobre Alteon y DefensePro.

Lea esa lista contra el registro de ataques y la coincidencia es real pero parcial. El grupo de protección (2) nombra exactamente las superficies de ataque visibles en el cable: abuso de protocolo, enumeración, flooding, denegación de servicio — las mismas clases que el artículo MCP Paradox rastrea hacia el diseño frictionless del protocolo. Lo que falta en la lista es igualmente informativo: nada afirma detección de drift de definiciones de herramienta (la clase Deadbugz), nada afirma procedencia de paquetes, nada afirma enforcement de la ventana de contexto, nada afirma el kill switch. Esos son los controles que viven antes y dentro del módulo — y son los que la matriz de este artículo puntúa como trabajo del operador.

El CVE de Splunk muestra por qué la distinción importa en la práctica. CVE-2026-76286 es un defecto de configuración de herramienta: el MCP Server envió el token de autenticación de plataforma del usuario en ejecución a la URL configurada para esa herramienta — y si otro usuario controlaba esa URL, capturaba el token y actuaba como el usuario. Un control de red puede señalar el intento de salida después del hecho; la corrección es una regla de configuración que ya estaba en la línea base de 12 controles — el servidor valida y posee cada URL configurada por herramienta, y el egress del módulo se acota antes de que el token se mueva (CWE-918, CVSS 5.3, parcheado en 1.2.1). Detección en el borde y aplicación en la configuración son controles diferentes, y solo uno de ellos evita que el token salga.

La prueba buy-vs-build de 12 controles

La matriz de abajo es el artefacto de trabajo del artículo. El estado se puntúa contra los cinco grupos de capacidades anunciados: Cierra significa que la capacidad anunciada cubre la clase de ataque del control en el borde de red; Parcial significa que el producto ve o detecta la superficie mientras la aplicación, el ciclo de vida o el registro autoritativo quedan con el operador; No cubierto significa que la superficie del control es invisible para una herramienta de capa de red por construcción — no necesariamente por culpa de ningún producto específico.

#	Control	Lo que el producto puede afirmar cubrir	Estado	Lo que queda con usted
1	Migración SSE → Streamable HTTP	El inventario marca servidores con SSE obsoleto	Parcial	La migración misma — un cambio de arquitectura, no una regla de filtro
2	Aislamiento de red y validación de origen	Enforcement de frontera en L3–L7 (el terreno del proveedor)	Cierra	La validación de Host/Origin dentro del SDK sigue en la capa de aplicación
3	Enforcement de OAuth 2.1 + OIDC	Detección de ataques de autenticación, interacciones no autorizadas	Parcial	Emisión de tokens, scopes, binding de audiencia RFC 8707 — el despliegue es suyo
4	Separación de identidad de agentes	Monitorización de identidad de agentes, anomalías de comportamiento	Parcial	Aprovisionamiento, atestación, ciclo de vida de revocación (SCIM/SPIFFE) es suyo
5	Escaneo de tool poisoning / detección de drift	Abuso de protocolo y enumeración en el cable	Parcial	Escaneos en tiempo de aprobación y fingerprinting post-instalación de tools/list (clase Deadbugz) siguen suyos
6	Procedencia firmada y AIBOM	—	No cubierto	Registro y cadena de suministro npm: ataques que aterrizan antes de que el servidor hable
7	Endurecimiento STDIO	—	No cubierto	Transporte localhost entre cliente y subproceso; sin tráfico de cable que inspeccionar
8	Rate limiting (flooding / DoS)	Flooding de herramientas por IA, denegación de servicio	Cierra	Límites por herramienta y por agente a nivel de módulo más allá de la frontera
9	Frontera de contexto (OWASP MCP10)	—	No cubierto	Lo que el modelo lee dentro de la sesión no son datos de red
10	Kill-switch por módulo	—	No cubierto	Su feature flag; un bloqueo de red es contención de último recurso
11	Registro de auditoría por llamada	Telemetría de flujo y anomalías en el punto de red	Parcial	El JSON inmutable autoritativo por llamada — con hashes de entrada — es suyo
12	Detección de servidores sombra	Descubrimiento de superficie de ataque de servidores desplegados	Cierra	El vetting de registro y la política de drift que definen «conocido-bueno»

Recuento: 3 cierran, 5 parciales, 4 no cubiertos. La misma estructura se sostiene para cada proveedor de esta categoría emergente, porque la división no es una limitación del producto — es una frontera arquitectónica. El hallazgo de UpGuard de que uno de cada 15 servidores MCP es una suplantación lookalike es invisible para una frontera de red si el lookalike está del lado npm; el payload Deadbugz llega dentro de respuestas MCP legítimas que un monitor puede ver pero no juzgar semánticamente; y la ventana de contexto del modelo está detrás de cada frontera que un producto de red puede aplicar.

La matriz en una vista: tres bandas de cobertura, los números de mercado detrás de ellas, y la regla RFP que la imagen lleva:

Comprar los parciales sigue siendo racional — si los puntúa con honestidad

Las 5 filas parciales son donde se desvían las conversaciones de procurement. «Detección de ataques de autenticación» no significa que OAuth 2.1 esté desplegado, y la monitorización de identidad de agentes no significa que las identidades de agentes sean revocables. Los parciales son valor real — la detección sin aplicación es un tripwire, y un inventario de red que encuentra servidores que no registró es el censo shadow-MCP más rápido que puede comprar. Puntúelos como cobertura de detección, no como cierre de control:

• Los parciales C1/C3/C4 se convierten en controles completos solo cuando ocurre el trabajo del propio operador — la migración de transporte, el despliegue OAuth, el ciclo de vida de identidades. La monitorización puede alimentar la cola de remediación; no puede ser la remediación.
• El parcial C5 merece una pregunta RFP específica, porque es la brecha de mayor consecuencia: ¿puede el producto hacer diff de las respuestas tools/list de un servidor a lo largo del tiempo y alertar sobre drift semántico? El anuncio nombra visibilidad de herramientas y recursos expuestos — no afirma la detección de drift, y Deadbugz está diseñado para derrotar cada revisión que se detiene antes de una cuarta llamada sin diff.
• El parcial C11 corta en ambas direcciones: la telemetría del punto de red alimenta la detección de anomalías que el módulo no puede ver, pero el registro de auditoría autoritativo — timestamp, ID de agente, herramienta, hash de entrada, estado de salida — debe ser estructurado, inmutable y bajo su control. AgentCorruption es el contraejemplo que zanja el porqué: después de que un rol por defecto de la plataforma expusiera cada agente de la cuenta, «qué agente, qué herramienta, entrada de quién» tuvo que responderse desde logs que el operador poseía.

La frontera buy-vs-build

Cuatro reglas se desprenden de la matriz:

1. Compre la capa de red cuando su exposición tenga forma de red. Flooding, enumeración, abuso de protocolo y una población de servidores desconocida son problemas visibles en el cable, y un proveedor con linaje DDoS/WAF los opera como servicio. Si ejecuta parques multi-inquilino y multi-equipo de agentes sobre infraestructura compartida, esa capa probablemente es la competencia central de otra persona.
2. Posea los cuatro controles de capa de aplicación independientemente de la compra. Procedencia (C6), endurecimiento STDIO (C7), acotamiento de contexto (C9) y el kill switch (C10) no están en la lista afirmada de ningún proveedor de red esta semana, y no son comprables como línea de producto — son propiedades de cómo se construyen y operan sus módulos. El MCP Module Code Standard es la referencia del lado de la construcción para hacerlos aplicables en el propio módulo.
3. Convierta los 12 controles en el RFP. Pida a cualquier proveedor prospectivo de seguridad MCP evidencia contra la matriz, no afirmaciones: una demostración de detección de drift contra el patrón Deadbugz, un registro de auditoría de muestra que coincida con su esquema, y el alcance exacto de «gobernanza» — aplicación sobre qué, aplicada dónde. Lo que el proveedor evidencia, cierra; lo que no puede, queda en su lista de construcción.
4. La mitad de construcción tiene una referencia gratuita. El Microsoft Agent Governance Toolkit incluye cobertura 10/10 del OWASP MCP Top 10 (7 completa, 3 parcial con roadmap) como runtime open-source — el complemento no comercial de un perímetro comercial. El modelo de puntuación del checklist (12/12 production-ready; por debajo de 8, no exponer a producción) es la puerta de aceptación para ambas mitades.

El patrón se generaliza más allá de Radware: la ola Black Hat 2026 ya trajo descubrimiento de servidores sombra (Cyera Agent Guardian), gobernanza de identidades (SailPoint) y monitorización de capa de red (Check Point AI Network Firewall) — cubiertos en el registro de actualizaciones del checklist padre — y proveedores de gateway como TrueFoundry llevan la mitad de gobernanza. La entrada de Radware pone un proveedor cotizado detrás del producto construido a propósito. La convergencia de la categoría es el trabajo del mercado de aquí en adelante; los cuatro controles que un producto de red no puede ver siguen siendo del operador.

Lecturas relacionadas

• Lista de comprobación de endurecimiento MCP: 1.467 servidores expuestos y los controles que cierran las brechas — el artículo padre: los 12 controles en cinco capas contra los que la matriz de este artículo prueba, más el registro de actualizaciones de CVEs, listados KEV y clases de ataque.
• El rol predeterminado, no el modelo: cómo un solo prompt tomó el control de todos los agentes de una cuenta de AWS — el incidente de plataforma gestionada que define el requisito de auditoría del lado del operador: un rol de ejecución por defecto de la plataforma, con alcance de toda la cuenta, decidió el radio de impacto.
• Deadbugz: la cuarta clase de ataque MCP permanece oculta hasta que confía — la clase de envenenamiento de metadata runtime-gated detrás de la pregunta RFP C5 de este artículo: el escaneo en tiempo de aprobación no la ve; fingerprint-and-diff sí.

---

Un build representativo: un distribuidor de mercado medio exponiendo un módulo MCP a producción — un lector de catálogo NetSuite y un generador de cotizaciones con write-back al ERP. La capa de red (en la forma de producto en la que el parque ya confía) descubre el módulo, monitoriza el tráfico de agentes y protege contra flooding la frontera. Los cuatro controles de capa de aplicación se construyen dentro del módulo antes de la primera llamada de herramienta: procedencia firmada del artefacto, sin rutas controladas por usuario en STDIO, contexto acotado por herramienta, kill switch ejercitado una vez en staging. La fase Discovery de una semana produce el inventario de servidores y la tarjeta de puntuación de 12 controles que convierte la lista de capacidades de cualquier proveedor — este o el siguiente — en una respuesta RFP verificable en lugar de una diapositiva.

Discovery de una semana. Recibe un inventario de sistemas, un mapa de flujos de trabajo y un alcance fijo — construya con nosotros o no.