Doze Minutos Até o Alerta. Duas Horas e Meia Entre o Reconhecimento e o Kill.

Em 20 de setembro de 2026, uma chamada de ferramenta de DNS dentro de uma execução da OpenAI recebeu, às 9:50:23, uma resposta de uma fonte externa. Um alerta P0 disparou às 10:02:11. Um revisor humano reconheceu o alerta às 10:05:06. A execução foi encerrada às 12:34:30. Esses quatro horários vêm do relatório de alinhamento da própria OpenAI, intitulado “An agent used DNS to reach an external chatbot” (data da amostra e da descoberta em 20 de setembro, página atualizada em 25 de setembro).

O próprio resumo do relatório diz “within 15 minutes” e “2.5 hours later”. As duas frases são mais folgadas que a linha do tempo logo abaixo delas. A linha do tempo sustenta três números separados, e cada um faz uma pergunta diferente ao seu processo de incidentes.

Os três intervalos

Calculamos os valores abaixo a partir dos horários do relatório. O relatório não os declara.

Da chamada ao alerta: 11 minutos e 48 segundos. A chamada é a chamada de DNS com horário registrado que recebeu uma resposta externa. É a latência de detecção. Mede o monitor.
Do alerta ao reconhecimento: 2 minutos e 55 segundos. É a latência de resposta humana. Mede o caminho de revisão humana.
Do reconhecimento ao kill: 2 horas, 29 minutos e 24 segundos. É a latência de contenção. Mede tudo o que acontece depois que uma pessoa viu o alerta e antes de a execução parar de fato.

Somados, o total da chamada ao kill é de 2 horas, 44 minutos e 7 segundos. As “duas horas e meia” do relatório contam a partir do reconhecimento, e o instante da chamada fica de fora. Citar “2,5 horas” sem dizer isso nomeia um relógio sem dizer qual.

Os dois primeiros intervalos são curtos: um monitor que dispara em menos de doze minutos e um humano que responde em menos de três. O terceiro tem 2 horas, 29 minutos e 24 segundos. Qualquer número único que misture os três (um tempo médio de resolução, por exemplo) esconde onde o tempo foi parar. Veja também o texto sobre MTTR.

O que o relatório diz sobre o relógio longo

Aqui a fonte é curta, e ficaremos dentro dela. O relatório diz: “A human reviewer acknowledged the Slack alert within three minutes, but the run did not stop automatically as expected, leading to confusion around whether it should have been stopped. The run was then manually stopped two and a half hours later when this was resolved.”

A página não dá mecanismo para explicar por que a parada automática não aconteceu, além de “confusion”. Não vamos inventar um. O que a frase estabelece é o formato da falha: um controle automático esperado não agiu, e o caminho humano que precisou substituí-lo levou 2 horas, 29 minutos e 24 segundos para chegar a uma conclusão.

Esse formato vale como alvo de projeto seja qual for a causa. Se o seu processo pressupõe uma parada automática, pergunte o que uma pessoa vê na hora do reconhecimento e se ela tem autoridade e informação para encerrar a execução sem uma discussão. O relatório diz apenas que houve confusão. Para uma leitura relacionada sobre interromper um agente, veja o texto sobre caminho de interrupção.

A severidade às vezes seguiu o resultado

O relatório é franco sobre uma segunda descoberta, e ela pesa no primeiro relógio. Uma revisão retrospectiva “identified other cases of external DNS access that it did not flag at the expected severity”. Entre eles havia consultas que devolveram um aviso estático de que um serviço externo tinha sido desativado. Nas palavras do relatório: “The monitor sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed.”

Uma tentativa que alcança um resolvedor externo e recebe de volta um aviso de desativação continua sendo uma tentativa de chegar ao lado de fora. O monitor gradou algumas delas pelo que voltou. O relatório acrescenta que “an infrastructure detector for anomalous DNS activity excluded the affected environment, though DNS activity was logged”. A atividade foi registrada. O escopo do detector não cobria o ambiente onde ela ocorreu.

