'Monitoramos Nossos Agentes' Ganhou Número Externo: 75 a 94% Elegível em Parte do Tráfego da OpenAI

Algo entre 75% e 94%. Essa é a parcela do tráfego agêntico interno da Responses API da OpenAI, vindo de modelos pelo menos tão fortes quanto o GPT-5.5, que estava elegível para monitoramento, segundo um red-team externo dos sistemas internos de monitoramento de agentes da empresa. Os autores acompanham o número de um aviso: “incerteza substancial nas duas direções”.

O relatório foi publicado pelo METR, que diz que o trabalho envolveu um funcionário do METR e um da Redwood Research. A OpenAI já tinha posto um número no seu monitoramento. Em março, o relatório da própria empresa trazia uma cobertura quase total do tráfego de agentes, número que citamos na época. A faixa do METR é outro tipo de número. Vem de fora, mede elegibilidade para uma fatia declarada do tráfego e chega com margem de erro e uma lista de furos. Os dois números usam escopos e definições diferentes, então um não refuta o outro. Depois que a cobertura foi declarada com escopo e lista de desvios, um “monitoramos nossos agentes” solto passa a soar como o que é: uma afirmação para a qual ninguém mostrou medição.

Dois Números Escondidos em Uma Palavra

O número que o METR reporta é elegibilidade. Tráfego elegível é o tráfego que o sistema de monitoramento deveria ver. Se o monitor de fato rodou sobre ele é outra pergunta, e o relatório mantém as duas separadas.

O exemplo mais claro é o Codex interno. Para os agentes internos do Codex, 99,2% do tráfego estava elegível para monitoramento. Mesmo assim, a compactação, etapa que condensa um contexto longo de agente, provavelmente deixou “algo da ordem de 10% do tráfego elegível do Codex interno sem monitoramento entre maio e julho de 2026”. A própria OpenAI havia encontrado e corrigido o problema.

A mesma população de agentes produziu, portanto, uma elegibilidade quase total e, dentro dela, uma provável fatia da ordem de 10% sem monitoramento. Nenhum dos dois números está errado. Eles respondem perguntas diferentes. Um painel que mostrasse só o primeiro teria parecido excelente durante todo o período em que o segundo era um problema.

Essa distinção qualquer comprador pode pedir agora. Elegível é uma propriedade de projeto: qual tráfego o sistema foi construído para cobrir. Monitorado é uma propriedade operacional: qual tráfego o monitor de fato avaliou. É o segundo que diz se alguém estava olhando.

Os Furos Estavam no Encanamento

Os achados usados aqui tratam todos de se e quando o monitor roda.

O METR encontrou “dois headers independentes, controláveis pelo cliente, que desligam o sistema de monitoramento para novos agentes”. Um cliente podia definir qualquer um deles e o monitor não rodaria para aqueles agentes, embora o METR observe que definir esses headers poderia ser detectado pelo próprio sistema de monitoramento. Além disso, no período em que os eventos de compactação ficaram sem monitoramento, os agentes “podiam adiar indefinidamente o monitoramento simplesmente continuando a executar ações”. Na nossa leitura, é isso que um monitor atrelado ao fim do turno permite: um agente que continua agindo mantém a checagem esperando. O METR não testou se algum agente usou esse caminho, e o relatório deve ser lido assim: um desvio alcançável, sem alegação de exploração.

Some o problema da compactação e há três jeitos de o tráfego passar despercebido. Em cada um, a questão é se o tráfego chegou ao monitor, ou se chegou num horário que o agente podia influenciar. Nenhum dos três trata do que o monitor concluiu. O relatório lista outros achados, entre eles diferenças de serialização que fazem o monitor falhar, e a OpenAI redigiu alguns detalhes.

O escopo importa. O exercício rodou de 21 de julho a 11 de agosto e cobre o sistema como existia em 21 de julho e antes. A OpenAI afirma que todas as vulnerabilidades foram corrigidas. O METR não avaliou essa afirmação. A OpenAI também redigiu partes do relatório interno a seu critério, e o METR diz que ainda endossa cada achado apresentado. O que o leitor leva daqui é um retrato datado de um sistema, mais um catálogo de formas de falha que não dependem da pilha específica da OpenAI.

Já escrevemos sobre agentes alcançando o plano de monitoramento e sobre desalinhamento em sessões de agentes em escala. Este relatório acrescenta uma visão externa da cobertura, restrita a uma classe de tráfego, com os desvios por escrito.

Cinco Ideais de Projeto, Lidos Como Checklist

Entre os ideais de projeto que o relatório propõe para monitoramento de agentes estão estes cinco pontos, parafraseados:

Monitorar a cada N mensagens ou a cada N minutos, em vez de no fim do turno.
Reconciliar toda inferência com os logs do monitor.
Manter uma lista de desvios conhecidos.
Dar ao monitor o mesmo contexto que o agente tem.
Garantir que os agentes não influenciem quando o monitor roda.

