Tool Misuse y Excessive Agency: cuando los agentes de IA tienen demasiados permisos

Excessive Agency designa una autonomía, unos permisos o una funcionalidad demasiado amplios en un agente de IA: puede hacer más de lo que su tarea requiere. Tool Misuse es el uso indebido de herramientas legítimas: el acceso está autorizado, el uso no. Ambos provocan acciones no deseadas, fugas de datos y costes descontrolados. En la clasificación de OWASP, Excessive Agency es el paraguas bajo el cual el Tool Misuse se materializa como riesgo concreto de los agentes.

• Respuesta rápida 1: Excessive Agency es la causa (demasiada autonomía o demasiados permisos); Tool Misuse, la consecuencia (una herramienta legítima se usa de forma insegura o para otro fin).
• Respuesta rápida 2: OWASP recoge el tema en el LLM Top 10 2025 como LLM06:2025 y en el Agentic Top 10 2026, publicado el 9 de diciembre de 2025, como ASI02 (Tool Misuse & Exploitation).
• Respuesta rápida 3: Las contramedidas clave son el mínimo privilegio, tokens de alcance limitado y corta duración, aprobación humana para acciones críticas y límites estrictos de tasa o de coste.

Por qué «poder demasiado» es el verdadero problema de los agentes

Las aplicaciones LLM clásicas responden: entra un prompt, sale una completion. Los sistemas agénticos planifican, eligen herramientas, escriben en la memoria y actúan, con una aprobación humana mínima paso a paso. Justo este salto de «responder» a «actuar» convierte los permisos en la cuestión central de seguridad.

OWASP lo recoge en el LLM Top 10 2025 bajo LLM06:2025 Excessive Agency: conceder a los LLM autonomía de acción sin control cuando la delimitación de permisos o la supervisión humana son insuficientes. Esta entrada se amplió expresamente en 2025 a las arquitecturas agénticas y tiende así el puente entre los riesgos de los LLM y los riesgos de los agentes. Excessive Agency es la antesala directa de varios riesgos de agentes del OWASP Top 10 para aplicaciones agénticas 2026, en concreto ASI02 (Tool Misuse), ASI03 (Identity & Privilege Abuse) y ASI10 (Rogue Agents).

Excessive Agency suele surgir en tres niveles:

• Demasiados permisos: el agente hereda derechos excesivamente amplios del usuario o de la cuenta de servicio con la que se ejecuta.
• Demasiada funcionalidad: el agente dispone de herramientas que su tarea no requiere en absoluto (por ejemplo, una herramienta de borrado o de pagos en un caso de uso de solo lectura).
• Demasiada autonomía: las acciones críticas se ejecutan sin confirmación, por ejemplo mediante modos de aprobación automática o «YOLO» activados.

Tool Misuse (ASI02): acceso legítimo, uso ilegítimo

La descripción de OWASP para ASI02 es precisa: el agente opera dentro de sus privilegios autorizados, pero aplica una herramienta legítima de forma insegura o no prevista. Borra datos valiosos, llama en exceso a API caras, ejecuta operaciones destructivas o exfiltra información. La diferencia con ASI03 es importante: el acceso es legítimo, el uso no.

Vectores típicos de ataque y de fallo:

• Inyección de prompts que desvía una herramienta de su fin, por ejemplo send_email, que de repente se usa para hacer phishing a toda la base de clientes.
• Desalineación entre la interpretación de la tarea que hace el agente y la intención del desarrollador.
• Delegación insegura: el agente pasa una herramienta potente a un subagente sin mecanismos de protección contextuales.
• Modos de aprobación automática o «YOLO» que desactivan las solicitudes de confirmación.

Riesgos concretos: acciones, datos, costes

Las tres dimensiones del daño se pueden separar con claridad:

La dimensión de los costes es especialmente delicada en el mundo de los agentes: OWASP la recoge en el LLM Top 10 como LLM10:2025 Unbounded Consumption («denial-of-wallet»). Los planes de varios pasos multiplican el consumo de tokens, por eso cada plan necesita un presupuesto aplicado de forma estricta.

Incidentes documentados (a fecha de 2026)

Entre los casos documentados públicamente figuran estos:

