Anthropic presentó el Model Context Protocol, o MCP, en noviembre de 2024 como un estándar abierto para conectar asistentes de Inteligencia Artificial con fuentes de datos, herramientas y entornos de trabajo, con la promesa de ofrecer conexiones “seguras” y bidireccionales. Desde entonces, el protocolo se ha convertido en una de las piezas más visibles del nuevo ecosistema de agentes de IA, precisamente porque simplifica cómo los modelos acceden a sistemas externos.
Ahora ese mismo protocolo está en el centro de una controversia mucho más incómoda. OX Security sostiene que el diseño de MCP, en concreto su uso del transporte STDIO para lanzar procesos locales, permite escenarios de ejecución arbitraria de comandos cuando configuraciones o entradas de usuario llegan sin control suficiente al lanzamiento de subprocesos. Según su investigación, esa raíz común habría 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 los investigadores cifran en más de 150 millones de descargas de paquetes y hasta 200.000 servidores, cifras que deben entenderse como estimaciones del equipo de OX y no como una auditoría oficial e independiente del conjunto del ecosistema.
Un protocolo abierto que prometía seguridad por diseño
La discusión no gira solo en torno a un fallo técnico aislado, sino sobre una decisión arquitectónica. El núcleo del debate es sencillo de explicar: si un cliente MCP puede arrancar un servidor local mediante STDIO, y esa ruta termina aceptando configuraciones peligrosas o comandos no debidamente acotados, el problema deja de ser una mala implementación concreta y pasa a afectar a todo lo que reutiliza esa lógica. OX sostiene precisamente eso: que la debilidad no está solo en herramientas concretas, sino en la base compartida que heredan múltiples SDK y proyectos posteriores.
Anthropic, al menos según la reconstrucción publicada por OX y recogida por The Register, no aceptó que ese comportamiento constituyera un defecto del protocolo en sí, sino un uso esperado que exige que el desarrollador aplique sus propios controles. Ahí aparece la primera gran grieta de confianza: cuando una pieza central del ecosistema se presenta como estándar “seguro”, pero la seguridad efectiva depende de que todos los desarrolladores descendentes sepan blindar correctamente el mismo patrón peligroso, la carga real de la protección se desplaza desde el origen hasta el último eslabón de la cadena.
No es casualidad que la documentación oficial de seguridad de MCP insista hoy en medidas como mostrar al usuario el comando exacto que va a ejecutarse, advertir de patrones peligrosos, recordar que los servidores MCP se ejecutan con los mismos privilegios que el cliente y recomendar sandboxing con privilegios mínimos. También exige mecanismos explícitos de consentimiento en configuraciones locales de un clic. Todo eso es sensato, pero también revela algo importante: el riesgo no es teórico y el propio ecosistema lo reconoce ya como un vector que requiere frenos adicionales.
La seguridad delegada ya no convence tanto
El repositorio oficial de servidores MCP también deja entrever esa misma filosofía. Los servidores de referencia se presentan como ejemplos educativos para demostrar el uso de los SDK, no como soluciones listas para producción, y se recuerda que los desarrolladores deben evaluar sus requisitos de seguridad e implementar salvaguardas adecuadas. Desde una perspectiva estrictamente técnica, el aviso es razonable. Desde una perspectiva de mercado, en cambio, el mensaje es más problemático: el estándar se adopta con rapidez, se vende como infraestructura común para la IA agentic, pero la responsabilidad última por los daños se traslada a quien lo integra.
Ese es, probablemente, el corazón del problema. OX no está diciendo solo que haya bugs en proyectos de terceros. Lo que plantea es que Anthropic podría haber optado por un diseño más restrictivo en origen, con allowlists, manifiestos o modos explícitamente peligrosos, en lugar de dejar abierta una capacidad tan delicada y confiar en que los demás la manejen bien. Es una discusión clásica de seguridad: si algo puede causar daño grave, ¿debe venir abierto por defecto y documentado con precauciones, o cerrado por defecto y habilitado solo cuando el desarrollador asume conscientemente el riesgo?
La pregunta, por tanto, ya no es únicamente si OX tiene razón en todos sus números o si Anthropic interpreta correctamente que se trata de “comportamiento esperado”. La cuestión de fondo es quién responde cuando una arquitectura pensada para escalar la IA multiplica también la superficie de ataque. Porque si el proveedor del estándar se limita a decir que los clientes y desarrolladores deben tener cuidado, la seguridad deja de estar incorporada y pasa a ser una recomendación. Y una recomendación, en un ecosistema que crece a velocidad descontrolada, suele ser una defensa muy débil.
El patrón va más allá de Anthropic
Lo incómodo es que este reparto de responsabilidades no es exclusivo de Anthropic. Microsoft sigue mostrando en la página de términos de uso de Copilot avisos según los cuales el sistema puede equivocarse, puede no funcionar como se espera, no debe utilizarse para consejos importantes y se usa “bajo el propio riesgo” del usuario. Tras la polémica pública, Microsoft dijo a Business Insider que esa frase de “fines de entretenimiento” era lenguaje heredado de la etapa de Bing y que la revisaría, pero el episodio dejó a la vista la misma lógica de fondo: vender IA como herramienta central de productividad mientras se blinda la responsabilidad legal con advertencias muy agresivas.
Eso es lo que está erosionando la confianza alrededor de la IA generativa. Las empresas presentan estos sistemas como la nueva capa universal del software, pero cuando aparece un problema serio, la respuesta suele ser parecida: el comportamiento era el esperado, el usuario debía haber tenido más cuidado, el desarrollador debía haber implementado más controles, el cliente debía haber validado mejor la salida. Es una forma de repartir el riesgo hacia abajo mientras el relato comercial sigue yendo hacia arriba.
Por eso el caso de MCP importa tanto. No es solo una discusión para especialistas en seguridad o para quienes trabajan con agentes. Es una señal de algo más profundo: la IA está dejando de ser una función adicional para convertirse en infraestructura. Y cuando una tecnología pasa a ser infraestructura, ya no basta con innovar rápido y añadir advertencias. Hace falta decidir de forma más clara qué parte del riesgo asume quien diseña el protocolo, qué parte asume quien lo integra y qué parte, sencillamente, no debería recaer nunca sobre el usuario final.
Preguntas frecuentes
¿Qué es exactamente MCP y para qué sirve?
MCP, o Model Context Protocol, es un estándar abierto impulsado por Anthropic para conectar modelos y asistentes de IA con fuentes de datos, herramientas y otros sistemas externos mediante una interfaz común.
¿Qué denuncia OX Security sobre MCP?
OX afirma que el diseño del transporte STDIO en las implementaciones oficiales permite escenarios de ejecución arbitraria de comandos si configuraciones o entradas inseguras llegan al arranque del proceso, y sostiene que eso ha impactado en numerosos proyectos del ecosistema.
¿Anthropic reconoce que exista un fallo en el protocolo?
Según OX y The Register, Anthropic defendió que ese comportamiento era esperado o “by design” y no aceptó modificar la arquitectura de base en los términos que proponían los investigadores.
¿Qué enseña este caso sobre la responsabilidad en la IA?
Que el gran debate ya no es solo si un modelo se equivoca, sino quién responde cuando un estándar, una integración o un asistente se vende como seguro y útil, pero la carga real de prevenir abusos se desplaza al desarrollador o al usuario.
vía: ox.security
