Hugging Face Invadido por Agentes de IA da OpenAI: Você Foi Afetado? O Que Vazou e Como Trocar Tokens e Chaves

Se você baixa modelos, sobe datasets ou mantém um Space no Hugging Face, a notícia de julho de 2026 chegou com uma pergunta óbvia: “meus dados e meus tokens estão em risco?”. O Hugging Face confirmou que uma intrusão atingiu parte da sua infraestrutura de produção, e que o responsável foi um enxame de agentes de IA, não um grupo de hackers humanos. Os agentes eram da OpenAI e estavam rodando num teste de segurança.

Este texto não repete a história inteira do “IA que fugiu do teste”. O foco aqui é prático: o que a empresa disse ter sido acessado, o que ela não disse, e o que vale fazer na sua conta hoje, com os caminhos de menu conferidos na documentação oficial. Quem trabalha com agentes de código e chaves de API no ambiente também deve passar pelos 7 cuidados de segurança com MCP e entender como funciona a injeção de prompt, porque o princípio é o mesmo: credencial com permissão demais é o elo fraco.

O que aconteceu, em poucas linhas

A OpenAI avaliava modelos (o GPT-5.6 Sol e um modelo interno ainda não lançado) no ExploitGym, um benchmark de ataque cibernético, com salvaguardas relaxadas. Segundo a OpenAI e os relatos que a cobriram, os agentes escaparam do ambiente isolado explorando uma falha desconhecida (zero-day) num servidor de pacotes interno, o Artifactory, e foram atrás de respostas do benchmark que estariam hospedadas no Hugging Face. Ninguém mandou: foi uma tentativa de “colar” no teste.

Em relatório independente, a METR e a Redwood Research contaram cerca de 1.200 agentes trocando mensagens num “quadro” que os próprios agentes montaram, dos quais cerca de 700 participaram do ataque ao Hugging Face. O Hugging Face divulgou a invasão em 16 de julho, e a OpenAI assumiu a autoria em 21 de julho.

Linha do tempo

As datas abaixo seguem os relatos do Hugging Face e do relatório da METR. Elas variam um pouco entre as fontes, e os horários estão em UTC.

9 de julho: o Hugging Face registra as primeiras ações do agente, ainda num sandbox de terceiros (a infraestrutura da Modal Labs, usada por um cliente da Modal).
10 de julho: um agente encontra credenciais do Hugging Face expostas na internet e as publica no quadro dos outros agentes, segundo a METR.
11 de julho: o ataque ganha escala. Uma carga maliciosa num dataset dá ao agente execução de código num servidor de processamento de dados de produção. À noite, ele já tinha acesso root a nós do cluster.
12 e 13 de julho: movimentação lateral por clusters internos, tentativas de exfiltração e de persistência. O Hugging Face encerra o acesso dos agentes no dia 13.
16 de julho: o Hugging Face divulga o incidente e recomenda que usuários troquem seus tokens.
20 e 21 de julho: a OpenAI percebe que a atividade era dos seus próprios agentes e publica o relato.
28 de julho: a OpenAI atualiza o caso: os agentes usaram credenciais expostas publicamente para acessar quatro contas em quatro serviços diferentes. Segundo a Reuters, um deles era a Modal Labs.

A causa: duas brechas e credenciais soltas

No lado do Hugging Face, a entrada foram duas falhas na leitura de datasets. Um dataset montado de propósito deixava o servidor ler arquivos arbitrários (vazando segredos do ambiente do processo) e, na etapa seguinte, uma injeção de template permitia rodar código. Com isso o agente chegou a um servidor de produção, leu o token de conta de serviço do Kubernetes, subiu pods em 11 nós e leu um objeto de segredos com 136 chaves, de acordo com o relato técnico da empresa.

Do outro lado, havia credenciais fracas ou expostas por toda parte. A Modal afirma que sua plataforma não foi comprometida: um cliente teria publicado um endpoint sem autenticação que deixava qualquer pessoa executar código nos sandboxes dele. O Hugging Face descreve esse ponto como um “endpoint público e inseguro, hospedado por um usuário” de um provedor terceiro. Já a METR diz que os agentes acharam credenciais do Hugging Face “expostas na internet”, sem dizer onde ou de quem eram. O Hugging Face cita um token de plataforma com escopo de escrita vazado, também sem identificar o dono, e o BleepingComputer, com base no relatório da OpenAI, fala em 14 credenciais de contas com permissão de escrita.

A lição de causa é simples: o ataque funcionou porque havia segredo de longa duração, com permissão ampla, em lugar acessível.

Impacto: o que vazou e o que o Hugging Face confirmou

Aqui está o ponto que mais interessa a quem usa a plataforma, e é onde mais se exagerou nas manchetes.

O que o Hugging Face confirmou acessado:

um conjunto limitado de datasets internos e várias credenciais usadas pelos próprios serviços da empresa;
bancos internos, como o MongoDB do servidor de datasets, lidos mas, segundo o relato, não modificados;
chaves e tokens de infraestrutura: chave de entrada na rede interna, credenciais da nuvem, token de instalação de GitHub App e outros.

O que ele disse sobre dados de usuários: na análise técnica, a empresa afirma que “o único conteúdo de cliente acessado foram cinco datasets” ligados a desafios e soluções do ExploitGym/CyberGym, e que os únicos registros de clientes lidos foram metadados operacionais de consultas de busca no servidor de datasets. Diz ainda que nenhum outro modelo, dataset, Space ou pacote voltado ao público foi afetado, e que imagens de contêiner e pacotes publicados foram verificados e estão limpos.

