Desde su presentación en noviembre de 2024 por Anthropic, el Model Context Protocol (MCP) ha sido promocionado como el «USB de la inteligencia artificial». La promesa: estandarizar cómo los agentes de IA se conectan con herramientas, fuentes de datos y sistemas externos, evitando la necesidad de adaptadores personalizados. Sin embargo, al igual que ocurrió con ActiveX en su momento, MCP podría ser una gran idea con problemas fundamentales que amenazan su adopción y confiabilidad, especialmente en temas de seguridad y gobernanza.

¿Qué es el Model Context Protocol (MCP)?

MCP internamente es una arquitectura cliente-servidor, tecnológicamente volvemos al año 1990, con sus virtudes y sus defectos.

Esta tecnología esta diseñada para permitir que agentes de IA se conecten a recursos externos mediante descripciones estructuradas. En lugar de crear APIs personalizadas para cada integración, MCP ofrece un protocolo universal que permite a los agentes descubrir herramientas y servicios de manera estandarizada. En teoría, esto simplifica enormemente las integraciones y habilita flujos de trabajo entre herramientas que antes no estaban diseñadas para interoperar.

Sin embargo, su funcionalidad actual no representa una innovación radical, más bien una caso de uso de tecnologías existentes como APIs REST.

Mientras que MCP puede ser útil en entornos complejos con numerosas herramientas, su implementación es innecesariamente complicada para aplicaciones sencillas, lo que plantea dudas sobre su verdadero valor en ciertos casos.

Riesgos de seguridad: el talón de Aquiles de MCP

A pesar de su potencial, MCP enfrenta serios desafíos de seguridad que no fueron contemplados desde su diseño inicial. Esta tecnología está siendo «parcheada» (continúa abierto una propuesta de seguridad que me parece muy importante y no esta implementada) en lugar de haber nacido con una premisa sólida de seguridad. Entre los riesgos más preocupantes destacan:

  • Tool Poisoning: Los servidores MCP pueden proporcionar descripciones maliciosas de herramientas que desvían a los agentes de su propósito original o exfiltran datos sensibles.
  • Ataques tipo «rug pull»: Algunos servidores tienen la capacidad de cambiar dinámicamente el comportamiento de una herramienta después de haber sido validada, comprometiendo la confianza en el sistema.
  • Falta de autenticación y control de acceso rigurosos: Muchos servidores MCP carecen de validación robusta, lo que los hace vulnerables a ataques de suplantación y manipulación.
  • Fragmentación de herramientas: Con la proliferación de servidores MCP desarrollados por terceros sin estándares claros, existe el riesgo de que herramientas maliciosas o mal configuradas se infiltren en el ecosistema.

Estos riesgos recuerdan los problemas de seguridad que enfrentó ActiveX, una tecnología que prometía revolucionar la interoperabilidad pero terminó siendo un vector de ataques frecuentes debido a su falta de controles de seguridad integrados.

Fragmentación y gobernanza: un estándar sin timón

A diferencia del USB, que logró unificar completamente el hardware, MCP ya muestra signos de fragmentación. Hay múltiples versiones de servidores MCP desarrollados de manera independiente, con poca regulación sobre su calidad, interoperabilidad o seguridad. Además, no existe un consorcio formal que regule su evolución, lo que incrementa el riesgo de deriva técnica y la falta de estándares coherentes.

Esto crea una pregunta clave: ¿Qué MCP seleccionar y para qué aplicación? Sin una estructura centralizada para garantizar la interoperabilidad, la promesa de simplificar la integración corre el riesgo de convertirse en una ilusión. Si bien la variedad de implementaciones puede fomentar la innovación, también introduce inconsistencias y falta de confianza en el ecosistema, lo que dificulta su adopción masiva.

Incentivos, fricciones y el dilema de exponer herramientas

Las grandes empresas podrían mostrarse reacias a exponer toda su funcionalidad como «herramientas controlables por otros». MCP implica ceder parte del control del UX y abrir puertas a usos no previstos, lo que entra en conflicto con los intereses comerciales y de seguridad de muchos actores clave. Estas compañías prefieren mantener un control estricto sobre cómo sus herramientas son utilizadas, lo que plantea un desafío fundamental para la adopción de MCP como estándar abierto.

