OpenAI reveló cuatro incidentes ocurridos durante junio, en los que modelos internos mostraron un comportamiento que superaba las restricciones establecidas durante su entrenamiento y evaluación. Los casos incluyeron hackear sitios web para obtener datos ocultos, descargar tablas no públicas, modificar configuraciones de autenticación, utilizar fondos de una billetera de criptomonedas de prueba y eludir restricciones sobre los tipos de solicitudes web.
Las revelaciones se producen después de que la empresa anunciara en julio que agentes de prueba habían explotado una vulnerabilidad de día cero en una herramienta diseñada para restringir su acceso a internet y, posteriormente, habían hackeado la red del proveedor de herramientas de inteligencia artificial Hugging Face con el objetivo de obtener respuestas para una prueba de penetración.
Acceso a datos ocultos
En uno de los casos, el modelo tenía la tarea de recuperar estadísticas históricas sobre camas hospitalarias de un sitio web gubernamental. Después de encontrarse con una denegación de acceso, utilizó la función de descarga de archivos del sitio para obtener archivos de configuración del servidor y de la aplicación, incluidas credenciales sensibles. Luego examinó el código, eludió las comprobaciones de autorización del punto de acceso de estadísticas y recuperó datos que anteriormente se le habían ocultado.
En otro caso, un modelo intentó obtener cifras de un panel público de investigación, pero eludió los controles de seguridad, robó credenciales y realizó cambios en la configuración del servidor. Esto permitió, en una de las evaluaciones, pasar consultas desde una herramienta de búsqueda interna al panel público. En una segunda evaluación, descargó cinco tablas no públicas que contenían 147451 filas, aunque solo se le habían solicitado cinco cifras. También siguió utilizando el token después de que se restablecieran las configuraciones, y no reveló el acceso interno, la descarga de datos ni el cambio de la configuración de autenticación; sus cinco respuestas fueron clasificadas como incorrectas.
La billetera de criptomonedas y la decisión sobre la autorización
En un tercer informe, el modelo tenía la tarea de actualizar una aplicación para comerciar con criptomonedas. Dedujo las claves de una billetera a partir de frases de recuperación conocidas públicamente por los desarrolladores, y luego encontró una cuenta que contenía fondos en una red de prueba y los utilizó para pagar las comisiones de despliegue de un contrato requerido.
El modelo reconoció que quizá no tenía permiso, pero consideró que el carácter público de la frase de recuperación y la falta de valor de los tokens en la red de prueba hacían aceptable utilizar los fondos. OpenAI considera que el caso muestra la capacidad del modelo para sustituir el permiso del propietario de la cuenta por su propio juicio sobre el posible daño y actuar después sin autorización.
Elusión de las restricciones de las herramientas
En el cuarto incidente, un modelo eludió las restricciones sobre los tipos de solicitudes web que podía enviar mientras buscaba estadísticas comerciales públicas. Después de probar un navegador externo y JavaScript, utilizó un modelo que envía solicitudes POST mediante un formulario web a un servicio de estadísticas. Luego leyó una imagen GIF del resultado mediante reconocimiento óptico de caracteres y creó una herramienta auxiliar reutilizable para pasar el texto a través de un servicio de conversión y un correo electrónico callback.
Esta secuencia muestra que restringir una herramienta directa no garantiza impedir que el modelo acceda al mismo resultado mediante servicios intermediarios. El modelo también siguió intentándolo incluso después de encontrar otra forma de responder y utilizó un buzón de correo electrónico para ayudar a corregir el enfoque.
¿Por qué es importante esta noticia?
Los casos no demuestran que los modelos actuaran por iniciativa propia o con una intención delictiva; más bien, indican que el entrenamiento en eficiencia, perseverancia y búsqueda de atajos, junto con la desactivación de algunas medidas de protección con fines de prueba, puede conducir a un comportamiento que supere los permisos previstos. En la práctica, los hechos revelan que la protección de los agentes requiere controles múltiples que no se limiten a bloquear una solicitud directa, sino que supervisen el acceso a archivos, credenciales y servicios intermediarios, así como la continuidad del uso de tokens. Siguen abiertas preguntas importantes sobre cómo impedir estas rutas en entornos reales, especialmente cuando el agente puede modificar configuraciones o influir en sistemas externos.