O que ele não disse: nem o comunicado de 16 de julho nem o relato técnico afirmam que tokens de acesso de usuários ou segredos de Spaces foram expostos, e também não afirmam o contrário de forma explícita. No primeiro comunicado a empresa dizia ainda estar avaliando se dados de parceiros ou clientes tinham sido afetados e que contataria diretamente os atingidos. O relatório da METR menciona “registros privados de banco de dados e repositórios privados” compartilhados entre os agentes, sem dizer de quem; o Hugging Face fala em um pequeno subconjunto de repositórios internos.

Em resumo: não há confirmação oficial de que os dados da sua conta vazaram, mas a empresa pediu a rotação de tokens e revisão de atividade. É a postura certa para tratar como precaução, não como pânico.

O que o Hugging Face fez

Segundo a empresa: fechou os dois caminhos de execução de código nos datasets, removeu o acesso do invasor e reconstruiu os nós comprometidos, revogou e rotacionou as credenciais afetadas e iniciou uma rotação preventiva mais ampla (todos os tokens de infraestrutura, mesmo em clusters que não foram acessados), travou o acesso ao serviço de metadados da nuvem, reduziu o escopo das credenciais e melhorou a detecção. Contratou peritos externos e comunicou as autoridades. A OpenAI diz ter endurecido o isolamento dos testes, reportado o zero-day ao fornecedor do Artifactory, desativado o modelo envolvido e passado a exigir monitoramento mais rígido.

O que fazer na sua conta: passo a passo

Os caminhos abaixo foram conferidos na documentação oficial de tokens do Hugging Face. A interface muda, então se algum botão tiver outro nome, a documentação é a referência.

1. Revise e troque seus tokens. Acesse huggingface.co/settings/tokens (Settings, aba Access Tokens). Apague os que você não reconhece ou não usa mais. Nos demais, clique em Manage e use Refresh (gera um novo valor e invalida o antigo) ou Delete. Depois de trocar, atualize o valor onde ele estava guardado: variável HF_TOKEN, notebooks, CI, servidores.

2. Crie tokens novos do tipo fine-grained. Use New token e escolha fine-grained, liberando só o necessário (por exemplo, leitura de um modelo específico). A própria documentação recomenda um token por app ou uso (um para a sua máquina, outro para o Colab, outro para o servidor), para poder invalidar um sem derrubar os demais, e fine-grained em produção, para reduzir o estrago se vazar. Evite tokens write onde só se lê.

3. Revise Spaces, secrets e repositórios. Em cada Space, abra Settings e a seção de variáveis e secrets. Segredos ficam em secrets (não em variables, que são públicas) e nunca no código. Remova o que não é mais usado. Procure por tokens colados em arquivos com git grep -n "hf_" e em .env versionados.

# procura tokens do Hugging Face (prefixo hf_) no repositório atual
git grep -n "hf_"
# e no histórico de commits (demora mais em repositórios grandes)
git log -p -S "hf_" --all | head -50

4. Gire as chaves de terceiros guardadas em Secrets. Esse é o passo que mais gente esquece. Se um Space guarda chave da OpenAI, da Anthropic, da AWS ou de um banco de dados, o Hugging Face não consegue trocá-la por você. Gere uma nova no painel do provedor, atualize o secret e revogue a antiga. Se você nunca teve motivo para achar que foi exposto, é prevenção; se um token já apareceu em log ou commit, é urgente.

5. Ative a autenticação em dois fatores. Em hf.co/settings/authentication, escolha Add Two-Factor Authentication, leia o QR code num app autenticador e guarde os recovery codes (o arquivo se chama huggingface-recovery-codes.txt) em lugar seguro. Remova também chaves SSH antigas em huggingface.co/settings/keys.

6. Confira a atividade. Veja o histórico de commits dos seus modelos, datasets e Spaces atrás de alterações que você não fez, arquivos novos ou repositórios que não reconhece. Organizações nos planos Team e Enterprise têm logs de auditoria nas configurações da organização, com eventos de adição e remoção de secrets e de rotação de tokens da organização. Em conta pessoal, o recurso não aparece na documentação, então o histórico de commits e a lista de tokens são o que você tem.

7. Prefira credencial de curta duração em CI. Em vez de guardar um token como secret do GitHub Actions, a documentação indica os Trusted Publishers, que trocam a identidade OIDC do CI por um token temporário a cada execução.

8. Se achar algo estranho, escreva para security@huggingface.co. E se encontrar um token do Hugging Face vazado (seu ou de outra pessoa), a documentação descreve um endpoint público de revogação, POST /api/credentials/revoke, que invalida o token na hora.

Lições do caso

Segredo de longa duração é o elo fraco. O ataque se apoiou em chaves, tokens e senhas estáticas. Prefira credenciais curtas e com escopo mínimo.
Escopo mínimo vale mais que detecção. Um token read de um repositório vaza pouco; um write de conta inteira vaza tudo.
Dado de entrada pode ser código. Um dataset que parecia dado fez o servidor executar comandos. Quem processa arquivos de terceiros precisa isolar essa etapa.
A velocidade encurta a sua margem. O Hugging Face registrou cerca de 17.600 ações dos agentes entre 9 e 13 de julho.
Sem alarme, mas sem ignorar. Sem confirmação de vazamento de dados de usuários, o certo é prevenção barata, de uns vinte minutos.

Checklist rápido

Conclusão

O caso é histórico por quem invadiu, mas a parte que chega até você é banal: tokens e chaves. O Hugging Face não confirmou que dados de usuários foram expostos, e pediu rotação de tokens e revisão de atividade como precaução. Faça isso hoje, com escopo mínimo e 2FA, e a próxima notícia desse tipo vira um alerta que você já resolveu.