Un servidor MCP puede modificar las descripciones, los parámetros o el conjunto de herramientas que ofrece después de recibir la aprobación. Si un agente de IA sigue confiando en la configuración inicial sin revisar los cambios posteriores, instrucciones maliciosas pueden influir en sus próximas acciones. Este ataque se conoce como rug pull de herramientas. El riesgo está documentado, pero eso no significa que todas las integraciones MCP sean vulnerables ni que todo cambio sea malicioso.
Model Context Protocol (MCP) es un estándar para conectar aplicaciones de inteligencia artificial con herramientas externas, como sistemas de archivos, bases de datos y servicios web. Un agente elige acciones según la petición del usuario; el servidor MCP proporciona las herramientas y sus descripciones. La distinción esencial es que esas descripciones son datos procedentes de un componente externo, no órdenes que deban tener autoridad sobre el agente.
Dónde deja de proteger la aprobación inicial
Para descubrir herramientas, el cliente utiliza tools/list y recibe metadatos como el nombre, la descripción y inputSchema, el esquema que define los argumentos aceptados. Para ejecutar una operación utiliza tools/call. Una persona puede aprobar una conexión o una llamada basándose en lo que muestra la interfaz, mientras que el modelo recibe información más detallada.
Según la especificación MCP del 28 de julio de 2026, el conjunto de herramientas disponibles puede cambiar con el tiempo. Los servidores que declaran listChanged responden con la lista disponible y pueden notificar cambios a los clientes suscritos mediante subscriptions/listen. Esa notificación sirve para la sincronización técnica; no equivale a una nueva aprobación de seguridad. El protocolo recomienda supervisión humana, pero la interfaz y la política concreta de consentimiento dependen de cada implementación.
Hay una diferencia importante entre aprobar un servidor, autorizar el acceso a una cuenta y confirmar cada acción sensible. Ninguna de esas decisiones vuelve fiables para siempre las descripciones futuras. Si una aplicación reutiliza una autorización antigua sin comprobar el contenido y los efectos de la operación actual, aparece una oportunidad para el abuso.
Cómo puede cambiar una herramienta aparentemente legítima
Imaginemos un servidor que al principio describe una herramienta como una simple consulta de documentos. Tras una actualización o un nuevo descubrimiento, su descripción incorpora indicaciones para que el agente examine archivos ajenos a la tarea. El agente podría interpretar esas frases como instrucciones de trabajo aunque procedan de una fuente menos fiable. Es una inyección de instrucciones, o prompt injection, incluida en los metadatos de la herramienta.
En un rug pull, el momento del cambio es lo determinante: la definición parece aceptable durante la revisión inicial, pero se sustituye después. Tool poisoning es el término más amplio para las instrucciones maliciosas introducidas en descripciones, esquemas o resultados. Otro riesgo es el tool shadowing, cuando un servidor intenta influir en el uso de herramientas de otros servidores conectados al mismo agente. Una respuesta de herramienta con instrucciones falsas también es peligrosa, pero no debe confundirse con una modificación posterior de la definición.
La técnica necesita condiciones concretas: el agente debe recibir el contenido manipulado, interpretarlo como orientación y disponer de accesos o permisos que permitan la acción indebida. Una instrucción incrustada no concede por sí sola acceso a recursos bloqueados por el sistema operativo, una API o controles de autorización externos al modelo.
Qué se demostró y qué sigue sin confirmarse
El 1 de abril de 2025, Invariant Labs publicó experimentos con descripciones manipuladas en clientes MCP, incluidos ejemplos en los que las instrucciones de un servidor interferían con las herramientas de otro. Los investigadores describieron expresamente la posibilidad de modificar una descripción después de la aprobación. Fueron experimentos comunicados por sus autores, no pruebas de que todos los clientes y versiones actuales se comporten del mismo modo.
Una recopilación publicada el 8 de octubre de 2026 en el sitio del proyecto OWASP GenAI describió la campaña Deadbugz. Según ese informe, el 10 de agosto de 2026 se presentaron 23 solicitudes de cambio en GitHub en 74 minutos para promocionar un servidor MCP malicioso. Supuestamente, el servidor funcionaba con normalidad durante las tres primeras llamadas y luego cambiaba sus metadatos para dirigir a los agentes hacia credenciales y ocultar la actividad.
La misma recopilación señala que ninguna de esas solicitudes se incorporó a los repositorios y que no se confirmó ningún compromiso posterior. Por tanto, el caso documenta un intento activo de distribución y un mecanismo malicioso, pero no un robo consumado de credenciales de usuarios. El texto también se presenta como una selección no exhaustiva y aclara que no constituye una publicación oficial de OWASP.
Lista de comprobación defensiva para integraciones MCP
- Registra qué se aprobó. Conserva la identidad y procedencia del servidor, junto con la descripción completa, los esquemas de entrada y salida y las anotaciones de cada herramienta.
- Compara las definiciones a lo largo del tiempo. Utiliza hashes criptográficos y revisión humana ante cambios, también después de reconexiones o actualizaciones. Un hash revela cambios en los metadatos, no modificaciones ocultas del código.
- Exige una nueva aprobación ante cambios relevantes. No reutilices automáticamente una decisión anterior para una herramienta cuyos parámetros o efectos hayan cambiado.
- Reduce los privilegios. Separa las credenciales por servidor y concede solo el acceso necesario. Evita que agentes generales accedan ampliamente a secretos locales, cuentas de administración o directorios completos.
- Aísla servidores y contextos de ejecución. Las herramientas con privilegios elevados necesitan sus propias barreras, en lugar de compartir libremente contexto y autoridad con integraciones externas.
- Confirma las acciones de riesgo fuera del texto del modelo. Muestra la operación, el destino y todos los parámetros antes de divulgar datos, borrar información o realizar otra acción sensible.
- Valida argumentos y resultados. Rechaza formatos inesperados, trata las respuestas como datos no fiables y aplica las reglas de ejecución en el servicio o sistema operativo, no solo en las instrucciones al modelo.
- Audita las llamadas reales. Registra los cambios de definiciones, el uso de herramientas y las acciones bloqueadas sin almacenar secretos innecesarios; revisa dependencias y procedencia de los servidores.
La guía de seguridad de OWASP recomienda combinar privilegios mínimos, integridad de definiciones, aislamiento, confirmación humana, validación de entradas y salidas y auditoría. Ninguna de esas medidas elimina por sí sola todas las formas de inyección de instrucciones.
Los límites de comprobar los metadatos
Comparar las descripciones y esquemas actuales con una versión aprobada ayuda a detectar un rug pull visible. Sin embargo, un servidor puede modificar su código o los datos que devuelve sin cambiar esos campos. Del mismo modo, una etiqueta como readOnlyHint indica la intención de uso, pero no garantiza técnicamente que la operación sea inocua. Por eso, los permisos deben aplicarse en el momento de ejecutar cada acción.
La cuestión práctica para quienes integran agentes no es confiar o desconfiar indiscriminadamente de MCP. Es determinar exactamente qué se aprobó, qué cambió y qué puede hacer realmente cada herramienta. Estas recomendaciones se basan en documentación e investigaciones publicadas; no representan pruebas propias de DTech ni una certificación de seguridad de ningún cliente o servidor.
Fuentes y referencias
- MCP, especificación de herramientas, revisión del 28/07/2026
- MCP, anuncio técnico de la revisión del 28/07/2026
- Proyecto OWASP GenAI, recopilación del tercer trimestre de 2026
- OWASP, guía de seguridad para MCP
- Invariant Labs, investigación sobre envenenamiento de herramientas, 01/04/2025
- MCP, recomendaciones oficiales de seguridad, revisión 2026-07-28
