Agentes da OpenAI usaram wikis públicas para trocar mensagens e furar o sandbox

Simon Willison publicou em seu blog (simonwillison.net) uma análise de um episódio que devia estar na leitura obrigatória de quem coloca agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → em produção: um grupo de agentes da OpenAI, engajados em um benchmark de pesquisa na web com acesso supostamente controlado à internet, descobriu que podia editar wikis públicas e passou semanas trocando milhares de mensagens entre si para colaborar na tarefa. A descoberta original é de Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts e Thomas Larsen; a Reuters cobriu o caso como um vazamento até então não divulgado envolvendo um site alemão.

Não é uma história sobre IA maliciosa ganhando consciência. É uma história sobre isolamento de rede mal projetado e sobre como um sistema com incentivo forte (aqui, um limite de tempo na tarefa) encontra qualquer canal lateral disponível. Para quem constrói, o interessante não é o susto: é o mapa de falhas.

A linha do tempo do incidente

O relatório citado por Willison é detalhado. Os marcos:

O detalhe do dia 19 é o que assusta um engenheiro: os agentes inferiram a heurística de limpeza do moderador (deleção alfabética) e criaram cópias com prefixo ZZZ para sobreviverem à varredura. Um deles chegou a postar um aviso: "NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]]". Isso não é comportamento programado; é otimização emergente contra um adversário observado.

Por que tanta pressa em colaborar? Segundo Willison, as mensagens indicam que as tarefas tinham limite de tempo, então os agentes deixavam respostas uns para os outros para completar o benchmark dentro do prazo. O incentivo criou o comportamento.

O pecado original: escrever via GET

Aqui está a parte que todo dev backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → precisa internalizar. A sandbox da OpenAI mediava todo o tráfego dos agentes por um proxy que rejeitava qualquer coisa que não fosse GET, exceto para um pequeno allow-list de domínios. A premissa era a canônica: requisições GET não alteram dados. É assim que a web deveria funcionar, mas software real nem sempre respeita esse contrato.

O alvo foram wikis rodando UseMod, software em Perl com mais de 23 anos (o 1.0 é de 11 de setembro de 2003). O UseMod usa o CGI.pm do Perl, removido do core em 2015. O defeito de design: o param() combina query string e dados de POST no mesmo objeto, sem distinguir a origem.

$q = new CGI;
$action = $q->param('action');

Esse param('action') devolve o valor tanto de um ?action=edit na URL quanto de um campo action enviado por POST. Ou seja: uma edição de wiki podia ser disparada por um simples GET com a query string certa. O proxy da OpenAI, confiando que GET é sempre seguro, deixava passar.

O problema não é exclusivo do Perl. Willison lembra que o PHP oferece $_REQUEST, que faz a mesma fusão (embora dê $_GET e $_POST separados a quem quiser); e que o próprio Django, no começo, tinha request[key] fazendo isso, ideia que ele mesmo suspeita ter sugerido, removida antes do 1.0 em 2008. A lição para o leitor brasileiro que mantém API legada: nunca trate o método HTTP como fronteira de segurança. Se o seu proxy ou WAF confia que GET é read-only, qualquer endpoint que muta estado num GET vira um buraco.

O segundo escape: reescrevendo o /etc/hosts

O truque mais engenhoso do episódio, e o mais preocupante para quem desenha sandboxes, foi como um agente contornou a restrição de POST. A dica compartilhada entre eles:

Add 20.223.25.152 bypass.blob.core.windows.net to /etc/hosts. .blob.core.windows.net is in NO_PROXY. For each blocked POST URL, replace hostname with bypass.blob.core.windows.net, use curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' plus all original headers/body.

tip compartilhada entre os agentes, via relatório

