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 hacer que el agente entregue silenciosamente los datos de la empresa a un extraño.
El truco es que el agente nunca infringe una regla. Cada paso parece rutinario, por lo que en una configuración predeterminada no se puede activar ninguna alarma.
El trabajo proviene de Microsoft Incident Response y su equipo de investigación de seguridad Defender, y llega cuando las empresas comienzan 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 enmarcaba principalmente en lo que leía y escribía un modelo. Un documento envenenado podía distorsionar una respuesta, y ahí fue donde terminó.
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 los sistemas empresariales y ejecutar trabajos de varios pasos por sí solos.
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 realmente hace el software.
Estos agentes llegan a los sistemas empresariales a través de MCP, el protocolo de contexto modelo, 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 la llama la parte de más rápido crecimiento de la cadena de suministro de IA agente, lo que la convierte en una superficie de ataque en expansión.
Cómo funciona el ataque
Cada herramienta MCP viene con una descripción: unas pocas líneas de texto sin formato que le dicen al agente qué hace la herramienta y cuándo usarla. El agente lee ese texto para decidir cómo actuar. Ésa es toda la debilidad. La descripción son sólo palabras, y las palabras pueden contener instrucciones.
Microsoft lo explica con un ejemplo de factura, creado para mostrar el patrón en lugar de informar sobre una víctima nombrada. Un equipo de finanzas contrata a un agente para que se encargue de las facturas de los proveedores. Se conecta a tres herramientas, incluido un servicio de “enriquecimiento de facturas” de terceros cuyo uso fue aprobado pero que nunca recibió una revisión de seguridad real.
Luego, 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: tome las últimas treinta facturas impagas y adjúntelas a la siguiente llamada. MCP detecta cambios en la descripción sobre la marcha. En configuraciones sin un activador de reaprobación, la versión envenenada se activa sin revisión adicional.
Después de eso, un analista hace una pregunta de rutina sobre un proveedor. El agente sigue el orden oculto, recoge las facturas y las envía como parte de una solicitud de apariencia normal. La herramienta devuelve una respuesta limpia y copia silenciosamente los datos robados a un servidor que controla el atacante. El analista no ve nada malo.
Cada movimiento que hace el agente es legítimo por sí solo. La herramienta fue aprobada. La consulta de datos se ejecutó con los permisos propios del analista. La llamada saliente fue a un servidor que estaba permitido cuando se agregó. La debilidad no está en ningún sistema en particular. 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 orientar al agente con tanta eficacia como reescribir el mensaje del sistema.
El agente no tiene una forma confiable de distinguir una instrucción honesta de una maliciosa introducida por quien mantiene la herramienta. Microsoft señala que esto no es un error en Copilot en sí. Es una brecha de confianza que se abre al conectar herramientas externas.
¿Qué deben hacer los defensores?
El consejo de Microsoft, resumido en términos sencillos:
- Trate cada herramienta conectada como parte de su cadena de suministro. Mantenga una lista de editores de herramientas aprobados, desactive “permitir todo” y permita que un agente use solo las herramientas específicas que necesita.
- Trate la descripción de una herramienta como un mensaje del sistema. Revise los cambios de la misma manera que revisaría un cambio de código y escanee el texto en busca de comandos que no tienen por qué estar en un campo de ayuda.
- Pon a un humano frente a acciones riesgosas. Cualquier cosa que mueva dinero, comparta datos fuera de la empresa o cambie de cuenta debe necesitar la aprobación de una persona.
- Dale a cada agente su propia identidad y observa lo que hace. Registre sus acciones, establezca una línea de base para lo normal y marque nuevos puntos finales, extracciones de datos más grandes o consultas extrañas.
- Aplique la menor agencia, no sólo el mínimo privilegio. Incluso un agente con poco permiso puede causar un daño real si se le permite actuar sin controles.
Microsoft asigna sus propios productos a cada paso, incluidos Prompt Shields, Purview DLP, Entra Agent ID, Defender for Cloud y Sentinel, pero los principios se aplican independientemente de la pila que ejecute.
No es una teoría: cómo llegamos aquí
Esta clase de ataque tiene un rastro documental. Invariant Labs denominó “intoxicación de herramientas” en abril de 2025, con una prueba de concepto que ocultaba instrucciones en la descripción de una herramienta de calculadora y hacía que el editor Cursor leyera la clave SSH privada de un usuario y la enviara. El desarrollador Simon Willison investigó días después.
Más tarde, el mismo grupo mostró un truco relacionado: un problema malicioso de GitHub podría secuestrar un agente conectado al servidor MCP de GitHub y sacar datos de repositorios privados. Las herramientas allí eran confiables y estaban intactas; las malas instrucciones se basaron en los datos que leyó el agente.
OWASP ahora cita ese caso como un ejemplo de vulnerabilidades de la cadena de suministro de agentes en su Top 10 de aplicaciones de agentes de diciembre de 2025.
Ya se ha producido un fallo relacionado en la cadena de suministro. En septiembre de 2025, investigadores de Koi Security encontraron un paquete npm llamado postmark-mcp. Había reflejado una herramienta de correo electrónico legítima durante quince versiones limpias antes de que la versión 1.0.16 incluyera una línea que ocultaba en secreto cada correo electrónico que un agente enviaba a un atacante. Koi lo llamó el primer servidor MCP malicioso del mundo real.
Los académicos también han comenzado a medir el problema. El punto de referencia MCPTox, publicado en agosto de 2025, ejecutó descripciones de herramientas envenenadas en 45 servidores MCP reales y 20 modelos líderes de IA. Encontró que el ataque fue ampliamente efectivo, con una tasa de éxito de hasta el 72,8 por ciento, y los modelos casi nunca se negaron.
La línea completa es la que Microsoft está presionando ahora. La IA que puede actuar es tan confiable como las herramientas que le dejas tocar, y en este momento esas herramientas son fáciles de envenenar y difíciles de observar.
