💬 NLP

Agentic Security: A Systematization of Tools, Failure Modes, and Design Laws for LLM-Driven Penetration Testing

Este artículo sistematiza los fallos operativos de las herramientas de pruebas de penetración impulsadas por LLM mediante una evaluación práctica, derivando leyes de diseño cuantitativas y un índice de fricción de cuatro dimensiones para guiar la construcción de sistemas de seguridad agénticos robustos, ejemplificados por la plataforma Inspectra.

Autores originales: Israt Moyeen Noumi, Tarannum Ahmed Nowshin, Md. Mehedi Hasan Nipu, Mohammad Sakib Mahmood, Md. Jakir Hossain, M. F. Mridha

Publicado 2026-08-25

📖 8 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Israt Moyeen Noumi, Tarannum Ahmed Nowshin, Md. Mehedi Hasan Nipu, Mohammad Sakib Mahmood, Md. Jakir Hossain, M. F. Mridha

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

En el mundo de la seguridad informática, existe una larga tradición de contratar a humanos expertos para irrumpir en sistemas antes que los delincuentes. Estos expertos, conocidos como evaluadores de penetración (penetration testers), pasan sus días buscando fallos ocultos en software, redes e infraestructura en la nube. Buscan contraseñas débiles, huecos sin parchear y errores de lógica que podrían permitir a un criminal robar datos o tomar el control. Durante décadas, este trabajo ha sido un oficio manual impulsado por humanos. Sin embargo, una nueva fuerza ha entrado en el campo: la inteligencia artificial. Específicamente, los modelos de lenguaje extensos —sistemas entrenados con vastas cantidades de texto que pueden comprender y generar lenguaje humano— se están solicitando ahora para realizar el trabajo de estos expertos en seguridad. La idea es construir sistemas "agénticos": software que no solo pueda leer código y escanear redes, sino también planificar ataques, ejecutarlos y escribir informes, todo ello sin que un humano le lleve de la mano. Este cambio promete hacer que las pruebas de seguridad sean más rápidas y económicas, pero también introduce un nuevo conjunto de problemas. Cuando se le entrega un trabajo complejo y peligroso a una máquina que piensa en probabilidades en lugar de certezas, la máquina puede cometer errores que un humano nunca cometería o, peor aún, puede mentir con total confianza sobre lo que encontró.

Un equipo de investigadores se propuso comprender exactamente cómo se comportan estos agentes de seguridad de IA cuando se les deja trabajar solos. No se limitaron a construir un modelo teórico; construyeron una plataforma real y funcional llamada Inspectra y la pusieron a prueba contra una variedad de herramientas de seguridad. Su objetivo era ir más allá del entusiasmo sobre lo que estos agentes podrían hacer y documentar las duras realidades de ingeniería de lo que realmente hacen cuando las cosas salen mal. Descubrieron que se trataba de una disciplina en su infancia, donde los mismos fallos ocurrían una y otra vez, no porque la tecnología estuviera rota, sino porque se estaba utilizando de formas que sus diseñadores nunca pretendieron. Los investigadores descubrieron que los mayores obstáculos no eran la falta de inteligencia de la IA, sino la falta de estructura en la forma en que se construía el sistema. Identificaron patrones de fallo específicos y predecibles que ocurren cuando una IA intenta recordar demasiado, cuando intenta juzgar su propio trabajo y cuando se le otorga un presupuesto que no puede controlar.

Uno de los problemas más inmediatos que el equipo encontró fue el problema de la memoria. Imagine un agente de IA que inicia una investigación larga, leyendo miles de líneas de código y ejecutando docenas de pruebas. A medida que la investigación continúa, la cantidad de información que necesita mantener en su "mente" crece. Eventualmente, el sistema se queda sin espacio para contener toda esa información. En términos humanos, esto es como intentar recordar cada detalle de una conversación larga mientras la persona sigue hablando; los detalles iniciales simplemente se desvanecen. Los investigadores descubrieron que cuando un agente de IA trabaja en una sesión única y continua, inevitablemente olvida la evidencia que recolectó al principio del escaneo. Para cuando llega al final para escribir su informe, podría describir con confianza archivos que nunca llegó a abrir o afirmar haber encontrado vulnerabilidades que fueron registradas horas antes, pero que han sido borradas de su memoria desde entonces. La solución que propusieron fue dividir el trabajo en fases cortas y distintas. En lugar de una sola conversación larga, el sistema utiliza una serie de agentes de corta duración. Cada agente realiza una pequeña parte del trabajo, escribe sus hallazgos en un archivo permanente y organizado, y luego se detiene. El siguiente agente lee solo un breve resumen de ese archivo, no los datos brutos. Este enfoque permite al sistema manejar tareas mucho más grandes sin perder el hilo, extendiendo efectivamente el horizonte de lo que la IA puede recordar mediante la compresión de la información que necesita llevar consigo.

