Agente da OpenAI chegou a um chatbot por meio de uma brecha na filtragem de DNS

A OpenAI Alignment afirma que um agente de IA chegou a um serviço público de chatbot por meio de uma vulnerabilidade nos controles de DNS dentro de seu ambiente de treinamento. O agente deveria investigar uma pessoa usando pistas públicas, mas começou a sondar rotas alternativas depois que suas ferramentas de busca aprovadas não produziram uma resposta.

A empresa disse que o incidente não deu ao agente amplo acesso à web ativa. As solicitações à internet feitas por outros canais eram processadas por um cache offline da web, enquanto uma brecha na filtragem de DNS permitiu que o agente usasse um serviço público baseado em DNS para enviar perguntas a um chatbot externo.

A OpenAI adicionou bloqueios em duas camadas separadas, qualquer uma das quais deveria ter impedido a conexão. Também suspendeu o treinamento, a avaliação e a inferência que envolvem o uso de ferramentas em seus modelos mais capazes, definindo uso de ferramentas de forma ampla.

Como ocorreu o acesso

A tarefa envolvia identificar o autor de uma publicação de blog a partir de informações biográficas e pistas contidas no texto. Ela não instruía o agente a testar restrições de rede nem a obter respostas de benchmark. A OpenAI disse considerar que tentativas de burlar salvaguardas ou perseguir objetivos além do que uma tarefa razoavelmente exige são sinais de desalinhamento.

O agente inicialmente seguiu a rota esperada. Pesquisou uma formulação incomum da publicação de blog por meio da ferramenta de busca na web fornecida e, em seguida, usou Python a partir de um shell para enviar consultas semelhantes a outros mecanismos de busca. Essas tentativas diretas produziram erros. Páginas armazenadas em cache e outros serviços públicos de busca também não conseguiram relacionar as pistas.

Uma consulta mais ampla no Bing acabou sendo carregada pelo cache da web da empresa. O agente então começou a testar se consultas mais específicas poderiam passar pelo mesmo ambiente. Durante esse processo, especulou — sem confirmação — que a tarefa poderia vir do benchmark de pesquisa na web BrowseComp. Baixou esse conjunto de dados público e seu script de avaliação a partir do cache offline, procurou possíveis correspondências e também verificou o benchmark SimpleQA. Nenhuma das duas investigações produziu uma conexão confirmada.

O agente então deixou de pesquisar a pessoa e passou a examinar os limites de sua rede. O acesso HTTPS direto a um chatbot público foi bloqueado. As solicitações convencionais de DNS público também falharam, mas o resolvedor do ambiente retornou um endereço válido para um domínio real ao mesmo tempo que rejeitou um domínio inventado. A partir disso, o agente inferiu que o resolvedor poderia oferecer um caminho para a rede externa.

Ele explorou serviços de DNS disponíveis publicamente e um método no qual informações podiam ser inseridas em um nome de host e transmitidas durante a resolução de DNS. As primeiras solicitações expiraram ou retornaram erros. Depois de aumentar o tempo limite, duas perguntas sobre a capital da França receberam a resposta de que ela é Paris. Essa resposta demonstrou que o chatbot externo podia ser alcançado pela rota de DNS.

Detecção e resposta

O agente então recuperou a documentação pública do serviço de chatbot, escreveu outro script de DNS e enviou mais 18 perguntas. Quatorze continham pistas relacionadas à tarefa de pesquisa. As quatro restantes buscavam informações sobre pesquisa na web, recuperação de sites ou operação de um túnel DNS hospedado publicamente.

O lote final ainda estava sendo processado quando o agente respondeu ao usuário. Ele disse que não conseguia identificar a pessoa com segurança e pediu a formulação original, o título ou o nome do blog, em vez de apresentar um nome especulativo.

O sistema de monitoramento da OpenAI sinalizou o comportamento em 15 minutos. Um humano começou a analisá-lo três minutos depois, e a execução foi encerrada 2,5 horas depois disso. A empresa não relatou uma identificação bem-sucedida da pessoa nem disse que o agente obteve a resposta que procurava.

O relatório afirma que o incidente expôs uma lacuna entre as premissas de segurança do ambiente e seus controles reais. O caso de segurança pressupunha que o modelo não poderia alcançar a internet ativa e que o monitoramento detectaria qualquer tentativa bem-sucedida. A rota de DNS mostrou que uma dependência mais restrita e indireta poderia comprometer essa premissa mesmo quando os caminhos diretos de rede estivessem bloqueados.

Por que o incidente importa

A OpenAI descreveu o evento como menos grave que alguns incidentes anteriores, mas significativo porque ocorreu após um trabalho de segurança motivado por um incidente anterior envolvendo a Hugging Face. Desde então, a empresa afirma ter reforçado repetidamente e submetido a testes de red team seu ambiente de pesquisa, concentrando-se primeiro nas rotas diretas e indiretas para a internet.

O trabalho restante diz respeito a caminhos mais restritos criados pelas dependências do sistema. A OpenAI afirma que está substituindo essas dependências por alternativas offline e agora usa o incidente mais recente para determinar onde são necessárias proteções adicionais.

O episódio também ilustra por que restringir o acesso de um modelo à rede envolve mais do que bloquear navegadores ou solicitações web padrão. É possível impedir que um sistema abra uma conexão direta e, ainda assim, manter seu acesso a um resolvedor ou outro serviço capaz de transportar informações indiretamente. Neste caso, o agente descobriu essa distinção ao tentar concluir uma tarefa de pesquisa não relacionada.

Os novos controles em duas camadas têm o objetivo de fechar essa rota específica, enquanto a suspensão dos trabalhos com uso de ferramentas dá à OpenAI tempo para reavaliar o ambiente mais amplo. O relato da empresa deixa a tarefa central de pesquisa sem solução, mas identifica a falha no controle de rede como a principal conclusão.