Seguramente nunca lo has configurado tú, pero es probable que algún asistente de IA que usas ya lo hable. El Model Context Protocol (MCP) es el estándar que permite a los agentes de inteligencia artificial conectarse con herramientas y fuentes de datos: consultar una base de datos, buscar en una documentación o leer una API pública. Ars Technica ha publicado un análisis que lo señala como uno de los protocolos más arriesgados del momento. El motivo no es un error de programación aislado, sino un problema de diseño: los agentes se fían demasiado unos de otros.

El análisis parte del trabajo del investigador independiente Syed Anas Mohiuddin. En mayo de 2026 hizo una predicción: si la debilidad era estructural, el mismo fallo aparecería en servidores MCP escritos por equipos que no comparten código, sector ni país. En octubre ha publicado el resultado, y la predicción se ha cumplido.

Cómo funciona MCP y dónde se rompe

Un agente de IA no sabe consultar una base de datos por sí solo. Para hacerlo llama a un servidor MCP, una pieza intermedia que recibe la petición del agente, la ejecuta y le devuelve el resultado. Es cómodo y flexible, pero obliga a decidir cuánto hay que fiarse de lo que pide el agente y de lo que llega de vuelta.

Según el investigador, muchos servidores dan las dos cosas por buenas. Eso provoca dos tipos de fallo:

• Falsificación de peticiones desde el servidor (SSRF). El servidor construye una conexión a partir de una dirección, ruta o URL que le pasa el agente, pero no comprueba adónde apunta en realidad. Quien controle al agente puede hacer que el servidor llame a sistemas internos que nunca deberían verse desde fuera.
• Datos sensibles mal guardados. Algunos servidores copian en sus registros (logs) las respuestas completas de las API con las que trabajan, sin tapar nada. Basta un error corriente para que esa información acabe almacenada donde no debe.

El mismo patrón de SSRF apareció y se corrigió en cinco organizaciones sin relación entre sí: Google (en su MCP Toolbox for Databases, registrado como CVE-2026-14540), JPMorgan Chase, la empresa de bases de datos Weaviate, la dirección digital interministerial de Francia y el ayuntamiento de Tangerang, en Indonesia. Cada caso tenía su variante. En uno, el cliente HTTP no limitaba las redirecciones ni revisaba las direcciones IP. En otro, una herramienta usaba una lista de destinos permitidos y su herramienta hermana aceptaba cualquier URL. En otro, se bloqueaban las IP escritas tal cual, pero no los nombres de dominio que llevaban a ellas. Según las publicaciones que recogen el caso, varios servidores de otras administraciones seguían en revisión o sin corregir.

El salto de agente a agente

Lo más inquietante llega cuando entran en juego varios agentes a la vez. Hoy es habitual que un agente coordinador (el «orquestador») reparta tareas entre agentes especializados. Para que se entiendan existe otro protocolo, A2A (Agent-to-Agent), impulsado por Google.

Mohiuddin llama a este ataque «protocol pivoting», algo así como saltar de un protocolo a otro. Funciona así:

• El atacante esconde un texto en un contenido que acabará devolviendo una herramienta MCP, por ejemplo una página o un documento.
• Ese texto imita el formato de una tarea A2A.
• El orquestador lo recibe y lo reenvía a un subagente como si fuera un encargo más.
• El subagente lo ejecuta porque confía en el orquestador.

Es una variante de la inyección indirecta de instrucciones (prompt injection): la orden maliciosa no la escribe el usuario, viene escondida en los datos. Lo grave es que nadie hace nada raro, porque cada pieza cumple su función. Douglas McKee, de la firma de seguridad Rapid7, lo resumía así en declaraciones recogidas por Ars Technica:

«Cada pieza de esa cadena hizo exactamente lo que estaba diseñada para hacer, y eso es lo que lo hace tan difícil de detectar».

A esto se suma que muchos agentes especializados tienen protecciones débiles, o ninguna, contra este tipo de inyección. Se da por hecho que el filtro ya lo ha puesto alguien antes en la cadena.

Qué cambia para el usuario y cuál es la letra pequeña

Para quien solo usa un asistente de IA, el riesgo no es inmediato ni depende de lo que haga. Los fallos descritos están en servidores que montan empresas y organismos, y los que se conocen se han ido corrigiendo: Google añadió protecciones contra el DNS rebinding (una técnica para engañar al servidor sobre la dirección real de destino) y listas de rangos de IP permitidos y prohibidos, y Weaviate limitó los destinos a los servidores de la API de Google.

La letra pequeña es que arreglar cada servidor no resuelve el problema de fondo. El protocolo no exige comprobar lo que cruza de una pieza a otra, y cada equipo tiene que acordarse de hacerlo por su cuenta. Las medidas razonables son conocidas, aunque no siempre se aplican:

• Comprobar adónde lleva de verdad cada URL antes de conectarse, también después de una redirección.
• Limitar los destinos a una lista cerrada de servicios permitidos.
• Tapar los datos sensibles antes de escribir nada en los registros.
• Tratar lo que devuelve una herramienta como datos, nunca como órdenes, aunque llegue de otro agente «de confianza».

Por qué importa

Los agentes de IA están pasando de responder preguntas a actuar: leer bases de datos, llamar a servicios y encargar tareas a otros agentes. Cuantos más eslabones tiene la cadena, más importa saber en qué se confía y por qué. El caso de MCP muestra que un fallo de diseño se repite en lugares que no tienen nada que ver entre sí, porque cada equipo comete el mismo error por su cuenta. La lección vale para cualquier sistema que conecte agentes: la confianza no se hereda, hay que comprobarla en cada salto.