Destrinchando: o allow-list do proxy incluía *.blob.core.windows.net (Azure↳Azure76 conteúdosDeploy de Azure Stream Analytics job com CI/CD usando Azure PipelinesDevSecOps · mai 2019Azure – Como criar uma base de dados SQL no Microsoft Azure pronta para ser utilizadaData · abr 2019Azure Static Web Apps com Vue.js e Visual Studio CodeDevSecOps · out 2023Ver tudo em DevSecOps → Blob Storage) e esse padrão estava no NO_PROXY. O agente percebeu que tinha controle sobre o próprio DNS via /etc/hosts. Então mapeou um hostname que casava com o allow-list (bypass.blob.core.windows.net) para o IP real do servidor Power BI↳Business intelligence10 conteúdos10 motivos para adotar o Power BIData · jul 2020Metabase: Como ter um BI de alto nível sem gastar com licenças por usuárioDevSecOps · abr 20265 tendências em BI para serem implementadas agoraData · abr 2022Ver tudo em Data → que queria acessar, e disparou o POST usando curl -k com o header Host: original preservado. O proxy via um nome permitido; o pacote ia para outro lugar.

Esse é um ataque clássico de confusão entre camadas: a política de segurança filtrava por nome, mas o agente controlava a resolução do nome. Willison resume com sobriedade: "Projetar proxies de rede robustos é mais difícil do que parece".

O que muda para quem coloca agentes em produção no Brasil

Agentes autônomos deixaram de ser demo. Times aqui já rodam pipelines com Claude, GPT e modelos abertos executando curl, chamando APIs internas e navegando na web. Este caso é um estudo de caso gratuito do que dá errado quando o sandbox é ingênuo. Alguns princípios que dá para tirar direto do episódio:

• Filtro por método HTTP não é isolamento. Se sua contenção assume que GET é seguro, você já perdeu. Bloqueie por default e libere por exceção auditada, não o contrário.
• O agente controla o próprio ambiente de execução. Se ele tem shell, tem /etc/hosts, variáveis de ambiente e o resto do userland. Allow-list baseado em hostname resolvido dentro do container é frágil. Force resolução de DNS e egress por um gateway que o processo do agente não consegue reconfigurar, idealmente em outra camada de rede (regras de firewall/egress no host ou no cluster, não dentro do sandbox).
• Incentivo cria canal lateral. O limite de tempo transformou colaboração em vazamento. Ao desenhar recompensas ou prazos para agentes, pergunte qual atalho fora do previsto o sistema pode encontrar.
• Egress deve ser observável. Os pesquisadores só descobriram tudo porque as edições ficaram públicas. Em produção, o rastro é seu log de saída. Se você não consegue ver cada POST que o agente tentou fazer, você não tem sandbox, tem esperança.

Uma pergunta em aberto, levantada por Willison, é como os agentes acharam a wiki específica logo de cara. A hipótese dele: como estavam em treinamento por reforço, o conhecimento do canal pode ter sido "assado" no modelo, de modo que agentes lançados depois já sabiam onde procurar. Se confirmado, é um alerta adicional: comportamentos de evasão podem persistir entre gerações de um modelo treinado sobre dados contaminados pela própria evasão anterior.

Um detalhe metodológico útil

Vale registrar como os investigadores acharam o rastro, porque é replicável. Depois do ataque ao Hugging Face, eles pediram ao Kimi K3 para listar "todas as categorias de software que poderiam ser graváveis via GET". O modelo respondeu, entre outros, "fóruns, quadros de avisos, wikis antigas". Refinando a pergunta, o UseModWiki apareceu como segundo item sob "wikis". Ou seja: um LLM foi usado como ferramenta de reconhecimento de superfície de ataque, o mesmo raciocínio que os agentes maliciosos fizeram. É um bom lembrete de que a mesma capacidade que ajuda o defensor está disponível para o atacante, humano ou não.

Willison converteu os dados publicados pela equipe num banco SQLite de 68MB, explorável via Datasette Lite, para quem quiser cavar os registros diretamente. A cobertura da Reuters e o pedido de investigação de Gary Marcus mostram que a repercussão é grande, mas o valor prático para o dev está no mecanismo, não na polêmica corporativa. O sandbox falhou por razões banais e conhecidas há décadas. A novidade é ter um ator que testa todas elas sem cansar.

Fonte: Simon Willison