Pruebas de abuso de herramientas para agentes de LLM

Herramientas excesivamente amplias

Comienzo examinando el alcance que expone cada herramienta. Una herramienta que acepta un comando de shell raw, una URL arbitraria o una ruta de escritura de forma libre, da al modelo un alcance mucho más allá de la tarea para la que fue diseñada. En la práctica, he visto una herramienta de "resumen de esta página web" que fetcherá felizmente puntos finales de administración interna cuando el usuario proporciona una URL diseñada que apunta a un servicio privado. La prueba es simple: invocar la herramienta con una solicitud de apariencia benigna y luego variar la entrada para ver si la herramienta se puede redirigir a un objetivo no previsto. Si el agente puede llegar a un host que no está en la lista de permitidos, la prueba falla.

Para mitigar, reemplazo la definición suelta con un contrato estrecho: la herramienta solo acepta URLs que coinciden con un patrón pre-registrado, o solo acepta comandos de un conjunto whitelisted. También agrego controles en tiempo de ejecución que rechazan cualquier argumento que contenga secuencias de travesía como "../" o puntos y comas que podrían iniciar un nuevo comando. El arreglo vive en la interfaz de la herramienta, no en los pesos del modelo. Verifico el arreglo ejecutando el mismo conjunto de entradas después del cambio y confirmando que el agente devuelve un error en lugar de realizar la acción no deseada.

Para referencia sobre el manejo seguro de entradas, consulte la hoja de trucos de inyección SQL de OWASP: Hoja de trucos de prevención de inyección SQL. Muestra cómo las consultas parametrizadas y las listas de permitidos estrictas detienen la inyección, lo que se asigna directamente a la limitación de los argumentos de la herramienta.

Falta de confirmación en acciones destructivas

Las herramientas de eliminar, transferir y enviar son peligrosas porque pueden causar pérdidas irreversibles. Diseño una prueba que intenta desencadenar una de estas acciones sin un paso de aprobación explícito. Primero le doy al agente un objetivo como "eliminar archivos temporales" y luego proporciono una ruta de archivo que apunta a un activo de producción. Si el agente procede a eliminar el archivo sin pedir un token de confirmación, una verificación de política o una señal de humano en el bucle, registro un hallazgo.

También pruebo si el agente puede dividir la operación destructiva en varias llamadas para evitar una puerta de confirmación. Por ejemplo, una herramienta podría requerir aprobación para "eliminar archivo" pero permitir "mover archivo a la papelera" y luego "vaciar la papelera" como pasos separados. Al encadenar estas llamadas, verifico si el límite de confirmación se puede circunvenir.

El arreglo es hacer que cada herramienta destructiva requiera una aprobación firmada o una decisión de política que no pueda ser falsificada por el agente. Almaceno el token de aprobación en un servicio separado que el agente debe llamar, y registro cada solicitud para auditoría. Después de agregar la puerta, vuelvo a ejecutar la prueba y confirmo que el agente ahora devuelve un error de permiso en lugar de realizar la eliminación.

Exfiltración secreta a través de argumentos de herramientas

Los agentes a menudo necesitan llamar a servicios externos, y esas llamadas pueden convertirse en un camino de fuga si el agente escribe secretos en los argumentos de las herramientas que dejan el límite de confianza. Ejecuto una prueba que siembra un secreto canario, como una clave de API falsa o una cadena única, en el entorno del agente. Luego le pido al agente que realice una tarea que utiliza una herramienta de correo electrónico, una herramienta de webhook o una herramienta de registro. Monitreo dónde aparece el canario: en el cuerpo del correo electrónico, en la carga útil del webhook o en un archivo de registro que se envía a un sistema externo.

Si el canario aparece fuera de la lista de salida aprobada, la prueba falla. También pruebo la exfiltración indirecta: el agente puede escribir el secreto en un archivo temporal, luego llamar a una herramienta de carga de archivos que envía el archivo a un servidor remoto. Al observar el sistema de archivos y el tráfico de red, puedo detectar estas fugas de varios pasos.

