OWASP ASI02: cuando un agente vuelve sus propias herramientas contra usted
Tool Misuse & Exploitation es el riesgo n.º 2 del Top 10 de OWASP para Aplicaciones Agénticas 2026. El peligro no es que un agente gane nuevas herramientas, sino que abuse de las que ya tiene: sobreprivilegio, descriptores envenenados, encadenamiento inseguro.
¿Qué es esto?
ASI02 — Tool Misuse & Exploitation es la segunda entrada del Top 10 de OWASP para Aplicaciones Agénticas 2026, publicado por la Agentic Security Initiative del proyecto OWASP GenAI Security. Mientras que el antiguo Top 10 de OWASP para LLM trataba a los modelos como simples generadores de texto, la lista agéntica aborda sistemas que actúan: invocan API, ejecutan shells, consultan bases de datos y envían correo. ASI02 designa el riesgo de que un agente utilice una herramienta que tiene legítimamente permitido invocar de forma insegura, no prevista o dirigida por un atacante.
Este artículo es un recorrido defensivo por la categoría. Complementa nuestra cobertura de ASI06 (envenenamiento de memoria y contexto) y completa el panorama de cómo el marco de 2026 descompone el riesgo agéntico. La categoría recibió un análisis a fondo de Adversa AI en junio de 2026, que motiva este texto.
Cómo funciona
La idea central, expuesta con claridad en el material de OWASP y en las guías de Teleport y Adversa, es esta: la amenaza no es que el agente adquiera de repente herramientas no autorizadas, sino que abuse de las herramientas que ya posee. ASI02 se activa bajo tres condiciones recurrentes:
1. SOBREPRIVILEGIO la herramienta tiene más autoridad de la que la tarea requiere
(herramienta de archivos sobre $HOME, no el directorio de trabajo)
2. ENTRADA ENVENENADA un descriptor de herramienta o contenido recuperado
lleva instrucciones que orientan su uso
3. ENCADENAMIENTO INSEGURO varias herramientas inofensivas se combinan para
producir un resultado que ninguna estaba autorizada a entregar
Ninguna de estas condiciones exige un exploit de software clásico. El bucle de razonamiento normal del agente es la superficie de ataque: una entrada no confiable (un documento, un correo, un resultado web, una descripción de herramienta) empuja al modelo a seleccionar una herramienta permitida y a alimentarla con argumentos influenciados por el atacante. La herramienta hace exactamente aquello para lo que está construida; la brecha de autorización está aguas arriba, en lo que se permitió intentar al agente.
Incidentes públicamente documentados que encajan en el patrón (todos divulgados y discutidos en 2025-2026):
- CVE-2025-54136 («MCPoison») — un problema del IDE Cursor en el que una configuración de servidor MCP previamente aprobada podía sustituirse silenciosamente por una maliciosa, convirtiendo una herramienta de confianza en hostil.
- Demostración de tool-poisoning de WhatsApp por Invariant Labs (abril de 2025) — un descriptor de herramienta MCP malicioso que manipulaba qué herramienta elegía invocar el agente.
- Exposición entre inquilinos del MCP de Asana (junio de 2025) — una frontera de herramienta que permitió que datos cruzaran la separación entre clientes.
- Borrado de una base de datos de producción por el asistente de IA de Replit (julio de 2025) — una acción destructiva ejecutada pese a una instrucción explícita de congelar los cambios.
No se reproduce ningún payload aquí; la forma es la lección. Una herramienta capaz, más un agente poco restringido, más una entrada no confiable, equivalen a un abuso.
Por qué importa
El acceso a herramientas es toda la razón de ser de un agente y, por tanto, todo su radio de impacto. Un agente que puede leer un repositorio, invocar una API en la nube y disparar un webhook reúne, en la formulación de OWASP, exactamente los ingredientes del daño: exfiltración de datos, escalada de privilegios y acciones irreversibles. Es la misma dinámica que Simon Willison llama la trifecta letal (datos privados + entrada no confiable + canal de exfiltración o de acción), expresada como categoría de riesgo de diseño en lugar de un fallo aislado.
ASI02 merece su propia casilla porque es invisible para los controles tradicionales. No hay paquete malformado, ni cadena SQL inyectada en el borde de la red, ni binario no autorizado. Cada invocación de herramienta parece válida. El fallo es semántico: el agente hizo algo que tenía técnicamente permitido hacer pero que nunca debió hacer. Las defensas por coincidencia de patrones lo pasan por alto porque los bytes son inocuos.
Defensas
OWASP, Teleport y Adversa convergen en un conjunto de controles coherente. Ninguno es novedoso; toda la disciplina consiste en aplicarlos todos.
- Mínimo privilegio por herramienta, no por agente. Limite cada herramienta a la autoridad mínima que la tarea inmediata necesita: rutas permitidas, límites de tasa, dominios de datos concretos. Una herramienta de archivos debería ver el directorio de trabajo, no todo el directorio personal.
- Confirme las acciones destructivas e irreversibles. Exija aprobación humana explícita (o un control de política) para borrados, transferencias, envíos y cambios de privilegios. El caso de Replit es lo que ocurre sin esto.
- Valide los argumentos de las herramientas frente a la semántica esperada antes de ejecutar: no solo el tipado, sino «¿tiene sentido este argumento para esta tarea?». Nunca reenvíe una salida de agente sin validar hacia un comando de shell o de base de datos.
- Aísle la ejecución de las herramientas con control de salida de red. Ejecute las herramientas en entornos aislados con restricciones de red, de modo que una herramienta abusada no pueda alcanzar secretos ni endpoints externos ajenos a su cometido.
- Fije y atestigüe los descriptores de herramientas. Trate la configuración del servidor MCP y los metadatos de herramienta como una frontera de confianza: fírmelos y detecte las sustituciones silenciosas (el modo de fallo de MCPoison).
- Vigile los patrones de invocación. Registre cada invocación de herramienta y alerte ante cadenas anómalas, picos inesperados o secuencias que combinen capacidades sensibles. El abuso se manifiesta en el patrón, no en la invocación aislada.
El principio unificador: una invocación de herramienta es una decisión de autorización, no un detalle de completado de texto. Diseñe la autoridad que porta cada herramienta y la frontera de lo que el agente puede intentar, y asuma que el juicio del modelo sobre «¿debería ejecutar esto?» acabará por equivocarse.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Top 10 de OWASP para Aplicaciones Agénticas 2026 | OWASP GenAI | 2025-2026 | ASI02 = Tool Misuse & Exploitation, n.º 2 de 10 |
| Análisis a fondo de ASI02 | Adversa AI | 2026-06 | Definiciones, catálogo de incidentes, controles defensivos |
| Resumen de la categoría + mitigaciones | Teleport | 2025-12-15 | Pasos de mitigación por riesgo para ingenieros |
ASI02 es una categoría de marco, no un CVE único: solo se «parcheará» al ritmo en que los desarrolladores adopten herramientas de mínimo privilegio, validación de argumentos y aislamiento. La conclusión para quien despliega un agente: enumere cada herramienta que puede invocar, pregúntese cuál sería el peor uso legítimo de cada una y restrinja la autoridad antes de que el agente siquiera lo razone.
Sources
- → https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
- → https://adversa.ai/blog/owasp-asi02-tool-misuse-and-exploitation-the-definitive-security-guide/
- → https://goteleport.com/blog/owasp-top-10-agentic-applications/
- → https://adversa.ai/blog/top-agentic-ai-security-resources-june-2026/