Qué modelos de IA rechazan el trabajo de seguridad

Apunta un agente de pentest autónomo a un objetivo real y disparará miles de peticiones que un filtro de seguridad no puede separar limpiamente de un ataque. A SwarmAttacker le rechazan muchas de ellas, y por eso la gestión de rechazos acabó siendo la parte más importante del sistema. También nos dejó un activo poco habitual: un corpus de 411 peticiones reales que nuestro modelo de producción rechazó de verdad, extraídas directamente de ejecuciones de benchmark en vivo contra la suite de seguridad web XBOW. No son prompts sintéticos. Cada una es el turno exacto, a mitad de un engagement, en el que un filtro de contenido bloqueó a un agente que estaba explotando una aplicación.

Así que hicimos una pregunta simple: reproducir esas mismas 411 peticiones a través de dieciséis modelos frontera y open-weight, y ver quién las rechaza. La métrica es la tasa de denegación: la proporción de peticiones que un modelo rechazó con sus propias palabras o que un filtro de la plataforma bloqueó.

La división es tajante. Dos modelos frontera cerrados, Claude Opus 5 y GPT-5.6 Sol de OpenAI, rechazan casi todo: 100% y 96.8%. Y todo el campo open-weight, DeepSeek V4, GLM-5.2, gpt-oss-120b, MiniMax M3, Nemotron Ultra, Kimi K3, no rechaza nada. Ni una sola petición de 411, cada uno.

No es una historia de laboratorios occidentales cautelosos y laboratorios abiertos imprudentes. Es más específico que eso. El rechazo agresivo en ciberseguridad se concentra en un puñado de modelos concretos, Opus 5, Sol, mientras que sus propios hermanos se comportan de forma completamente distinta. GPT-5.4, GPT-5.6 Terra y GPT-5.6 Luna de OpenAI están todos en el 4% o por debajo. El rechazo vive en el modelo, no en el proveedor.

Cada columna es una ejecución completa de las 411 peticiones, dividida en tres partes. Verde es la proporción que el modelo simplemente hizo: completó la tarea. Ámbar es el modelo declinando con sus propias palabras. Rojo es un filtro de la plataforma bloqueando la petición antes de que el modelo llegue a responder. Leído así, el campo open-weight es un muro sólido de verde, y los dos rechazadores frontera son un muro de rojo. Entre los modelos estrictos el mecanismo es el mismo: Sol, Opus 5, Fable 5, Terra y el GPT-5.5 de producción son casi por completo bloqueos rojos de plataforma, mientras que GPT-5.4 y Luna muestran solo una franja de ámbar: sin filtro, solo el propio modelo declinando. Solo Opus 4.8 y Sonnet 5 mezclan los dos. Pasa el cursor por cualquier columna para ver el desglose exacto.

El mismo modelo rechazó el 46% un día y el 4% al siguiente

El hallazgo más incómodo tiene que ver con GPT-5.5, el modelo que generó este corpus en primer lugar, y por eso aparece dos veces en el gráfico de arriba. En producción el 15 de junio, la ejecución que produjo el corpus, bloqueó 190 de las 411, un 46.2%, cada uno un bloqueo de política cibernética de la plataforma. Reproduce los prompts idénticos a través del mismo modelo el 26 de julio y la tasa de denegación se desploma al 4%. Los mismos pesos, los mismos prompts, seis semanas de diferencia.

Por eso ambos llevan fecha y se muestran lado a lado: el número no es una propiedad fija del modelo. Que una petición sea bloqueada depende mucho de la vía de servicio, del contexto que la rodea y de cómo fuera el filtro ese día, así que solo significa algo con una fecha adjunta. El corpus existe porque GPT-5.5 rechazó estas peticiones en junio, y sin embargo reproducirlas en julio apenas reproduce el rechazo. Para quien construya encima de un filtro de seguridad, ese no determinismo es el verdadero quebradero de cabeza: no puedes predecir, petición a petición, si el mismo modelo te ayudará.

¿En qué punto de una ejecución se disparan realmente los rechazos?

El corpus también muestra cuándo se marca una petición dentro de una ejecución, y no es donde uno supondría. El modelo rara vez rechaza una pregunta en frío. Dos de cada tres veces está reaccionando a lo que una herramienta acaba de devolver.

El 67% de las marcas caen justo después de un volcado de herramienta: el agente acaba de sacar una contraseña, una base de datos, un archivo de configuración o una flag{…}, y el siguiente paso es lo que dispara el filtro. El descubrimiento es el detonante. Por eso tampoco puedes encoger estas transcripciones para ahorrar tokens recortando la salida de las herramientas: el secreto exfiltrado es precisamente lo que causó el bloqueo.

Qué significa esto para quien construya una herramienta de seguridad

Si estás construyendo una herramienta de seguridad autorizada, la elección de modelo no es un error de redondeo: es la diferencia entre un sistema que funciona y uno que rechaza la mitad de su propio trabajo. El campo open-weight hará el trabajo sin quejarse. Entre los modelos cerrados, la dispersión dentro de un mismo proveedor es mayor que la dispersión entre proveedores, y el comportamiento de bloqueo es lo bastante inestable como para que un benchmark sea la única forma honesta de saber dónde cae un modelo concreto.

Por eso SwarmAttacker corre sobre GPT-5.4 como modelo principal resistente a rechazos y trata la gestión de rechazos como un componente de primera clase y no como una ocurrencia tardía. Cuando el filtro te da la espalda en dos de cada tres peticiones en el instante en que encuentras algo, el agente alrededor del modelo tiene que estar construido para esperarlo.

Método: 411 peticiones que nuestro modelo de producción rechazó y que sobrevivieron a un reintento con el mismo modelo, reproducidas una vez por modelo (GPT-5.5 se muestra en dos fechas, 15 jun y 26 jul). Claude Fable 5 es una ejecución agéntica con herramientas activadas sobre una muestra de 40 peticiones, donde su cyber-gate se dispara mucho más que en una llamada simple sin herramientas. El % denegado cuenta rechazos y bloqueos de plataforma sobre las peticiones que llegaron al modelo; los errores de transporte se excluyen. Las respuestas completas se almacenaron y se auditaron de forma independiente en busca de rechazos no detectados.