Un análisis de la infraestructura del Protocolo de Contexto de Modelos (MCP) indexada públicamente ha detectado deficiencias de gobernanza relacionadas con el alojamiento, la titularidad de los dominios y el código que ejecutan los servicios remotos.
OX Security afirma que examinó 15.465 registros de servidores MCP de cinco registros y, después, consolidó esos datos en 5.095 nombres de host únicos. Los resultados no describen 15.465 operadores distintos ni organizaciones afectadas: la cifra más alta corresponde a registros de servidores indexados y la más baja, a nombres de host diferentes.
Según el análisis de la investigación publicado por OX Security, algunos de los servidores incluidos estaban alojados en jurisdicciones posiblemente no autorizadas, expuestos a través de túneles para consumidores o asociados a dominios que ya no resolvían.
No se trata de un informe sobre una brecha confirmada. En el artículo publicado, OX no identificó a ninguna víctima, ningún robo de datos verificado ni ninguna explotación activa vinculada a los servidores analizados. La investigación, en cambio, traza distintas vías por las que un agente de IA podría confiar en una infraestructura cuya titularidad, ubicación o comportamiento cambien más adelante.
Miles de registros se reducen a 5.095 nombres de host
MCP apareció en 2024 como estándar para conectar modelos de IA, agentes de software y entornos de desarrollo integrados con herramientas externas y fuentes de datos. Un servidor MCP puede poner capacidades a disposición de un agente e integrarse así en flujos de trabajo sensibles.
El análisis de OX abarcó cinco registros de MCP, aunque el artículo publicado no los identifica ni describe sus respectivos procesos de admisión y revisión. Esto limita las comparaciones entre registros e impide determinar si los cinco aplican los mismos controles.
La diferencia entre registros e infraestructura es importante. OX recopiló 15.465 servidores indexados públicamente, pero, tras eliminar los duplicados, obtuvo 5.095 nombres de host únicos. Por tanto, varias entradas de los registros pueden apuntar al mismo nombre de host.
Los porcentajes publicados se refieren a nombres de host, no a personas. No deben interpretarse como cifras de sistemas, clientes u organizaciones comprometidos.
A diferencia de un aviso convencional sobre vulnerabilidades, la investigación no identifica una versión defectuosa de un producto, no asigna un CVE ni ofrece una puntuación de gravedad. El problema es más amplio: los agentes pueden conectarse a servicios de terceros sin garantías suficientes sobre quién los opera, por dónde se envían las solicitudes o qué código de backend las procesa.
La ubicación del alojamiento puede crear una ruta de datos no autorizada
OX informa de que el 15,6 % de los nombres de host resolvía a infraestructura situada fuera de Estados Unidos. El artículo menciona concretamente 19 en China y 18 en Rusia, pero no ofrece cifras completas para cada país.
La ubicación geográfica no demuestra que un servidor sea malicioso. Sin embargo, puede determinar qué jurisdicción legal y qué requisitos internos de residencia de datos se aplican cuando un agente envía instrucciones, código fuente, credenciales o información empresarial a ese servicio.
Una empresa puede haber aprobado una herramienta de IA concreta sin revisar por separado todos los endpoints de MCP a los que esta puede conectarse. En ese caso, la conexión de un agente podría crear una ruta de datos hacia regiones no autorizadas por la organización.
OX también plantea un escenario en el que un operador aloja inicialmente un servicio en una dirección IP de Estados Unidos y más adelante lo redirige a otro lugar. Los resultados publicados no demuestran que OX observara un cambio así en los servidores analizados. Se trata de un escenario de amenaza que ilustra por qué una comprobación puntual de la ubicación puede no ofrecer garantías duraderas.
El reto práctico es la verificación continua. El nombre de host puede mantenerse igual aunque cambie la infraestructura que hay detrás, mientras las configuraciones existentes de los agentes siguen intactas.
Los túneles para consumidores dificultan verificar quién opera el servidor
OX afirma que el 0,45 % de los nombres de host analizados dirigía el tráfico a través de servicios de túneles para consumidores, principalmente ngrok-free.
Un túnel permite exponer una aplicación que se ejecuta localmente sin necesidad de desplegarla en una infraestructura de alojamiento convencional. Esto resulta útil para demostraciones y tareas de desarrollo, pero ofrece a las empresas menos información sobre el entorno que hay detrás del endpoint público.
OX describe los servicios tunelizados incluidos como servicios que se ejecutan en equipos personales. También considera probable que estén conectados a través de redes domésticas, aunque esta afirmación sobre la ubicación de la red es una inferencia, no un resultado confirmado para cada endpoint.
La preocupación se centra en el control operativo, no en una vulneración demostrada de la plataforma de túneles. Un servicio MCP incluido en un registro público puede depender del equipo de una persona, de un proceso de despliegue informal o de una infraestructura ajena a los sistemas habituales de supervisión y gestión de cambios de una organización.
Esto puede afectar tanto a la disponibilidad como a la seguridad. El agente ve un endpoint accesible, pero quizá su operador no ofrece las garantías de identidad, ciclo de vida y cadena de suministro que se esperan de un servicio empresarial.
Los dominios caducados pueden transferir la identidad de un servidor de confianza
OX descubrió que el 2,3 % de los nombres de host ya no resolvía. Según el informe, seis estaban asociados a dominios caducados que podían registrarse por un precio estimado de entre 4 y 12 dólares al año.
Esto plantea un posible problema de transferencia de identidad. Si un agente sigue configurado para conectarse a uno de esos dominios, un nuevo titular podría reactivar el nombre de host y empezar a recibir las futuras solicitudes destinadas al operador anterior de MCP.
El dominio adquiere valor porque la confianza puede seguir presente en las configuraciones de los clientes aunque la titularidad haya caducado. Los usuarios pueden seguir reconociendo el nombre del servidor y los agentes automatizados quizá no distingan entre el operador anterior y el nuevo titular.
OX no afirma que un atacante haya registrado alguno de los seis dominios. Tampoco documenta que se interceptaran solicitudes a través de ellos. El hallazgo identifica una vía viable para hacerse con el control, no una toma de control consumada ni una exposición confirmada.
El impacto también dependería del uso que el agente hiciera del endpoint. Las cifras publicadas no permiten saber qué herramientas, permisos o información estaban disponibles para los clientes configurados para utilizar los dominios afectados.
Un repositorio público no demuestra qué ejecuta un servidor remoto
La investigación también cuestiona una premisa habitual en la revisión de software: que examinar un repositorio público basta para determinar cómo se comporta un servicio MCP remoto.
Revisar un repositorio puede ayudar a evaluar el código fuente, las dependencias y las funciones declaradas. Pero, si los usuarios no pueden verificar que ese código corresponde al servicio desplegado, el backend remoto podría ejecutar otra compilación o una lógica completamente distinta.
OX afirma que los marketplaces de MCP carecen de un mecanismo equivalente a la detección de malware de las tiendas de aplicaciones y señala que los editores pueden publicar servidores sin someterse a un proceso de verificación comparable. El artículo no identifica los cinco registros ni documenta sus controles específicos, por lo que, con la información disponible, esta afirmación no puede aplicarse de manera uniforme a todos ellos.
El artículo cita Google Bouncer, una herramienta que Google utilizó en 2012 para analizar aplicaciones de Android, como referencia. También reconoce que los investigadores encontraron formas de eludir Bouncer. Por tanto, los controles no son una garantía absoluta, pero pueden añadir una capa de revisión que, según OX, falta en el ecosistema de MCP.
Según OX, el informe completo, titulado «15,465 MCP Servers, 0 Governance», incluye una prueba de concepto de inyección de instrucciones y otros escenarios de amenaza. El resumen publicado no ofrece suficientes detalles técnicos para determinar en qué condiciones funcionaba la prueba de concepto ni si se probó contra un servicio de terceros en producción.
Las empresas necesitan controlar las conexiones, no solo el código
OX pide a los marketplaces de MCP que incorporen evaluación de los servicios, firma de código y verificación del origen. En conjunto, estas medidas ayudarían a responder a tres preguntas distintas: quién puede publicar, si un artefacto ha cambiado y si un servicio remoto corresponde al origen esperado.
Las organizaciones que utilizan MCP también pueden someter estas conexiones a sus programas de gobernanza actuales. Entre las prácticas que señala la investigación figuran las reglas de residencia de datos, los límites de Zero Trust, la gestión granular de identidades y accesos (IAM) y las auditorías de la cadena de suministro.
Aplicadas a los despliegues de MCP, estas medidas implican mantener visibilidad sobre qué agentes pueden acceder a qué servidores y comprobar si esos endpoints siguen dentro de los límites aprobados de jurisdicción y titularidad. El estado de un dominio y la ubicación de un servidor pueden cambiar, por lo que una aprobación basada en una revisión inicial podría quedar desactualizada.
La inspección del repositorio también debería considerarse una fuente de información, no una prueba del comportamiento en tiempo de ejecución. Cuando un flujo de trabajo maneja información sensible, las organizaciones necesitan garantías sobre el servicio desplegado y su operador, no solo sobre el código publicado en un proyecto público.
OX también menciona una investigación anterior sobre vulnerabilidades en el código fuente de MCP de Anthropic. Las califica de críticas y afirma que el código se había descargado más de 150 millones de veces. El artículo disponible no proporciona identificadores CVE, versiones afectadas, pruebas técnicas ni detalles sobre las medidas correctivas de esos hallazgos anteriores. Por tanto, no es posible evaluarlos como parte del análisis actual de servidores.
Las cifras recién publicadas corresponden a los resultados de OX y no se han validado de forma independiente en el material disponible para este artículo. Aun así, describen un problema concreto de gobernanza: la relación de confianza de un agente de IA puede perdurar más que la infraestructura, el titular del dominio o la implementación de software que la justificaron en un principio.
