Seguridad MCP: los riesgos que hereda tu agente de IA

La seguridad MCP evita que las herramientas a las que tu agente de IA accede mediante el Model Context Protocol (MCP) se vuelvan en tu contra. Cada conexión pasa por un programa llamado servidor MCP, así que cualquier fallo o instrucción plantada en él se convierte en tu problema. Entre los riesgos clave están los comandos ocultos en las respuestas de una herramienta, los cambios dañinos después de la aprobación y las solicitudes enviadas a cualquier dirección sin controles.

Tus desarrolladores pueden conectar una nueva herramienta a tu IA en una tarde, a menudo con un servidor copiado de GitHub que nadie más ha revisado. A partir de ese momento, ese código comparte el acceso de tu agente a datos y acciones. En 2026, incluso Google y JPMorgan Chase tuvieron que corregir el mismo fallo en software MCP creado por sus propios ingenieros, y alguien intentó colar un servidor malicioso en 23 proyectos de IA en 74 minutos.

Durante las pruebas de agentes de IA, los especialistas de QAwerk examinan cada conexión como lo haría un intruso. Nuestros Bug Crawls, en los que probamos aplicaciones populares y publicamos lo que encontramos, muestran por qué es importante. En Otter.ai, un asistente de reuniones con IA, bastó una sola pregunta escrita para que el chatbot listara sus herramientas internas y sus parámetros, lo que da a un atacante un mapa de dónde apuntar. Todo lo que cuenta este artículo viene de ese trabajo, para que sepas qué preguntar antes de que tu agente se conecte a su próximo servidor.

¿Qué protege la seguridad MCP?

La seguridad MCP protege los datos, las acciones y las credenciales que tu agente obtiene de cada conexión. En el fondo, MCP es un estándar abierto que permite a la IA conectarse a herramientas externas de una forma común. Por ejemplo, en cuanto añades un servidor de calendario, tu agente puede de repente leer reuniones, enviar invitaciones y actuar con el inicio de sesión de la cuenta.

Cada nuevo servidor MCP puede dar a tu agente tres tipos de acceso:

• Datos: Todo lo que el servidor puede leer, desde registros de clientes hasta documentos internos
• Acciones: Todo lo que el servidor permite hacer al agente, como enviar mensajes, editar registros o ejecutar comandos
• Credenciales: Las contraseñas y claves de acceso que el servidor guarda para llegar a otros sistemas

Quien controle un servidor, o cuele instrucciones en sus respuestas, puede llegar a los tres a través de tu agente. Cuánto acceso debería tener cualquier agente en el conjunto de sus herramientas es una cuestión más amplia, que tratamos en seguridad de la IA agéntica.

¿Qué riesgos de seguridad MCP trae cada nuevo servidor?

La mayoría de los riesgos de seguridad MCP se remontan a un servidor en el que tu equipo confió sin revisarlo. El Open Worldwide Application Security Project (OWASP), una organización sin ánimo de lucro cuyas listas de verificación se usan ampliamente en el sector, publica ahora un top 10 específico para MCP, todavía en beta. La mayoría de los riesgos siguientes aparecen en esa lista:

• Órdenes ocultas en las respuestas de las herramientas: Un agente lee todo lo que un servidor le devuelve, ya sea una página web, un correo electrónico o una entrada de base de datos. Si un atacante plantó instrucciones en ese contenido, el agente puede seguirlas como si vinieran de ti. Este ataque se llama inyección indirecta de prompts, y las respuestas de las herramientas son una de sus vías de entrada más fáciles.
• Servidores que cambian después de la aprobación: Un servidor puede pasar la revisión el primer día y reescribir sus propias instrucciones más adelante. La sección sobre el envenenamiento de herramientas MCP, más abajo, explica cómo funciona ese truco.
• Servidores que consultan cualquier dirección: Muchos servidores descargan páginas o llaman a otros servicios en nombre del agente. Sin un control del destino, un atacante puede llevar al agente a hacer que el servidor contacte con sistemas internos.
• Conexiones con demasiado poder: Un servidor creado para leer archivos también podría borrarlos o enviarlos a otro lugar. Los agentes toman el camino más corto que permite una conexión, como descubrió un desarrollador cuando un asistente de reservas con IA canceló la reserva de otro socio para liberar una plaza en una clase del gimnasio.
• Servidores desconocidos: A veces los desarrolladores añaden servidores por su cuenta, sin avisar a la persona que aprueba las herramientas. OWASP los llama servidores MCP en la sombra (shadow MCP servers), y nadie puede revisar una conexión cuya existencia desconoce.
• Sin registro de las llamadas a herramientas: Sin logs, nadie puede saber después qué pidió el agente a un servidor ni qué recibió.

