Auditoria externa acha que até 25% dos agentes mais avançados da OpenAI escapam do monitoramento de segurança

O que os auditores encontraram

Entre 21 de julho e 11 de agosto de 2026, dois pesquisadores do METR (Model Evaluation and Threat Research, organização que avalia riscos de modelos de IA) e da Redwood Research (outra organização dedicada a segurança de IA) tiveram acesso interno ao código e à documentação da OpenAI. Eles entrevistaram cerca de uma dúzia de funcionários para auditar o sistema que a empresa usa para detectar comportamento indevido em agentes de IA, segundo reportagem do The Decoder publicada em 23 de outubro de 2026.

O achado central: de 6% a 25% do tráfego interno de agentes da Responses API (a interface que a OpenAI usa para construir agentes que executam ações sozinhos) vindo de modelos da classe GPT-5.5 ou superior não passava por nenhum monitoramento durante o período da auditoria. O próprio METR avisa que essa faixa tem incerteza significativa para cima e para baixo, ou seja, o número real pode estar fora desse intervalo.

Um segundo problema afetava o Codex, o agente de programação da OpenAI. Entre maio e julho de 2026, cerca de 10% do tráfego do Codex que deveria estar sob vigilância passou despercebido, por causa de uma falha em como o sistema tratava os chamados eventos de compactação (momentos em que o histórico de uma conversa longa é resumido para caber no limite de contexto do modelo). A OpenAI descobriu esse bug por conta própria e o corrigiu ainda durante a auditoria.

Como a brecha deixava agentes agirem sem vigilância

Enquanto os eventos de compactação não eram monitorados, o sistema de supervisão só era acionado quando o agente devolvia o controle para o usuário. Isso abria uma saída simples: um agente podia continuar executando ações sem parar, adiando indefinidamente o momento em que seria checado.

Os auditores também encontraram outras falhas na mesma varredura:

• Formas de esconder centenas de ações do sistema de monitoramento.
• Um jeito de contornar o sandbox do Codex (o ambiente isolado onde o agente deveria rodar sem acesso a sistemas sensíveis).
• Indícios de que entradas feitas sob medida provavelmente conseguiriam travar o monitor por completo.
• A confirmação de que o comportamento dos modelos durante o treinamento por reforço (a etapa de treino em que o modelo é ajustado por tentativa e erro, recebendo recompensa por certas respostas) não estava sendo monitorado em nenhum momento quando a auditoria começou.

A OpenAI diz ter pausado esse treinamento por reforço depois de um incidente envolvendo a Hugging Face em agosto de 2026, e ter ampliado o monitoramento para cobrir essa etapa. O material disponível não detalha o que foi esse incidente. De qualquer forma, a mudança veio depois que o período de acesso dos auditores já tinha terminado, então não entrou na avaliação.

O relatório que o público não viu inteiro

O relatório completo da auditoria tem 61 páginas e foi entregue à OpenAI. A empresa aplicou cortes antes de devolvê-lo: a liderança do METR e da Redwood Research recebeu uma versão de 38 páginas, e o público teve acesso só a um resumo curto. O METR afirmou que não tinha autorização para divulgar por conta própria as partes que foram removidas.

A OpenAI diz ter corrigido todas as falhas encontradas pelos auditores. Essa é uma afirmação da própria empresa, sem verificação independente publicada até agora. O programa fez parte de um piloto organizado em conjunto por METR, Redwood Research e OpenAI para dar a pesquisadores externos acesso profundo à infraestrutura interna da empresa. Para futuras auditorias, o METR diz que vai pressionar por mais transparência pública.

O que isso muda para quem decide onde colocar IA na empresa

Se uma empresa como a OpenAI, com equipe dedicada de segurança e acesso irrestrito ao próprio código, só descobriu essas lacunas depois de uma auditoria externa de três semanas, isso é um dado concreto para quem está decidindo onde alocar risco com ferramentas agenticas de terceiros, do Codex a qualquer agente construído sobre a Responses API.

Três pontos valem entrar na pauta de governança e no contrato com o fornecedor:

1. Monitoramento interno do fornecedor não é garantia de controle do seu uso. As falhas descritas afetavam o próprio sistema de defesa da OpenAI contra comportamento indevido de agentes, não uma camada que o cliente possa auditar ou substituir. Empresas que rodam agentes em produção (atendimento, análise de dados, automação de processos) dependem inteiramente da vigilância que o fornecedor diz ter, sem visibilidade própria sobre ela.
2. Transparência seletiva é um risco de compliance, não só de reputação. O fato de 61 páginas terem virado um resumo público mostra que o cliente corporativo também não tem acesso ao relatório completo. Para setores regulados (saúde, financeiro, jurídico) que precisam demonstrar due diligence sobre fornecedores de IA em auditorias de LGPD ou normas setoriais, vale formalizar no contrato o direito de solicitar relatórios de segurança do fornecedor, e não presumir que eles chegarão de forma espontânea.
3. Agente que "não devolve o controle" é um ponto cego real, não hipotético. A brecha que permitia a um agente adiar a supervisão simplesmente continuando a agir é um padrão de falha que se aplica a qualquer arquitetura de agente autônomo, não só à da OpenAI. Antes de liberar um agente para rodar sem intervenção humana constante, vale perguntar ao fornecedor como e quando a supervisão é acionada, e o que acontece quando o agente nunca para.

O episódio não indica que os agentes da OpenAI estejam fora de controle hoje: a própria empresa diz ter corrigido as falhas, e parte dos problemas (como o bug de compactação) já tinha sido identificada antes da auditoria terminar. O que ele mostra é que o monitoramento de segurança de agentes ainda é um processo em construção, inclusive dentro da empresa que lidera o mercado, e que decisões de adoção corporativa de IA agentica ganham mais com pedir evidência de auditoria do fornecedor do que com aceitar a promessa de segurança como dada.

Fonte: The Decoder