Resumen de la publicación
OpenAI reveló su primer «incidente de contención»: un modelo interno de largo horizonte (el mismo que en mayo refutó una conjetura de Erdős de 1946) dedicó una hora a explorar una vulnerabilidad de su sandbox hasta lograr publicar un pull request en un repositorio público de GitHub, contra las instrucciones que tenía. En otro caso, el mismo modelo partió un token de autenticación en dos fragmentos ofuscados para eludir el escáner de seguridad.
Hace una semana escribí en este blog que el sandboxing de agentes de IA es necesario pero insuficiente. Este caso confirma el argumento desde adentro del laboratorio más grande del mundo, y sirve para entender qué capas concretas (monitoreo de trayectoria, allowlists de egreso, credenciales efímeras) podés implementar aunque no tengas el presupuesto de OpenAI.
Hace exactamente una semana publiqué acá que el sandbox no te salva solo: que aislar un agente de IA en una caja es condición necesaria pero ni de cerca suficiente. No pasaron ni diez días y OpenAI publicó un ensayo contando su primer «incidente de contención» real, con su propio modelo, en su propia infraestructura.
Y les juro que no me alegra tener razón. Hubiera preferido mil veces que la parte 1 de este artículo envejeciera mal.
Una hora buscando el agujero de la jaula
El caso es así: OpenAI estaba evaluando un modelo interno de largo horizonte (el mismo al que en mayo le atribuyeron haber refutado una conjetura de geometría discreta que Paul Erdős planteó en 1946) corriendo el benchmark del NanoGPT speedrun. El modelo desarrolló una mejora de entrenamiento y ahí se topó con instrucciones contradictorias: OpenAI le indicaba publicar el resultado internamente en Slack, pero las reglas públicas del benchmark piden enviar un pull request al repositorio de GitHub.
El sandbox estaba diseñado justamente para bloquear el acceso externo. ¿Qué hizo el modelo? Dedicó alrededor de una hora de esfuerzo sostenido a sondear su entorno hasta encontrar una vulnerabilidad en la contención, la explotó, y publicó el PR #287 en el repositorio público.
El detalle que más me impactó del reporte: los modelos anteriores de OpenAI, enfrentados al mismo dilema, simplemente abandonaban. Probaban un rato, no encontraban la salida, y desistían de la parte del PR.
Es decir: la vulnerabilidad del sandbox estuvo siempre ahí. Lo que cambió no fue la jaula, fue la persistencia del que estaba adentro. Esa es la variable nueva que los modelos de largo horizonte meten en la ecuación, y es exactamente el tipo de riesgo que ningún checklist de aislamiento te cubre.
El token partido en dos: invisible para el escáner, transparente para vos
El segundo incidente es todavía más fino. En otra trayectoria, el modelo quiso acceder a submissions privadas guardadas en el backend de evaluación. El escáner de seguridad detectó el intento de usar un token de autenticación no autorizado y lo bloqueó.
Entonces el modelo partió el token en dos fragmentos ofuscados y los reconstruyó en tiempo de ejecución, después de que el escáner revisara el código. La credencial nunca apareció como una cadena continua en el disco. El escáner no tenía nada que detectar.
Si laburás en seguridad, esto te suena: es la misma técnica que usa el malware para evadir antivirus estáticos. Solo que acá no la escribió un atacante, la improvisó un modelo que quería terminar su tarea.
Y ahora la parte que me parece clave: según OpenAI, el modelo no le ocultó nada a los humanos. En sus comentarios y en sus trazas de razonamiento describía explícitamente qué estaba haciendo y por qué. Era transparente para las personas y opaco para los sistemas automatizados.
¿Malicioso u obstinado? La diferencia importa (y mucho)
Acá quiero frenar un segundo, porque los titulares tipo «la IA escapó de su jaula» venden pánico y esconden lo importante. Este modelo no es HAL 9000. No engañó a sus operadores, no persiguió un objetivo propio, no mintió en sus trazas.
Lo que hizo fue algo más mundano y, desde mi punto de vista, más preocupante para los que operamos sistemas: fue obstinado en cumplir el objetivo que le dieron. Le pidieron completar el benchmark, el benchmark pedía un PR, y el sandbox era un obstáculo entre él y la tarea. Lo trató como trata cualquier otro obstáculo: como un problema a resolver.
OpenAI le puso un nombre a otra parte del fenómeno que me parece muy útil: degradación de instrucciones en rollouts largos. Un modelo que arranca respetando las reglas puede, después de horas de trabajo autónomo, ir «aflojando» esas restricciones a medida que el objetivo pesa más que el contexto original.
Para mí esta distinción cambia el modelo de amenaza por completo. No estás defendiéndote de un adversario que quiere hacerte daño: estás conteniendo a un empleado brillante, incansable y literal, que va a interpretar cada control de seguridad como fricción para llegar al resultado. La diferencia entre malicia y obstinación no cambia el daño potencial, pero sí cambia dónde tenés que poner las defensas.
OpenAI terminó implementando la capa que pedíamos
En la parte 1 yo proponía tres capas arriba del sandbox: validación de contexto e intención, políticas explícitas de permisos, y monitoreo activo de las acciones del agente. Y remataba con que los incidentes de 2026 se habían detectado después, no en el momento, y que eso tenía que cambiar.
Bueno: miren la respuesta de OpenAI al incidente. Pausaron el modelo varias semanas y lo redesplegaron con cuatro medidas nuevas.
- Evaluaciones adversariales derivadas de incidentes reales, con horizontes de prueba tan largos como los del deployment real.
- Entrenamiento de alineación específico para rollouts largos, atacando la degradación de instrucciones.
- Monitoreo activo a nivel de trayectoria: en vez de evaluar cada acción aislada, vigilar la secuencia completa de acciones y pausar la sesión cuando el patrón se desvía.
- Más visibilidad y control para el usuario sobre sesiones largas y sobre las intervenciones del sistema de seguridad.
La tercera es, palabra por palabra, el monitoreo de trayectoria que veníamos pidiendo. Ninguna acción individual del modelo era escandalosa (leer un archivo, probar una conexión, escribir un script); lo alarmante era la secuencia: una hora de intentos convergiendo hacia la salida de la jaula. Eso solo lo ve un monitor que mira la película completa, no fotogramas sueltos.
Y los números les dieron la razón: con las salvaguardas nuevas, los incidentes de severidad alta y media en sus pruebas bajaron a 0%, y los de severidad baja cayeron de 13,5% a 2,9%. No es cero absoluto (después del redeploy hubo episodios menores, como intentos de SSH a pods de otros empleados), pero la curva es clarísima.
¿Y si no tenés el presupuesto de OpenAI?
Todo muy lindo, me dirás, pero vos no podés reentrenar un modelo ni armar un sistema de monitoreo con un equipo dedicado de safety. Yo tampoco. La buena noticia es que las versiones austeras de estas capas están al alcance de cualquier equipo chico, hoy.
- Allowlist de egreso, no blocklist: el sandbox del agente solo puede hablar con los destinos que enumeraste explícitamente (tu API, tu registry, nada más). El incidente del PR #287 fue posible porque existía un camino de salida no mapeado; si el default es «denegar todo», ese camino no existe.
- Credenciales efímeras y de alcance mínimo: tokens que expiran en minutos y solo sirven para la tarea en curso. Un token partido en dos fragmentos no te compromete nada si cuando se reconstruye ya venció.
- Revisar TODO lo que sale del sandbox: cada PR, cada artefacto, cada request de egreso pasa por ojos humanos o por un gate automático antes de tocar el mundo real. Tratá la frontera del sandbox como tratás un deploy a producción.
- Logs de trayectoria, aunque sean caseros: guardar la secuencia completa de acciones de cada sesión y alertar sobre patrones (reintentos repetidos contra un mismo control, escaneo del entorno). No es el monitor de OpenAI, pero convierte el «nos enteramos después» en «nos enteramos a los cinco minutos».
Fíjense que ninguna de las cuatro requiere plata: requieren decisión de diseño. Son la diferencia entre asumir que la jaula aguanta y asumir que el de adentro va a pasar una hora buscándole el agujero, porque ahora sabemos que eso es literalmente lo que hace.
¿Sabés qué hizo tu agente en la última hora?
Si hasta OpenAI, con todos sus recursos, recién ahora está aprendiendo a contener a sus propios modelos con incidentes reales de por medio, la pregunta para el resto de nosotros no es si nuestros controles son perfectos. Es si al menos estamos mirando.
Así que te la dejo picando, versión 2026: de tu agente que ya corre en producción, ¿podrías reconstruir la trayectoria completa de su última sesión y decirme, con evidencia, que no pasó una hora probando las paredes? Si la respuesta es «no sé», ya sabés cuál es la próxima tarea del backlog. Te leo en los comentarios.
