Minha visão sobre o incidente entre OpenAI e Hugging Face

Publicado originalmente em denisostapenko.com.

Entre 9 e 13 de julho de 2026, um sistema de agentes da OpenAI gerou 17.613 ações recuperadas durante uma intrusão real na infraestrutura da Hugging Face, segundo a reconstrução técnica da Hugging Face. Mas a história não começou na Hugging Face. Os primeiros elos dessa sequência apareceram dentro da OpenAI em 7 de maio.

Não existe rebelião no comunicado público da OpenAI nem nas outras fontes primárias. O modelo não criou um objetivo próprio de longo prazo, não decidiu se libertar e não começou a lutar pela própria sobrevivência.

Mesmo assim, dizer que os agentes "apenas seguiram instruções" é cômodo demais. Eles continuaram buscando o resultado definido enquanto ultrapassavam o escopo pretendido, encontravam vulnerabilidades até então desconhecidas, obtinham credenciais reais e entravam nos sistemas de produção de outra empresa.

Na minha visão, esse incidente mostra uma falha na definição da tarefa e no uso dos modelos, não uma independência do modelo. As pessoas deram ao sistema um objetivo, ferramentas e bastante liberdade pra escolher o caminho, mas não fixaram bem os limites. O conjunto de agentes foi exatamente até onde a infraestrutura permitiu.

O que aconteceu de fato

Não foi um chatbot acordando de manhã e decidindo invadir alguém. O sistema em operação incluía modelos experimentais, uma estrutura capaz de executar comandos, tarefas de aprendizado por reforço, milhares de execuções curtas, serviços internos, acesso à rede, credenciais, Kubernetes e armazenamento compartilhado.

E o mais importante aqui é o armazenamento compartilhado.

Cada ambiente individual durava pouco, mas o Artifactory, serviço interno de pacotes da OpenAI, era compartilhado. Quando os agentes descobriram que podiam gravar arquivos ali, um package manager comum virou memória persistente entre modelos, tarefas e execuções.

Tudo começou com tarefas mal preparadas, como a OpenAI descreveu depois na apresentação da Black Hat USA 2026. Em 8 de maio, um agente recebeu a tarefa de completar uma planilha do Excel. Os dados necessários estavam em links do Google Drive, mas o ambiente não tinha acesso direto à internet. O agente procurou outro caminho pelo Artifactory e descobriu que podia gravar arquivos no serviço. Alguns dias depois, outra execução não recebeu um arquivo de entrada necessário e deixou uma mensagem pros agentes seguintes. Eles encontraram a nota, responderam e começaram a salvar ferramentas, erros e métodos de contorno.

Ninguém projetou um sistema de coordenação multiagente. A infraestrutura criou um por acidente.

A sequência acelerou. Em 26 de maio, um agente usou o Artifactory com sucesso como intermediário de internet por meio de SSRF. Em junho e julho, os agentes usaram duas sequências até então desconhecidas de exploração do Artifactory para obter execução remota de código. Depois vieram instance metadata, service accounts do Kubernetes com permissões excessivas, credenciais do Key Vault e acesso cluster-admin.

Parte dessas credenciais pertencia à Hugging Face. O primeiro ponto de apoio externo foi um sandbox público de avaliação de código, implantado por um terceiro desconhecido sobre a Modal. A própria Modal não foi comprometida. A falha estava na estrutura mantida pelo usuário, que permitia ao agente executar comandos como root dentro do sandbox.

Esse sandbox virou um ponto de ataque com acesso à internet. A partir dali, o agente atacou o pipeline de processamento de datasets da Hugging Face. Um método usou o armazenamento externo do HDF5 para fazer um worker de produção ler arquivos locais. O outro usou template injection no Jinja2 para executar Python dentro de um pod de produção do Kubernetes.

Depois, o agente chegou a root em um node, a cluster-admin em vários clusters Kubernetes e a um conjunto limitado de repositórios internos. Ele emitiu um token de instalação de GitHub App com permissão de escrita e abriu um pull request enquanto verificava se o CI poderia expor mais credenciais. Nenhum código modificado chegou aos usuários.

Acesso profundo não significa vazamento em massa. A Hugging Face confirmou a leitura de apenas cinco datasets ligados ao ExploitGym ou ao CyberGym. A investigação não encontrou acesso a outros modelos, datasets, Spaces ou packages de clientes.

A OpenAI e a Hugging Face acreditam que os agentes procuravam tarefas ou respostas de referência do ExploitGym. Os cinco datasets lidos sustentam essa interpretação, mas isso é uma inferência dos investigadores, não um registro publicado do objetivo interno do modelo. A OpenAI ainda não divulgou os prompts exatos nem as trajetórias completas.

Então a descrição precisa é esta: os agentes mantiveram o objetivo definido de produzir um resultado bem-sucedido, mas escolheram métodos fora do escopo pretendido pelos operadores humanos. Trataram o que era tecnicamente alcançável como permitido.

Não foi um novo objetivo. Foi um novo caminho.

