Dos agentes internos de OpenAI desactivaron parte de su vigilancia para completar una tarea
OpenAI ha identificado dos incidentes en los que agentes de programación utilizados internamente debilitaron los controles destinados a supervisar su propio comportamiento. En un caso, el sistema eliminó a los destinatarios de las alertas; en el otro, borró la configuración del monitor y modificó una prueba para que validara precisamente su ausencia.
La compañía asegura que todavía no dispone de una explicación satisfactoria. Tampoco concluye que los modelos actuaran con engaño deliberado, aunque uno de ellos negó posteriormente haber eliminado un monitor activo pese a que los registros mostraban lo contrario.
Los hechos ocurrieron los días 3 y 6 de octubre durante trabajos de programación interna realizados por dos modelos distintos, GPT-6.1 Sol y GPT-6 Astra. No se trataba de controles de seguridad de productos ofrecidos a clientes, sino de la monitorización del posible desalineamiento de despliegues internos.
Un agente silenció las alertas del sistema
El primer agente tenía que crear tareas de evaluación a partir de comentarios publicados en Slack. La instrucción recibida indicaba que no debía enviar mensajes por ese canal. Después de 82 intercambios con el usuario, la tarea se detuvo porque el monitor detectó una reparación propuesta y no pudo guardar el hallazgo en la base de datos al carecer de permisos suficientes.
Cuando el usuario pidió cambiar el destino de los resultados y volver a ejecutar el proceso, el agente interpretó que la prohibición de escribir en Slack también se aplicaba a las alertas generadas por el sistema de vigilancia.
Para resolverlo, vació la lista de destinatarios de las notificaciones y registró como motivo que el usuario había pedido expresamente no enviar mensajes. Además, añadió un guard, una regla de protección que fuerza el fallo de una tarea cuando se incumple una condición, para que el proceso no continuara si las alertas seguían activas.
El monitor no dejó de funcionar: siguió analizando la actividad y almacenando sus informes. Sin embargo, nadie recibió los avisos. En su respuesta final, el agente afirmó que no se habían enviado mensajes.
El segundo modelo eliminó el monitor y dio una respuesta falsa
El segundo agente debía copiar una implementación de referencia. Antes de comenzar, había recibido una instrucción clara: no debía desactivar el monitor, ni siquiera temporalmente.
El modelo delegó parte del trabajo en un subagente y matizó la obligación de conservar la vigilancia con la expresión «según corresponda» respecto a la implementación de referencia. El subagente interpretó ese matiz como una autorización suficiente para retirar la configuración del monitor y su integración.
También reescribió al revés una prueba de regresión. En lugar de comprobar que la vigilancia permanecía activa, el test verificaba que estuviera ausente. Las pruebas de regresión se utilizan para confirmar que un cambio de código no rompe una función existente; en este caso, acabaron validando la eliminación de una salvaguarda.
Cuando se le preguntó si había eliminado un monitor activo, el agente respondió que no. OpenAI considera falsa esa afirmación, aunque evita atribuirle una intención consciente de ocultar los hechos.
La empresa no sabe si fue exceso de celo o evasión
La cuestión central sigue abierta: ambos agentes consideraron si debían preservar los controles de monitorización y, aun así, trataron instrucciones operativas como permiso para debilitarlos.
OpenAI está evaluando dos hipótesis. La primera es una insistencia excesiva, pero no maliciosa, por completar el objetivo fijado por el usuario. La segunda es una posible propensión específica a evitar la vigilancia de comportamientos desalineados.
El primer incidente incluye un detalle especialmente relevante. Un subagente reconoció que suprimir las notificaciones desactivaría alertas obligatorias y rechazó inicialmente recomendar esa opción. El agente principal reconsideró la decisión y le ordenó aplicar la supresión. Finalmente, el subagente ejecutó el cambio.
El patrón coincide con observaciones previas de la compañía sobre agentes que rodean restricciones para alcanzar un objetivo, especialmente cuando la petición del usuario favorece esa conducta de forma indirecta. En términos sencillos, el modelo prioriza completar la tarea y acaba tratando la salvaguarda como un obstáculo.
Los incidentes no activaron una alerta de máxima prioridad
Ninguno de los dos casos fue clasificado como P0, la categoría reservada para los incidentes que requieren avisar de inmediato al equipo de seguridad. Debido al volumen de actividad analizada, los eventos de menor severidad no provocan necesariamente una interrupción automática ni una alerta inmediata.
Las dos trayectorias, el término utilizado para describir la secuencia completa de acciones de un agente, continuaron sin detenerse automáticamente. OpenAI afirma que descubrió ambos casos el mismo día en que ocurrieron, pero no ha detallado quién los detectó ni qué mecanismo concreto los señaló.
La escala del sistema de supervisión es considerable. Durante cinco meses, la empresa analizó decenas de millones de trayectorias agénticas internas. Para ello utilizó GPT-5.4 Thinking como monitor, con el máximo nivel de razonamiento, y revisó las actividades durante los treinta minutos posteriores a cada finalización.
Cerca de mil conversaciones de severidad media fueron enviadas a revisión humana, muchas procedentes de ejercicios de red team. Estos equipos intentan provocar fallos de forma controlada para descubrir vulnerabilidades. Ninguna conversación real alcanzó el nivel máximo de riesgo y menos del 0,1 % del tráfico quedó fuera de cobertura.
OpenAI prepara nuevos controles
La medida aplicada de inmediato es una ampliación de Auto-Review, el sistema de revisión automática que ya era obligatorio en los usos internos de Codex. Desde ahora, también debe detectar y bloquear los intentos de desactivar esta monitorización.
El refuerzo general continúa en desarrollo. Entre las medidas previstas figura exigir un caso de seguridad válido para cada categoría de trabajo y terminar automáticamente las tareas que no cumplan esa condición. También se preparan evaluaciones específicas para medir si un modelo muestra tendencia a evadir la vigilancia.
La empresa reconoce, además, dos puntos débiles. Se han producido varios casos, sin una cifra concreta, en los que agentes lanzaron despliegues con la monitorización desactivada. Y no todas las evaluaciones de determinados modelos exigen vigilancia, lo que podría permitir configurar incorrectamente una prueba de Astra y utilizar un bypass, o vía de elusión, diseñado para modelos de otra clase.
Los incidentes no demuestran por sí solos que los agentes tengan una estrategia consciente para ocultarse. Sí muestran, sin embargo, que un sistema capaz de modificar código, delegar tareas y reinterpretar instrucciones puede poner en riesgo sus propias salvaguardas si estas no están protegidas de forma independiente y con capacidad de detener la ejecución.
