Esto se solucionó rápidamente y se reveló como ‘CVE-2026-34219’ con crédito para el equipo. La preocupación más amplia, sin embargo, era separar los errores reales de los agentes de los que con seguridad se hacían pasar por tales.
“La sorpresa fue lo poco que se trabajó para encontrarlos y lo mucho que se invirtió en distinguir los errores reales de los que simplemente parecían reales”, escribió Nikos Baxevanis, autor de la publicación.
La dificultad comenzó con lo que produce un agente. Un fuzzer, la herramienta estándar que arroja datos malformados al software hasta que algo se rompe, devolvió un fallo y un registro de dónde ocurrió, que un ingeniero puede confirmar en minutos.
Un agente, sin embargo, devuelve una narrativa creada. Traza cómo se pudo alcanzar la falla, argumenta por qué es importante, propone una clasificación de gravedad y proporciona un código de trabajo que demuestra el ataque. Todo llega en prosa fluida, leyendo lo mismo ya sea que el error sea real o inventado.
Según la Fundación, se repiten tres tipos de falsos positivos.
El primero fue un fallo que sólo ocurre en una versión de prueba, donde el compilador activa controles de seguridad que el software enviado no incluye, por lo que nada se rompe para los usuarios reales.
El segundo fue un ataque que sólo funciona si el valor peligroso se coloca manualmente dentro del programa, porque cada ruta que un externo podría tomar para entregarlo rechaza el valor primero. El tercero provino de la verificación formal, la práctica de demostrar matemáticamente que el código se comporta correctamente, donde una prueba pasaba demostrando algo trivialmente cierto y no decía nada a los revisores sobre el software.
