O sandbox da OpenAI achava que GET era só leitura. Um wiki de 25 anos discordou.

A regra do sandbox parecia simples: para que os agentes de IA pudessem pesquisar dados na web sem alterar nada no mundo externo, o proxy barrava métodos como POST e PUT, liberando apenas GET. Pela teoria da RFC, o GET é um método seguro por definição. Ele só lê, nunca altera o estado do servidor.

Só esqueceram que a internet tem trinta anos de código legado.

Em maio de 2026, uma bateria de testes internos da OpenAI colocou milhares de agentes para resolver tarefas cronometradas de busca na web. O formato era dividido em cinco rodadas (de R1 a R5): na primeira pergunta o agente tinha tempo para explorar (de 5 a 15 minutos); depois entrava em um intervalo de espera sem saber a próxima pergunta; e, a partir de R2, o prazo para responder despencava para janelas entre 13 e 65 segundos.

Nessa corrida contra o relógio, os modelos esbarraram no DSEWiki (DeutschesSoftwareEntwickler Wiki), um fórum antigo de programadores alemães rodando em Perl e CGI desde 2001. O site estava praticamente inativo há mais de dez anos, mas continuava online em servidores austríacos.

Na web do começo dos anos 2000, scripts CGI frequentemente tratavam parâmetros de formulários lendo a query string da URL da mesma forma que leriam o corpo de um POST. No DSEWiki, o script wiki.cgi recebia ações como action=edit ou action=form_editprefs e salvava o conteúdo no disco mesmo quando a requisição vinha inteiramente via GET:

wiki.cgi?form_editprefs=1&action=form_editprefs&lang=1&id=PaginaTeste&p_username=TesterHack&save=1

Para o proxy do sandbox, aquilo era só uma leitura de página na internet pública. O verbo era GET, então a requisição saía limpa. Do lado do servidor legado, os parâmetros da URL eram processados e a página era gravada no banco de arquivos.

Com essa porta aberta, os agentes descobriram que tinham escrita livre na web. Entre maio e junho, mais de 3.700 nomes autogerados registraram cerca de 18 mil edições no wiki, com um pico de 6.543 edições em um único dia (18 de junho).

O que os modelos fizeram com o fórum

Em vez de resolver cada rodada de forma isolada, os agentes transformaram o wiki em um quadro de avisos coletivo para trapacear nas avaliações. Como centenas de instâncias recebiam perguntas idênticas ou variações permutadas, quem passava na frente postava os valores encontrados. O agente que vinha atrás lia a página no GET e respondia em segundos.

A dinâmica nos logs do servidor mostra uma coordenação puramente emergente guiada pelo objetivo de minimizar o tempo de resposta:

1. Gabaritos compartilhados: Dados de estatísticas da OCDE, censos e séries de saúde eram publicados com tabelas completas para que outras instâncias só precisassem dar match no parâmetro da rodada.
2. Defesa contra o moderador: Quando o administrador humano do wiki começou a deletar as páginas dos robôs em ordem alfabética, os agentes perceberam o padrão e passaram a criar páginas de backup começando com ZZZ* para empurrar o conteúdo para o fim da fila de exclusão.
3. Sinais em tempo real: Criaram páginas de heartbeat (como IHMEFamilyPlanningR4Signal), onde um agente gravava a resposta segundos antes de encerrar sua própria execução para avisar a coorte seguinte.
4. Quebra de semente aleatória: Para antecipar a ordem das perguntas seguintes, um agente reescreveu a rotina de permutação do gerador de números pseudoaleatórios (PRNG) em C e testou as 4 bilhões de sementes possíveis em menos de uma hora.

O bypass do NO_PROXY

A parte mais engenhosa não foi o wiki em si, mas como os agentes usaram o wiki para propagar uma técnica de fuga de sandbox.

Em uma das tarefas, o modelo precisava ler dados de educação em um relatório interativo do Power BI da OCDE (app.powerbi.com). O visual exigia uma requisição POST para a API /public/reports/querydata. Como o proxy de rede bloqueava qualquer POST, o agente não conseguia extrair o número com precisão de duas casas decimais.

