MCP (Model Context Protocol): la nueva superficie de ataque para desarrolladores.

El Model Context Protocol, o MCP, es un protocolo abierto —originado en Anthropic y adoptado desde entonces de forma mucho más amplia en toda la industria— para estandarizar cómo una aplicación de IA se conecta con el mundo exterior. En concreto: en lugar de que un cliente de chat, un asistente de IDE o un agente autónomo envíen cada uno su propio código de integración a medida, hecho una sola vez para cada sistema de archivos, base de datos o API que necesiten tocar, MCP define una forma común de que un «cliente» (la aplicación que aloja el modelo) hable con un «servidor» (un pequeño programa que expone al modelo un conjunto concreto de herramientas, fuentes de datos u otro contexto).

Es fácil ver el atractivo, honestamente, porque resuelve un problema real. Antes de que existiera un estándar compartido como este, cada integración de herramientas era código pegamento a medida —autenticación distinta, formatos de datos distintos, modos de fallo distintos— reescrito para cada proveedor de modelos y cada aplicación que quería la misma capacidad. MCP convierte eso en algo más parecido a un patrón de plugins: escribe un servidor que exponga «leer archivos de este directorio» o «consultar esta base de datos», y cualquier cliente compatible con MCP puede conectarse a él. Eso es una victoria genuina de ingeniería. También es, estructuralmente, un nuevo lugar donde se negocia la confianza cada vez que se establece una conexión.

Por qué estandarizar la conexión es también estandarizar el riesgo

Cuando cada integración era a medida, un atacante que quisiera abusar de una tenía que entender tu código pegamento específico —tu envoltorio de API concreto, tu forma concreta de trasladar datos al contexto del modelo—. Esa heterogeneidad era una seguridad accidental por oscuridad, y no algo en lo que nadie debiera haber confiado, pero sí significaba que una técnica de ataque rara vez se trasladaba limpiamente de un sistema al siguiente.

Una vez que las integraciones siguen un protocolo compartido, eso deja de ser cierto. Una técnica que explote una debilidad en la forma en que los servidores MCP manejan habitualmente las descripciones de herramientas, o en la forma en que los clientes muestran habitualmente la salida de las herramientas de vuelta al modelo, puede generalizarse a todos los servidores construidos de la misma manera, no solo a una integración a medida. Esto no es un defecto exclusivo de MCP; es el compromiso que hace todo esfuerzo de estandarización. Los formatos comunes y los protocolos comunes son lo que hace posible la interoperabilidad, y son exactamente lo que hace que una única técnica de ataque sea portable entre muchas implementaciones a la vez. TCP/IP, HTTP y USB hicieron todos este mismo compromiso antes que MCP. La lección no es «no estandarices», sino que el trabajo de seguridad tiene que ocurrir a nivel de protocolo y de implementación, y no dejarse a que cada integración lo reinvente.

Dónde reside el riesgo real

• Servidores MCP maliciosos o comprometidos. Un servidor puede describir sus propias herramientas al cliente y devolver datos arbitrarios como resultado de una llamada a una herramienta. Ambas cosas son lugares donde un servidor hostil o comprometido puede colar instrucciones dentro de lo que parece una salida corriente: una descripción de herramienta que le dice discretamente al modelo que se comporte de otro modo, o una respuesta de datos con texto oculto que le dice al modelo que emprenda alguna acción adicional. Esto es una variante específica del protocolo de la inyección de prompts indirecta: el atacante nunca habla directamente con el modelo, simplemente controla algo que el modelo lee a través de un canal en el que se le dijo que confiara.
• Concesiones de permisos demasiado amplias. Un servidor conectado una vez para una tarea acotada —digamos, leer un único archivo de configuración— acaba a menudo con acceso permanente a todo un sistema de archivos, a toda una base de datos o a todo el alcance de una API, porque eso es lo que ofrecía la conexión por defecto y nadie volvió a acotarlo. La brecha entre «lo que la tarea necesita» y «lo que la conexión realmente concede» es donde un solo error, o una sola instrucción inyectada, se convierte en un problema mucho mayor de lo que debería.
• Riesgo de cadena de suministro al instalar servidores de terceros que no has auditado. Conectarte a un servidor MCP que encontraste en internet y que no escribiste tú es, en términos de seguridad, cercano en su naturaleza a instalar un paquete npm sin revisar o una extensión de navegador: estás concediendo a un trozo de código que no inspeccionaste la capacidad de ejecutarse con algunos de tus privilegios, y las intenciones y competencia de su autor pasan a formar parte de tu frontera de confianza, lo pretendieras o no.
• Aislamiento (sandboxing) débil en servidores ejecutados localmente. Muchos servidores MCP se ejecutan como procesos locales corrientes, lo que significa que normalmente se ejecutan con los mismos privilegios que el usuario que los arrancó —acceso completo a los archivos, credenciales y red de ese usuario, no a un subconjunto reducido y aislado—. Un fallo o una instrucción maliciosa dentro de ese servidor no queda contenido por nada que el propio protocolo proporcione.

Qué comprobar de verdad antes de conectar un servidor

Nada de esto es exótico una vez que lo planteas correctamente: un servidor MCP es código de terceros al que estás concediendo acceso a tu máquina o a tus datos, y merece exactamente el mismo escrutinio que le darías a cualquier otro trozo de código de terceros en esa posición.

• Revisa el código fuente si es abierto. Si no puedes o no vas a leer el código, trátalo como un coste real de usar el servidor, no como un trámite que saltarse.
• Prefiere servidores de mantenedores en los que realmente confíes —un proyecto u organización consolidados con trayectoria— antes que un script sin verificar de una fuente desconocida.
• Acota sus permisos al mínimo que la tarea necesite en lugar de aceptar cualquier acceso por defecto que el servidor pida. Si solo necesita acceso de lectura a un directorio, no le concedas toda tu carpeta personal.
• Ejecuta los servidores no confiables en un entorno aislado (sandbox) o en contenedor, de modo que un servidor comprometido o que se comporte mal no pueda llegar más lejos de lo previsto, aunque lo intente.
• Monitoriza y registra qué herramientas se llaman en realidad y con qué argumentos, para tener algo que examinar después en lugar de limitarte a confiar en que se comportó bien.

Esto es seguridad agéntica, una capa más abajo

Nada de esto es un problema separado del que se trata en los fundamentos de seguridad de la IA agéntica. Ese artículo habla en abstracto de lo que ocurre una vez que un agente obtiene acceso a herramientas y puede tomar acciones en el mundo: el riesgo de herramientas con permisos excesivos, la necesidad de aprobación humana en las acciones de consecuencia, la importancia de registrar lo que un agente hizo realmente. MCP es uno de los mecanismos concretos por los que un agente obtiene ese acceso a herramientas en primer lugar. Cada servidor MCP que conectas es una concesión de herramienta, y las mismas mitigaciones se aplican directamente, solo que acotadas a una pregunta concreta: ¿qué servidores MCP están conectados ahora mismo, y qué puede tocar realmente cada uno de ellos? Si ya piensas en los permisos de los agentes en términos de privilegio mínimo y de puertas de aprobación, conectar un servidor MCP es donde ese pensamiento tiene que aplicarse de verdad, no solo reconocerse.

Los protocolos que facilitan la integración siempre hacen que las fronteras de confianza sean más fáciles de difuminar; eso no es una crítica específica de MCP, es lo que ocurre siempre que «conectar cualquier cosa con cualquier cosa» se convierte en una acción de un clic en lugar de una decisión deliberada. Tratar cada conexión MCP como una decisión real de control de acceso, y no como una comodidad de un clic, es toda la mitigación en una sola frase.