Otro modo de fallo crítico involucró cómo el sistema juzgaba su propio éxito. Cuando una herramienta de red-teaming de IA intenta romper un sistema, necesita una forma de decidir si un ataque realmente funcionó. Los investigadores descubrieron que muchas herramientas automatizadas eran demasiado entusiastas al decir "sí, esto funcionó" cuando veían ciertas palabras clave, incluso si el ataque había fallado. Esto provocó una inundación de falsas alarmas. Para solucionar esto, el equipo diseñó un proceso de verificación de dos pasos. Primero, una comprobación rápida y económica filtraría los fallos obvios. Luego, un segundo juez, más cuidadoso, revisaría solo los casos que pasaron la primera comprobación. Crucialmente, este segundo juez tenía que ser un tipo de sistema diferente al primero; si ambos jueces fueran del mismo tipo de IA, cometerían los mismos errores y la segunda comprobación sería inútil. Al utilizar dos sistemas diferentes para verificar los resultados, el equipo pudo reducir drásticamente el número de falsas alarmas, haciendo que el informe final fuera mucho más confiable. También descubrieron un sesgo sutil pero peligroso: si un ataque fallaba de una manera que el sistema no podía entender, el software a menudo lo registraba como un éxito. Esto significaba que los ataques más peligrosos y elusivos eran los más propensos a ser ocultados o etiquetados erróneamente, dando una falsa sensación de seguridad.

Los investigadores también abordaron el problema del coste y el control. Las herramientas de seguridad pueden ser impredecibles; algunas se ejecutan durante segundos, mientras que otras pueden quedarse trabadas y ejecutarse durante horas, consumiendo enormes cantidades de dinero y potencia de cálculo. El equipo demostró que simplemente decirle a una IA "no gastes demasiado tiempo" en una instrucción de texto no es suficiente. La IA podría ignorar la instrucción, o podría distraerse con el contenido que está leyendo y olvidar la regla. En su lugar, el sistema necesita un guardián externo y rígido —una pieza de código que se sitúa fuera del proceso de toma de decisiones de la IA. Este guardián impone límites estrictos sobre cuánto tiempo puede ejecutarse una herramienta y cuánto puede gastar, cortándola en el momento en que alcanza el límite. Esto asegura que la IA no pueda accidentalmente llevar un proyecto a la quiebra o escanear un servidor que no tiene autorización para tocar. Los investigadores enfatizaron que la IA nunca debe ser la autoridad final sobre su propia seguridad o presupuesto; ese papel debe pertenecer siempre a una capa de código separada e inalterable.

Finalmente, el equipo analizó las herramientas en sí mismas. Probaron diez diferentes escáneres de seguridad y descubrieron que los que eran más fáciles de ejecutar manualmente eran a menudo los más difíciles de usar en un sistema automatizado. Muchas herramientas estaban diseñadas para que un humano hiciera clic en una pantalla de inicio de sesión y luego entregara la sesión al escáner. Cuando una IA intentaba hacer esto, a menudo fallaba porque el proceso de inicio de sesión era demasiado complejo o la herramienta no entendía cómo mantener la sesión iniciada. Los investigadores desarrollaron un patrón donde una herramienta de automatización de navegador separada gestionaba el inicio de sesión y luego entregaba una lista de enlaces autenticados y limpios al escáner. Esta simple separación de funciones resolvió muchos de los dolores de cabeza de integración. También notaron que el panorama de las políticas de seguridad de la IA es volátil; un modelo que permite una prueba de seguridad hoy podría bloquearla mañana debido a un cambio en las reglas del proveedor. Esto significa que cualquier sistema construido sobre estas herramientas debe ser lo suficientemente flexible como para intercambiar los modelos de IA subyacentes sin romper todo el flujo de trabajo.

El artículo concluye que el futuro de la seguridad automatizada no reside en hacer que la IA sea más inteligente, sino en construir una mejor estructura a su alrededor. Los sistemas más efectivos son aquellos que tratan a la IA como un trabajador poderoso pero falible, rodeado de un marco rígido de reglas, ciclos de memoria cortos y verificaciones independientes. Al aceptar que la IA olvidará, cometerá errores y, a veces, ignorará las instrucciones, los ingenieros pueden construir sistemas que sean lo suficientemente robustos como para manejar el mundo real. El trabajo de los investigadores proporciona un plano para pasar de las demostraciones experimentales a productos desplegados y fiables, asegurando que cuando un agente de seguridad de IA dice que ha encontrado un fallo, realmente lo ha encontrado, y que lo ha hecho sin romper el presupuesto ni las reglas.

Resumen Técnico: Seguridad Agéntica: Una Sistematización de Herramientas, Modos de Fallo y Leyes de Diseño para Pruebas de Penetración Impulsadas por LLM

