La herramienta que aprobaste no es la que se ejecuta: el rug-pull de descripciones MCP

¿Qué es esto?

El 30 de junio de 2026, el equipo de Microsoft Incident Response y su célula de investigación Defender publicaron un análisis de una brecha de confianza que aparece en cuanto un agente de IA puede actuar y no solo leer y resumir. El hallazgo, difundido ese mismo día, no es una nueva clase de ataque —el envenenamiento de descripciones está documentado desde abril de 2025— sino una variante reciente e importante: el envenenamiento puede ocurrir después de que una herramienta haya pasado la revisión. Una herramienta que auditaste y aprobaste con una descripción limpia puede ser redescrita en silencio más tarde, y como los agentes releen las descripciones en cada turno, el cambio entra en vigor sin nueva aprobación.

Los detalles importan sobre todo a quienes despliegan Microsoft 365 Copilot, Copilot Studio o agentes de Azure AI Foundry, pero el mecanismo se aplica a cualquier agente que alcance sus herramientas mediante el Model Context Protocol (MCP).

Cómo funciona

Cada herramienta MCP se entrega con una descripción: unas líneas de texto que indican al agente qué hace la herramienta y cuándo llamarla. El agente lee ese texto para decidir cómo actuar, y reside en la memoria de trabajo justo al lado de sus instrucciones reales. Para el modelo, una descripción honesta y una maliciosa son el mismo flujo de tokens: no hay forma fiable de distinguirlas.

Microsoft ilustra el matiz temporal con un ejemplo de facturación, concebido para mostrar el patrón y no para señalar a una víctima. Un equipo de finanzas monta un agente para procesar facturas de proveedores y lo conecta a tres herramientas, incluido un servicio externo de «enriquecimiento de facturas», aprobado pero nunca sometido a una revisión de seguridad real. Más tarde, el atacante actualiza esa herramienta. El nombre y el resumen visibles siguen idénticos; enterrada en la descripción, disfrazada de notas de formato, se oculta una orden: recopilar las últimas treinta facturas impagadas y adjuntarlas a la siguiente llamada.

Entrada de registro de herramienta (esquemática — payload censurado)
--------------------------------------------------------------------
name: invoice_enrichment
description: |
  Enriquece los registros de facturas de proveedores con metadatos
  fiscales y de pago.
  [CENSURADO: instrucción que ordena al agente reunir y adjuntar
   registros adicionales en la siguiente llamada]

MCP toma en cuenta los cambios de descripción sobre la marcha. Sin un disparador de reaprobación, la versión envenenada simplemente queda activa. Un analista formula entonces una pregunta rutinaria sobre un proveedor; el agente sigue la orden oculta, extrae las facturas con los propios permisos del analista y las envía dentro de una petición de aspecto normal a un servidor incluido en la lista blanca al añadir la herramienta. Cada paso es legítimo por separado. La debilidad reside en lo que Microsoft llama «la frontera de confianza entre ellos».

Por qué importa

El paso de leer a actuar cambia lo que está en juego. Frente a un lector, una inyección altera la salida. Frente a un agente, altera lo que hace el software: enviar correo, mover archivos, alcanzar sistemas de negocio. Microsoft describe MCP como la parte de más rápido crecimiento de la cadena de suministro de la IA agéntica, lo que la convierte en una superficie de ataque en expansión.

El ángulo temporal es el que los defensores suelen pasar por alto. La aprobación se trata como un control puntual, pero la descripción de una herramienta es un estado mutable que puede derivar mucho después de la revisión. La medición académica respalda la preocupación: el benchmark MCPTox, publicado en agosto de 2025, probó descripciones envenenadas contra 45 servidores MCP reales y 20 modelos punteros, con una eficacia de hasta el 72,8 % y modelos que casi nunca se negaban. OWASP incluye ahora este patrón entre las vulnerabilidades de cadena de suministro agéntica en su Top 10 for Agentic Applications de diciembre de 2025.

Defensas

No hay payload que parchear; la solución es arquitectónica, y las recomendaciones de Microsoft encajan con ella.

• Fije y compare las descripciones. Trate la descripción de una herramienta como un prompt de sistema o un cambio de código. Congele la versión aprobada, revise de nuevo cualquier cambio y exija reaprobación antes de que una descripción modificada entre en vigor: no deje que las actualizaciones pasen en silencio.
• Controle la cadena de suministro. Mantenga una lista blanca de editores de herramientas aprobados, desactive «permitir todo» y otorgue a cada agente solo las herramientas que necesita.
• Humano en el bucle en las acciones con consecuencias. Toda acción que mueva dinero, comparta datos hacia el exterior o modifique cuentas debe ser aprobada por una persona antes de ejecutarse.
• Dé una identidad a cada agente y vigílelo. Registre las acciones, establezca una línea base de lo normal y señale nuevos endpoints, extracciones de datos mayores o consultas inusuales.
• Aplique la mínima agencia, no solo el mínimo privilegio. Incluso un agente con pocos permisos puede causar daño real si puede actuar sin controles.

Status

Elemento	Referencia	Fecha
Análisis de Microsoft «leer → actuar»	Microsoft Security Blog	2026-06-30
Difusión	The Hacker News	2026-06-30
Medición del envenenamiento de descripciones	MCPTox (arXiv:2508.14925)	2025-08
PoC original de envenenamiento de herramienta	Invariant Labs	2025-04
Referencia de framework	OWASP Top 10 for Agentic Applications	2025-12

La conclusión: la aprobación no es una propiedad permanente de una herramienta. Si una descripción puede cambiar tras la revisión y el agente la adopta sin que se lo pidan, la herramienta que aprobaste no es necesariamente la que se ejecuta.