Fuera, paridad; dentro, una lotería
El hecho más importante aquí es incómodamente simple: en la misma aplicación el mismo día, los modelos divergieron en 48 puntos en una prueba de caja blanca. En el informe original de ejecución, se ve crudo: Kimi K3 obtuvo 88/100, Claude Opus 4.8 70/100, GPT-5.5 40/100.
Mientras, el reconocimiento externo casi no mostró diferencias. Los tres modelos produjeron el mismo conjunto: 7 hallazgos, 0 CVEs, 5 direcciones IP y 10 puertos. En otras palabras, el reconocimiento básico se ha vuelto un commodity: el escáner encontró, el modelo recontó.
Pero una vez concedido el acceso, estalló el caos. Kimi K3, según el autor de la prueba, primero leyó el frontend, extrajo la estructura de la API y la navegó como un mapa: 20 pasos, 20 hallazgos, 3 exploits vivos, 0 fallos.
Claude Opus 4.8 parecía más estable en comportamiento pero más débil en cobertura: 11 pasos, 2 hallazgos, 0 fallos. Confirmó el acceso, leyó una fuente de datos y simplemente se detuvo. Esto es particularmente frustrante en red teaming: formalmente, el modelo no falló, pero en esencia no examinó suficientemente el objetivo.
GPT-5.5, por el contrario, se movió más tiempo pero se desvió. El informe dice que el modelo decidió tempranamente que las credenciales no funcionaban, nunca revisó esa decisión, se fue a la superficie pública y finalmente dio una conclusión falsa: 18 pasos, 8 hallazgos, 3 fallos.
Por separado, el coste del proceso es llamativo. Según las mismas notas, Kimi consumió unos 23k tokens por hallazgo, Claude unos 280k. Si esas cifras son correctas, no es solo una diferencia de coste sino una diferencia en cómo el modelo mantiene una trayectoria de trabajo.
Por qué esto importa en la práctica
La conclusión clave aquí no es qué modelo "ganó". Es que las frases "no se encontró nada" y "el modelo no pudo comprobar correctamente" pueden disimularse mutuamente en un informe.
Por lo tanto, yo miraría no la puntuación final de severidad sino la mecánica de ejecución: cuántos pasos se dieron, dónde se atascó el modelo, si volvió a las hipótesis, qué cubrió exactamente después del inicio de sesión. Una puntuación baja no equivale a seguridad. A menudo solo significa una cosa: no se demostró la ruta crítica.
Y eso ya no es un matiz académico. Si un modelo califica "medio" y otro en el mismo objetivo extrae un escenario crítico con exploits vivos, el problema no es la estética de un benchmark sino una falsa sensación de riesgo mitigado.
De este caso, extraería una regla muy práctica: las pruebas autenticadas no pueden reducirse a un solo agente y un solo veredicto. Fuera, los LLM ya son bastante parejos, pero dentro de una aplicación aún tienen demasiada aleatoriedad como para confundir el silencio del modelo con la ausencia de vulnerabilidad.