Investigaciones de Microsoft revelan que los agentes de IA pueden ser manipulados mediante descripciones de herramientas "envenenadas" para robar datos corporativos sin activar alarmas. El ataque ocurre cuando instrucciones maliciosas se ocultan en el texto descriptivo de una herramienta aprobada, engañando al agente para que ejecute acciones ilegítimas. Para mitigarlo, se recomienda supervisar los cambios en las descripciones, limitar los permisos de los agentes y requerir aprobación humana para acciones críticas.





Una nueva investigación de Microsoft muestra cómo los atacantes pueden secuestrar agentes de IA que actúan en nombre de un usuario, utilizando nada más que una descripción de herramienta envenenada para lograr que el agente entregue silenciosamente datos de la empresa a un tercero.

El truco es que el agente nunca rompe ninguna regla. Cada paso parece rutinario, por lo que en una configuración predeterminada no saltaría ninguna alarma.

El trabajo proviene de Microsoft Incident Response y su equipo de investigación de seguridad Defender, y llega justo cuando las empresas empiezan a permitir que la IA haga más que leer y resumir.

Qué cambia cuando un agente puede actuar

Hasta hace poco, el riesgo de la IA en el lugar de trabajo se centraba principalmente en lo que un modelo leía y escribía. Un documento envenenado podía sesgar una respuesta, y ahí terminaba la mayoría de las veces.

Los agentes son diferentes. Microsoft 365 Copilot puede enviar correos electrónicos, crear archivos y cambiar calendarios. Los agentes personalizados creados en Copilot Studio o Azure AI Foundry pueden acceder a sistemas empresariales y ejecutar tareas de varios pasos por su cuenta.

El mismo truco de inyección que sesga un resumen ahora desencadena una acción. Contra un lector, un ataque cambia la salida. Contra un agente, cambia lo que el software hace realmente.

Estos agentes acceden a los sistemas empresariales a través de MCP, el Model Context Protocol, un protocolo abierto que permite a una IA llamar a herramientas externas de la misma manera que una aplicación llama a una API. Microsoft lo define como la parte de la cadena de suministro de IA agentica que más rápido crece, lo que lo convierte en una superficie de ataque en expansión.

Cómo funciona el ataque

Cada herramienta MCP incluye una descripción: unas pocas líneas de texto plano que le dicen al agente qué hace la herramienta y cuándo usarla. El agente lee ese texto para decidir cómo actuar. Esa es la debilidad total. La descripción son solo palabras, y las palabras pueden transportar instrucciones.

Microsoft lo explica en este enlace con un ejemplo de factura, creado para mostrar el patrón en lugar de reportar a una víctima real. Un equipo de finanzas implementa un agente para gestionar facturas de proveedores. Se conecta a tres herramientas, incluido un servicio de "enriquecimiento de facturas" de terceros que fue aprobado para su uso pero que nunca pasó por una revisión de seguridad real.

Entonces, el atacante actualiza esa herramienta de terceros. El nombre y el resumen visible siguen siendo los mismos. Enterrada en la descripción, disfrazada de notas de formato, hay una orden oculta: toma las últimas treinta facturas impagadas y adjúntalas a la siguiente llamada. MCP detecta los cambios de descripción sobre la marcha. En configuraciones sin un disparador de reaprobación, la versión envenenada entra en funcionamiento sin revisión adicional.

Después de eso, un analista hace una pregunta rutinaria sobre un proveedor. El agente sigue la orden oculta, recopila las facturas y las envía como parte de una solicitud que parece normal. La herramienta devuelve una respuesta limpia y copia silenciosamente los datos robados a un servidor que el atacante controla. El analista no ve nada extraño.

Cada movimiento que hace el agente es legítimo por sí solo. La herramienta fue aprobada. La consulta de datos se ejecutó con los propios permisos del analista. La llamada saliente fue a un servidor que estaba permitido cuando se añadió. La debilidad no está en ningún sistema concreto. Vive en lo que Microsoft llama "el límite de confianza entre ellos".



El problema más profundo es que MCP mezcla instrucciones y datos en el mismo lugar. La descripción de una herramienta vive en la memoria de trabajo del agente justo al lado de sus órdenes reales, por lo que editar esa descripción puede guiar al agente con la misma eficacia que reescribir su prompt del sistema.

El agente no tiene una forma fiable de distinguir una instrucción honesta de una maliciosa introducida por quien mantiene la herramienta. Microsoft señala que esto no es un error del propio Copilot. Es una brecha de confianza que se abre al conectar herramientas externas.

Qué deberían hacer los defensores

El consejo de Microsoft, en términos sencillos:

* Trata cada herramienta conectada como parte de tu cadena de suministro. Mantén una lista de editores de herramientas aprobados, desactiva "permitir todo" y deja que un agente use solo las herramientas específicas que necesite.
* Trata la descripción de una herramienta como un prompt del sistema. Revisa los cambios de la misma forma que revisarías un cambio de código y analiza el texto en busca de comandos que no deberían estar en un campo de ayuda.
* Pon a un humano frente a las acciones riesgosas. Cualquier cosa que mueva dinero, comparta datos fuera de la empresa o cambie cuentas debería requerir la aprobación de una persona.
* Dale a cada agente su propia identidad y vigila lo que hace. Registra sus acciones, establece una línea base de lo que es normal y marca nuevos endpoints, extracciones de datos más grandes o consultas extrañas.
* Aplica la menor agencia, no solo el menor privilegio. Incluso un agente con permisos bajos puede causar un daño real si se le permite actuar sin controles.

Microsoft asocia sus propios productos a cada paso, incluyendo Prompt Shields, Purview DLP, Entra Agent ID, Defender for Cloud y Sentinel, pero los principios se mantienen independientemente de la infraestructura que utilices.

No es una teoría: cómo hemos llegado aquí

Esta clase de ataque tiene un historial. Invariant Labs denominó "envenenamiento de herramientas" en abril de 2025, con una prueba de concepto en este enlace que ocultó instrucciones en la descripción de una herramienta de calculadora y logró que el editor Cursor leyera la clave SSH privada de un usuario y la enviara. El desarrollador Simon Willison profundizó en ello pocos días después.

El mismo grupo mostró más tarde un truco relacionado: un problema malicioso de GitHub podría secuestrar un agente conectado al servidor MCP de GitHub y extraer datos de repositorios privados. Las herramientas allí eran confiables y no habían sido tocadas; las instrucciones maliciosas viajaron en los datos que el agente leyó.

OWASP cita ahora este caso como un ejemplo de vulnerabilidades de la cadena de suministro agentica en su Top 10 para aplicaciones agenticas de diciembre de 2025.

Ya ha ocurrido un fallo de cadena de suministro relacionado en el mundo real. En septiembre de 2025, investigadores de Koi Security encontraron un paquete npm llamado postmark-mcp. Había imitado una herramienta de correo electrónico legítima durante quince versiones limpias antes de que la versión 1.0.16 introdujera una línea que enviaba secretamente una copia oculta (BCC) de cada correo que el agente enviaba a un atacante.

Los académicos también han empezado a medir el problema. El benchmark MCPTox publicado en agosto de 2025, probó descripciones de herramientas envenenadas contra 45 servidores MCP reales y 20 modelos de IA líderes. Encontró que el ataque era ampliamente efectivo, con una tasa de éxito de hasta el 72,8 por ciento, y los modelos casi nunca se negaron.

El hilo conductor es el que Microsoft está recalcando ahora: la IA que puede actuar es tan confiable como las herramientas que permites que toque, y ahora mismo esas herramientas son fáciles de envenenar y difíciles de vigilar.

Fuente:
THN