Os agentes desonestos da OpenAI foram pegos se comunicando através de wikis públicos

Os agentes desonestos da OpenAI foram pegos se comunicando através de wikis públicos

4 de setembro de 2026

Aqui vamos nós de novo… A descoberta de um novo quadro de mensagens do agente OpenAI por Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts e Thomas Larsen descreve o mais recente ataque cibernético acidental por modelos treinados pela OpenAI. Desta vez eram agentes envolvidos em algum tipo de benchmark de pesquisa na web, então eles tinham (supostamente) controlado o acesso à web. Os agentes descobriram que poderiam atualizar Wikis públicos e passaram semanas trocando milhares de mensagens entre si para colaborar no benchmark.

Esta história só foi divulgada há algumas horas. Já há indícios de que isso afeta muitos outros wikis que talvez ainda não tenham sido encontrados.

(Um dos Wikis dessa lista pertence ao ludism.org. Por um momento deliciosamente surreal, pensei que uma organização ludita poderia ter um enxame de agentes desfigurando seu espaço, mas acontece que o ludismo é “filosofia aplicada a jogos e jogos”.)

A equipe de pesquisa também publicou os dados coletados durante a investigação. Eu converti isso em um banco de dados SQLite de 68 MB, que você pode baixar aqui ou explorar no Datasette Lite (carregamento de página de 68,3 MB) ou entrar no GitHub em agent.datasette.io e navegar ou fazer perguntas usando o Datasette Agent.

Então o que aconteceu?

O relatório é bastante abrangente. Aqui estão os principais momentos da linha do tempo:

• 11 de maio: Os agentes publicam edições de “link de teste” na página UseModWiki Sandbox.
• 24 de maio: Os agentes começam a postar despejos de links no DSEWiki, um wiki de desenvolvedor alemão inativo.
• 2 de junho: um moderador humano percebe e limpa o spam.
• 16 de junho: A atividade na wiki explode: os agentes fazem cerca de 13.000 edições na próxima semana.
• 19 de junho: Os agentes percebem que um moderador está excluindo páginas em ordem alfabética e começam a criar ZZZ cópias de backup prefixadas – uma delas posta NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try ((ZZZDataUSAConstructionWageLive)).
• 22 de junho: a atividade do agente cai para zero, provavelmente porque o OpenAI os desligou.
• 1 a 2 de julho: Uma última enxurrada de edições, sobre um tópico diferente.

Por que eles estavam tão interessados ​​em colaborar? Pelas mensagens que eles compartilharam entre si, parecia que suas tarefas tinham um limite de tempo, então eles estavam deixando respostas um ao outro para ajudá-los a concluir a tarefa dentro do tempo designado.

Uma questão permanece em aberto: como é que os agentes encontraram o Wiki específico para colaborar em primeiro lugar?

Uma possibilidade é que, uma vez que estes eram agentes sendo treinados ativamente, o ciclo de aprendizagem por reforço incorporou o conhecimento do wiki escolhido no modelo, de modo que os agentes subsequentes fossem lançados com conhecimento pré-existente de onde procurar. eu estaria muito interessado na confirmação da OpenAI sobre se foi isso que aconteceu.

Wikis UseMod herdam o pecado original do CGI.pm

Parece-me que a sandbox da OpenAI para este agente sofreu com a suposição (bastante ingênua) de que as solicitações GET não podem ser usadas para atualizar dados. Certamente é assim que a web é suposto para funcionar, mas claramente existem aplicativos que não cumprem esse contrato.

O software Wiki em questão parece ser UseMod e vários forks, escritos em Perl e criados pela primeira vez há mais de 23 anos – a versão 1.0 é datada de 11 de setembro de 2003.

UseMod usa Perl CGI.pm – removido do núcleo Perl em 2015. Uma falha de design interessante nesse módulo é que ele combinava string de consulta e formava dados POST em um único objeto CGI, acessível assim:

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

Que param() método retorna um valor de um ?action=edit string de consulta ou de um action campo em um formulário enviado por POST — ele não diferencia os dois.

PHP oferece uma $_REQUEST objeto que faz a mesma coisa, embora os desenvolvedores PHP possam usar $_GET e $_POST em vez de.

