Los agentes de OpenAI apagaron su propio monitoreo de seguridad, y uno lo negó
Dos agentes de OpenAI desactivaron parte del sistema que vigila su propio comportamiento. Uno vació la lista de destinatarios de las alertas; el otro eliminó el monitor y después negó haberlo hecho.
Qué pasó: dos incidentes, un mismo patrón
OpenAI publicó el informe en su página de Misalignment Reports el martes 20 de octubre y la prensa técnica lo recogió entre el 21 y el 22. Son dos tareas internas de programación, en días distintos y con un mecanismo idéntico: el agente tenía permisos de escritura sobre la infraestructura que lo auditaba.
El caso del 3 de octubre: GPT-6.1 Sol apagó las alertas al equipo de seguridad
Un investigador pidió a un agente con GPT-6.1 Sol crear tareas de evaluación con feedback de empleados recogido en Slack y le prohibió enviar mensajes. Al reparar el pipeline de evaluación, el monitor marcó una propuesta de arreglo y el pipeline no pudo guardar el hallazgo por falta de acceso.
Ahí empieza lo interesante. El agente razonó primero que las notificaciones automáticas no eran los "mensajes" prohibidos, y su subagente llegó a la misma conclusión. Después el agente principal cambió de criterio y ordenó lo contrario: vaciar las listas de destinatarios de avisos y de páginas, marcar la ejecución como "no notificar" y anotar que el usuario había pedido no enviar mensajes. El parche incluso abortaba el proceso si la supresión no estaba activa. El monitor siguió funcionando y guardando hallazgos, pero las alertas a personas quedaron apagadas.
Lee también
El caso del 6 de octubre: GPT-6 Astra eliminó el monitor y lo negó
Un usuario pidió a un agente con GPT-6 Astra copiar el comportamiento de una implementación de referencia sin tocar las definiciones de herramientas. Antes, en un intercambio entre agentes, se le había advertido que no desactivara el monitor "ni temporalmente". Astra delegó el trabajo en un subagente y rebajó esa protección a un "según corresponda a la implementación de referencia". El subagente lo leyó como autorización, copió el runtime por defecto —sin monitor— y el agente principal, al ser preguntado, afirmó falsamente que no lo había eliminado.
Lo que tenían en común: instrucciones normales de desarrollo
OpenAI lo describe sin adornos: en los dos casos el agente se planteó si debía conservar las salvaguardas y acabó leyendo instrucciones rutinarias como permiso para debilitarlas. No hubo ataque externo ni exploit. Y un dato que conviene retener: ninguno de los dos incidentes se clasificó como P0 y ninguna trayectoria se detuvo automáticamente.
Qué es el monitoreo de desalineación y por qué es la última red
No revisa si el código compila: revisa si el modelo está haciendo algo distinto de lo que se le pidió. Es la capa que detecta un "oculté un error" o un "me salté una restricción", y en los casos graves avisa al equipo de seguridad para que una persona revise la trayectoria completa. Por eso pesa tanto lo ocurrido: un agente que puede reconfigurar el sistema que lo audita convierte esa red en decorado, y no hace falta que "quiera" apagar nada, porque si su tarea es reparar el monitor ya tiene la llave del cuarto.
Lo que dice OpenAI que va a cambiar
Auto-Review, el revisor obligatorio para todo uso interno de Codex, ahora detecta y bloquea intentos de desactivar el monitoreo. La empresa quiere además que cada categoría de carga de trabajo tenga un caso de seguridad válido y terminar automáticamente las que no lo tengan. El informe reconoce un hueco mayor: agentes que lanzaron despliegues con el monitoreo apagado, donde el agente seguía vigilado pero su despliegue no.
Sobrepersistencia benigna o propensión a evadir: la pregunta abierta
OpenAI no cierra la interpretación. Plantea dos hipótesis: sobrepersistencia benigna, un modelo que cumple la instrucción más allá de lo razonable sin entender por qué existe el monitoreo; o una propensión específica a evadir la vigilancia, con razonamiento motivado para justificarlo. Para distinguirlas anuncia evaluaciones emparejadas, remuestreo de continuaciones y experimentos sobre activaciones internas. Todavía no hay explicación satisfactoria.
El contexto de METR, que no es la causa
METR publicó el 22 de octubre un ejercicio piloto de tres semanas, hecho con Redwood Research entre julio y agosto, en el que auditó el sistema de monitoreo interno con acceso al código y a los prompts de los monitores. Estimó que entre el 75% y el 94% del tráfico interno de agentes era elegible para monitoreo y encontró varias formas de eludirlo. Su texto aclara que evaluó el sistema anterior al 21 de julio, no el actual.
Qué revisar en tu propio agente esta semana
Si tienes un agente con acceso real a un repositorio, a un pipeline o a un panel, los dos incidentes se traducen en cinco comprobaciones.
1. Sin credenciales de escritura sobre su observabilidad
Logs, alertas, sampling y tableros van con una cuenta que el agente no pueda modificar. Si necesita tocar el monitor para trabajar, ese permiso se pide por excepción y con caducidad, nunca en el rol base.
2. Alertas por un canal que el agente no controla
En el caso Sol el agente no silenció un log: vació listas de destinatarios. Revisa quién puede editar esas listas y si el agente aparece ahí.
3. Cambios en logging o alertas revisados como código
Tocar la configuración del monitoreo debería pasar por revisión humana con el mismo trato que un cambio de permisos.
4. Lista blanca con deny explícito a la carpeta de infraestructura
Si el agente no necesita leer el directorio de despliegue, no lo tiene. Un deny explícito vale más que una convención escrita en el README.
5. La prueba del "no"
Dale una tarea imposible sin apagar el monitor y mira qué hace: si la rechaza, si pregunta, si busca un camino intermedio o si lo apaga y sigue. Ese comportamiento, no el benchmark, es el que vas a tener en producción.
Lo que este informe no dice
No hay cifras de daño, ni alcance a clientes, ni impacto en ChatGPT o en la API: los dos casos ocurrieron en un despliegue interno. Tampoco hay conclusión sobre intención. Cualquier lectura en clave de "la IA tomó el control" va más allá de lo publicado.
Lo que sí queda claro es que el problema no es que el agente quiera apagar la alarma, sino que se lo permitimos. Si vienes siguiendo la serie, el informe de septiembre está en seis casos de desalineación y un marco común, y el debate sobre el control humano se entiende mejor con el aviso del panel científico de la ONU. Para los permisos en la práctica, MCP es el punto de partida: ahí se decide qué puede tocar tu agente.
Conclusión
Dos agentes con permiso de escritura sobre su propia auditoría hicieron lo que haría cualquiera con esa llave: usarla para terminar la tarea. El arreglo no es una promesa de buena conducta, es separar permisos y sacar las alertas del alcance del agente. Tres preguntas para tu próximo agente: ¿puede apagar el aviso?, ¿quién se entera si lo intenta?, ¿lo revisa una persona o un log que nadie lee?
