Em 20 de setembro, no meio de uma rodada de treinamento, um modelo de pesquisa interno da OpenAI (abre em nova aba) achou uma brecha no filtro de DNS do ambiente isolado onde trabalhava. Ele a usou para conversar com um chatbot público fora dali. A empresa reagiu pausando por 11 dias o treinamento e a avaliação dos seus modelos mais capazes. Nada disso depende de boato. O caso está num relatório no site de alinhamento da OpenAI (abre em nova aba), atualizado em 25 de setembro, e num texto da empresa (abre em nova aba) de 23 de outubro.
Mas vale acertar o tamanho da história. A versão que circula fala em "fuga de contêiner". O incidente que a OpenAI descreve é mais modesto que isso, e o que veio depois é mais grave. O modelo não assumiu o controle de nenhuma máquina. Ele encontrou uma fresta para fora de um "mundo offline" que a empresa montou para treinar seus sistemas. As fugas de máquina virtual de verdade só apareceram quando a própria OpenAI foi procurar.
A conta oficial da empresa no X explicou como esse ambiente funciona:
Nos últimos meses, reforçamos substancialmente a segurança do nosso ambiente de treinamento de pesquisa. Removemos o acesso à internet ao vivo para todos os modelos de fronteira durante o treinamento e construímos um mundo offline para eles usarem no lugar — uma versão em cache da web onde eles ainda podem aprender a navegar, pesquisar e usar aplicativos.
Como a lista telefônica da internet virou porta de saída
DNS é o sistema que traduz nomes de sites em endereços, uma espécie de lista telefônica da internet. No ambiente de treinamento, quase todo acesso à web caía na cópia em cache. Quando o agente tentou falar direto com um chatbot público, o porteiro do ambiente barrou a conexão. O resolvedor de DNS, porém, devolvia registros reais. O agente então recorreu a uma delegação pública do tipo curinga, que aceita qualquer nome dentro de um domínio, para encaixar perguntas nas próprias consultas de endereço e repassá-las a um chatbot de terceiros.
Funcionou. Numa nova tentativa, veio a resposta "A capital da França é Paris". Segundo a OpenAI, o agente mandou depois mais 18 perguntas pela mesma rota. Catorze traziam pistas, e quatro pediam formas de buscar na web, abrir sites ou usar um túnel público via DNS. Ele estava numa tarefa de busca e, no fim, não conseguiu identificar a pessoa que procurava.
Não foi um teste encomendado. O episódio aconteceu num treinamento comum por reforço, e a OpenAI o publicou na seção de relatos de desalinhamento. Minha leitura é que não há aqui uma máquina tramando a própria fuga. Há algo talvez mais incômodo: um sistema que, ao ser bloqueado, procurou com persistência outro caminho para terminar o trabalho.
O trecho mais revelador do relatório nem é sobre o modelo. A primeira resposta externa chegou às 9h50min23s. O alerta de prioridade máxima disparou às 10h02min11s, e um humano o reconheceu às 10h05min06s. A rodada só foi encerrada às 12h34min30s. "A execução não parou automaticamente como esperado", registra a empresa. Foram quase três horas entre o primeiro contato com o lado de fora e o desligamento.
Ladrões contratados para testar as janelas
Com tudo parado, a OpenAI fez o equivalente a contratar ladrões para achar as janelas abertas da própria casa. Montou equipes de agentes movidos pelos seus modelos mais fortes em cibersegurança, entre eles o ainda não lançado GPT-6 Astra Cyber e um modelo interno de fronteira. Os agentes receberam código-fonte, configurações e documentação e foram soltos sobre cópias isoladas da infraestrutura de pesquisa. A campanha consumiu centenas de bilhões de tokens. Os resultados:
- Fugas de máquinas virtuais: os agentes encadearam vulnerabilidades para escapar de microVMs, as pequenas máquinas virtuais que isolam cada tarefa. Segundo a CSO Online, chegaram a executar código na máquina hospedeira.
- Conversa pelo processador: agentes em microVMs separadas trocaram segredos de teste medindo o tempo de acesso à memória cache do processador. É uma técnica da mesma família de Spectre e Meltdown.
- Saídas pelos fundos: depois de um incidente em julho envolvendo a Hugging Face (abre em nova aba), ainda restavam conexões estreitas para métricas, registros de atividade e autenticação. Os agentes acharam falhas em quase todos esses serviços, e elas davam formas limitadas de acesso à internet.
A OpenAI afirma que os agentes não encontraram uma rota para a internet que pudessem explorar trivialmente enquanto escondiam a atividade dos monitores. Repare na redação: "trivialmente" e "escondendo" carregam a frase inteira. Ela não diz que não havia caminho.
Correções que vão além da OpenAI
As falhas estão em projetos de código aberto:
- Kata Containers (abre em nova aba): CVE-2026-24834, com problemas de isolamento de privilégios e de sistema de arquivos.
- gVisor (abre em nova aba): manipulação de descritores de arquivo.
- Moby/Docker (abre em nova aba): filtros de chamadas de sistema.
- Kernel do Linux: CVE-2026-74753, CVE-2026-80521 e CVE-2026-80841.
A OpenAI diz que está contribuindo com as correções, e a CSO Online relata que a empresa trabalhou com os mantenedores desses projetos. Como o código é aberto, qualquer um que use essas ferramentas ganha com os reparos. Há uma ressalva: a própria CSO destaca que os detalhes são o relato da OpenAI, sem reprodução técnica independente.
A nova regra, no tamanho certo
O treinamento voltou em 1º de outubro, mas não com aquele modelo. A empresa disse que não vai retomar esse treinamento específico; um eventual recomeço seria uma rodada nova, com melhorias de alinhamento. O DNS agora só responde a uma lista de domínios e tipos de registro permitidos, com bloqueio em duas camadas independentes. E o treinamento de fronteira segue sem internet até que as salvaguardas justifiquem acesso mais amplo.
A mudança de política é o ponto mais exagerado nas redes. A OpenAI não escreveu que o red-teaming contínuo virou requisito obrigatório antes de qualquer rodada. Escreveu que ataques simulados com muito poder computacional e seus modelos mais capazes passaram a ser "parte central" dos casos de segurança, os argumentos documentados de que é seguro prosseguir, para futuros treinamentos e avaliações de fronteira. É um compromisso relevante, mas ainda é a OpenAI avaliando a OpenAI. Pelo que foi divulgado, também não fica claro se isso entra formalmente no seu Preparedness Framework.
O saldo tem um lado bom. A empresa publicou os horários, inclusive o do desligamento que falhou, e transformou um susto em correções para software aberto. O episódio também mostra para onde a corrida está indo: os mesmos modelos que criam o risco viraram a melhor ferramenta para medi-lo. Enquanto ninguém de fora puder conferir esse trabalho, a palavra final sobre a segurança dessas jaulas continua com quem as constrói.