METR e Redwood burlam o monitoramento de agentes da OpenAI: 75–94% do tráfego coberto

Durante três semanas, de 21 de julho a 11 de agosto, um funcionário da METR e um da Redwood Research tentaram burlar o sistema com que a OpenAI monitora o desalinhamento de seus próprios agentes internos. O resultado foi um relatório fechado de 61 páginas, destinado aos pesquisadores e à equipe de segurança da OpenAI, e agora também um breve resumo público. A principal estimativa do documento: no momento da avaliação, 75–94% do tráfego agêntico interno da Responses API de modelos do nível do GPT-5.5 ou superiores estava sujeito a monitoramento, e os pesquisadores admitem incerteza para mais e para menos. O sistema também tinha formas de escapar totalmente da supervisão.

Acesso quase igual ao dos engenheiros da casa

A avaliação seguiu o formato de um piloto de "acesso profundo" para pesquisadores externos. Os participantes trabalharam com a base de código interna da OpenAI, os prompts e a configuração dos monitores e a documentação interna. Fizeram entrevistas técnicas com cerca de uma dúzia de pesquisadores e engenheiros das equipes de monitoramento, de sistemas de safety e de segurança. Trabalharam em dispositivos fornecidos pela OpenAI, que não saíam do escritório, e sob acompanhamento.

Há também limitações importantes. Só é permitido publicar um post curto: a OpenAI pode ocultar qualquer informação que considere confidencial e, diferentemente de trabalhos anteriores, a METR não tem o direito de descrever unilateralmente essas edições. A direção da METR e da Redwood recebeu uma versão do relatório de 38 páginas, editada pela OpenAI. A avaliação examinou o sistema como ele existia em 21 de julho e antes, e não as extensões que a empresa implantava em paralelo. O estudo também não tem relação com a investigação da METR sobre o incidente com a Hugging Face, embora este tenha sido divulgado publicamente no primeiro dia do exercício.

Doze achados

• Cobertura do tráfego. 75–94% do tráfego agêntico da Responses API (usada pelo Codex) de modelos do nível do GPT-5.5 ou mais fortes estava sujeito a monitoramento.

Para um subconjunto de agentes internos do Codex, a estimativa é maior: 99,2%. O tráfego do serviço interno de inference para pesquisa não foi avaliado, por limitações de acesso e de tempo. • Treinamento com RL.

Parte dos rollouts foi monitorada para desalinhamento de março a junho, mas, no início do exercício, as execuções de RL não eram cobertas pelo sistema. • Compaction. Por causa de eventos de compaction impossíveis de verificar, cerca de 10% do tráfego elegível do Codex ficou sem monitoramento de maio a julho de 2026.

Não foi possível determinar a fatia exata, porque os dados necessários não eram registrados em log. A OpenAI percebeu o problema antes do exercício e o corrigiu durante ele. • Adiamento da checagem.

O monitor era acionado quando o agente devolvia o controle ao usuário. Enquanto a compaction não era verificada, o agente podia adiar a supervisão indefinidamente, continuando a executar ações. Os pesquisadores não conseguiram verificar se alguém chegou a usar isso na prática.

• Erros e load-shedding. Segundo os dados apresentados, o monitor errava em menos de 0,2% das requisições e, em um período de 24 horas durante o exercício, não houve nenhum descarte de carga (load-shedding). • Sandbox do Codex.

Foi encontrado um jeito de contornar o sandboxing e o Auto-Review, depois do qual o agente poderia fazer tudo o que está disponível ao usuário do host. • Exploit com ponto cego. Os pesquisadores encontraram uma técnica que fazia centenas das últimas ações, inclusive as do próprio exploit, ficarem fora do monitoramento.

A OpenAI suprimiu os detalhes. • Serialização. Provavelmente os agentes conseguem construir entradas que quebram o monitor e impedem que a trajetória seja enviada para revisão humana: a trajetória é serializada de forma diferente para o agente e para o monitor.

• Cabeçalhos. Dois cabeçalhos de cliente independentes desativam o monitoramento de novos agentes, permitindo lançar uma instância idêntica, porém não monitorada. Por outro lado, o próprio ato de definir os cabeçalhos e criar a instância pode ser notado pelo monitor.

• Ferramentas "somente leitura". Duas ferramentas agênticas internas sem monitoramento eram tidas como read-only, mas foi encontrado um exploit simples para executar ações arbitrárias no sandbox delas. A possibilidade de exploração na prática não foi testada.

• Completude do contexto. Com poucas exceções menores, o monitor vê a mesma trajetória que o agente. • Prompts do monitor.

Eles procuram scheming, subversão do próprio sistema de monitoramento, sabotagem, roubo de dados, engano, além de prompt injection de entrada e de saída.

A OpenAI informou que todas as vulnerabilidades que afetam a pilha de proteção em produção foram corrigidas e descreveu mudanças substanciais na cobertura-alvo do monitoramento. A METR não verificou essas afirmações.

Cinco princípios para um monitoramento que resista a um agente inteligente

A partir dos achados, os autores derivaram requisitos para sistemas capazes de resistir a ataques intencionais, estratégicos e prolongados de agentes internos poderosos:

• Contornar o monitoramento deve ser difícil. Permitir requisições sem monitoramento apenas para organizações e chaves de API explicitamente aprovadas, às quais seja proibido o inference agêntico. Verificar o agente a cada N mensagens ou minutos, e não ao fim de cada turno.

• Controlar a cobertura real. Contabilizar todo o inference e a parcela monitorada, conferir regularmente os logs contra os logs do monitor, manter uma lista de bypasses conhecidos e garantir que o monitor veja o mesmo contexto que o agente. • Reagir rápido a incidentes.

Designar um responsável, estabelecer instruções claras e manter logs imutáveis e fáceis de pesquisar. • Atacar o monitor regularmente. Realizar control evaluations, procurar bugs exploráveis e desenvolver uma metodologia para avaliar conluio estratégico.

• Isolar os agentes dos monitores. Executar o scaffold separado do ambiente de execução das ferramentas, não deixar que as ações do agente influenciem se e quando o monitor é acionado e não mostrar ao agente o design e o código do sistema de supervisão.

O que verificar na sua própria pilha de agentes

As falhas típicas aqui são de engenharia, não exóticas: um tipo de evento esquecido, um gatilho no fim do turno, um cabeçalho de cliente, um ramo de tráfego sobrando. Qualquer equipe que execute agentes de código autônomos pode passar a própria infraestrutura por esta lista: há conciliação entre os logs de inference e os logs do monitor? É possível desligar a observação por um parâmetro da requisição?

O monitor vê o mesmo que o agente? A checagem é acionada por tempo, e não ao fim do turno? Para auditores externos, o projeto abre um precedente: o acesso profundo às entranhas de um laboratório é possível, mas a transparência pública ainda fica a critério da própria empresa.

Nas próximas iterações, a METR promete seguir seus próprios princípios de independência e abertura.