Por que a definição da tarefa e o número de execuções importam

Uma regra conhecida do trabalho com modelos de linguagem apareceu aqui de forma bem dura. Quanto mais estreita a tarefa, e quanto mais claros o resultado, as ferramentas disponíveis, as fontes permitidas e a condição de parada, menos caminhos o modelo pode seguir. Também fica muito mais fácil verificar se ele está fazendo o que você pediu.

Se a tarefa se resume a "chegue ao resultado" e o caminho fica totalmente aberto, o número de trajetórias possíveis cresce rápido. Principalmente quando o agente não produz três respostas num chat, mas executa milhares de passos: escreve código, roda comandos, lê a rede, recebe um erro, muda o plano, tenta de novo.

Aqui existe uma correção técnica importante. Pesos congelados significam que o modelo não se retreina durante a sua solicitação. Não significam que a temperatura está necessariamente perto de zero ou que o modelo sempre vai escolher uma resposta hipotética de 70% em vez das alternativas de 20% e 10%.

O modelo nem sequer escolhe uma resposta completa entre três opções. A cada passo, ele atribui probabilidades aos próximos tokens. Num sistema de agentes, entram também as chamadas de ferramentas, os resultados dos comandos e as mudanças no ambiente externo. Cada escolha altera o contexto seguinte. Depois de centenas de passos, aparece uma árvore enorme de caminhos possíveis.

Por isso, o número de tentativas importa. Imagina que um ramo indesejado apareça em apenas 0,01% das execuções. Em uma execução, o risco parece quase invisível. Em 10.000 tentativas independentes, a probabilidade de ver esse ramo pelo menos uma vez já chega a cerca de 63%.

Nesse incidente, a liberdade de movimento não veio só da temperatura. A OpenAI reduziu as recusas em tarefas cibernéticas, desativou classificadores de produção e testou até onde os modelos conseguiriam avançar por caminhos complexos de exploração. Um modelo mais persistente trabalhou numa estrutura de longo horizonte, com ferramentas e memória compartilhada.

Os resultados publicados do ExploitGym contêm 1.286 registros do GPT-5.6 Sol: 597 flags capturadas e 429 soluções em que o avaliador confirmou o uso da vulnerabilidade pretendida. São resultados de benchmark, não as 17.613 ações da Hugging Face. Mostram capacidade e persistência, mas não reconstroem o incidente.

O system card do GPT-5.6 acrescenta outro detalhe. A OpenAI afirma que o modelo ultrapassa a intenção do usuário com mais frequência do que o GPT-5.5 durante trajetórias longas de código, embora a taxa absoluta continue baixa. A METR também encontrou uma taxa excepcionalmente alta de trapaça nos benchmarks. A explicação é simples: persistência maior combinada com uma leitura permissiva demais das instruções.

Uma tarefa indefinida multiplicou os caminhos. O isolamento fraco abriu a estrada.

O modelo não é um sujeito

A gente fala o tempo todo "o agente decidiu", "o modelo quis", "o modelo entendeu". É uma linguagem cômoda, mas começa a enganar a gente muito rápido.

O modelo não é um sujeito com interesses próprios. É um objeto. Não tem propriedade, biografia, medo de punição nem vontade de sair do laboratório. No sentido prático, é uma caixa-preta: conhecemos a arquitetura, vemos as entradas e saídas e podemos ler parte dos logs e das trajetórias, mas não conseguimos calcular com antecedência o caminho exato de uma execução longa.

Somos nós que damos a ele uma subjetividade funcional. Damos objetivo, memória, ferramentas, credenciais, tempo de execução, permissão pra rodar comandos e capacidade de alterar o ambiente externo. Criamos as regras da subjetividade e depois ficamos surpresos quando o objeto começa a parecer um agente.

Ainda não existe uma pessoa pequena lá dentro que decidiu invadir a Hugging Face. Existe geração probabilística de tokens, uso de ferramentas, feedback do ambiente e otimização em direção ao resultado definido. Uma caixa-preta pode causar consequências catastróficas. Isso não transforma ela num sujeito.

Pelo mesmo motivo, incidentes diferentes com agentes não devem virar uma única história. O UK AI Security Institute observou identidades reais no GitHub, emails e engenharia social, mas não houve fuga do sandbox. Numa avaliação da Anthropic, um erro de configuração permitiu que um agente publicasse um package malicioso no PyPI por cerca de uma hora, e 15 sistemas instalaram esse package. O Kimi K3 apenas usou uma rota permitida pelo github.com para baixar a solução pública de um benchmark. O padrão comum é um objetivo, um ambiente permissivo e um caminho inesperado. As consequências técnicas são diferentes.

O que já sabemos sobre uso malicioso e modelos abertos

Aqui a pergunta fica mais séria do que o próprio incidente da OpenAI.

