El caso del Protocolo de Contexto del Modelo, conocido como MCP, ha dejado de ser un tema de nicho para desarrolladores de agentes y se ha convertido en una cuestión mucho más relevante para toda la industria: cuando una capa fundamental del nuevo ecosistema de inteligencia artificial genera riesgos en la ejecución de comandos, ¿quién debe asumir la responsabilidad real?
Anthropic presentó MCP en noviembre de 2024 como un estándar abierto para conectar modelos de IA con herramientas, fuentes de datos y sistemas externos mediante una interfaz común. La promesa era clara: reducir integraciones a medida y facilitar conexiones bidireccionales “seguras” entre asistentes y software empresarial. Desde entonces, MCP se ha expandido rápidamente en clientes, SDK, marketplaces y frameworks de terceros.
Sin embargo, esa expansión ha traído consigo una controversia importante. OX Security sostiene que el problema no es simplemente un bug aislado, sino una debilidad arquitectónica vinculada a cómo las implementaciones oficiales permiten lanzar procesos locales mediante STDIO. Según su investigación, esta lógica ha llevado a más de 30 divulgaciones responsables, más de 10 CVE de gravedad alta o crítica, y una exposición potencial que la firma cifra en más de 150 millones de descargas y hasta 200.000 servidores. Aunque estas cifras corresponden al equipo de OX Security y no a una auditoría independiente del ecosistema completo, han sido suficientes para encender el debate.
El problema no está solo en el código, sino en el diseño
Lo que hace especialmente delicado este caso es que no encaja en la categoría habitual de vulnerabilidad puntual. Según OX Security, si una implementación permite configuraciones inseguras o deja que entradas de usuario lleguen a la creación de un proceso STDIO, el comando puede ejecutarse incluso si el servidor MCP no arranca correctamente. Desde esta perspectiva, el fallo no es tanto una excepción concreta, sino una arquitectura excesivamente permisiva en un punto crítico.
Anthropic no parecen compartir esa interpretación. La especificación oficial del MCP aclara que el protocolo no puede imponer principios de seguridad a nivel de protocolo y que los implementadores deben construir flujos robustos de consentimiento, controles de acceso y protecciones de datos. Además, su documentación de seguridad insiste en mostrar al usuario el comando exacto que será ejecutado, advertir sobre patrones peligrosos, aplicar sandboxing y operar con privilegios mínimos. Es decir, el modelo oficial traslada gran parte del control de seguridad al desarrollador y al operador de la integración.
La principal fricción radica en esto. Para Anthropic, el comportamiento puede considerarse esperado si el desarrollador mal utiliza una capacidad poderosa. Para OX Security, esa misma capacidad nunca debería haberse expuesto de forma tan abierta en una pieza que está destinada a convertirse en infraestructura común del ecosistema agentic. OX Security resumió bien este choque al describir la polémica como una diferencia entre “fallo de diseño” y “comportamiento esperado basado en una mala elección de diseño”.
Cuando el estándar es abierto, pero la seguridad no viene cerrada
En medios tecnológicos, este matiz cobra mucha más importancia de lo que parece. MCP no es una aplicación concreta ni una extensión marginal. Se ha convertido en una capa de compatibilidad que aspira a funcionar como un traductor universal entre modelos y herramientas. Y cuando una pieza así se adopta con rapidez, cualquier decisión permisiva desde el inicio puede amplificarse a través de SDK, adaptadores, marketplaces e IDEs.
Este efecto en cascada es precisamente uno de los aspectos más delicados del caso. OX Security y otros medios que han divulgado su trabajo afirman que el impacto no se limita al repositorio principal, sino que se extiende a proyectos que reutilizan la lógica del SDK oficial o construyen sobre ella. Entre los ejemplos citados se incluyen adaptadores de LangChain, plataformas como LangFlow y Flowise, y escenarios de inyección de prompts locales en entornos de desarrollo asistido por IA.
Esto obliga a abordar el problema como un asunto de cadena de suministro de software, no solo como una discusión sobre buenas prácticas de programación. Si una librería o patrón oficial se adopta masivamente y su uso inseguro resulta fácil, la seguridad ya no depende solo del proveedor del producto final. Depende de todos los eslabones de la cadena. Y cuanto más rápida sea esa expansión, más probable es que alguien la implemente de forma incorrecta.
La gran pregunta: ¿seguridad por defecto o precaución por defecto?
Lo que realmente está en juego es una cuestión filosófica de ingeniería. En una tecnología que aspira a conectar modelos con sistemas externos, ¿debería venir cerrada por defecto en todo lo que pueda implicar ejecución local, o basta con documentar los riesgos y promover la prudencia?
Anthropic parece inclinarse más hacia la segunda postura. Su especificación y guías de seguridad indican que el protocolo habilita capacidades, pero no puede obligar a cada implementador a diseñar una integración completamente segura. Por otro lado, OX Security sostiene que un cambio arquitectónico en el origen habría reducido significativamente el riesgo para los proyectos derivados. Ambas posiciones tienen fundamentos lógicos, pero no implican el mismo coste. La primera distribuye la responsabilidad de la seguridad entre miles de equipos, mientras que la segunda requiere una restricción mayor desde la base.
Para los medios tecnológicos, esta es la parte más relevante de toda la historia. La IA ya no solo responde preguntas, sino que empieza a ejecutar acciones, abrir procesos, modificar configuraciones y afectar sistemas reales. Cuando eso ocurre, la discusión deja de ser puramente algorítmica y pasa a ser una cuestión de arquitectura, gobernanza y responsabilidad operativa.
No es un caso aislado: el sector se protege legalmente mientras acelera comercialmente
El episodio de MCP también refleja una tendencia más amplia. Las empresas de IA promueven estos sistemas como el nuevo centro de la productividad digital, pero al mismo tiempo limitan su responsabilidad mediante advertencias, restricciones de uso y traslados de riesgos hacia usuarios, empresas y desarrolladores. El caso de Copilot y sus términos de uso, que generaron controversia por el lenguaje que invitaba a no usar el sistema para decisiones importantes, fue un ejemplo reciente de esa contradicción.
La paradoja resulta evidente: la industria desea que la IA se convierta en infraestructura, pero sigue gestionando los problemas como si fueran incidentes de producto. Y esa infraestructura no funciona así. Cuando una capa central falla, o se percibe como insegura por diseño, el daño no se limita al laboratorio, sino que se propaga a todo lo que depende de ella.
Por eso, el debate sobre MCP es tan importante. No porque vaya a frenar por sí solo la adopción de agentes, sino porque plantea una cuestión que el sector ha postergado demasiado tiempo: si la IA quiere operar sobre sistemas reales, manejar datos sensibles y ejecutar tareas críticas, no puede seguir dejando la seguridad “como ejercicio del integrador”. En algún momento, alguien tendrá que aceptar que lo abierto no es suficiente y que la responsabilidad también debe venir por defecto empaquetada.
Preguntas frecuentes
¿Qué es MCP y por qué es tan relevante en la IA?
Es un estándar abierto impulsado por Anthropic para conectar modelos y asistentes con herramientas, datos y sistemas externos. Su importancia radica en que reduce integraciones personalizadas y facilita el trabajo de agentes con software real.
¿Qué denuncia exactamente OX Security sobre MCP?
OX Security sostiene que la lógica de lanzamiento de procesos vía STDIO en las implementaciones oficiales puede facilitar la ejecución arbitraria de comandos cuando se combina con configuraciones inseguras o entradas sin sanitizar. Afirman que el problema es de arquitectura, no solo un bug aislado.
¿Anthropic ha admitido un fallo en el protocolo?
No en los términos que plantea OX. La postura oficial, según su especificación y documentación de seguridad, es que el protocolo no puede imponer todos los controles y que los implementadores deben aplicar consentimiento, aislamiento y controles de acceso.
¿Por qué este caso es importante más allá de Anthropic?
Porque MCP se ha adoptado como capa de integración en agentes, SDK y herramientas de terceros. Si un cambio de diseño en esa capa genera riesgos, el impacto puede extenderse mediante frameworks, marketplaces e IDEs que reutilizan el mismo patrón.
vía: ox.security