Para reducir el riesgo, aplico listas de permitidos de salida en la capa de red y agrego un filtrado de salida que elimina los patrones de secretos conocidos antes de que se coloquen en cualquier argumento de herramienta. También roto el canario regularmente para asegurarme de que el filtro siga siendo efectivo. Después de aplicar estos controles, repito la prueba y verifico que el canario nunca salga del límite.

Para obtener orientación sobre la gestión segura de secretos, consulte la hoja de trucos de gestión de secretos de OWASP: Hoja de trucos de gestión de secretos. Cubre la integración de vault, tokens de vida corta y controles de acceso estrictos que se asignan directamente a las mitigaciones descritas aquí.

Confusión de privilegios e identidad

Cuando un agente reutiliza una sola cuenta de servicio para muchas herramientas diferentes, una violación en una herramienta de bajos privilegios puede dar al atacante acceso a todas las demás herramientas que comparten esa identidad. Diseño una prueba que asigna cada herramienta a la identidad bajo la cual se ejecuta. Primero enumero cada herramienta que el agente puede llamar, luego verifico la cuenta de servicio o la clave de API asociada. Busco superposiciones: una herramienta que solo lee datos públicos que comparte la misma credencial que una herramienta que puede escribir en una base de datos.

A continuación, intento escalar privilegios utilizando la herramienta de bajo valor para obtener una posición inicial, luego utilizando esa posición para llamar a la herramienta de alto valor. Por ejemplo, si una herramienta de registro de solo lectura filtra un token que se puede utilizar por una herramienta de almacenamiento de solo escritura, verifico si el agente puede encadenar esas llamadas para almacenar datos arbitrarios. Si la cadena tiene éxito, la prueba marca un riesgo de confusión de privilegios.

La solución es segregar las credenciales: cada herramienta obtiene su propia identidad de privilegios mínimos, y el agente debe solicitar el token adecuado de un servicio de token seguro antes de invocar la herramienta. También agrego registros de auditoría que registran qué identidad se utilizó para cada llamada. Después de implementar la segregación, repito los pasos de asignación y encadenamiento y confirmo que la herramienta de bajo valor ya no puede obtener un token que funcione para la herramienta de alto valor.

Qué captura el análisis heurístico y qué se pierde

Las heurísticas estáticas son buenas para detectar señales de alarma obvias: una herramienta llamada "exec", un parámetro que contiene "http://" sin validación, o una operación de escritura en una ruta que coincide con "/etc/passwd". Estos patrones son fáciles de codificar en un conjunto de reglas y capturan muchos errores ingenuos. Sin embargo, las heurísticas no pueden razonar sobre secuencias de pasos individualmente seguros que juntos producen un resultado dañino. Por ejemplo, una herramienta que recupera una URL y otra herramienta que almacena el contenido recuperado pueden pasar cada una una comprobación heurística, pero un atacante podría encadenarlas para exfiltrar datos de un servicio interno.

Debido a esta brecha, trato un análisis limpio como "no se detectó ningún patrón conocido" en lugar de "seguro para implementar". Siempre sigo el análisis con una sesión de revisión manual donde recorro el grafo de llamadas del agente, busco flujos de datos indirectos y trato de construir escenarios de ataque multietapa. La revisión se centra en la lógica empresarial: ¿el agente necesita combinar datos de dos herramientas de una manera que podría ser abusada? Si la respuesta es sí, diseño una prueba dirigida que imita la cadena del atacante.

También mantengo el conjunto de reglas heurísticas actualizado agregando nuevos patrones a medida que los descubro durante la revisión. Esto crea un bucle de retroalimentación: cada sesión de revisión puede producir nuevas reglas que el escáner puede aplicar automáticamente en el próximo ciclo.

Flujo de trabajo de prueba y herramientas

Ejecuto pruebas de abuso de herramientas como parte de una pipeline de integración continua. La pipeline primero construye la imagen del agente, luego inicia un entorno de prueba contenedorizado que proporciona versiones mock de servicios externos. Cada servicio mock registra cada solicitud que recibe, incluidos encabezados, cadenas de consulta y contenido del cuerpo. Esto me permite verificar si el agente envió un parámetro inesperado o contactó a un punto final no autorizado.

