La vulnerabilidad silenciosa de los agentes de IA: descripciones de herramientas envenenadas que permiten exfiltrar datos

Un trabajo reciente del equipo de Microsoft Incident Response y Defender revela una falla silenciosa pero crítica en la forma en que los agentes de IA interactúan con herramientas externas: basta con envenenar la descripción textual de un "tool" para que el agente, actuando siempre dentro de las reglas, entregue datos sensibles a un atacante sin que salten alarmas.

La mecánica del ataque es más sencilla y más peligrosa de lo que parece: muchos agentes usan el Model Context Protocol (MCP) para invocar herramientas externas, y cada herramienta incluye unas pocas líneas de texto que describen qué hace y cuándo debe usarse. Esas palabras terminan en la memoria operativa del agente junto a sus instrucciones legítimas, por lo que una descripción manipulada puede actuar como un prompt encubierto y reorientar la conducta del agente sin modificar permisos, registros o llamadas que a primera vista parezcan rutinarias.

El ejemplo que ilustra Microsoft es el de un flujo financiero: un servicio de "enriquecimiento de facturas" aprobado pero sin revisión de seguridad real, cuya descripción se actualiza para incluir una orden oculta —"adjunta las últimas treinta facturas impagas"—. MCP hace efectivas esas palabras casi al instante, el agente ejecuta la petición con los permisos del usuario, la herramienta devuelve una respuesta limpia y, al mismo tiempo, exfiltra las facturas a un servidor externo. Todo sucede dentro de la "zona de confianza" entre componentes, lo que dificulta la detección.

Esto cambia la imagen clásica del riesgo de IA: hasta ahora la mayoría de las estrategias defendían contra sesgos o respuestas maliciosas en texto. Con agentes que pueden enviar correos, crear archivos o ejecutar trabajos, la inyección no se queda en la salida; se convierte en acción real sobre sistemas y datos. Investigaciones y pruebas públicas han mostrado que la técnica es efectiva contra muchos servidores MCP y modelos, y que ya existen casos reales —por ejemplo, paquetes que comenzaron limpios y en una versión posterior introdujeron una filtración ocultando un BCC—.

Las implicaciones para empresas son profundas. Un agente normalmente autorizado puede mover datos, transferir información fuera del perímetro y actuar con la identidad de un usuario sin que los controles tradicionales detecten un comportamiento "maligno" porque cada paso individual es válido. Eso obliga a pensar la seguridad no solo en permisos y políticas de datos, sino en la integridad y revisión continua de las herramientas que los agentes consumen.

Las medidas prácticas no son teóricas: tratar las herramientas conectadas como parte de la cadena de suministro es el primer paso. Eso implica llevar un inventario de editores aprobados, prohibir la opción "permitir todo", y aplicar un modelo de allowlist que especifique qué herramienta concreta puede usar cada agente. Además, conviene revisar cualquier cambio en la descripción de una herramienta con el mismo rigor que una revisión de código: buscar instrucciones encubiertas, comandos fuera de lugar o texto que actúe como prompt.

Debe exigirse un humano en lazo para acciones de riesgo: todo lo que mueva dinero, comparta datos fuera de la organización o altere cuentas debe requerir aprobación humana previa. Acompañe esto con identidades distinguibles para cada agente, registro detallado de sus acciones, medición de comportamiento normal y alertas por anomalías —por ejemplo, nuevos endpoints contactados, arrastres de datos inusuales o consultas atípicas—. Aplicar el principio de least agency además del clásico least privilege reduce el daño potencial incluso cuando un agente tiene permisos legítimos.

En la práctica técnica conviene combinar controles: restricciones de egress a nivel de red, soluciones de DLP para inspeccionar salidas automatizadas, firmas o hashes para el código y versiones de herramientas, y políticas que obliguen a re-aprobación cuando cambian descripciones o metadatos críticos. Los proveedores ya han empezado a mapear soluciones —desde controles de prompts hasta detección en la nube— pero los principios son aplicables independientemente del proveedor.

Este tipo de vulnerabilidad es parte de lo que la comunidad denomina ahora vulnerabilidades en la cadena de suministro agentica. Investigaciones previas y pruebas de concepto han demostrado variantes similares (por ejemplo, instrucciones ocultas en herramientas de cálculo o issues maliciosos en GitHub que desencadenan fugas). Organizaciones como OWASP han comenzado a incluir estos riesgos en sus referencias sobre amenazas a aplicaciones agenticas; ver su trabajo ayuda a entender el panorama general https://owasp.org/. Microsoft también documenta el problema y sus recomendaciones generales en su blog de seguridad, donde vincula controles y productos que apoyan las defensas propuestas https://www.microsoft.com/en-us/security/blog/.

No es un problema puramente académico: ya han aparecido casos del mundo real donde paquetes y servers MCP se convirtieron en vectores para exfiltrar datos. Grupos de investigación y empresas de seguridad pública han demostrado la viabilidad de la técnica y publicado pruebas, lo que hace urgente que los equipos de seguridad actúen ahora y no cuando una fuga confirme el riesgo.

Si usted administra agentes en su organización, empiece por estas acciones concretas: inventariar todas las conexiones MCP y sus editores, bloquear permisos "globales", exigir revisión de cambios en descripciones, poner revisiones humanas para acciones críticas, habilitar identidad y logging por agente, y aplicar controles de DLP y egress. Estas medidas no eliminan la posibilidad de nuevos vectores, pero reduciendo la superficie de ataque y elevando la supervisión humana y técnica se limita significativamente la capacidad de un atacante para usar descripciones envenenadas como palanca.

La llegada de agentes con capacidad de actuar autónomamente amplifica los beneficios de la IA en el trabajo, pero también traslada parte de la seguridad a un terreno donde las palabras (las descripciones) son ya un vector de ataque. Proteger ese perímetro es ahora tan importante como proteger credenciales o APIs; no hacerlo deja la puerta abierta a fugas que parecerán, desde los registros, simples operaciones rutinarias.