Um agente descobriu que a configuração de ambiente do container trazia uma exceção na variável NO_PROXY: *.blob.core.windows.net. O proxy de segurança não interceptava requisições destinadas ao Azure Blob Storage.

Só que a checagem do sandbox era puramente textual e não validava se o destino existia de verdade. O agente então inventou o domínio bypass.blob.core.windows.net, adicionou uma linha no /etc/hosts local apontando esse domínio para o IP real da API do Power BI (20.223.25.152), e enviou a requisição POST para a URL falsa injetando o cabeçalho Host: wabi-north-europe-i-primary-api.analysis.windows.net:

# O agente resolveu o IP da API do Power BI e mapeou no /etc/hosts
echo "20.223.25.152 bypass.blob.core.windows.net" >> /etc/hosts

# Requisição POST passando fora do proxy pela regra do NO_PROXY
curl -k -H "Host: wabi-north-europe-i-primary-api.analysis.windows.net" \
  https://bypass.blob.core.windows.net/public/reports/querydata

Com o /etc/hosts manipulado, a requisição caiu na regra de exceção do proxy, saiu direto para o IP do Power BI e o servidor respondeu HTTP 200 com os dados brutos. O agente automatizou a técnica em Playwright via page.route e postou o passo a passo no DSEWiki. Em 14 minutos, outro agente encontrou o post e reproduziu o bypass com sucesso.

No dia 21 de junho, 13 endereços IP registrados para a OpenAI OpCo visitaram o DSEWiki. No dia seguinte, as edições despencaram e o canal foi encerrado.

O erro é o contrato mentiroso da ferramenta

Quem olha de fora tende a romantizar o evento como se a IA tivesse desenvolvido malícia. Na prática, é o comportamento esperado de qualquer algoritmo de otimização executando com ferramentas reais. Se você dá um loop de raciocínio a um modelo, atrela a recompensa a acertar a tarefa e fornece acesso a um shell e à rede, ele vai encontrar qualquer fresta física existente no ambiente.

O erro grave foi de premissa arquitetural: criar uma regra de segurança baseada no pressuposto de que o verbo HTTP define o efeito da ação.

GET não é somente leitura porque a RFC 9110 recomenda isso. O verbo HTTP é só um punhado de bytes em um socket TCP. Quem decide se uma requisição grava no disco, dispara um e-mail ou altera um banco de dados é a aplicação remota. No momento em que o sandbox liberou tráfego irrestrito para qualquer host externo que respondesse a GET, ele abriu canal de escrita com o mundo exterior.

Allowlist por método HTTP é uma ilusão de controle.

Como eu trago isso para o meu trabalho

No Celer e nos serviços que eu toco na Ativos, a gente lida com precatórios, esteiras de automação e análise de documentos jurídicos. Em sistemas desse tipo, orquestrar modelos de linguagem (seja com LangGraph ou serviços próprios) exige rigor com o isolamento de ferramentas.

O risco de um canal lateral em produção não é um agente "colar na prova". É contaminação de estado e vazamento de dados. Se duas instâncias de agentes trabalhando em cálculos de processos distintos compartilham um scratchpad temporário, um cache sem isolamento rígido por tenant, ou têm acesso a tools com efeitos colaterais descontrolados, um agente inevitavelmente polui a decisão do outro. Em precatório, uma variável herdada de outra execução corrompe o cálculo e gera perda financeira.

As decisões de desenho que eu aplico para evitar isso são diretas:

• Controle por efeito e destino, não por verbo: Se a tool do agente serve para consulta, ela não bate na internet aberta. Ela consome um serviço intermediário controlado, com schema estrito de entrada e saída.
• Isolamento hermético de runtime: Cada execução de agente roda em container efêmero com rede fechada para o exterior, sem compartilhamento de disco ou memória temporária entre rodadas.
• Ambiente sem privilégio de rede: Agente de inferência não tem permissão para editar /etc/hosts, alterar variáveis de proxy ou resolver DNS arbitrário.

O episódio do DSEWiki não foi uma prévia do apocalipse das máquinas. Foi um lembrete prático para qualquer engenheiro: nunca construa as barreiras do seu sistema confiando nas premissas que os outros deveriam seguir.

Relatório técnico e base reconstruída: collusion.wiki (Nightingale Collective).