MalTool: cuando una IA escribe la herramienta maliciosa que instala tu agente

¿Qué es esto?

MalTool es un marco de investigación, publicado en arXiv en febrero de 2026 (arXiv:2602.12194) por investigadores de Duke University y UC Berkeley, que aborda una pregunta que la mayoría de los trabajos sobre seguridad de agentes pasa por alto: no cómo se describe una herramienta al agente, sino qué hace realmente el código de la herramienta una vez que el agente la invoca. Los autores lo presentan como el primer estudio sistemático de implementaciones de código de herramientas maliciosas dirigidas a agentes LLM.

El modelo de amenaza es mundano, y eso es justamente lo que lo hace importante. Un atacante publica una herramienta en una plataforma de distribución: un registro de servidores MCP, un marketplace de plugins, un índice de paquetes. Un desarrollador la instala. El agente, haciendo su trabajo, selecciona esa herramienta durante una tarea. La herramienta se ejecuta con los accesos que tiene el agente, y su código hace algo que el usuario nunca autorizó. No se requiere ninguna inyección de prompt: el comportamiento malicioso reside en la implementación, no en un prompt manipulado.

Para medir esta superficie, el equipo usó un LLM de código para sintetizar herramientas maliciosas de forma automática, organizadas según una taxonomía construida sobre la tríada clásica confidencialidad–integridad–disponibilidad (CIA) adaptada al contexto de los agentes. La cifra destacada: 6.487 herramientas maliciosas generadas. El hallazgo destacado es en el que los defensores deberían detenerse.

Cómo funciona

La contribución es un generador, no un exploit único, así que aquí no hay ningún payload que reproducir, y ninguno hace falta para entender la lección.

El marco le pide a un modelo capaz de escribir código que produzca herramientas autónomas que (a) implementen una función anunciada plausible y de apariencia inofensiva y (b) además ejecuten un comportamiento malicioso elegido de la taxonomía CIA: filtrar datos que el agente puede leer (confidencialidad), alterar archivos o resultados (integridad), o interrumpir el host o la tarea (disponibilidad). Para cada comportamiento objetivo, los autores generaron muchas variantes independientes, produciendo un corpus amplio y diverso en lugar de una muestra reutilizada.

Esa diversidad es el punto clave. Como cada herramienta la escribe de cero un modelo, el corpus no tiene firmas comunes, ni cadenas de texto compartidas, ni binarios reutilizados: precisamente las características en las que se apoya la detección de malware tradicional. Cuando los investigadores enviaron las herramientas generadas a VirusTotal, el servicio de escaneo multimotor no detectó la mayoría de ellas. La lógica maliciosa no es más que código fuente de apariencia ordinaria que realiza acciones ordinarias (leer un archivo, hacer una petición HTTP) en un contexto en el que esas acciones resultan ser dañinas.

Esto complementa trabajos anteriores sobre cómo conseguir que un agente elija una herramienta hostil en primer lugar — por ejemplo, el Attractive Metadata Attack (NeurIPS 2025), que fabrica metadatos de herramienta para ganar la selección del agente. MalTool asume que la selección tiene éxito y se pregunta qué hace entonces el código, y si algo lo interceptaría.

Por qué importa

Los ecosistemas de agentes se están reorganizando en torno a capacidades de terceros instalables — servidores MCP, skills, plugins, packs de herramientas — distribuidas de forma muy parecida a los paquetes open source. Los equipos importan en bloque el modelo de riesgo de la cadena de suministro de software, incluido su control por defecto: escanear el artefacto con antivirus y motores de firmas antes de confiar en él.

MalTool demuestra que ese control es en gran medida cosmético frente a herramientas escritas por IA. Un motor de firmas reconoce elementos maliciosos conocidos. Un modelo puede escribir un suministro ilimitado de elementos maliciosos inéditos, nunca vistos antes, cada uno sintácticamente único. La economía se ha invertido: producir una herramienta maliciosa nueva y no detectada es ahora barato, y la tasa de detección por muestra del escaneo por firmas tiende a cero. Esto coincide con lo que los equipos de inteligencia de amenazas reportan de forma más amplia sobre el malware polimórfico impulsado por IA: la detección tiene que pasar de cómo se ve el código a qué hace.

Para los sistemas agénticos, el radio de impacto es amplio, porque una herramienta se ejecuta dentro del sobre de privilegios del agente: sus credenciales, su acceso al sistema de archivos, su salida de red, su memoria.

Defensas

Trata las herramientas de los agentes como código no confiable que se ejecuta con la autoridad del agente, y deja de apoyarte en las firmas como barrera.

• Mínimo privilegio por herramienta, no por agente. Limita cada herramienta al mínimo de datos, rutas de archivos y destinos de red que necesita. Una herramienta de «resume este documento» no tiene por qué alcanzar URLs arbitrarias. Los controles basados en capacidades limitan lo que una implementación maliciosa puede alcanzar, incluso cuando se ejecuta.
• Monitorización del comportamiento en lugar de escaneo por firmas. Observa lo que las herramientas hacen en tiempo de ejecución — lecturas de archivos inesperadas, conexiones salientes (sobre todo a APIs de IA o a hosts desconocidos), creación de procesos, acceso a credenciales — en lugar de la apariencia de su código. Es el mismo giro que los defensores están adoptando frente al malware polimórfico.
• Control de la salida de red (egress). Un ataque de confidencialidad necesita una vía de exfiltración. Una política de red saliente con deny por defecto para el entorno de ejecución del agente rompe los comportamientos de herramienta más dañinos, independientemente de la detección.
• Ejecuta las herramientas en un sandbox. Ejecuta las herramientas de terceros en contenedores o bajo usuarios restringidos, sin credenciales ambientales, de modo que una herramienta maliciosa que llegue a ejecutarse no pueda alcanzar secretos, el sistema de archivos más amplio ni la red.
• Procedencia y firma, no solo escaneo. Prefiere herramientas de fuentes que puedas atribuir y verificar criptográficamente. Mantén una lista de permitidos; exige una revisión y una decisión humana antes de que una nueva herramienta de terceros entre en el conjunto disponible de un agente. Consulta el Top 10 for Agentic Applications 2026 de OWASP para las entradas de «uso indebido de herramientas» y «cadena de suministro».
• No equipares «limpio según VirusTotal» con «seguro». Un escaneo limpio sobre una herramienta escrita por IA no aporta casi ninguna señal. Hazlo explícito en tu proceso de revisión para que un resultado en verde no cortocircuite el juicio humano.

Estado

Elemento	Detalle
Tipo	Marco de investigación / estudio de medición
Fuente	arXiv:2602.12194 (febrero de 2026)
Afiliación	Duke University; UC Berkeley
Alcance	Código de herramientas maliciosas (no la descripción/metadatos) para agentes LLM
Taxonomía	Comportamientos de Confidencialidad / Integridad / Disponibilidad
Corpus generado	6.487 herramientas maliciosas
Hallazgo clave	VirusTotal no detectó la mayoría
Conclusión defensiva	Controles de comportamiento + por capacidades, no escaneo por firmas

La lección duradera no es «existe una nueva herramienta de ataque». Es que la cadena de suministro de herramientas de IA hereda los supuestos de confianza de la cadena de suministro de software a la vez que rompe el método de detección en el que esos supuestos se apoyaban discretamente. Cuando el coste de generar una herramienta maliciosa inédita capaz de evadir las firmas se acerca a cero, escanear artefactos deja de ser una barrera. La barrera tiene que estar en lo que una herramienta está autorizada a hacer una vez que tu agente la invoca.