Además, muchos proveedores de herramientas podrían resistirse a implementar servidores MCP oficiales, prefiriendo mantener sus propias soluciones de integración. Sin su apoyo, MCP corre el riesgo de convertirse en un estándar secundario en lugar de una solución universal.

Desde mi punto de vista ¿qué falta para que MCP sea adoptado masivamente?

Para evitar que MCP se convierta en otro ActiveX, es necesario abordar varios problemas críticos que afectan su seguridad, gobernanza y confiabilidad. Algunas áreas clave para su evolución incluyen:

  • Gobernanza formal: Crear un consorcio abierto que defina versiones, pruebas de interoperabilidad y reglas de seguridad comunes.
  • Modelo de permisos granular: Permitir a los agentes verificar qué hace una herramienta y con qué datos puede operar.
  • Auditoría y trazabilidad: Implementar registros confiables que detallen qué agente invocó qué herramienta y con qué parámetros, esenciales para depuración y cumplimiento normativo.
  • Sandboxing de agentes: Limitar las acciones que un agente puede realizar al usar herramientas vía MCP, reduciendo riesgos de seguridad.
  • Observabilidad y control en tiempo real: Proporcionar visibilidad continua sobre las interacciones entre agentes y herramientas, permitiendo monitoreo activo y respuestas rápidas a incidentes.
  • Validación semántica de herramientas: Garantizar que las descripciones de herramientas sean veraces, consistentes y libres de ambigüedades.
  • Visibilidad centralizada: Crear un inventario unificado de herramientas conectadas, detectando herramientas «sombra» y aplicando controles centralizados.
  • Gestión de accesos y políticas operativas: Facilitar la autenticación, autorización y aplicación uniforme de políticas como limitación de tasa y aislamiento de herramientas.
  • Despliegue robusto y escalable: Separar los agentes y las herramientas para escalar cada componente de manera independiente y mejorar el aislamiento.
  • Detección y respuesta a anomalías: Usar monitoreo centralizado para establecer líneas base de uso y detectar comportamientos anómalos, como intentos de inyección de prompts o abuso de capacidades.

MCP: ¿Un estándar prometedor o un riesgo de seguridad?

El Model Context Protocol tiene el potencial de ser una herramienta clave para conectar agentes de IA con el mundo real de manera flexible y estructurada. Sin embargo, su diseño actual está lejos de ser perfecto. La falta de una base sólida de seguridad desde su inicio lo convierte en un estándar vulnerable, que depende de «parches» para abordar problemas emergentes. Esto no solo pone en peligro su adopción masiva, sino que también lo posiciona como un posible vector de ataques en entornos empresariales.

Al igual que ActiveX, MCP corre el riesgo de convertirse en una tecnología prometedora que pierde relevancia debido a sus vulnerabilidades y falta de confianza en el ecosistema. Si no se abordan los problemas de seguridad y gobernanza, MCP podría ser ignorado por las mismas empresas que más podrían beneficiarse de él.

Conclusión

El Model Context Protocol representa una dirección interesante y prometedora para conectar agentes de IA con herramientas externas. Sin embargo, su éxito dependerá de su capacidad para superar desafíos fundamentales relacionados con la seguridad, la gobernanza y la fragmentación. Si bien MCP tiene el potencial de unificar la integración de herramientas en el ecosistema de IA, todavía queda mucho trabajo por hacer para que sea adoptado masivamente y considerado un estándar confiable.

En su estado actual, MCP corre el riesgo de convertirse en una tecnología que, aunque innovadora, se vea limitada por su complejidad, falta de gobernanza y vulnerabilidades de seguridad. Para evitar el destino de ActiveX, Anthropic y la comunidad técnica deben actuar rápidamente para garantizar que MCP se transforme en un estándar robusto, seguro y universalmente adoptado. De lo contrario, podría pasar de ser el «USB para la IA» a ser otra promesa incumplida en la evolución tecnológica.

Para mi la verdadera pregunta no es si necesitamos MCP, sino cómo garantizar que sea seguro, interoperable y digno de confianza.