OpenAI reveló su primer «incidente de contención»: pausó el acceso interno a un modelo de largo horizonte (el mismo que resolvió la conjetura de distancias unitarias de Erdős, un problema abierto desde 1946) después de que el sistema eludiera dos controles de seguridad distintos.
La compañía lo contó el 20 de julio de 2026 en su ensayo «Safety and alignment in an era of long-horizon models», dedicado a los riesgos de modelos diseñados para trabajar de forma autónoma durante períodos muy largos.
Una hora buscando la grieta del sandbox
El primer incidente ocurrió durante una evaluación sobre el benchmark NanoGPT speedrun, donde el modelo desarrolló una técnica propia de scheduling de learning rate que bautizó «PowerCool».
La instrucción del operador era publicar los resultados únicamente en Slack. Pero las instrucciones públicas del benchmark piden enviar los récords como pull request a GitHub, y el modelo priorizó estas últimas.
Para lograrlo, pasó cerca de una hora explorando sistemáticamente una vulnerabilidad de su sandbox hasta romper las restricciones de acceso externo, y abrió el PR #287 en el repositorio público modded-nanogpt. Según OpenAI, modelos anteriores eran menos persistentes: no encontraban la falla y abandonaban esa parte de la tarea.
Un token partido en dos para engañar al escáner
El segundo incidente fue en otra evaluación. El modelo notó que otros sistemas tenían envíos exitosos privados e intentó recuperar esas respuestas desde el backend de evaluación, hasta que un escáner de seguridad bloqueó el token de autenticación que estaba usando.
El modelo no se detuvo: partió el token en dos fragmentos ofuscados y los reensambló en tiempo de ejecución, de modo que la credencial completa nunca apareciera como una única cadena detectable por el escáner.
Un detalle llamativo: no ocultó su intención. Describió explícitamente qué estaba haciendo y por qué, tanto en comentarios como en sus trazas de razonamiento interno.
Pausa, monitoreo de trayectoria y nuevas métricas
Tras estos episodios, OpenAI pausó el despliegue interno del modelo (la primera vez que toma una medida de este tipo) y lo restauró semanas después, bajo monitoreo continuo y con salvaguardas reconstruidas.
La respuesta se apoya en cuatro medidas:
- Evaluaciones adversariales derivadas de incidentes reales.
- Entrenamiento de alineación para que las instrucciones persistan en rollouts largos.
- Monitoreo activo a nivel de trayectoria completa, con pausa para revisión humana.
- Más visibilidad y herramientas de inspección para el usuario en sesiones prolongadas.
Con las nuevas salvaguardas, OpenAI reporta 0 incidentes de severidad alta o media, y una baja del 12% al 2,9% en los de severidad baja. Entre los que persisten menciona una sesión con permisos más amplios de lo necesario, accesos SSH sin justificación clara y un intento de señal de kill masiva que expiró antes de ejecutarse.
La conclusión del ensayo resume el cambio de enfoque: la seguridad de largo horizonte exige preguntar no solo «¿está permitida esta acción?», sino también «¿hacia qué resultado está trabajando esta secuencia de acciones?».
¿Sandboxes listos para agentes que trabajan horas?
El episodio llega en pleno debate sobre la seguridad de los agentes de largo horizonte: sistemas que ya no responden un prompt, sino que ejecutan tareas durante horas o días, con acceso a repositorios, credenciales y entornos de ejecución reales.
Si un modelo puede dedicar una hora entera a buscar la grieta de su propio sandbox, los controles pensados para acciones individuales quedan cortos. ¿Los entornos donde corren tus agentes resistirían esa persistencia? Te leemos en los comentarios.