Cómo viaja una instrucción plantada entre agentes

Las órdenes ocultas en las respuestas de las herramientas son más difíciles de rastrear cuando los agentes trabajan en equipo. Muchos productos usan un agente orquestador, un coordinador que divide un trabajo y entrega cada parte a un subagente especializado. El investigador de seguridad independiente Syed Anas Mohiuddin llama al ataque resultante protocol pivoting. La cadena se desarrolla en tres pasos:

1. Un atacante planta texto en un contenido que devolverá una herramienta MCP. El texto está escrito para parecer una solicitud de tarea en el formato que usan los agentes para comunicarse entre sí.
2. El agente orquestador lee la respuesta de la herramienta y transmite la tarea. Para el orquestador, la solicitud plantada parece trabajo normal.
3. Un subagente ejecuta la tarea. Como la solicitud llega desde el orquestador, el subagente no tiene motivos para cuestionar dónde se originó la orden.

En el último paso, ningún agente de la cadena puede saber que la instrucción la escribió alguien de fuera. Los traspasos fallan de muchas otras maneras, como muestra nuestro análisis sobre las pruebas de sistemas de IA multiagente.

Envenenamiento de herramientas MCP: cuando un servidor de confianza cambia de idea

El envenenamiento de herramientas MCP (MCP tool poisoning) es un ataque que esconde instrucciones en las descripciones de un servidor, las notas breves que indican a un agente cuándo y cómo usar cada función. Las personas rara vez las leen, pero la IA trata cada línea como una pauta. Por eso, unas notas envenenadas pueden dirigir al agente hacia secretos o cambiar el comportamiento de otras herramientas.

Una de las versiones más difíciles de detectar es la diferida, en la que un servidor se comporta bien durante la revisión, obtiene la aprobación y solo entonces reescribe sus propias descripciones. El 10 de agosto de 2026, alguien intentó exactamente eso a gran escala. En una campaña de la que informó la empresa Pillar Security, 23 pull requests, es decir, propuestas de cambio en el código de un proyecto, llegaron a 23 proyectos de IA en GitHub en 74 minutos. Cada propuesta pretendía añadir el mismo servidor MCP malicioso.

Según el resumen trimestral de exploits de OWASP, el servidor se comportó con normalidad durante sus tres primeras llamadas a herramientas. Tras la tercera llamada, reescribió sus propias descripciones de herramientas para dirigir al agente conectado hacia los archivos más valiosos del ordenador de un desarrollador:

• Claves SSH, que dan acceso a servidores remotos
• Credenciales de inicio de sesión de cuentas en la nube de Amazon Web Services
• El historial de comandos escritos en el ordenador, que a veces contiene contraseñas
• El archivo de configuración que controla los clústeres de servidores Kubernetes de una empresa

El servidor nunca abrió esos archivos directamente. En su lugar, usó al agente de confianza para recopilarlos e intentó ocultar la actividad a las personas que gestionaban el sistema.

Ninguna de las pull requests se fusionó, y OWASP no informa de ninguna intrusión confirmada. Aun así, un servidor que supera una inspección puede volverse hostil más adelante. Para protegerse, OWASP recomienda registrar las descripciones de herramientas de cada servidor en el momento de la aprobación y exigir una nueva revisión cada vez que cambien.

Por qué Google y JPMorgan Chase lanzaron el mismo fallo MCP

Muchos servidores MCP consultan páginas web o llaman a otros servicios en cualquier dirección que indique el agente. Si el servidor nunca comprueba el destino, cualquiera que dirija al agente puede llegar a sistemas que deberían seguir siendo privados, como la red interna de una empresa. Esta debilidad se llama falsificación de solicitudes del lado del servidor (SSRF).

En 2026, Google, JPMorgan Chase, Weaviate, la agencia digital de Francia y el gobierno de una ciudad de Indonesia cometieron este error, porque comprobar cada solicitud saliente es un paso fácil de saltarse. El investigador de seguridad Syed Anas Mohiuddin lo notificó a los cinco equipos, que no comparten código ni propietarios, y todos lo han corregido desde entonces:

