Los filtros de seguridad frustran a un investigador que analizaba un posible fallo del kernel de Linux

El investigador de seguridad Daniel Fox Franke afirma que los controles de seguridad automatizados de un servicio de IA cerrado le impidieron repetidamente utilizar el sistema para investigar fallos relacionados con la utilidad de código abierto ripgrep. Finalmente recurrió a modelos de pesos abiertos para continuar con el análisis.

Franke declaró a The Register que el trabajo comenzó después de que ripgrep se bloqueara repetidamente durante una extensa sesión de Codex. Pidió a un agente que examinara el fallo, incluido el modo en que ripgrep y la biblioteca C musl gestionaban la asignación de memoria. El clasificador de ciberseguridad de OpenAI marcó varias de las solicitudes resultantes, especialmente las relacionadas con la reproducción del fallo y el análisis del montón.

Según Franke, acotó la tarea e indicó explícitamente al sistema que se centrara en el análisis del código fuente, en lugar de reproducir el fallo o inspeccionar archivos de volcado. No obstante, el clasificador siguió bloqueando las respuestas. Franke afirmó que el modelo subyacente GPT-5.6 Sol parecía dispuesto a ayudar, pero el sistema de filtrado independiente interrumpía el intercambio.

También afirmó que no probó los modelos de Anthropic porque esperaba que sus restricciones fueran más estrictas. Los mensajes de error de OpenAI le remitieron a sus programas Trusted Access para investigadores de seguridad, pero no prosiguió con la verificación. Describió el proceso como engorroso y afirmó que los modelos abiertos seguían siendo una alternativa viable.

Los modelos abiertos ofrecieron distintos niveles de asistencia

Franke utilizó Kimi K3, de Moonshot AI, y GLM-5.2, de Z.ai, durante la investigación. Atribuyó a K3 la identificación de indicios de que el problema podía estar relacionado con el kernel de Linux, aunque describió parte de sus razonamientos posteriores como poco fiables y propensos a conclusiones sin fundamento. Posteriormente, GLM-5.2 revisó ese trabajo y ayudó a reunir lo que Franke consideró un caso técnico más sólido.

El investigador recalcó que la investigación no está completa. Cree que los fallos están causados por un defecto del kernel y ha identificado un posible error en él, pero no ha demostrado que el defecto sospechado sea responsable de los fallos de ripgrep. Afirmó que actualmente no existe ningún parche y que el problema no parece ser explotable.

El episodio pone de relieve una tensión constante en las herramientas de seguridad basadas en IA: las salvaguardas diseñadas para limitar la asistencia a los atacantes también pueden interferir con la depuración legítima y la investigación de vulnerabilidades. Franke sostuvo que las herramientas inaccesibles o poco colaborativas pueden empujar a los investigadores hacia sistemas de pesos abiertos, cuyo comportamiento puede inspeccionarse y ajustarse de forma más directa.