El caso del Model Context Protocol, más conocido como MCP, ha dejado de ser una discusión de nicho para desarrolladores de agentes y se ha convertido en una pregunta mucho más seria para toda la industria: cuando una capa básica del nuevo ecosistema de la Inteligencia Artificial genera riesgos de 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 extendido con rapidez en clientes, SDK, marketplaces y frameworks de terceros.

Pero esa expansión ha traído ahora una controversia de fondo. OX Security sostiene que el problema no es un simple bug aislado, sino una debilidad arquitectónica ligada a cómo las implementaciones oficiales permiten lanzar procesos locales mediante STDIO. Según su investigación, esa lógica ha desembocado en 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. Son cifras del equipo de OX Security, no una auditoría independiente global del ecosistema, pero han bastado para encender el debate.

El problema no está solo en el código, sino en el diseño

Lo que hace especialmente incómodo este caso es que no encaja bien en la categoría habitual de vulnerabilidad puntual. Según OX Security, si una implementación acepta configuraciones inseguras o deja que entradas de usuario lleguen a la creación de un proceso STDIO, el comando puede ejecutarse aunque el servidor MCP no llegue a arrancar correctamente. En esa lectura, el fallo no es tanto una excepción concreta como una arquitectura demasiado permisiva en un punto crítico.

Anthropic no parece compartir esa interpretación. La especificación oficial de MCP deja claro que el protocolo no puede imponer esos principios de seguridad a nivel de protocolo y que los implementadores deben construir flujos robustos de consentimiento, controles de acceso y protecciones de datos. Su documentación de seguridad insiste además en mostrar al usuario el comando exacto que va a ejecutarse, advertir de patrones peligrosos, aplicar sandboxing y operar con privilegios mínimos. Es decir, el modelo oficial traslada buena parte del control de seguridad al desarrollador y al operador de la integración.

Ahí aparece la fricción principal. Para Anthropic, el comportamiento puede entrar dentro de lo esperado si el desarrollador usa mal una capacidad poderosa. Para OX Security, esa misma capacidad nunca debió exponerse de forma tan abierta en una pieza llamada a convertirse en infraestructura común del ecosistema agentic. Open Security resumió bien ese 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 importa mucho más 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 traductor universal entre modelos y herramientas. Y cuando una pieza así se adopta a gran velocidad, cualquier decisión permisiva en origen puede amplificarse a través de SDK, adaptadores, marketplaces e IDEs.

Ese efecto cascada es precisamente uno de los puntos más delicados del caso. OX Security y varios medios que se han hecho eco de su trabajo sostienen 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 encima de ella. Entre los ejemplos citados aparecen adaptadores de LangChain, plataformas como LangFlow y Flowise, y escenarios de prompt injection local en entornos de desarrollo asistido por IA.

Eso obliga a mirar el problema como un asunto de supply chain de software, no solo como una discusión sobre buenas prácticas de programación. Si una librería o un patrón oficial se adopta masivamente y su uso inseguro resulta demasiado fácil, la seguridad deja de depender solo del proveedor del producto final. Depende de todos los eslabones. Y cuanto más deprisa crece la cadena, más probable es que alguien la integre mal.

La gran pregunta: ¿seguridad por defecto o cautela por defecto?

Lo que está realmente en juego es una cuestión de filosofía de ingeniería. En una tecnología que aspira a conectar modelos con sistemas externos, ¿debe venir cerrada por defecto en todo lo que pueda implicar ejecución local, o basta con documentar los riesgos y pedir prudencia?

Anthropic parece situarse más cerca de la segunda postura. Su especificación y sus guías de seguridad apuntan a que el protocolo habilita capacidades, pero no puede obligar a cada implementador a diseñar una integración segura. OX Security, en cambio, sostiene que un cambio arquitectónico en origen habría reducido de forma muy significativa el riesgo para los proyectos descendentes. Las dos posiciones tienen lógica interna, pero no tienen el mismo coste. La primera deja la seguridad distribuida entre miles de equipos. La segunda exige restringir más desde la base.

Para un medio de tecnología, esa es la parte más importante de esta historia. La IA ya no se limita a responder preguntas. Está empezando a ejecutar acciones, abrir procesos, editar configuraciones y tocar 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 encaja con una tendencia más amplia. Las compañías de IA impulsan estos sistemas como el nuevo centro de la productividad digital, pero al mismo tiempo blindan su responsabilidad con advertencias, limitaciones de uso y traslados de riesgo hacia usuarios, empresas y desarrolladores. El caso de Copilot y sus términos de uso, que generaron polémica por lenguaje que invitaba a no usar el sistema para decisiones importantes, fue otro ejemplo reciente de esa contradicción.

La paradoja es evidente: la industria quiere que la IA se convierta en infraestructura, pero a menudo sigue gestionando los problemas como si fueran simples incidencias de producto. Y la infraestructura no funciona así. Cuando una capa central falla, o se percibe como insegura por diseño, el daño no se queda en el laboratorio. Se propaga por todo lo que depende de ella.

Por eso el debate sobre MCP importa tanto. No porque vaya a hundir por sí solo la adopción de los agentes, sino porque obliga a plantear una cuestión que el sector lleva demasiado tiempo aplazando: si la IA quiere operar sobre sistemas reales, mover datos sensibles y ejecutar tareas críticas, no puede seguir dejando la seguridad “como ejercicio para el integrador”. En algún momento, alguien tendrá que asumir que lo abierto no basta, y que la responsabilidad también debe venir empaquetada por defecto.

Preguntas frecuentes

¿Qué es MCP y por qué se ha vuelto tan importante en la IA?
MCP es un estándar abierto impulsado por Anthropic para conectar modelos y asistentes con herramientas, datos y sistemas externos. Su relevancia ha crecido porque reduce integraciones a medida y facilita que los agentes trabajen con software real.

¿Qué denuncia exactamente OX Security sobre MCP?
OX Security afirma que la lógica de lanzamiento de procesos vía STDIO en las implementaciones oficiales puede facilitar ejecución arbitraria de comandos cuando se combina con configuraciones inseguras o entradas no sanitizadas. La firma sostiene que el problema es arquitectónico y no solo un bug puntual.

¿Anthropic ha reconocido un fallo en el protocolo?
No en los términos planteados por OX. La postura pública que reflejan la especificación y la documentación de seguridad es que el protocolo no puede imponer todos los controles a nivel de diseño y que los implementadores deben aplicar consentimiento, aislamiento y controles de acceso.

¿Por qué este caso importa más allá de Anthropic?
Porque MCP se ha extendido como capa de integración para agentes, SDK y herramientas de terceros. Si una decisión de diseño en esa base genera riesgo, el impacto puede multiplicarse a través de frameworks, marketplaces e IDEs que reutilizan el mismo patrón.

vía: ox.security