Lista de verificación de endurecimiento de seguridad MCP: 1,467 servidores expuestos y los controles que los cierran

Trend Micro escaneó internet y encontró 1.467 servidores MCP abiertos — sin autenticación, sin cifrado, accesibles por cualquiera. Practical DevSecOps encontró que el 82% de 2.614 servidores encuestados son vulnerables a path traversal. Un protocolo diseñado para conectar agentes de IA a sistemas empresariales se publicó sin una base de seguridad de producción, y los patrones de despliegue lo demuestran: la mayoría de los equipos expusieron MCP a internet antes de endurecerlo. Este checklist es la base que debería haber venido primero — 12 controles de transporte, autenticación, registro de herramientas, runtime y auditoría, cada uno verificable en menos de cinco minutos antes de que un servidor MCP toque tráfico de producción.

Puntos clave

• 1,467 servidores MCP son accesibles públicamente sin autenticación ni cifrado — escaneo corregido de Trend Micro, julio de 2026. 1,227 de ellos ejecutan el transporte SSE deprecado que la especificación 2026-07-28 retira con un reloj de deprecación de 12 meses.
• 82% de 2,614 servidores MCP encuestados son vulnerables a path traversal, y solo 8.5% usan OAuth — Practical DevSecOps MCP Security Statistics 2026 Report. Las clases de ataque están generalizadas en servidores desplegados, no son teóricas.
• 3 CVEs aterrizaron en el SDK oficial de Python de MCP en julio de 2026 — CVE-2026-59950 (DNS rebinding/CSRF), CVE-2026-52869 (peticiones de sesión no verificadas), CVE-2026-52870 (manejadores de tareas abiertos). La implementación de referencia envió la misma clase de flaw que los servidores comunitarios.
• 78.3% de tasa de éxito de ataque cuando 5 servidores MCP se conectan a 1 agente — Palo Alto Networks Unit 42. Cinco servidores es un despliegue típico, no uno grande. OX Security identificó un RCE arquitectónico que afecta 150M+ descargas, y la Cloud Security Alliance clasificó la seguridad de MCP como un problema de design-flaw sistémico.
• La especificación MCP 2026-07-28 se publica como final el 28 de julio de 2026 — los cuatro SDKs Tier 1 (TypeScript, Python, Go, C#) hablan el nuevo núcleo sin estado, con una política de deprecación de 12 meses para el transporte SSE. La migración y el endurecimiento son el mismo trabajo.

Un despliegue MCP de producción que pasa los 12 controles de esta lista de verificación no es invulnerable — ningún sistema lo es — pero ya no está en la población que Trend Micro encontró, que Practical DevSecOps escaneó, o que la oleada de CVEs de julio atrapó. La lista de verificación mapea cada control a la categoría del OWASP MCP Top 10 que aborda, el CVE o exposición que previene, y el paso de verificación que un operador puede ejecutar en menos de cinco minutos. El Microsoft Agent Governance Toolkit — el primer runtime de gobernanza open-source enviado por un hyperscaler con cobertura 10/10 del OWASP MCP Top 10 — es la implementación de referencia. Este artículo es el complemento operativo: una revisión de endurecimiento escaneable para un Head of Engineering o líder de plataforma preparándose para exponer un servidor MCP a tráfico de producción.

La superficie de ataque, en números

El OWASP MCP Top 10 (Beta Release v0.1, Phase 3 of 5) cataloga 10 categorías de riesgo nombradas a lo largo del ciclo de vida del sistema habilitado por MCP. Los números detrás de ellas son lo que convierte "la gobernanza es buena práctica" en "la gobernanza es una puerta de producción":

• 1,467 servidores expuestos — el escaneo corregido de Trend Micro encontró 1,467 servidores MCP accesibles públicamente sin autenticación ni cifrado, desde un conteo inicial de 492. 1,227 ejecutan el transporte SSE deprecado. Al menos tres exponen registros médicos de pacientes vía una herramienta progress_note. La herramienta execute_sql aparece en 70 hosts.
• 82% de exposición a path traversal — Practical DevSecOps midió 82% de vulnerabilidad a path traversal y 8.5% de adopción de OAuth en 2,614 servidores encuestados. 97M+ descargas mensuales de MCP significa que la exposición escala con la adopción.
• 150M+ descargas afectadas por RCE arquitectónico — OX Security enmarcó la causa raíz de inyección de comandos STDIO como un flaw a nivel arquitectónico, no CVEs aislados. La Cloud Security Alliance lo clasificó como un problema de design-flaw sistémico en la infraestructura de agentes de IA.
• 3 CVEs en el SDK en julio de 2026 — CVE-2026-59950 (falta de validación Host/Origin, DNS rebinding/CSRF), CVE-2026-52869 (peticiones de sesión no verificadas), CVE-2026-52870 (manejadores de tareas abiertos). El SDK oficial de Python — la implementación de referencia de la que hereda todo servidor MCP en Python — envió la misma clase de flaw que los servidores comunitarios que soporta.
• 3 nuevas superficies de ataque en la especificación final — backslash.security identificó tres nuevas superficies de ataque introducidas por el rediseño sin estado en la especificación 2026-07-28. Las nuevas capacidades crean nuevos puntos de entrada que la comunidad de seguridad aún está mapeando.

El análisis de cataam.com enmarca el estado de la seguridad de MCP con precisión: "La seguridad de MCP está aproximadamente donde estaba la seguridad web hace quince años — los ataques son viejos, solo el objetivo es nuevo." La lista de verificación de endurecimiento de abajo es el conjunto de controles que movió la seguridad web de 82% de exposición a path traversal a una línea base donde se espera que los sistemas de producción pasen. Los mismos controles aplican aquí.

Los 12 controles de endurecimiento

La lista de verificación se organiza en cinco capas que mapean al OWASP MCP Top 10 y a los cambios de la especificación MCP 2026-07-28:

Capa 1 — Transporte y red

Control 1: Migración de SSE a Streamable HTTP. La especificación MCP 2026-07-28 se publica como final el 28 de julio de 2026, con una política de deprecación de 12 meses para el transporte HTTP+SSE. Los cuatro SDKs Tier 1 (TypeScript, Python, Go, C#) hablan el nuevo núcleo sin estado a partir del día de publicación, con notas de migración para las partes que rompen. Los 1,227 servidores SSE deprecados en el escaneo de Trend Micro son la población más afectada — ejecutan un transporte que la especificación está retirando. Verificación: revise la configuración de transporte del servidor. Si sirve SSE, está en el reloj de deprecación. Migre a Streamable HTTP antes de que la ventana de 12 meses cierre.

Control 2: Aislamiento de red y validación de origen. CVE-2026-59950 — confirmado en la National Vulnerability Database — es un flaw de falta de validación Host/Origin en el SDK oficial de Python de MCP. Una página web que la víctima visita puede dirigir su servidor MCP local vía DNS rebinding y CSRF. El navegador se convierte en el proxy del atacante hacia un servidor loopback que el operador creía privado. Verificación: confirme que el servidor valida los headers Host y Origin en cada petición. Si el servidor está expuesto a internet, confirme que está detrás de un límite de red que previene acceso directo desde orígenes no confiables. Un servidor que nunca debería haber sido alcanzable desde internet público no debe ser accesible desde internet público.

Capa 2 — Autenticación e identidad

Control 3: Aplicación de OAuth 2.1 + OIDC. La especificación 2026-07-28 hace obligatorio OAuth 2.1 más OpenID Connect — un cambio del enfoque anterior de "trae tu propio token". La guía de migración de autenticación de WorkOS detalla los requisitos: RFC 8707 (Resource Indicators) para prevenir replay de tokens entre servidores, Client ID Metadata Documents reemplazando Dynamic Client Registration, verificación de issuer (RFC 9207). El hallazgo de Practical DevSecOps — solo 8.5% de los servidores encuestados usan OAuth — es la línea base que este control eleva. Verificación: revise la configuración de autenticación del servidor. Si acepta peticiones sin autenticar o usa API keys estáticas sin OAuth, falla. Confirme que el servidor implementa resource indicators RFC 8707.

Control 4: Separación de identidad del agente. La NIST AI Agent Standards Initiative (febrero de 2026) propone tratar a los agentes como identidades no humanas distintas con su propio ciclo de vida: aprovisionamiento, atestación, revocación. La mayoría de los despliegues autentican al usuario humano y pasan esa identidad al agente. Cuando el agente toma una acción, el log de auditoría dice que la hizo el humano. Verificación: confirme que cada agente tiene su propia credencial (token OAuth, SPIFFE SVID) distinta de la del operador humano. Revocar la identidad del agente debería detener todas las llamadas del agente sin afectar el acceso del humano.

Capa 3 — Registro de herramientas y cadena de suministro

Control 5: Escaneo de tool poisoning. OWASP MCP03 nombra el tool poisoning como un riesgo top-10: rug pulls (herramientas de confianza actualizadas a versiones maliciosas), schema poisoning (definiciones de interfaz corrompidas para engañar al modelo), tool shadowing (herramientas falsas interceptando llamadas destinadas a las reales). El McpSecurityScanner del Microsoft Agent Governance Toolkit detecta tool poisoning, typosquatting e instrucciones ocultas — una herramienta demo llamada read_flie (typosquatting de read_file) con inyección en su descripción puntuó 85/100 de riesgo. Verificación: inspeccione el proceso de registro de herramientas. Si las herramientas se registran sin un escaneo de seguridad, falla. El escaneo debe cubrir patrones de prompt injection en descripciones, typosquatting contra nombres de herramientas conocidos, y directivas de sistema ocultas.

Control 6: Proveniencia firmada y monitoreo de dependencias. OWASP MCP04 cubre ataques a la cadena de suministro y manipulación de dependencias. El backdoor de Postmark MCP — el primer servidor MCP malicioso atrapado en estado salvaje — era un paquete npm de apariencia legítima que interceptaba emails silenciosamente y los exfiltraba. Pasó la revisión del registro. La investigación de UpGuard encontró que uno de cada 15 servidores MCP es un lookalike diseñado para suplantar a un servicio legítimo. Verificación: confirme que cada servidor MCP en el despliegue tiene un registro de proveniencia firmada y un inventario AIBOM (AI Bill of Materials). Confirme que el monitoreo de dependencias está activo y alerta sobre nuevos CVEs en el árbol de dependencias.

Control 7: Endurecimiento de STDIO. La divulgación de OX Security identificó un RCE arquitectónico en configuraciones STDIO que afecta 150M+ descargas. La causa raíz: shell: true en el SDK de TypeScript habilitaba inyección de comandos vía strings de configuración. La Cloud Security Alliance clasificó esto como un problema de design-flaw sistémico. Verificación: si el servidor usa transporte STDIO, confirme que shell: false o el endurecimiento equivalente está configurado. Confirme que las allowlists de comandos verifican argumentos, no solo nombres de binarios — los bypasses de Upsonic y Flowise (CVE-2026-30625, CVE-2026-40933) demostraron que npx -c <comando-malicioso> pasa a través de una allowlist que verifica solo el binario.

Capa 4 — Tiempo de ejecución y ejecución

Control 8: Rate limiting. Cada herramienta declara su propio límite de tasa en la llamada de registro. El backbone aplica límites por-agente, por-herramienta y por-ventana. Cuando se alcanza un límite, el agente recibe una respuesta 429 con un header Retry-After. Un agente comprometido no puede agotar las cuotas del API upstream porque el límite de tasa se aplica en la frontera del módulo. Verificación: confirme que cada herramienta registrada tiene un límite de tasa. Confirme que el límite se aplica en la frontera del módulo, no en el API upstream. Una herramienta sin límite de tasa es una herramienta que un agente comprometido puede llamar sin límite.

Control 9: Frontera de contexto. OWASP MCP10 nombra la inyección de contexto y el sobre-compartir como un riesgo top-10. Un agente con acceso amplio al contexto filtra información a través de tenants, sesiones o usuarios — una preocupación particularmente aguda para despliegues B2B donde el mismo agente sirve a múltiples clientes con diferentes derechos de acceso a datos. Verificación: confirme que cada herramienta recibe solo el contexto que necesita para su operación específica. Confirme que la ventana de contexto está delimitada por-herramienta, no compartida globalmente entre todas las herramientas. Una herramienta que recibe el contexto completo de la sesión cuando necesita solo un campo es una superficie de fuga de datos.

Control 10: Kill-switch por módulo. Cada módulo MCP debe ser desactivable independientemente sin tocar el backbone de orquestación. El kill switch es un cambio de configuración, no un despliegue de código. Cuando se divulga una vulnerabilidad — como la oleada de CVEs de julio divulgó 3 CVEs del SDK y 7+ CVEs de servidores en una quincena — la primera pregunta del operador es: ¿puedo desactivar este módulo sin tirar el agente? En un despliegue gobernado, la respuesta es sí. Verificación: confirme que cada módulo puede ser desactivado vía un feature flag o cambio de configuración. Confirme que la ruta de desactivación ha sido probada — no solo configurada. Un kill switch que nunca ha sido ejercitado es un kill switch que fallará cuando se necesite.

Capa 5 — Auditoría y telemetría

Control 11: Logging de auditoría por llamada. OWASP MCP08 nombra la falta de auditoría y telemetría como un riesgo top-10. Sin logs de invocaciones de herramientas y cambios de contexto, el robo de tokens y la inyección permanecen invisibles. Cada llamada a una herramienta debe registrar timestamp, ID del agente, nombre de la herramienta, hash del input (no input en bruto — frontera PII), estado del output, duración, y sistema upstream. Los logs son JSON estructurado enviado al pipeline de observabilidad. Verificación: confirme que cada llamada a una herramienta produce una entrada de log estructurada. Confirme que el log incluye el hash del input, no el input en bruto. Confirme que el log es inmutable — un atacante que compromete el servidor no puede reescribir el rastro de auditoría.

Control 12: Detección de servidores shadow. OWASP MCP09 cubre los servidores MCP shadow — despliegues no aprobados o no supervisados invisibles para la gobernanza. UpGuard encontró que uno de cada 15 servidores MCP es un lookalike. Un ingeniero que instala el mcp-server-postgress equivocado (note el typo) obtiene un paquete que exfiltra silenciosamente claves SSH y archivos .env. Verificación: confirme que hay un inventario de cada servidor MCP en el despliegue. Confirme que el inventario se verifica contra un registro de paquetes conocidos-buenos. Confirme que el monitoreo de drift alerta cuando aparece un servidor nuevo que no estaba en el inventario.

Cómo los frameworks mapean a la lista de verificación

Control	OWASP MCP	Spec 2026-07-28	Microsoft AGT	NIST	CSA
1. Migración SSE	—	Deprecación 12 meses	—	—	—
2. Aislamiento de red	MCP07	Validación de origen	—	—	—
3. OAuth 2.1 + OIDC	MCP07	Auth obligatoria	—	OAuth 2.0	—
4. Identidad del agente	MCP07	—	AgentMesh Identity	SPIFFE/SPIRE	—
5. Escaneo de tool poisoning	MCP03	—	MCP Security Gateway	—	—
6. Proveniencia firmada	MCP04	—	—	—	—
7. Endurecimiento STDIO	MCP05	—	—	—	Design flaw sistémico
8. Rate limiting	—	—	Policy Engine	—	—
9. Frontera de contexto	MCP10	—	Response sanitizer	—	—
10. Kill-switch por módulo	—	—	Hypervisor kill switch	—	—
11. Logging de auditoría por llamada	MCP08	—	Audit + metrics	—	—
12. Detección de servidores shadow	MCP09	—	—	—	—

Ningún framework individual cubre los 12 controles. La lista de verificación es la intersección de OWASP, la especificación, Microsoft, NIST y CSA — cada uno contribuyendo los controles que los demás carecen. El Microsoft Agent Governance Toolkit cubre 10/10 categorías del OWASP MCP Top 10 (7/10 completas, 3/10 parciales con roadmap) y es el primer runtime open-source enviado por un hyperscaler con mapeos OWASP explícitos — 68 tests en el Agent OS Policy Engine, 127 tests en el MCP Security Gateway, 80 tests en el Agent Hypervisor Execution Control incluyendo el kill switch.

Puntuando la lista de verificación

Un servidor MCP listo para producción pasa los 12 controles. Un servidor parcialmente listo pasa 8–11. Un servidor que pasa menos de 8 no debería ser expuesto a tráfico de producción sin un plan de remediación documentado y una fecha objetivo para cada control fallido.

Puntaje	Estado	Acción
12/12	Listo para producción	Desplegar con monitoreo
8–11/12	Parcialmente listo	Desplegar con excepciones documentadas y timeline de remediación
<8/12	No listo	No desplegar. Remediar los controles fallidos primero

El patrón de fallo más común es pasar los controles 1–4 (transporte, autenticación, identidad) mientras se fallan los controles 5–12 (cadena de suministro, runtime, auditoría). Los primeros cuatro son arquitectónicos y reciben atención en revisiones de diseño. Los últimos ocho son operacionales y se pierden hasta que un incidente o una auditoría los saca a la luz. La oleada de CVEs de julio de 2026 — 3 CVEs del SDK y 7+ CVEs de servidores en una quincena — es lo que pasa cuando los controles operacionales están ausentes.

Lecturas relacionadas

• La paradoja de MCP: por qué sin fricción es frágil — el análisis de riesgo a nivel de protocolo que los controles 5, 7 y 9 de esta lista de verificación abordan. Cubre el OWASP MCP Top 10, la tasa de ataque del 78.3% de Palo Alto Unit 42, y la divulgación de inyección de comandos STDIO de OX Security.
• Seguridad de MCP: por qué 200,000 instancias vulnerables convierten a los módulos gobernados en un criterio de compra — la capa de gobernanza que esta lista de verificación operacionaliza. Cubre la estimación de 200,000 instancias de OX Security, la línea temporal de brechas de 2026, y el proof point de 38 herramientas.
• MCP Module Code Standard — el estándar de código que hace los controles 8, 9, 10 y 11 aplicables en el propio módulo. Cubre estructura de directorios, registro de herramientas, manejo de errores, rate limiting y reglas de frontera PII.
• Lista de verificación de gobernanza de agentes de IA: una revisión pre-despliegue — la lista de verificación más amplia de 10 controles de gobernanza de agentes que esta lista de verificación específica de MCP complementa. Cubre identidad NIST, OWASP, niveles de autonomía Gartner, Stanford AILCCP y el paquete legislativo Warner.

---

Un build representativo: un distribuidor de mid-market desplegando un módulo MCP que lee un catálogo de NetSuite, genera cotizaciones, mantiene disponibilidad de inventario y escribe la orden aceptada de vuelta al ERP. Los controles 1–4 (migración SSE, aislamiento de red, OAuth, identidad del agente) son la arquitectura. Los controles 5–8 (escaneo de tool poisoning, proveniencia firmada, endurecimiento STDIO, rate limiting) son la capa de cadena de suministro y runtime. Los controles 9–12 (frontera de contexto, kill switch, logging de auditoría, detección shadow) son la capa operacional que determina si el módulo corre por una semana o por un año. La fase Discovery de una semana produce el inventario de sistemas y mapa de flujo que hace cada control verificable antes de que el módulo toque tráfico de producción.

Discovery de una semana. Obtienes un inventario de sistemas, mapa de flujo y alcance fijo — ya construyas con nosotros o no.