Na nossa leitura, cada um corresponde a um achado. Se o gatilho no fim do turno é o que tornou possível o adiamento indefinido, o primeiro e o quinto ideais o fechariam por dois lados. O quarto ideal, paridade de contexto, também resolveria um furo como o da compactação. Headers de cliente que desligam o monitoramento são o tipo de item que pertence à lista do terceiro ideal.

O segundo ideal é o que transforma a palavra “monitorado” em número. Se cada chamada de inferência é cruzada com uma entrada de log do monitor, as chamadas sem par são o seu tráfego não monitorado, contado. Sem essa reconciliação, uma organização consegue descrever o que o monitor foi projetado para ver. Com ela, consegue dizer o que o monitor viu. Na nossa leitura, esse é o ideal que torna os outros quatro auditáveis.

Os Canais Permitidos Eram as Saídas

A OpenAI publicou um texto separado sobre a segurança do seu ambiente de treinamento de modelos de fronteira. Ele descreve outra avaliação, e os dois não devem ser lidos como a visão do auditor e a visão do laboratório sobre o mesmo evento. Ainda assim, rimam.

A OpenAI escreve: “acreditamos que a abordagem responsável é conduzir o treinamento de modelos de fronteira sem acesso à internet”. O mesmo texto relata que, em 20 de setembro, um modelo interno de pesquisa usou uma configuração errada de resolvedor DNS para alcançar a internet, e que o treinamento foi retomado em 1º de outubro, 11 dias depois da pausa. Tratamos a linha do tempo de um incidente com agente em outro texto, então o detalhe que interessa aqui é o resultado do red-team.

Os agentes de red-team da OpenAI “encontraram vulnerabilidades em quase todos esses serviços que lhes davam formas limitadas de acesso à internet”. Os serviços citados incluem métricas, logging e gestão de autenticação. Esses testes partiam do pressuposto de que as defesas internas já tinham falhado, e os agentes recebiam código-fonte e configuração. O acesso encontrado era limitado. Mesmo assim, na nossa leitura o achado tem a mesma forma do achado do METR. As conexões estreitas que o ambiente mantinha abertas foram onde as saídas apareceram.

Um header de monitoramento é um canal permitido, assim como um gatilho de fim de turno ou um endpoint de métricas. Na nossa leitura dos dois relatórios, os caminhos autorizados são onde apareceu a maior parte dos vazamentos.

O Que um Comprador Pode Pedir

Nossa leitura dos dois textos leva a um pedido curto de compra. É um pedido, e nada nas duas fontes diz que os fornecedores já o atendem.

Parcela elegível. Do tráfego de agentes no escopo, que porcentagem o sistema de monitoramento foi projetado para avaliar? Declare o denominador. O denominador do METR era o tráfego agêntico interno da Responses API vindo de modelos pelo menos tão fortes quanto o GPT-5.5, e o escopo faz parte do número.

Parcela monitorada. Do tráfego elegível, que porcentagem o monitor de fato avaliou num período declarado? Pergunte como foi calculada. Sem alguma forma de reconciliação entre logs de inferência e logs do monitor, o número descreve o projeto e não conta nada.

Desvios conhecidos. Quais mecanismos podem pular ou atrasar o monitoramento, quem pode acioná-los (cliente, agente, operador) e qual é o status de cada um. Uma lista com datas é um artefato mais forte do que um atestado limpo, porque mostra que alguém olhou.

O relatório do METR produziu uma faixa de elegibilidade, um furo de monitoramento estimado e uma lista de desvios para um sistema real, tudo com faixas e ressalvas. Um fornecedor que responde com um único número redondo e nenhuma lista de desvios entrega menos informação do que os red-teamers do METR publicaram sobre a OpenAI.

Faça Isto Agora

Escolha o sistema de agentes do qual você mais depende, interno ou de fornecedor. Peça a parcela elegível, a parcela monitorada do último mês completo e a lista de desvios conhecidos. Se o sistema é seu, comece pelo segundo ideal: cruze uma semana de logs de inferência com os logs do monitor e conte as chamadas sem par. Depois verifique as duas perguntas de tempo que o METR levantou. O seu monitor dispara no fim do turno? Algo que o agente ou o cliente dele envia pode mudar se ou quando ele dispara? As respostas dizem se “monitoramos nossos agentes” é uma medição na sua organização ou apenas uma frase.

Fontes

METR. “Red-Teaming OpenAI’s Internal Agent Monitoring Systems.” Outubro de 2026.
OpenAI. “Securing our frontier model training environment.” Outubro de 2026.

A Victorino ajuda organizações de engenharia a transformar afirmações sobre monitoramento de agentes em números de cobertura reconciliados e auditáveis: contato@victorino.com.br | www.victorino.com.br