Tool Abuse

Una capacidad usada fuera de su finalidad

Tool Abuse es el uso de una herramienta o capacidad externa de manera que excede la finalidad, el alcance o las condiciones autorizadas para el trabajo. La operación puede ser técnicamente válida y ejecutarse con éxito. El problema no depende de que la API falle ni de que el agente escape del entorno.

En sistemas AI, una decisión desviada puede convertirse en lecturas, escrituras, llamadas de red o acciones remotas. La entrada de OWASP LLM 2026 sobre Excessive Agency relaciona el riesgo con funcionalidad, permisos y autonomía excesivos. Aquí el foco es la operación concreta y su autorización, no una prohibición general de delegar trabajo.

Disponibilidad, permiso e intención

Tool Calling organiza cómo se solicita una invocación; Tool Use conserva el uso general de capacidades. Ninguna de las dos cosas demuestra que los argumentos elegidos correspondan al encargo. Registrar una función en el harness no autoriza todos los recursos que esa función pueda alcanzar.

Un servicio puede aceptar una llamada porque la credencial técnica tiene permiso. Todavía puede faltar autorización del solicitante para ese tenant, destino o finalidad. Confused Deputy desarrolla esa relación cuando un intermediario utiliza autoridad propia a favor del actor equivocado.

También puede haber errores sin un actor malicioso: seleccionar una operación destructiva para resolver una tarea de lectura sigue siendo un uso indebido. La investigación debe describir el efecto y su causa probable sin atribuir intención a partir del resultado únicamente.

Shell y procesos

Una shell puede combinar lectura, escritura, procesos y acceso de red. Autorizarla para ejecutar tests no convierte todo comando disponible en parte del encargo. Importan argumentos, directorio, archivos consumidos y efectos de procesos secundarios.

El nombre del comando no basta. Un test puede cargar configuración y scripts del repositorio; una operación de instalación puede ejecutar código de una dependencia. AI Supply Chain Risk trata la adquisición de ese código. Una revisión de permisos debe considerar qué ejecución real queda habilitada, además de la instrucción que produjo la llamada.

No toda tarea requiere una shell genérica. Una herramienta acotada puede reducir decisiones y autoridad expuestas, siempre que su implementación también limite recursos y operaciones. Una descripción que dice «solo lectura» no demuestra que el backend la imponga.

Red, credenciales y destinos

Una consulta de red puede sacar datos del entorno. Que el destino responda por HTTPS protege aspectos del transporte, pero no lo convierte en un receptor autorizado del contenido. La revisión necesita distinguir acceso a una API, principal usado y datos enviados.

El agente puede usar una operación autenticada sin recibir la credencial. Si el secreto se entrega al proceso o al contexto, cambia qué componentes pueden leerlo. Least Privilege for Agents ayuda a limitar esa exposición y las operaciones disponibles.

Una consulta válida puede producir Data Leakage si retorna información de otro usuario o se transmite a otro canal. Limitar escritura no elimina esa consecuencia. Tampoco una lista de dominios permitidos sustituye la autorización del recurso y de la información enviada.

Acciones destructivas y estado externo

Borrar datos, publicar una versión, enviar una comunicación o modificar infraestructura pueden dejar efectos más allá del workspace. La reversibilidad debe examinarse por operación. Descartar un worktree o reiniciar un container no deshace necesariamente lo que ocurrió en un servicio externo.

Agent Permissions and Approval Boundaries distingue autorización existente y decisión adicional antes de un efecto. Aprobar una acción no debe usarse como permiso para sustituir silenciosamente el destino o ampliar su alcance.

Si una llamada falla o se cancela, el efecto remoto puede ser desconocido. Repetir sin comprobar estado puede ampliarlo. Idempotency y Timeout conservan los mecanismos generales para razonar sobre repetición y espera; no se crean variantes AI de esos conceptos.

Output Handling

La entrada de OWASP sobre Improper Output Handling examina el uso inseguro de salidas en componentes posteriores. Un resultado bien formado puede contener un destino, ruta u operación que no corresponda ejecutar. Validación de schema y autorización tienen responsabilidades distintas.

El consumidor necesita aplicar reglas del destino: uso seguro de consultas, encoding apropiado en interfaces y validación contextual de recursos. Convertir texto generado en código ejecutable agrega otra transición. No basta con pedir al modelo que produzca una respuesta «segura».

Esta frontera puede existir sin tool calling explícito. Un renderer que interpreta una salida o un proceso que consume un archivo generado también puede producir efectos. Trust Boundaries permite seguir el recorrido completo.

Ejemplo y comprobación

Un agente de Commerce investiga un fallo de pagos con acceso a lectura de pedidos. Una herramienta de administración también permite reembolsar. La existencia de esa operación no la vuelve necesaria para diagnosticar. Si una petición o un ticket induce al agente a usarla, la prueba debe observar qué autorización se comprobó y si el reembolso ocurrió.

Una evaluación segura puede sustituir la operación por un registro sintético, incluir pedidos dentro y fuera del alcance y verificar tanto el diagnóstico legítimo como el rechazo del efecto indebido. Prompt Injection es una posible causa de desvío; no es un requisito de todo abuso.

Logs y traces ayudan a reconstruir argumentos, identidad y resultado, pero no reemplazan controles previos ni prueban que todo efecto esté instrumentado. Agent Sandboxing reduce ciertos recursos alcanzables; una operación dañina puede seguir siendo posible dentro de ellos.

Fuentes y alcance

Fuentes consultadas el 2026-11-05. El ejemplo es síntesis del Atlas. No se prescribe aprobación humana para toda llamada ni se confunde un rechazo automático con ausencia de trabajo útil.