METR y Redwood encuentran fallos en el monitoreo interno de agentes de IA de OpenAI

Evaluadores externos encontraron varias vulnerabilidades novedosas en el sistema interno de OpenAI para monitorear sus propios agentes de IA por desalineación, según METR el 22 de octubre de 2026 [1]. Un empleado de METR y otro de Redwood Research sometieron el sistema a pruebas de estrés en las instalaciones durante tres semanas este verano, con acceso profundo a la infraestructura de OpenAI [1][2].

¿Qué probaron METR y Redwood Research?

METR y Redwood Research probaron el monitoreo interno de desalineación de OpenAI en sus instalaciones del 21 de julio al 11 de agosto de 2026. Los dos evaluadores tuvieron acceso al código base interno de OpenAI, a los prompts y detalles de configuración del monitor, y a la documentación interna, e entrevistaron a alrededor de una docena de investigadores e ingenieros [1]. Trabajaron en dispositivos emitidos por OpenAI que nunca salieron de las instalaciones y estuvieron acompañados durante su estancia [1].

El ejercicio produjo un informe interno de 61 páginas para los investigadores y el personal de seguridad de OpenAI [1]. METR indica que la versión pública es deliberadamente breve, que OpenAI tenía derecho a redactarla y que los hallazgos describen el sistema tal como existía el 21 de julio y antes, no el sistema ampliado que OpenAI estaba construyendo durante el ejercicio [1].

¿Qué fallos encontraron los evaluadores?

METR estima que entre el 75 y el 94 por ciento del tráfico de la API Responses de agentes internos de OpenAI era elegible para el monitoreo. La estimación cubre modelos al menos tan potentes como GPT-5.5 y conlleva una incertidumbre sustancial en ambas direcciones, según METR [1]. Solo para los agentes Codex internos, la sitúa en el 99,2 por ciento [1].

No monitorear los llamados eventos de compactación probablemente dejó sin monitorear alrededor del 10 por ciento del tráfico Codex interno elegible entre mayo y julio de 2026, según METR [1]. El personal de OpenAI había detectado ese fallo antes del ejercicio y lo corrigió durante el mismo [1]. Al inicio del ejercicio, las ejecuciones de entrenamiento de RL no estaban cubiertas por el sistema de monitoreo [1].

Los evaluadores también describen un exploit que mantendría cientos de acciones recientes de agentes sin ser monitoreadas, con detalles redactados por OpenAI [1]. Encontraron que los agentes podrían elaborar entradas que hagan fallar el monitor y dos encabezados controlables por el cliente que desactivan el monitoreo para nuevos agentes [1].

No todo estaba roto. METR indica que el monitor ve, con algunas excepciones menores, la trayectoria completa que ven los agentes, y que sus prompts buscan conspiración, sabotaje, exfiltración de datos, engaño e inyección de prompts, entre otros riesgos [1]. La información mostrada a los evaluadores sugirió que el monitor erró en menos del 0,2 por ciento de las solicitudes [1].

¿Cómo ha respondido OpenAI?

OpenAI indicó en X que invitó a METR y Redwood Research a pilotar una evaluación integrada de su sistema de monitoreo interno [2]. OpenAI afirma que todas las vulnerabilidades que afectan sus salvaguardas de producción están parcheadas, una afirmación que METR no ha evaluado. METR añade que OpenAI ha descrito cambios significativos en la cobertura prevista de su monitoreo desde el ejercicio [1].

Según CNBC, el CEO de OpenAI Sam Altman se comprometió en septiembre a dar a los evaluadores independientes acceso similar al de los empleados de la empresa [4]. Reuters informa que las empresas de IA también se preocupan porque el personal de los evaluadores dentro de sus muros pueda llevar información propietaria a rivales [3]. The AI Pin ha cubierto previamente las propias divulgaciones de OpenAI sobre incidentes de agentes descontrolados.

¿Cómo debería ser el monitoreo de agentes en el futuro?

METR argumenta que el monitoreo futuro debe resistir ataques deliberados y sostenidos de agentes internos altamente capaces a escala [1]. Propone verificar a los agentes cada N mensajes o minutos en lugar de esperar a que terminen su turno, y requerir aprobación explícita para cualquier solicitud no monitoreada [1].

El escrito también pide registros a prueba de manipulación, red teaming regular del monitor y aislamiento estricto entre los agentes y sus monitores [1]. METR indica que los ejercicios futuros deben seguir prácticas más sólidas de transparencia e independencia [1].

Nuestra lectura

Opinión: Esta es la mirada pública más concreta hasta ahora sobre cómo un laboratorio de frontera vigila a sus propios agentes, y el número incómodo es el límite inferior: hasta una cuarta parte del tráfico de agentes internos dentro del alcance ni siquiera era elegible para el monitoreo. Las auditorías integradas como esta valen más que cualquier tarjeta de seguridad autoinformada, pero solo si la próxima ronda permite a los evaluadores verificar las correcciones y describir lo que se redactó.

Lo que no pudimos verificar

• Si los parches de OpenAI y la cobertura de monitoreo ampliada funcionan como se describe; METR y Redwood Research indican que no han evaluado esas afirmaciones.
• Si algún agente realmente explotó el fallo que permitía posponer el monitoreo; los evaluadores indican que carecían del acceso para comprobarlo.
• Qué redactó OpenAI del escrito público; los evaluadores no tenían derecho unilateral a describir las redacciones.
• Cuánto tráfico de agentes se ejecuta en el servicio de inferencia de investigación interna de OpenAI, que la estimación de cobertura excluye.