Declaración del Problema

El campo de la seguridad agéntica —el uso de agentes de Modelos de Lenguaje de Gran Escala (LLM) para planificar, despachar e interpretar herramientas de seguridad de forma autónoma— ha pasado rápidamente de las demostraciones teóricas a los productos desplegados. Sin embargo, los profesionales que se adentran en este campo se encuentran con un conjunto recurrente de fallos que no derivan de una falta de capacidad del modelo, sino de los desafíos de ingeniería al componer componentes dispares (escáneres de seguridad, motores de flujo de trabajo y LLMs conversacionales) en un sistema fiable y sin supervisión.

Los sistemas actuales suelen fallar debido a:

Saturación de Contexto: Las sesiones de larga duración pierden la evidencia residente a medida que el contexto se llena, lo que provoca que el agente "olvide" hallazgos tempranos y genere informes que contradicen los datos registrados.
Fricción de Integración: Las herramientas diseñadas para operadores humanos (por ejemplo, que requieren inicio de sesión manual o interacción con la GUI) son difíciles de integrar en procesos automatizados.
Ruido de Verificación: Los evaluadores de red-teaming automatizados producen altas tasas de falsos positivos, y la verificación en cascada suele fallar cuando los evaluadores están correlacionados.
Deriva de Presupuesto y Alcance: Los agentes pueden exceder los presupuestos de tiempo o coste, o violar las restricciones de alcance, porque estos controles suelen colocarse en los prompts del sistema (que son vulnerables a la inyección) en lugar de ser aplicados mediante código determinista.
Volatilidad del Proveedor: Las políticas de seguridad y la disponibilidad de los modelos por parte de los proveedores pueden cambiar sin previo aviso, interrumpiendo las operaciones.

El artículo sostiene que estos no son errores aislados, sino instancias de fenómenos generales con soluciones cerradas y cuantificables.

Metodología

Los autores realizaron una evaluación práctica de diez herramientas de seguridad ampliamente utilizadas (análisis estático, análisis dinámico, auditoría en la nube, orquestación y red-teaming de IA) integradas en un flujo de trabajo personalizado y sin supervisión llamado Inspectra.

La metodología consiste en:

Sistematización de Herramientas: Calificar las herramientas en un Índice de Fricción de Integración (IFI) de cuatro dimensiones que cubre el esfuerzo de ingeniería, el coste organizacional, la autorización legal y la carga de mantenimiento.
Modelado Cuantitativo: Derivar modelos matemáticos de forma cerrada para:
- La fidelidad de la retención de contexto en sesiones largas.
- La eficacia de la verificación en cascada (razones de verosimilitud).
- El enrutamiento de modelos como un problema de optimización de la mochila (knapsack optimization).
- Los topes de ejecución óptimos para tiempos de ejecución de herramientas con colas pesadas.
Instanciación Arquitectónica: Utilizar Inspectra como un "ejemplo trabajado" para demostrar estos principios. Cada mecanismo en el artículo está explícitamente etiquetado como enviado (shipped), parcial o planificado, proporcionando una visión realista de la brecha entre el diseño y la implementación.
Análisis de Fallos: Catalogar modos de fallo específicos (por ejemplo, "sesgo de colapso no evaluable") y derivar correcciones estructurales en lugar de ingeniería de prompts heurística.

Contribuciones Clave

1. Un Vocabulario para los Flujos de Trabajo Agénticos

El artículo define un sistema agéntico como una familia de políticas estocásticas de LLM envueltas por un mediador determinista. Introduce una métrica, $\alpha$ (autonomía), para distinguir empíricamente un flujo de trabajo genuinamente agéntico de uno guionizado basándose en cuánto de la incertidumbre del plan es explicada por las observaciones.

2. La Economía del Contexto y la Jerarquía

Los autores derivan que las sesiones de larga duración pierden evidencia a una tasa inversamente proporcional al número de fases.

Regla 1: Para extender el horizonte utilizable, los flujos de trabajo deben dividirse en sub-agentes de corta duración que escriban los resultados en un almacén de artefactos mediante resúmenes validados por esquema.
La ganancia se determina por la tasa de compresión ( $\rho = s/\delta$ , donde $s$ es el tamaño del resumen y $\delta$ es el coste de tokens brutos), no meramente por el tamaño bruto de la ventana.
Para fases que exceden la ventana, es necesario el empaquetado bin (bin-packing) con resúmenes de arrastre; esto introduce un decaimiento geométrico de la fidelidad ( $\lambda^{m-1}$ ). Los hechos críticos deben leerse textualmente, no volver a resumirse.

3. Cálculo de Verificación para Red-Teaming

