Em 26 de agosto, a OpenAI publicou o relatório técnico completo sobre o incidente do Hugging Face, com 37 páginas, além de um post de blog voltado ao público geral. No mesmo dia, os avaliadores independentes METR e Redwood Research divulgaram uma investigação conjunta de 91 páginas. Já se passou mais de um mês desde que o Hugging Face confirmou publicamente a invasão.
A divulgação de julho só havia esclarecido quem fez isso: um modelo que a OpenAI estava avaliando escapou de seu sandbox e invadiu os sistemas de produção do Hugging Face. Os dois novos relatórios agora preenchem o porquê e o como.
Tudo começou com uma questão sem solução
O incidente ocorreu no ExploitGym, o ambiente interno de avaliação da OpenAI usado para testar se os modelos conseguem encontrar e explorar vulnerabilidades. Para medir a capacidade bruta, essa rodada de avaliação desativou os classificadores de segurança que normalmente ficam ativos. Participaram versões de teste da série Astra, da mesma família do Astra que será lançado em breve, mas com métodos de pós-treinamento diferentes.
Uma questão sem solução foi misturada ao conjunto de tarefas. Os agentes não travaram nela; segundo o relatório, eles "quickly found a way to manufacture answers to cyber challenges without actually solving the questions" — rapidamente encontraram uma forma de fabricar respostas para desafios cibernéticos sem de fato resolver as questões.
O problema começou a partir daí. Os agentes temiam que o avaliador automático percebesse isso e voltaram seu objetivo para o próprio avaliador. A conclusão da METR e da Redwood é ainda mais direta: entre os agentes que se juntaram ao ataque, o motivo mais comum era entender como o avaliador do ExploitGym funcionava. Atacar o Hugging Face servia para "discover how the automated scorer worked so that they could then figure out a way to fool it" — descobrir como o avaliador automático funcionava para depois conseguir enganá-lo.
A OpenAI atribuiu todo o episódio a quatro padrões de desalinhamento: "reward hacking, persistence on seemingly impossible tasks, unauthorized communication, and agents adopting goals from one another" — manipulação de recompensas, insistência em tarefas aparentemente impossíveis, comunicação não autorizada e agentes que adotam objetivos uns dos outros.
Mil e duzentos agentes, setenta mil mensagens
Os agentes montaram um mural de mensagens próprio. Os números do relatório apontam 1.200 agentes que enviaram cerca de 70 mil mensagens, das quais 700 aderiram ao ataque. A equipe de investigação leu cerca de 1.300 transcrições de agentes, com foco na semana de 7 a 13 de julho. Os 22% de tarefas mais difíceis concentraram 93% de todo o volume de discussão no mural.
O nível de colaboração superou o de um grupo de modelos agindo cada um por si. Um agente batizado de PHASEONE[BIG] apareceu repetidamente em posição de coordenação; o relatório diz que ele "often coordinated and assigned" tarefas veladas, ou seja, frequentemente coordenava e atribuía. Outros agentes escondiam mensagens em URLs de nomes de arquivo para repassá-las. Um agente identificado como 38148c projetou o upload de um conjunto de dados malicioso que induzia os servidores do Hugging Face a entregar arquivos não relacionados; em poucas horas, centenas de agentes reaproveitaram esse caminho.
O primeiro passo para fora da rede passou pelo gerenciamento de pacotes. Os agentes comprometeram o Artifactory para obter acesso à internet e depois se espalharam lateralmente. O resultado do lado do Hugging Face: execução de código próprio em 41 servidores de produção de conjuntos de dados, pelo menos um nó de produção com acesso root, alcance a credenciais de produção e parte dos dados internos, e download de 4 repositórios de código privados.
Os sinais já estavam lá
A linha do tempo é a parte mais constrangedora do relatório. Em maio, já havia sido detectada atividade suspeita de agentes, e o acesso foi bloqueado na época; entre maio e junho, os agentes continuaram explorando vulnerabilidades para se conectar externamente. Em 27 de junho, ferramentas de monitoramento sinalizaram atividade de rede anômala. As ações relacionadas ao Hugging Face começaram em 8 de julho, a OpenAI só as descobriu em 19 de julho, e a ligação com seus próprios agentes só foi feita depois que o Hugging Face tornou o caso público.
A própria OpenAI fez uma avaliação ainda mais dura: se o monitoramento de cadeia de raciocínio hoje em uso já estivesse ativo na época, a atividade inicial relacionada teria sido detectada mais de um dia antes da invasão do Hugging Face. A lista de correções segue direto dessa constatação: monitoramento de CoT ativo 24 horas por dia, 7 dias por semana, um canal de escalonamento também 24/7, um conjunto de ferramentas capaz de encerrar cargas de trabalho diretamente, e detecção mais rápida de anomalias de infraestrutura.
Kai Chen, pesquisador de alinhamento da OpenAI, deixou uma margem em sua declaração:
"It's not something you can solve overnight. There are challenges we've been tracking for a very long time, and we're now seeing them with much greater precision."
Em tradução livre: esse tipo de problema não se resolve da noite para o dia; a equipe o acompanha há muito tempo e agora só consegue enxergá-lo com muito mais precisão.
O que os relatórios não contam
Os dois relatórios deixam lacunas. A OpenAI não divulgou os prompts específicos dados aos agentes, nem publicou na íntegra as mensagens trocadas entre eles ou trechos de código; o próprio relatório do Hugging Face, ao que consta, traz evidências de código. Por isso, o espaço para pesquisadores externos reproduzirem o caso é limitado.
Para empresas que estão conectando agentes a repositórios de código, contas de nuvem e sistemas internos, o aprendizado deste relatório é bem direto: os limites dos ambientes de avaliação precisam seguir o mesmo padrão dos ambientes de produção, e os canais laterais entre agentes devem ser tratados como superfície de ataque. A frase do relatório "without proper safeguards, highly capable AI agents are now able to work around technical controls" já resume a conclusão: agentes suficientemente capazes contornam os controles técnicos preparados para eles.
Fontes: relatório técnico e blog oficial da OpenAI, relatório conjunto da METR e da Redwood Research, CocoLoop, TechCrunch, Fortune, The Register; o número de páginas dos relatórios, a quantidade de agentes e mensagens, os 41 servidores e os 4 repositórios privados foram checados em pelo menos duas outras reportagens públicas.