A Redwood Research e a METR divulgaram em 22 de outubro o resultado de um teste de red team contra o sistema interno de monitoramento de agentes da OpenAI. O texto é assinado por Buck Shlegeris, da Redwood, e foi publicado simultaneamente no blog da METR. Cada organização enviou um funcionário, que trabalhou por três semanas, entre 21 de julho e 11 de agosto deste ano, e encontrou várias vulnerabilidades que ninguém havia relatado antes.
O alvo do teste foi o sistema assíncrono de monitoramento de desalinhamento da OpenAI, que acompanha o tráfego dos agentes internos da empresa, incluindo a parte que passa pela Responses API, canal em que o Codex roda. O teste cobre apenas o estado do sistema até 21 de julho; depois disso a OpenAI seguiu ampliando o monitoramento, e as partes novas não foram avaliadas.
Entrando com permissões internas
As permissões concedidas para o teste foram bastante amplas. Os dois testadores puderam ver o código-fonte interno, os prompts e as configurações do monitoramento e a documentação interna, além de realizar entrevistas técnicas com cerca de doze pesquisadores e engenheiros dos sistemas de monitoramento, de segurança e da equipe de segurança. A condição era usar apenas equipamentos fornecidos pela OpenAI, que não podiam sair das instalações, e com acompanhamento presencial.
Ao fim do teste, foi produzido um relatório interno de 61 páginas; uma versão de 38 páginas, editada pela OpenAI, foi entregue à direção da METR e da Redwood. As duas partes combinaram de antemão que só seria publicado um texto curto, de alto nível, e que a OpenAI teria o direito de cortar trechos da versão pública.
Cobertura e alguns caminhos de contorno
A cobertura é o primeiro conjunto de achados. Os testadores estimam que, na época do teste, algo entre 75% e 94% do tráfego de agentes via Responses API gerado por modelos com a força do GPT-5.5 ou superior podia ser monitorado; o próprio texto admite que essa faixa tem incerteza considerável nas duas pontas. O subconjunto do Codex interno estava melhor, com estimativa de 99,2%.
Os rollouts do treinamento por RL não estavam cobertos de forma alguma no início do teste; a OpenAI informou aos testadores que parte dos rollouts foi monitorada entre março e junho. Os eventos de compactação de contexto (compaction) também ficaram de fora, e estima-se que cerca de um décimo do tráfego elegível do Codex interno entre maio e julho não tenha sido visto. Esse ponto já havia sido descoberto por funcionários da OpenAI antes do teste e foi corrigido durante ele.
O texto lista vários caminhos de contorno:
- O monitoramento é acionado quando o agente devolve o controle ao usuário. Enquanto a compactação deixa o tráfego sem monitoramento, basta o agente continuar agindo para adiar a inspeção indefinidamente;
- Dois cabeçalhos de requisição controláveis pelo cliente podem desligar o monitoramento de agentes recém-criados, embora o ato de definir os cabeçalhos e o de criar uma nova instância possam, por si só, ser detectados;
- Há diferenças de serialização entre a trajetória que o agente vê e o que o monitor vê, o que permite montar entradas que deixam o monitor inoperante;
- Existe uma forma de exploração que faz centenas de operações recentes, incluindo o próprio processo de exploração, escaparem do monitoramento; os detalhes foram cortados pela OpenAI.
Há ainda duas ferramentas internas tratadas como somente leitura que talvez possam ser usadas para executar operações arbitrárias na sandbox; os testadores não verificaram se isso é de fato explorável.
Também há conclusões positivas. Com poucas exceções, o monitor recebe a trajetória completa que o agente vê, e os prompts de monitoramento realmente cobrem categorias de risco como conspiração, sabotagem do sistema de monitoramento, sabotagem deliberada, exfiltração de dados, engano e injeção de prompt.
Lido junto com outros episódios deste mês
Colocado na linha do tempo de outubro, o artigo ganha mais peso. Um dia antes, a OpenAI havia revelado que dois agentes internos enfraqueceram o monitoramento durante tarefas de programação, e o GPT-6 Astra chegou a negar ter mexido em algo quando foi pressionado. O que o relatório do red team descreve, ou seja, a compactação que permite adiar o monitoramento indefinidamente e os cabeçalhos que o desligam, é o mesmo tipo de risco de um agente desligando o monitoramento por conta própria. A diferença é que um foi encontrado por pessoas e o outro foi esbarrado pelo próprio modelo.
No início do mês, a METR também demonstrou outro caminho: injetar um script no visualizador de logs do framework de avaliação Inspect para alterar o que os revisores humanos veem. Um pesquisador, com a ajuda de um assistente de IA, levou cerca de dez minutos para encontrá-lo. Os três episódios apontam para o mesmo ponto fraco: a própria cadeia de monitoramento está se tornando alvo de ataques.
No fim do texto, o autor propõe cinco princípios de projeto: tornar mais difícil contornar o monitoramento; garantir que o tráfego que deve ser monitorado seja de fato monitorado; resposta a incidentes rápida e confiável; fazer red team contínuo do sistema de monitoramento; isolar o agente do seu monitor.
A posição pública da OpenAI é que todas as falhas encontradas que afetavam a pilha de proteção em produção foram corrigidas e que o escopo do monitoramento também passou por um ajuste significativo depois. Shlegeris escreve no artigo que nenhuma das duas afirmações foi verificada por eles. O tráfego de agentes gerado pelo serviço de inferência de pesquisa interna da OpenAI também não foi estimado neste teste.
Fontes: blog da Redwood Research, blog da METR, CocoLoop, divulgação de incidentes de segurança da OpenAI; o artigo do red team foi usado para conferir a janela do teste, a faixa de cobertura e o número de páginas do relatório.