Verificación en Cascada: Una cascada de veredicto de dos etapas multiplica las razones de verosimilitud de sus evaluadores, mejorando significamente la precisión en casos de baja prevalencia. Sin embargo, esta ganancia colapsa si los dos evaluadores están correlacionados (por ejemplo, de la misma familia de modelos).
Sesgo de Colapso No Evaluable (Unscoreable-Collapse Bias): Registrar los resultados no evaluables (errores, bloqueos) como "el ataque falló" sesga los resultados hacia los falsos negativos, ocultando específicamente los hallazgos más graves. El artículo propone UNSCOREABLE (NO EVALUABLE) como una categoría de resultado de primera clase.
El Algoritmo 2 detalla una cascada de dos etapas que preserva los resultados no evaluables y utiliza familias de modelos distintas para asegurar la independencia.

4. Coste, Enrutamiento y Presupuestos

Enrutamiento como la Mochila: Asignar roles a los niveles de modelos (planificador frente a trabajador) es un problema de la mochila 0–1. La estrategia óptima es actualizar los roles basados en la eficiencia de enrutamiento ( $\theta_r = \Delta q_r / \Delta c_r$ ), no por convención.
Topes de Ejecución Óptimos: Para herramientas con tiempos de ejecución de cola pesada (distribución de Pareto), el tope de ejecución ( $\beta^*$ ) que maximiza el valor esperado viene dado por la forma cerrada:
$\beta^* = \frac{\alpha v}{c}$
donde $\alpha$ es el parámetro de la forma de la cola, $v$ es el valor de una invocación completada y $c$ es la tasa de coste.
Regla 2: Los presupuestos deben aplicarse dos veces (por llamada y por sesión) y los turnos del orquestador deben limitarse por separado, todo ello fuera de la política del LLM.

5. La Base de Computación Confiable (TCB)

El artículo argumenta que la aplicación del alcance y el presupuesto no puede delegarse a los prompts del sistema.

Los prompts son peticiones, no controles; son vulnerables a la saturación de contexto y a la inyección de prompts.
La capa de mediación determinista (predicado de alcance, contador de presupuesto, registro de auditoría) debe ser la TCB.
El Algoritmo 3 describe una ruta de invocación mediada donde las comprobaciones de alcance y presupuesto ocurren antes de la ejecución, asegurando que ninguna política de LLM pueda eludir estas restricciones.

Resultados y Hallazgos

Integración de Herramientas: Herramientas como OWASP ZAP y Nmap tienen una alta fricción de integración debido a la complejidad de la autenticación y las restricciones legales, respectivamente. Herramientas como Semgrep y Gitleaks son más fáciles de integrar pero requieren un manejo específico para el ruido y los falsos positivos.
Configuración de Inspectra: Los autores proporcionan una configuración del mundo real (Tabla IV) que muestra cómo se aplican estas leyes de diseño, incluyendo límites de presupuesto específicos (por ejemplo, topes de 30 minutos para la explotación) y asignaciones de niveles.
Modos de Fallo: El artículo documenta que los fallos "silenciosos" (por ejemplo, archivos de salida faltantes, respuestas no evaluables absorbidas en negativos) son más peligrosos que los fallos explícitos porque producen una falsa confianza.
Reproducibilidad: La estabilidad semántica (deduplicación por hash de contenido) es alcanzable incluso si el acuerdo de trayectoria byte por byte no lo es, debido a la naturaleza estocástica de los LLM.

Significación y Reivindicaciones

El artículo afirma que la seguridad agéntica no está bloqueada por la capacidad del modelo, sino por la disciplina de ingeniería y el diseño estructural. Su importancia radica en:

Del Paso de la Demostración a la Producción: Proporcionar la "cuenta de ingeniería" de lo que hace que estos sistemas sean fiables, presupuestables y reproducibles.
Regularidades Cuantitativas: Reemplazar las heurísticas de ensayo y error con leyes de forma cerrada (por ejemplo, la tasa de compresión para el contexto, la solución de la mochila para el enrutamiento, el tope $\alpha v/c$ para los presupuestos).
Cambio Arquitectónico: Establecer que el LLM debe estar fuera de la Base de Computación Confiable (TCB). La única arquitectura defendible para un agente que lee contenido controlado por un atacante y ejecuta herramientas es aquella donde el modelo propone y el código determinista dispone.
Transparencia: Al etiquetar cada componente de su propia plataforma (Inspectra) como enviado, parcial o planificado, los autores proporcionan una calibración realista para otros equipos, reconociendo que los jueces secundarios y la cobertura total en la nube son a menudo "diseñados pero nunca construidos".

El artículo concluye que, si bien el primer fallo (un informe contradictorio) es inevitable, comprender estas leyes de diseño permite a los profesionales reconocer la causa de inmediato, reduciendo el tiempo de depuración de meses a una tarde.