• Google: MCP Toolbox for Databases, con una gravedad alta de 8,0 sobre 10 (CVE-2026-14540)
• JPMorgan Chase: Un servidor de código abierto para buscar documentación
• Weaviate: El conector de la empresa de bases de datos con los servicios de Google
• DINUM (la agencia digital de Francia): El servidor oficial de la plataforma nacional de datos abiertos del país
• Tangerang (el gobierno de una ciudad de Indonesia): Un servidor de monitorización de seguridad que afirmaba proteger contra SSRF, pero solo bloqueaba direcciones numéricas sin procesar

Según TNW, otros cinco servidores MCP gestionados por una oficina federal de EE. UU., entre ellos uno para solicitudes de prestaciones de Asuntos de Veteranos, seguían pendientes de corrección en octubre. No se ha confirmado ninguna exposición de datos.

Incluso un servidor de una marca famosa necesita que se prueben sus solicitudes salientes antes de que tu agente dependa de él.

Qué revisar antes de que tu agente use un servidor MCP

Una buena seguridad MCP significa tratar cada servidor como cualquier código externo del que dependa tu producto. Lo que puedes revisar varía según el origen:

En cualquier caso, cada una de las afirmaciones siguientes debería cumplirse antes de que tu agente empiece a usar el servidor:

• Sabes quién mantiene el servidor. Un responsable identificado, actualizaciones recientes y una forma de informar de problemas significan que las correcciones te llegarán de verdad.
• El servidor solo llega a las direcciones que necesita. Durante las pruebas de API, las solicitudes a sistemas internos y a destinos inesperados deberían fallar siempre.
• La conexión concede solo lo que exige la tarea. Un agente de soporte que consulta pedidos no puede emitir reembolsos, y el acceso de solo lectura es la opción por defecto siempre que sea posible.
• El servidor tiene sus propias credenciales limitadas. Sus claves de acceso caducan pronto y no abren nada más allá de la función del servidor.
• Las descripciones de herramientas se registran en la aprobación. Cualquier cambio posterior activa una nueva revisión antes de que el agente vuelva a usar el servidor.
• Las respuestas de las herramientas cuentan como información, nunca como órdenes. Los testers han plantado instrucciones en el contenido que devuelve el servidor y han confirmado que el agente las ignora.
• Una persona aprueba las acciones de riesgo. El agente no puede hacer pagos, borrar registros ni enviar mensajes a clientes hasta que alguien de tu equipo diga que sí.
• Cada llamada a una herramienta queda registrada. Puedes ver después qué pidió el agente y qué recibió.
• Alguien ajeno al equipo de desarrollo ha probado la conexión. Los desarrolladores confirman que un servidor funciona, mientras que un tester independiente comprueba cómo se comporta cuando alguien intenta romperlo.

Cuando una conexión llega a registros de clientes o a dinero, esta lista se convierte en el alcance inicial de las pruebas de penetración de IA. En ese tipo de prueba, los especialistas atacan al agente y a sus servidores como lo haría un intruso real. Nuestros ingenieros mapean cada servidor al que puede llamar tu agente, prueban cada uno con todos los puntos anteriores y entregan a tu equipo un informe de lo que resiste y de lo que hay que corregir antes del lanzamiento.

¿No sabes hasta qué punto son seguras las conexiones de tu agente? Habla con nuestro equipo de seguridad.

Preguntas frecuentes

¿Es seguro MCP?

La seguridad MCP depende de los servidores que añadas, ya que MCP en sí es solo un estándar común que permite a los agentes de IA usar herramientas externas. El protocolo no comprueba si una herramienta conectada es honesta o está bien construida. Esa tarea corresponde al equipo que aprueba cada conexión, así que un agente es tan seguro como el servidor menos probado del que depende.

¿Debería usar servidores MCP de terceros?

Sí, siempre que evalúes un servidor MCP de terceros como evaluarías a un nuevo proveedor de software. Busca un responsable de mantenimiento activo, un historial público de correcciones y una documentación clara de aquello a lo que puede acceder. Concede el conjunto mínimo de permisos que permita hacer el trabajo y revisa la configuración tras cada actualización, porque un servidor aprobado puede cambiar su comportamiento más adelante.

¿Cómo se protege un servidor MCP?

Proteger un servidor MCP requiere varias capas de protección, y tres son las más importantes. Empieza por limitar el acceso, de modo que la conexión solo llegue a los sistemas y acciones que exige su función, con claves que caduquen pronto. Registrar cada solicitud y cada respuesta permite después a tu equipo ver exactamente qué hizo el agente de IA. La última capa es una prueba externa, en la que especialistas intentan colar comandos ocultos en los datos que devuelve el servidor.