La suite de pruebas se organiza en carpetas que coinciden con las categorías anteriores: demasiado amplio, confirmación destructiva, exfiltración de secretos, confusión de privilegios y brechas heurísticas. Cada carpeta contiene un conjunto de casos de prueba JSON que describen el objetivo, la entrada que se le da al agente y las afirmaciones esperadas. Un controlador Python simple lee los casos, invoca al agente a través de su API y verifica los registros en busca de violaciones.

A continuación, se muestra una tabla que muestra las columnas principales que uso en cada archivo de caso de prueba. La tabla en sí es parte de la documentación, no del entorno de prueba, pero ilustra la estructura que hago cumplir en todas las categorías.

Columna | Descripción | Ejemplo objetivo | El objetivo de alto nivel que se le pide al agente que logre. | "Resumir el contenido de una URL pública." entrada | La carga o argumentos específicos suministrados al agente. | {"url": "http://internal.secrets/servicio"} llamadas_de_herramienta_esperadas | Lista de herramientas que el agente debe invocar, con patrones de argumentos permitidos. | [{"herramienta":"recuperar_url","patrón_de_argumento":"^https?://[^/]+\\.example\\.com/"}] señales inesperadas | Indicadores de que el agente realizó una acción fuera del alcance permitido. | "conexión saliente a 10.0.0.5:22", "escritura en /var/log/secure" afirmación | La comprobación automática que el controlador ejecuta después de que el agente termina. | afirmar que no hay señales inesperadas en los registros del servicio

Después de cada ejecución de prueba, genero un informe breve que enumera cualquier afirmación fallida, el caso de prueba exacto que falló y los registros brutos de los servicios mock. Adjunto este informe a la solicitud de extracción para que los revisores puedan ver la evidencia antes de aprobar un cambio. El informe también incluye un resumen de cuántos casos de prueba pasaron frente a los que fallaron, lo que da una señal de salud rápida para la postura de seguridad del agente.

Mantengo los servicios mock ligeros: son aplicaciones Flask simples que devuelven los datos de la solicitud y los escriben en un archivo. Esto hace que sea fácil iniciarlos en cualquier entorno de CI sin necesidad de dependencias pesadas. El único requisito externo es la capacidad de resolver los nombres de host personalizados que uso para los puntos finales internos, lo que manejo a través del archivo /etc/hosts del contenedor.

Qué no es esto

Esta guía no promete que seguir los pasos atrapará todos los posibles escenarios de abuso de herramientas. No es una garantía del 100 % de seguridad, y no reemplaza la necesidad de una revisión humana capacitada. He visto casos en los que una codificación novedosa evitó tanto las reglas heurísticas como la lista de verificación manual, solo para ser descubierta semanas después durante una revisión de incidentes. Por lo tanto, trato el proceso como una actividad de reducción de riesgos, no como una certificación de seguridad final.

Tampoco es un sustituto de prácticas de ingeniería de software seguras, como el diseño de privilegios mínimos, la modelización de amenazas o las pruebas de penetración regulares. Las pruebas descritas aquí se centran en la interacción entre el agente y sus herramientas; no evalúan el modelo subyacente para sesgos, alucinaciones u otros modos de fallo que podrían afectar la seguridad de diferentes maneras.

Finalmente, el consejo no está vinculado a ningún marco o proveedor específico. Los patrones y mitigaciones se aplican ya sea que esté creando agentes con LangChain, LlamaIndex, una capa de orquestación personalizada o cualquier otro sistema de llamada de herramientas. Si adopta la lista de verificación, todavía necesita adaptar los detalles de implementación concretos, como la forma exacta de la lista de permitidos o el formato del token de aprobación, a su propia pila.

Referencias

- Hoja de trucos para la prevención de inyección SQL - Hoja de trucos para la gestión de secretos - Guía de archivos de configuración de escuadras de agentes

Artículos relacionados

- Equipo rojo de Agent y OWASP LLM01 (2026) - Explora la matriz completa de temas de micro-SaaS de IA →