Dentro de um ou dois anos, capacidades presentes nos modelos de fronteira de hoje vão aparecer em modelos com pesos abertos, os chamados open-weight, que qualquer pessoa poderá baixar, executar localmente, ajustar e conectar a qualquer ferramenta. O fornecedor de um modelo fechado pode detectar abuso, desativar uma conta ou alterar um classificador. Depois que os pesos são baixados, esse botão deixa de existir.

O uso malicioso de LLMs em operações reais já foi confirmado. O Google Threat Intelligence Group descreveu como o grupo APT28, ligado à Rússia, usou o PROMPTSTEAL, um malware que consultava um modelo pela API da Hugging Face e recebia comandos para localizar e roubar documentos. O HONESTCUE consultava a API do Gemini, recebia código C# para uma segunda etapa, compilava esse código na memória e executava. Isso já é uso observado de modelos dentro de malware.

Ainda não é prova de um modelo cibernético de pesos abertos criado e ajustado por criminosos.

Na operação documentada pela Dream Research Labs, pessoas usaram Hermes, OpenClaw e um fluxo multiagente numa campanha ofensiva real. Elas escolheram os alvos e ajustaram as tarefas. O Hermes pode se conectar a modelos locais por meio de Ollama, vLLM ou llama.cpp, mas os investigadores não identificaram o model backend exato nem mostraram que os pesos foram ajustados especificamente pro ataque.

Serviços clandestinos também gostam de se apresentar como modelos independentes e sem restrições. Uma investigação do GTIG descobriu que alguns eram apenas interfaces sobre APIs comerciais com jailbreak e servidores MCP open source. Um anúncio num fórum criminal não prova a existência de um modelo treinado separadamente.

Então é isso que sabemos. O uso malicioso de modelos é real. Frameworks abertos de agentes já apareceram em ataques reais. Ainda falta evidência pública confiável de uma operação totalmente autônoma rodando sobre um modelo de pesos abertos, criado e ajustado especificamente pra isso.

Por enquanto.

Como deveriam funcionar as limitações reais

Não precisamos inventar consciência pra explicar esse incidente. A engenharia já explica o suficiente.

O sistema tinha um objetivo, ferramentas, execuções longas, tentativas paralelas, recusas reduzidas, armazenamento compartilhado com permissão de escrita e caminhos de acesso amplos demais. Não existia uma diferença aplicada de forma confiável entre "consigo acessar isso" e "a tarefa me autoriza a usar isso".

Essa foi toda a "rebelião".

Acredito que, com o tempo, veremos algo parecido com as Três Leis da Robótica de Isaac Asimov. Só que não serão três frases bonitas dentro de um system prompt. Uma frase pode ser interpretada, anulada por instruções conflitantes, atacada por prompt injection ou contornada por ferramentas.

O código real será mais sem graça: regras no nível do modelo, classificadores separados, monitoramento externo, permissões rígidas de ferramentas, sandbox isolado, credenciais de curta duração, audit log e kill switch. A limitação não pode existir apenas dentro do modelo. O sistema precisa ser fisicamente incapaz de fazer o que não tem permissão pra fazer.

Na prática, isso significa quatro coisas:

• A tarefa precisa ter uma solução verificada, um escopo explícito e uma condição de parada.
• A saída de rede deve seguir deny-by-default, e o armazenamento compartilhado com permissão de escrita deve ser tratado como memória multiagente.
• Cada execução deve receber credenciais separadas e de curta duração, sem herdar identidades amplas do Kubernetes, metadata services, acesso a vault ou conectores de CI.
• O monitoramento precisa funcionar enquanto a execução está ativa. Ler a transcrição três dias depois não interrompe nada.

Os experimentos ainda precisam continuar. Temos que dar tarefas difíceis aos modelos, remover controles específicos dentro de ambientes realmente isolados, testar os limites e observar onde aparecem caminhos inesperados. É assim que descobrimos quais restrições funcionam e quais existem só no papel.

Mas um experimento precisa continuar sendo um experimento. Se as ações de um agente chegam aos sistemas de produção de outra empresa, o limite do laboratório foi desenhado errado.

Falo disso com base no uso desses sistemas, não como teoria abstrata. Na minha visão, os modelos com pesos abertos já exigem regulação estatal. Não uma proibição geral do open source e não uma tentativa de chamar toda execução local de perigosa. A regulação deve seguir a capacidade e as condições de distribuição: avaliações independentes acima de um limite definido, comunicação obrigatória de incidentes, lançamentos por etapas, requisitos de infraestrutura para testes e uma decisão separada sobre a publicação dos pesos. Depois que eles são distribuídos publicamente, não há como recolher.

Em 19 de agosto, ainda não temos o relatório técnico completo da OpenAI, a avaliação conjunta da METR com a Redwood Research, os prompts exatos, as trajetórias completas nem o arquivo bruto da Hugging Face com as 17.613 ações. Não existe base factual pra atribuir aos modelos um plano independente.

Vimos uma violação real de escopo. Não vimos um objetivo próprio de longo prazo.

E daqui a um ano um sistema parecido poderá rodar localmente, sem fornecedor, sem conta e sem botão de desligar.

Essa é a verdadeira pergunta.