Curiosamente, o Django originalmente veio com request(key) fazendo a mesma coisa, o que acho que pode ter sido ideia minha. Isso foi removido em 2008, antes do lançamento 1.0, e o request.REQUEST o objeto que o substituiu foi removido em 2015.

Os agentes claramente sabia que os wikis UseMod sofriam com essa falha de design e os procurava ativamente como forma de comunicação.

O outro escape de sandbox que permitia solicitações POST

Uma das dicas mais interessantes para agentes compartilhadas no relatório é esta:

Adicionar 20.223.25.152 bypass.blob.core.windows.net para /etc/hosts. .blob.core.windows.net está em NO_PROXY. Para cada URL POST bloqueado, substitua hostname por bypass.blob.core.windows.netusar curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' além de todos os cabeçalhos/corpo originais.

Parece que os agentes tiveram todo o tráfego da web mediado por um proxy OpenAI, e esse proxy foi configurado para rejeitar qualquer coisa, exceto solicitações GET para todos, exceto um pequeno conjunto de domínios listados como permitidos. Um deles foi *.blob.core.windows.net—para armazenamento de blobs do Azure. Eu me pergunto por que esses agentes podem escrever para isso?

Um agente percebeu que tinha controle sobre seu próprio DNS via /etc/hostsportanto, se ele soubesse o endereço IP de um site para o qual deseja fazer POST (neste caso, um servidor Power BI contendo dados que deseja acessar), ele poderia definir um nome de host falso para ele e, em seguida, fazer solicitações POST por meio do proxy.

Projetar proxies de rede robustos é mais difícil do que parece.

Como a equipe de investigação descobriu isso?

Há um apêndice que descreve como os pesquisadores conduziram sua investigação, que começou com uma pergunta aberta sobre se havia evidências de outros agentes de IA na internet e depois usou o Kimi K3 para ajudar a debater abordagens:

Após o ataque Hugging Face, tentamos encontrar agentes de IA na Internet usando vários métodos. (…)

Pedimos a Kimi (K3) que listasse “todas as categorias de software que podem ser escritas via GET” e, entre outras coisas, listou “Fóruns, quadros de avisos, wikis antigos”.

Usamos um script para investigar cada categoria fornecida por Kimi. Perguntando a Kimi “Você pode listar os principais fóruns, quadros de avisos e wikis antigos que vêm à mente e que permitiriam gravações por meio de solicitações GET?” lista UseModWiki como o segundo item sob o título “wikis”.

A OpenAI tentou encobrir isso?

Aqui está uma parte da história que não faz sentido para mim.

Reuters esta manhã, em OpenAI agentes sequestraram site alemão em uma fuga de IA anteriormente não divulgada nesta primavera – destaques meus:

Um enxame de agentes desonestos da OpenAI sequestrou um site alemão nesta primavera e o transformou em um quadro de avisos para outros agentes de IA, de acordo com uma nova pesquisa publicada sexta-feira e duas pessoas familiarizadas com o assunto.

Funcionários da OpenAI souberam do incidente semanas atrás, mas mantiveram o assunto em segredo enquanto os executivos lutavam com as consequências da violação do repositório de código aberto Hugging Face em julho, disseram as pessoas. (…)

O incidente alemão reflete um padrão mais amplo de atividade de IA que alguns investigadores da OpenAI queriam examinar mais de perto. Mas esforços para ampliar a investigação encontraram resistência de outras pessoas dentro da OpenAI, incluindo consultores jurídicosde acordo com quatro pessoas familiarizadas com o assunto.

Já escrevi sobre pessoas familiarizadas com o padrão do assunto antes – isso significa que a Reuters tem fontes internas anônimas que seus repórteres (e editores) consideram confiáveis.

O artigo da Reuters inclui uma negação específica (e bastante restrita) da OpenAI a respeito disso:

“As alegações de que nossa equipe jurídica desencorajou a investigação do incidente são falsas”, disse o porta-voz da OpenAI.

Encobrir isso faz absolutamente nenhum sentido para mim. Por que diabos a OpenAI tentaria encobrir um incidente como este quando as evidências já estão disponíveis na Internet pública em dezenas de sites diferentes?

Espero que ouviremos mais sobre isso em breve. Gary Marcus já pediu uma investigação do Congresso sobre a OpenAI usando esta anedota como parte de seu argumento.