METR y Redwood burlan la supervisión de agentes de OpenAI: la cobertura era del 75–94% del tráfico

Durante tres semanas, del 21 de julio al 11 de agosto, un empleado de METR y otro de Redwood Research intentaron eludir el sistema con el que OpenAI vigila el desalineamiento de sus propios agentes internos. El resultado fue un informe cerrado de 61 páginas para los investigadores y el equipo de seguridad de OpenAI, y ahora también un breve resumen público. Su conclusión principal: en el momento de la revisión, el 75–94% del tráfico agéntico interno de la Responses API procedente de modelos de nivel GPT-5.5 o superior estaba sujeto a monitorización, y los investigadores admiten que la incertidumbre juega en ambas direcciones. Además, en el sistema aparecieron formas de escapar por completo de la vigilancia.

Acceso casi como el de los ingenieros de plantilla

La revisión se hizo en formato de piloto de «acceso profundo» para investigadores externos. Los participantes trabajaron con la base de código interna de OpenAI, los prompts y la configuración de los monitores, y con la documentación interna. Realizaron entrevistas técnicas con una docena aproximada de investigadores e ingenieros de los equipos de monitorización, sistemas de safety y seguridad. Trabajaron en dispositivos facilitados por OpenAI que no salían de la oficina, y siempre acompañados.

Las limitaciones también importan. Solo se puede publicar un post breve: OpenAI puede ocultar cualquier información que considere confidencial y, a diferencia de trabajos anteriores, METR no tiene derecho a describir de forma unilateral esas ediciones. A la dirección de METR y Redwood se le entregó una versión de 38 páginas del informe, editada por OpenAI. Lo que se evaluó fue el sistema tal como existía el 21 de julio y antes, no las ampliaciones que la compañía desplegaba en paralelo. La investigación tampoco guarda relación con la que METR realiza sobre el incidente de Hugging Face, aunque este se hizo público el primer día del ejercicio.

Doce hallazgos

• Cobertura del tráfico. El 75–94% del tráfico agéntico de la Responses API (sobre la que funciona Codex) procedente de modelos de nivel GPT-5.5 o superior estaba sujeto a monitorización.

Para un subconjunto de agentes internos de Codex la estimación es más alta: 99,2%. El tráfico del servicio interno de inference para investigación no se evaluó, por limitaciones de acceso y de tiempo. • Entrenamiento con RL.

Una parte de los rollouts se monitorizó en busca de desalineamiento de marzo a junio, pero al inicio del ejercicio los lanzamientos de RL no estaban cubiertos por el sistema. • Compaction. Por los eventos de compaction que no se podían verificar, alrededor del 10% del tráfico elegible de Codex no se monitorizó de mayo a julio de 2026.

No se pudo determinar la proporción exacta, porque los datos necesarios no se registraban. OpenAI detectó el problema antes del ejercicio y lo corrigió mientras este se desarrollaba. • Aplazamiento de la revisión.

El monitor se activaba cuando el agente devolvía el control al usuario. Mientras la compaction no se verificaba, el agente podía posponer indefinidamente la supervisión y seguir ejecutando acciones. Los investigadores no pudieron comprobar si alguien lo había aprovechado en la práctica.

• Errores y load-shedding. Según los datos presentados, el monitor fallaba en menos del 0,2% de las solicitudes, y en un periodo de 24 horas durante el ejercicio no hubo ni un solo descarte de carga. • Sandbox de Codex.

Se encontró una forma de saltarse el sandboxing y Auto-Review, tras lo cual el agente podría hacer todo lo que está al alcance del usuario del host. • Exploit con zona ciega. Apareció una técnica por la que cientos de las últimas acciones, incluidas las del propio exploit, quedaban fuera de la monitorización.

OpenAI tachó los detalles. • Serialización. Es probable que los agentes puedan construir entradas que rompan el monitor e impidan enviar la trayectoria a revisión humana: la trayectoria se serializa de forma distinta para el agente y para el monitor.

• Cabeceras. Dos cabeceras de cliente independientes desactivan la monitorización de los nuevos agentes, lo que permite lanzar una instancia idéntica pero sin vigilancia. Eso sí, el monitor puede detectar tanto el envío de las cabeceras como la creación de la instancia.

• Herramientas «de solo lectura». Dos herramientas agénticas internas sin monitorización se consideraban read-only, pero se halló un exploit sencillo que permite ejecutar acciones arbitrarias en su sandbox. No se comprobó su explotabilidad práctica.

• Completitud del contexto. Salvo algunas excepciones menores, el monitor ve la misma trayectoria que el agente. • Prompts del monitor.

Buscan scheming, sabotaje del propio sistema de monitorización, sabotaje en general, robo de datos, engaño, así como prompt injection entrante y saliente.

OpenAI comunicó que todas las vulnerabilidades que afectan a la pila de protección en producción están cerradas, y describió cambios sustanciales en la cobertura objetivo de la monitorización. METR no ha verificado estas afirmaciones.

Cinco principios para una monitorización que resista a un agente inteligente

A partir de los hallazgos, los autores formulan requisitos para sistemas capaces de resistir ataques deliberados, estratégicos y prolongados de agentes internos potentes:

• Eludir la monitorización debe ser difícil. Las solicitudes sin monitorización solo deben permitirse a organizaciones y claves de API aprobadas de forma explícita, a las que se prohíba el inference agéntico. Hay que revisar al agente cada N mensajes o minutos, y no al terminar el turno.

• Controlar la cobertura real. Llevar el registro de todo el inference y de la proporción monitorizada, cotejar con regularidad los logs con los del monitor, mantener una lista de elusiones conocidas y asegurarse de que el monitor ve el mismo contexto que el agente. • Responder rápido a los incidentes.

Designar a un responsable, establecer instrucciones claras y conservar logs inmutables y fáciles de consultar. • Atacar el monitor con regularidad. Realizar control evaluations, buscar bugs explotables y desarrollar una metodología para evaluar la colusión estratégica.

• Aislar a los agentes de los monitores. Ejecutar el scaffold separado del entorno de ejecución de herramientas, impedir que las acciones del agente influyan en si el monitor se activa y cuándo, y no mostrar al agente el diseño ni el código del sistema de supervisión.

Qué revisar en tu propia pila agéntica

Los agujeros típicos son aquí de ingeniería, no exóticos: un tipo de evento omitido, un disparador al final del turno, una cabecera de cliente, una rama de tráfico de más. Cualquier equipo que ejecute agentes de código autónomos puede repasar su propia infraestructura con esta lista: si se concilian los logs de inference con los del monitor, si se puede desactivar la vigilancia con un parámetro de la solicitud, si el monitor ve lo mismo que el agente y si la revisión se activa por tiempo y no al finalizar el turno. Para los auditores externos, el proyecto sienta un precedente: es posible un acceso profundo a las entrañas de un laboratorio, pero la transparencia pública sigue dependiendo, por ahora, de la voluntad de la propia compañía.

En próximas iteraciones, METR promete atenerse a sus propios principios de independencia y apertura.