Filtrar las llamadas de un agente de pentest antes de ejecutarlas: qué debe ver un juez de alcance

¿De qué se trata?

Cuando un agente autónomo realiza trabajo de seguridad ofensiva —un escaneo de bug bounty, un pentest, una misión de red team—, una sola llamada de herramienta dirigida al host equivocado puede cruzar el límite del contrato con un cliente, interrumpir un sistema en producción o invalidar un hallazgo. El agente de un investigador que descubre una inyección SQL en un subdominio fuera de alcance no ha encontrado nada a ojos del programa, y en el peor caso ha cometido un delito.

Un artículo publicado en arXiv el 8 de julio de 2026, ScopeJudge: Cost-Aware Pre-Execution Gating for Offensive Security Agents (2607.07774), de Shane Caldwell, Max Harley, Ads Dawson, Michael Kouremetis, Vincent Abruzzo y Will Pearce (dreadnode), estudia si un segundo modelo más barato puede vigilar a ese agente y bloquear las llamadas fuera de alcance antes de que se ejecuten. Es un estudio defensivo: un benchmark y un conjunto de recetas de supervisión, no un ataque.

Cómo funciona

El planteamiento es el filtrado previo a la ejecución (pre-execution gating), una forma de supervisión de confianza. Un agente potente e intercambiable propone una llamada de herramienta; un juez barato y fijo inspecciona esa llamada y la acepta (se ejecuta) o la rechaza (se pide al agente que la corrija, o se escala a un humano). El juez actúa en cada paso, de modo que debe ser económico.

Lo difícil es que el alcance no es una regla fija. Como dicen los autores, el límite «vive en la petición»: un mismo comando —por ejemplo, un escaneo contra un dominio dado— está dentro de alcance en un encargo y es una violación en el siguiente, según el objetivo y el contexto. Una política escrita de antemano no puede enumerar el alcance específico de una petición que nunca ha visto.

Para medirlo, el equipo construyó ScopeJudge: 100 trayectorias de agentes procedentes de un conjunto de 30 entornos diseñados para tentar a los agentes a salirse del alcance, etiquetadas llamada por llamada por pentesters profesionales. El resultado son 4.897 llamadas de herramienta, de las cuales el 7,7 % son violaciones de alcance. La concordancia entre evaluadores es sustancial (κ de Fleiss = 0,64), y fija una referencia de experto humano en F1 = 0,78. Después probaron ocho modelos jueces bajo cinco estrategias de transcripción —cuánto contexto ve el juez, desde solo la política fija hasta la transcripción bruta completa— y trazaron la frontera coste-precisión.

El hallazgo destacado es negativo pero relevante: un juez que ve solo la política fija, ciego a la petición, tiene una exhaustividad (recall) que se desploma casi a cero. No puede detectar violaciones porque desconoce qué autorizaba el encargo. La supervisión condicionada a la petición es necesaria. Entre los jueces con contexto completo, los mejores son de pesos abiertos: GLM-5.2 alcanza F1 = 0,66, superando al mejor juez propietario (0,60) a alrededor de un tercio del coste por llamada.

Por qué importa

Dos controles habituales se quedan cortos aquí. El sandboxing supone que se puede aislar al agente, pero en seguridad los sistemas evaluados suelen ser de caja negra y propiedad del cliente: no se pueden clonar en un entorno desechable. La revisión humana sufre fatiga de alertas: el revisor pulsa «aprobar» alerta tras alerta hasta que la supervisión se vuelve teatro, el mismo reflejo documentado desde hace tiempo para los avisos de seguridad de los navegadores. Un juez automático no se cansa, y eso hace atractivo el filtrado por llamada a gran escala.

Pero los resultados moderan el optimismo. Incluso el mejor juez (0,66) queda por debajo del listón de acuerdo humano (0,78): esta supervisión reduce el riesgo sin eliminarlo. El artículo también señala una tensión real: dar más contexto al juez —el razonamiento del agente, las salidas de las herramientas— mejora la precisión pero amplía la superficie de ataque, porque un agente desalineado o un atacante externo podría envenenar ese contexto para colar una llamada fuera de alcance. Más visibilidad no es gratis.

Defensas

Recomendaciones prácticas para quien opera agentes de seguridad autónomos:

• Condicione el monitor a la petición, no solo a una política. Una constitución o lista blanca fija no captura el alcance de cada encargo. Entregue al juez el objetivo declarado y las restricciones del usuario para que razone sobre lo que esta tarea autorizaba.
• Filtre antes de ejecutar, no después. La auditoría a posteriori detecta las violaciones cuando el daño ya está hecho. Juzgue cada llamada dentro del bucle y bloquee, corrija o escale antes de que se ejecute.
• Elija un punto de operación de forma deliberada. Una violación no detectada suele costar más que un rechazo espurio: para encargos sensibles, ajuste el juez hacia la exhaustividad (menos fallos, más falsas alarmas) en lugar del F1 puro.
• Trate el contexto del juez como superficie de ataque. Las trazas de razonamiento y las salidas de herramientas mejoran el juicio pero pueden envenenarse; aísle y sanee lo que ingiere el juez, y no dé por hecho que un juez más inteligente es más seguro.
• Reserve al humano para la escalada, no para cada llamada. Destine la revisión humana a las llamadas que el juez marca: así la supervisión sigue siendo útil en vez de ahogar a los revisores en aprobaciones.

Estado

Elemento	Detalle
Hallazgo	Un juez LLM condicionado a la petición puede bloquear las llamadas fuera de alcance de agentes ofensivos antes de ejecutarse
Fuente	ScopeJudge: Cost-Aware Pre-Execution Gating for Offensive Security Agents, Caldwell et al., dreadnode, arXiv, 8 de julio de 2026
Benchmark	4.897 llamadas de herramienta (7,7 % de violaciones), 100 trayectorias etiquetadas por pentesters; κ de Fleiss = 0,64
Resultado clave	Los jueces limitados a la política fija tienen recall casi nulo; mejor juez F1 = 0,66 frente a referencia humana F1 = 0,78
Tipo	Benchmark defensivo / estudio de supervisión (investigación; sin CVE)