• Amazon Q Code Assistant (CVE-2025-8217, julio de 2025): Unos atacantes comprometieron un token de GitHub e introdujeron instrucciones maliciosas en la extensión de VS Code v1.84.0. Prompts destructivos combinados con los flags --trust-all-tools y --no-interactive habrían borrado sistemas de archivos y recursos en la nube sin confirmación (The Register). La extensión estaba instalada por alrededor de 1 millón de desarrolladores; la corrección llegó con la v1.85.0.
• OpenAI Operator (Embrace The Red, Johann Rehberger, febrero de 2025): Una inyección de prompts en un issue de GitHub llevó al agente a abrir páginas de cuentas con la sesión iniciada y a revelar datos privados, como la dirección de correo electrónico en Hacker News o la dirección y el número de teléfono en Booking.com (Embrace The Red).
• Langflow (CVE-2025-3248): Este framework de agentes, muy extendido, permitía en versiones anteriores a la 1.3.0 ejecutar código sin autenticación (CSA de Singapur). Según CrowdStrike, desde abril de 2025 varios actores de amenazas han explotado una vulnerabilidad crítica de Langflow para afianzarse, robar credenciales e introducir malware. Se trata de una vulnerabilidad del propio framework y no de Tool Misuse en sentido estricto: aquí la plataforma de agentes se convierte en el objetivo.

Experimento mental: el límite que se elimina con persuasión

En blogs de seguridad circula una cascada de compras en el sector manufacturero, por ejemplo en Stellar Cyber. No hemos encontrado una fuente primaria verificable que lo respalde. Por eso el caso solo sirve como experimento mental: a lo largo de tres semanas, un agente de compras es «convencido» paso a paso de que su límite de autorización es de 500.000 dólares estadounidenses. Después, el atacante realiza en 10 transacciones pedidos falsos por valor de 5 millones de dólares estadounidenses. La lección: un límite que solo figura en el contexto del agente se puede eliminar a base de persuasión. Tiene que estar como límite estricto en la herramienta o en el gateway.

Contramedidas: defensa en capas

Las medidas siguen el ciclo de vida de un agente. Importante: ninguna protección aislada basta. Las capas se complementan.

A ello se suman dos principios de arquitectura. Primero, el patrón de gateway o proxy delante de cada agente como punto central de aplicación de listas de permitidos, validación de esquemas, topes de coste, límites de tasa y registro de auditoría. Segundo, la cuestión de la identidad: cada agente es una identidad no humana (NHI) propia, con su propio ciclo de vida de credenciales, tokens de corta duración y aprovisionamiento just-in-time. Un error de despliegue frecuente es ejecutar un agente «para que funcione» con una cuenta de servicio con derechos equivalentes a los de administrador. Es más seguro usar la identidad delegada del usuario: el agente actúa como la persona y queda limitado a sus permisos.

Una nota sobre la eficacia de la aprobación humana: en la práctica, estos puntos de control suelen degradarse. OWASP lo recoge como riesgo propio, ASI09 (Human-Agent Trust Exploitation). El sesgo de automatización y una salida que suena autoritativa llevan a aprobar sin mirar. Por eso, los puntos de control eficaces obligan a la revisión independiente de las evidencias, no solo a dar el visto bueno a la recomendación del agente.

Ejemplo: permisos para un agente de newsletter

Un agente de marketing debe crear y enviar borradores de newsletter. La Excessive Agency aparece cuando obtiene acceso completo al sistema de correo electrónico. Mínimo privilegio en pseudocódigo:

```
agent_role: "newsletter-draft"
tools:

• read_segment: scope=audience.read rate_limit=20/min
• create_draft: scope=campaign.write rate_limit=10/min
• send_campaign: scope=campaign.send rate_limit=2/h
  require_human_approval=true # Gate: revisar destinatarios + contenido
  deny:
• delete_contact, export_audience, billing.*
  budget:
  token_cap=500000/day usd_cap=20/day circuit_breaker=on
  token:
  type=short_lived ttl=15min
  ```

Efecto: incluso con una inyección de prompts exitosa, el agente no puede exportar ni borrar contactos, ni sobrecargar una API masiva de pago, ni enviar una campaña sin aprobación humana. El token de corta duración y alcance limitado deja sin valor las credenciales robadas al cabo de 15 minutos.

Para agencias y B2B

Si gestionas agentes de IA para clientes en marketing, ventas o atención al cliente, eres responsable de su diseño de permisos. Un punto de partida práctico: inventaría por agente cada herramienta y cada alcance, desactiva la aprobación automática para todo lo que borre datos, mueva dinero o envíe mensajes, y fija límites estrictos de coste y de tasa antes de que un agente pase a producción. Blck Alpaca, desde Viena, acompaña a organizaciones B2B de toda Europa en la creación de arquitecturas de agentes conformes al principio de mínimo privilegio según el OWASP Agentic Top 10. Nota: este artículo tiene fines informativos y no constituye asesoramiento jurídico; las cuestiones concretas de cumplimiento normativo y responsabilidad es mejor que las aclares con asesores cualificados.