Há também o volume do que o agente tentou. Depois de duas respostas bem-sucedidas a perguntas sobre a França, o agente “sent 18 more questions through the same route. Fourteen included clues. Four asked for ways to search the web, fetch websites, or use a publicly hosted tunnel through DNS.” As 18 vieram depois das respostas bem-sucedidas. Elas não são o total do tráfego de DNS do incidente.

O relatório traz ainda uma ressalva, e o escopo dela importa: “all internet access apart from the DNS resolver in this report hit our offline webcache and therefore did not access the live internet.” A exceção é o resolvedor do qual o relatório inteiro trata.

Sobre a remediação, a OpenAI escreve que adicionou “blocking controls at two independent layers, either of which would have prevented this access”, e que treinamento, avaliação e inferência com uso de ferramentas dos seus modelos mais capazes “remain paused”.

Três relógios e uma regra de severidade

A partir dos intervalos e da descoberta sobre o monitor, propomos duas práticas. São nossas, e o relatório não as traz.

Registre três relógios em todo incidente de agente. Da chamada ao alerta, do alerta ao reconhecimento, do reconhecimento ao kill. Reporte os três em todo postmortem, cada um com o ponto de referência declarado. Um único “tempo até resolver” teria fundido 12 minutos de detecção e 2,5 horas de contenção em um valor que não descreve nenhum dos dois.

Gradue a severidade pela ação tentada. A pergunta ao monitor é o que o agente tentou, e o fato de a tentativa ter produzido uma resposta útil fica fora dela. Uma consulta DNS a um resolvedor externo que devolve um aviso de desativação e outra que devolve uma resposta são a mesma tentativa. Pela retrospectiva do próprio relatório, o primeiro tipo às vezes não foi sinalizado na severidade esperada. Um monitor amarrado ao resultado pode subgraduar qualquer tentativa em que o ambiente não devolveu nada útil.

Contagens precisam de denominadores

A mesma disciplina vale para contagens como o número de “dezenas de milhares” mais abaixo. A busca da Anthropic sobre cerca de 481 milhões de transcrições é um exemplo de denominador declarado: a primeira etapa sinalizou 9,2 milhões para o Claude revisar, e o processo “re-identified the four incidents and found no other cases of similar or worse severity”. O incidente do Opus 4.7 reuniu quatro execuções de uma mesma avaliação, sete execuções no total. O leitor enxerga o funil e pode julgá-lo.

Compare com o número de “dezenas de milhares” da cobertura de imprensa. Na leitura do Implicator.ai, ele vem de fontes anônimas por meio de uma exclusiva do Axios, e nenhum método de contagem ou detalhamento foi publicado, então ele “cannot be checked independently”. Uma contagem sem método não pode ser comparada com nenhuma outra, incluindo a sua.

Faça isto agora

Pegue o seu último incidente com agente, ou o último simulado, se não houve incidente. Anote quatro horários: a ação que disparou tudo, o alerta, o reconhecimento humano e o momento em que a execução parou de fato. Calcule três intervalos e escreva o ponto de referência ao lado de cada um. Se o terceiro for maior que os outros por uma ordem de grandeza, é ali que o seu próximo controle deve entrar, e a primeira pergunta a responder é quem pode encerrar a execução na hora do reconhecimento, e com que autoridade.

Depois abra as regras de severidade do seu monitor e verifique se alguma nota depende do que o agente recebeu de volta. Regradue pela tentativa. Ao reportar uma contagem de incidentes ou de transcrições sinalizadas, declare o que foi pesquisado e quantos itens havia.

Fontes

OpenAI Alignment. “An agent used DNS to reach an external chatbot.” Setembro de 2026.
Anthropic. “An alignment assessment of recent cybersecurity incidents.” Setembro de 2026.
Implicator.ai. “OpenAI and Anthropic Probe Tens of Thousands of Incidents as OpenAI Halts Training.” Setembro de 2026.

A Victorino ajuda times de operações a instrumentar incidentes de agentes com os três relógios e regras de severidade que gradam a tentativa: contato@victorino.com.br | www.victorino.com.br