Encontrei Modelos de IA com Backdoor no Hugging Face — e Todo Mundo Que Se Deu ao Trabalho de Olhar Também Encontrou

Era uma noite de terça-feira, e eu estava observando um dos meus engenheiros fazer algo que deveria ser rotina: carregar um modelo pré-treinado do Hugging Face em um ambiente de teste. Coisa padrão. Já tínhamos feito isso centenas de vezes. Mas, dessa vez, eu tinha acabado de ler a divulgação da JFrog de fevereiro de 2024 — aquela em que os pesquisadores de segurança deles encontraram mais de 100 modelos maliciosos hospedados no Hugging Face, alguns com backdoors que davam aos atacantes acesso remoto no instante em que você os carregava — e eu não conseguia parar de encarar o terminal.

"Espera", eu disse. "Em que formato está esse modelo?"

Pickle.

Meu estômago gelou.

Foi nesse momento que percebi que estávamos tratando os modelos de IA do jeito que a indústria tratava as bibliotecas de código aberto em 2014 — como artefatos inerentemente confiáveis que você simplesmente baixa da internet e executa. E eu soube, com aquele tipo de certeza que só vem de ver suas premissas ruírem em tempo real, que essa seria uma das crises de segurança definidoras da próxima década.

O Modelo Que Liga Para Casa

Aqui está o que realmente aconteceu no Hugging Face. Um usuário chamado "baller423" subiu um modelo PyTorch que parecia perfeitamente normal. Tinha um nome razoável, uma descrição plausível, métricas de aparência decente. Mas, enterrado dentro de seus pesos serializados em pickle, havia um payload que, no instante em que alguém executava torch.load(), abria um shell reverso para um endereço IP pertencente à Korea Research Environment Open Network.

Não um ataque teórico. Não uma prova de conceito. Um modelo ativo, transformado em arma, hospedado no hub de modelos de IA mais popular do mundo, esperando alguém baixá-lo.

E "baller423" não estava sozinho. A JFrog encontrou aproximadamente 100 modelos como esse — cada um deles um cavalo de Troia fantasiado de artefato pré-treinado prestativo.

Quando você executa torch.load() em um arquivo pickle, você não está carregando dados. Você está executando código. E você não faz ideia do que esse código faz até que seja tarde demais.

Preciso explicar por que isso é tão perigoso, porque a maioria das pessoas — até a maioria dos engenheiros — não entende o que o pickle realmente é. O formato pickle do Python não é apenas um método de serialização de dados. É uma máquina virtual baseada em pilha. Ele pode executar funções Python arbitrárias durante a desserialização. Quando o seu cientista de dados carrega um modelo, o pickle pode silenciosamente chamar os.system() ou subprocess.run() em segundo plano. O modelo funciona bem. As previsões parecem normais. E, enquanto isso, alguém do outro lado do mundo tem um shell no seu servidor.

Isso não é um bug. É como o pickle foi projetado. Nós apenas nunca encaramos o que isso significa quando os arquivos vêm de estranhos na internet.

Por Que os Scanners Não Detectaram?

Essa é a parte que me manteve acordado naquela noite. Nós tínhamos ferramentas de segurança. A indústria tinha o PickleScan, a ferramenta padrão para verificar arquivos de modelo. O próprio Hugging Face o executa. Certamente os scanners detectariam algo tão descarado, não?

Não detectaram. E fica pior.

A JFrog descobriu depois três vulnerabilidades zero-day no próprio PickleScan — incluindo uma registrada como CVE-2025-10155 — que permitiam aos atacantes contornar completamente a detecção manipulando extensões de arquivo ou explorando discrepâncias em arquivos ZIP. Um modelo malicioso podia ser marcado como "seguro" pela própria ferramenta projetada para proteger você.

O quadro estatístico é sombrio: até 96% dos alertas atuais dos scanners são falsos positivos. Pense no que isso faz com uma equipe de segurança. Depois do centésimo alarme falso, você para de olhar. Você começa a clicar em "aprovar" por reflexo. E é exatamente aí que a ameaça real entra pela porta.

Tive uma discussão acalorada com um dos meus líderes de equipe sobre isso. Ele achava que estávamos exagerando. "Só puxamos modelos de organizações verificadas", ele disse. Mostrei a ele os dados da JFrog. Mostrei que até formatos "seguros" mais novos, como o GGUF — projetado especificamente para evitar os problemas do pickle —, tinham sido flagrados abrigando templates Jinja maliciosos em seus metadados, que são executados durante a inferência, não durante o carregamento. O scanner nunca vê isso porque o ataque acontece depois, quando o modelo já está rodando.

Ele ficou em silêncio por um longo tempo. Então disse: "Então, em que a gente confia, afinal?"

Essa é a pergunta certa.

O Que Acontece Quando Sua IA Tem um Agente Adormecido Dentro Dela?

O incidente do Hugging Face envolvia payloads rudimentares e detectáveis — shells reversos, execução óbvia de código. Mas a ameaça mais profunda, a que genuinamente me assusta, é o envenenamento de dados. E a pesquisa sobre isso é aterrorizante.

O AI Red Team da NVIDIA, trabalhando em conjunto com descobertas da Anthropic, demonstrou que é possível implantar permanentemente um comportamento oculto em um modelo de 13 bilhões de parâmetros envenenando apenas 0.00016% dos dados de treinamento — cerca de 250 documentos entre milhões.

Deixe esse número penetrar. Duzentos e cinquenta documentos.

O modelo envenenado passa em todos os benchmarks. Ele tem desempenho idêntico ao de um modelo limpo em testes padrão. Mas, quando encontra um gatilho específico — uma determinada sequência de texto, um padrão de imagem, até mesmo uma manipulação em nível de bit nos dados de entrada —, ele muda de comportamento. Pode contornar a autenticação. Pode exfiltrar dados. Pode gerar código malicioso que acaba canalizado para um sistema downstream.

Um modelo de IA envenenado é o agente adormecido perfeito: ele passa em todos os testes, gabarita todos os benchmarks e espera pacientemente por um gatilho que só o atacante conhece.

E aqui vem o soco matemático no estômago: adicionar mais dados limpos não resolve. Uma vez que o backdoor atinge um limiar — tipicamente de 50 a 100 ocorrências do gatilho durante o treinamento —, ele fica permanentemente incorporado aos pesos. Você não consegue treiná-lo para fora. Você não consegue diluí-lo até que suma.

A NVIDIA formalizou isso no que chama de AI Kill Chain: cinco estágios — Recon, Poison, Hijack, Persist, Impact — que mapeiam como os atacantes comprometem sistematicamente sistemas de machine learning. Escrevi sobre esse framework e sobre todo o espectro de vetores de ataque em nossa visão geral interativa da pesquisa, e eu encorajaria qualquer pessoa que implante modelos em produção a dedicar um tempo a ela.

A implicação para qualquer empresa que faça fine-tuning de modelos com seus próprios dados é dura: mesmo que o seu conjunto de dados proprietário seja impecável, o modelo base que você baixou de um repositório público já pode estar comprometido. Você está construindo sobre uma fundação cujo interior você não pode ver.

O Problema da Shadow AI Que Ninguém Quer Discutir

Eu estava em um jantar com uma CISO de uma empresa de serviços financeiros de médio porte. Ela me contou, quase casualmente, que a equipe dela tinha descoberto recentemente 47 modelos de IA diferentes rodando em produção pela companhia. A política de governança de IA dela cobria três deles.

Isso é Shadow AI, e é uma epidemia. Os dados são impressionantes: 90% do uso de IA nas empresas acontece fora do alcance das equipes de TI e de segurança. Desenvolvedores e áreas de negócio puxam modelos não verificados de repositórios públicos porque o processo oficial demora demais. Eles colam código proprietário e dados de clientes em ferramentas públicas de IA — 77% dos funcionários já foram observados fazendo isso. E cada um desses modelos não autorizados é um backdoor em potencial que nenhum scanner jamais tocou.

O impacto financeiro não é abstrato. Incidentes envolvendo ferramentas de IA não verificadas aumentam o custo de uma violação de dados em, em média, $670,000. Esse é o prêmio que você paga por "andar rápido" sem governança.

Eu entendo o impulso. Entendo mesmo. Quando você é um engenheiro tentando entregar uma funcionalidade e o processo de revisão de segurança leva três semanas, claro que a tentação é simplesmente puxar um modelo do Hugging Face e plugá-lo. Eu mesmo já senti essa tentação. Mas a divulgação da JFrog deveria ter encerrado essa era. Agora sabemos, com certeza empírica, que os hubs públicos de modelos contêm artefatos transformados em armas. Tratá-los como fontes confiáveis é o equivalente, em IA, a executar curl | bash a partir de um gist aleatório do GitHub em produção.

Por Que Todo Mundo Ainda Está Voando às Cegas?

O NIST publicou sua diretriz AI 100-2 em 2024 — uma taxonomia abrangente de ataques adversariais a machine learning e de suas mitigações. É um bom trabalho. Dá à indústria uma linguagem comum para essas ameaças. E quase ninguém a implementou.

Os números são condenatórios:

• Apenas 17% das organizações têm controles automatizados de segurança de IA
• Apenas 12% têm governança de IA abrangente implementada
• Apenas 14% têm visibilidade sobre os fluxos internos de dados de IA
• 83% das organizações estão, na formulação do NIST, "operando às cegas"

Já vi essa lacuna de perto. As organizações confundem ter um documento de política com ter segurança operacional. Elas te mostram um PDF de governança de IA lindamente formatado enquanto seus desenvolvedores carregam modelos pickle não assinados em clusters Kubernetes de produção. O documento existe. Os controles, não.

83% das empresas não têm controles automatizados sobre sua cadeia de suprimentos de IA. Isso não é uma lacuna — é uma porta aberta.

Como Começamos a Tratar Modelos Como Código Malicioso

Depois daquela revelação na noite de terça, minha equipe na Veriprajna passou semanas redesenhando nossa abordagem para a ingestão de modelos. A mudança filosófica central era simples, mas radical: tratar todo modelo de IA como código executável potencialmente malicioso até que se prove o contrário.

Não "provavelmente está tudo bem". Não "vem de uma fonte respeitável". Potencialmente malicioso. Ponto final.

A Lista de Materiais de Machine Learning

A primeira coisa de que precisávamos era transparência. As tradicionais Listas de Materiais de Software (SBOMs) rastreiam bibliotecas e versões, mas os artefatos de IA precisam de algo mais: uma ML-BOM — uma Lista de Materiais de Machine Learning — que capture a proveniência dos dados, a linhagem do modelo, as dependências de framework e as atestações criptográficas.

De onde vieram os dados de treinamento? Quem fez o fine-tuning desse modelo, e com base em quê? Qual versão do PyTorch foi usada, e ela tem vulnerabilidades conhecidas? Podemos verificar criptograficamente que o modelo que estamos carregando é exatamente o artefato produzido por um pipeline confiável, sem adulteração durante o transporte?

Se você não consegue responder a essas perguntas, você não sabe o que está implantando.

Matando o Pickle, Assinando Tudo

Tomamos duas decisões imediatas de engenharia. Primeira: nada mais de pickle. Ponto. Todo modelo em nosso pipeline usa SafeTensors — um formato que armazena apenas dados de tensores com metadados em JSON e não pode executar código durante o carregamento. É menos flexível que o pickle, e é exatamente esse o ponto.

Segunda: assinatura criptográfica de modelos. Cada artefato de modelo recebe um hash único, assinado com nossa infraestrutura interna de PKI. Nossos servidores de inferência rodam um controlador de admissão que verifica a assinatura contra nossa raiz de confiança antes que os pesos sejam desserializados na memória. Se a assinatura não bate, o modelo não carrega. Sem exceções, sem overrides, sem "mas é só para teste".

Um dos meus engenheiros resistiu com força a isso. "Você está adicionando atrito ao fluxo de desenvolvimento", ele disse. Ele estava certo. Adicionei atrito de propósito. Porque a alternativa — o caminho sem atrito, em que qualquer um pode carregar qualquer modelo de qualquer lugar — é assim que você acaba com um shell reverso para a Coreia rodando no seu servidor de inferência.

Monitoramento em Runtime: Porque Varreduras Estáticas Não Bastam

Aprendemos com a vulnerabilidade de templates do GGUF que a varredura estática cobre apenas parte da superfície de ameaça. Um modelo pode estar limpo no momento do carregamento e ser malicioso no momento da inferência. Então adicionamos monitoramento contínuo em runtime: validação das saídas contra baselines limpos para detectar drift, throttling de consultas para prevenir ataques de extração de modelo e camadas de sanitização de entrada que reformulam as consultas antes que elas cheguem ao modelo central, desarticulando payloads adversariais cuidadosamente elaborados.

Para a arquitetura técnica completa — incluindo nossa abordagem de computação confidencial com Ambientes de Execução Confiáveis baseados em hardware — veja o aprofundamento técnico em nosso artigo de pesquisa. Há ali um nível de detalhe de implementação que vai além do que consigo cobrir em um ensaio.

A Verdade Incômoda Sobre "Deep AI" vs. Wrappers de API

Há uma razão para eu sempre voltar à distinção entre o que chamo de "Deep AI" — sistemas de IA auto-hospedados, com fine-tuning e arquiteturalmente controlados — e a abordagem de wrapper de API que domina o mercado. Não é apenas uma preferência técnica. É um argumento de segurança.

Quando você encapsula uma API pública, você terceiriza sua cadeia de suprimentos de IA para outra pessoa. Você não tem visibilidade sobre a proveniência dos modelos dela, seus dados de treinamento, sua postura de segurança. Você está confiando que a OpenAI, a Anthropic ou o Google fizeram o trabalho duro de proteger o pipeline delas. Talvez tenham feito. Mas você não pode verificar, e, em segurança, confiança sem verificação é só esperança.

Quando você constrói em profundidade — quando você controla os pesos do modelo, o pipeline de treinamento, a infraestrutura de inferência —, você herda a responsabilidade por toda a cadeia de suprimentos. Isso é mais difícil. É mais caro. Exige o tipo de disciplina de engenharia que venho descrevendo. Mas é o único caminho para uma segurança verificável.

Um investidor certa vez me disse: "É só usar a API do GPT e focar no produto". Eu disse a ele que, para os setores que atendemos — onde um modelo comprometido pode significar vazamento de dados financeiros, diagnósticos médicos manipulados ou análises jurídicas corrompidas —, "é só usar a API" é um passivo, não uma estratégia.

Segurança de IA e Segurança de Software Agora São o Mesmo Problema

Aqui está o insight que cristalizou tudo para mim: segurança de IA e segurança da cadeia de suprimentos de software não são mais disciplinas separadas. Não podem ser. Modelos de IA não rodam isolados — eles são construídos e implantados pelos mesmos pipelines de CI/CD, registries de containers e árvores de dependências que o software tradicional usa.

Se o seu modelo está assinado criptograficamente, mas a biblioteca Python da qual ele depende foi comprometida por um ataque à cadeia de suprimentos, você foi invadido. Se o seu pipeline de treinamento roda em uma imagem de container contaminada, os pesos do seu modelo não são confiáveis, por mais limpos que sejam os seus dados de treinamento.

A indústria insiste em criar equipes separadas de "segurança de IA" e de "segurança de aplicações". Essa divisão organizacional é uma vulnerabilidade. A superfície de ataque é unificada, e a defesa também precisa ser.

À medida que o código gerado por IA acelera a velocidade de desenvolvimento, o tradicional processo humano de revisão de código está entrando em colapso sob o volume. Pull requests grandes, geradas por IA, são difíceis de revisar com cuidado sob pressão de prazo, criando uma cultura de "revisão superficial" que remove um dos últimos controles de segurança com humano no circuito. Nesse ambiente, a verificação automatizada e determinística — ancorada em assinaturas criptográficas e ML-BOMs — não é opcional. É a única coisa que escala.

"Mas Nós Não Somos um Alvo"

As pessoas sempre resistem com alguma versão disso. "Não fazemos nada sensível o suficiente para justificar esse nível de segurança." "Nossos modelos são só para ferramentas internas." "Ninguém se daria ao trabalho de envenenar um modelo para nos atacar."

Ouvi os mesmos argumentos sobre segurança de bibliotecas de código aberto em 2018. Aí veio o SolarWinds. Aí veio o Log4Shell. Aí veio o backdoor do XZ Utils — uma campanha de engenharia social de vários anos para comprometer uma única biblioteca de compressão usada pelo SSH em todos os servidores Linux do mundo.

A cadeia de suprimentos de IA está seguindo a mesma trajetória, só que mais rápido. A superfície de ataque é maior (os pesos dos modelos são blobs binários opacos que não podem ser auditados como o código-fonte pode), o ferramental é menos maduro (o PickleScan tem zero-days) e a lacuna de governança é maior (83% das empresas não têm controles automatizados).

Você não precisa ser um alvo para ser uma vítima. Basta estar no caminho.

Como É uma Segurança de IA Entediante

Meu objetivo — e isso pode soar estranho — é tornar a implantação de IA entediante. Não empolgante, não de ponta, não "mova-se rápido e quebre as coisas". Entediante. Previsível. Auditável.

Entediante significa que todo modelo tem uma ML-BOM. Entediante significa assinaturas criptográficas verificadas no momento do carregamento. Entediante significa nada de pickle, nunca. Entediante significa monitoramento em runtime que detecta drift antes que ele vire uma violação. Entediante significa um registro centralizado de ativos de IA em que cada modelo, conjunto de dados e dependência é rastreado, verificado e versionado.

Entediante significa que, quando alguém pergunta "quais modelos de IA estão rodando em produção?", você consegue responder em menos de cinco minutos, com prova criptográfica.

O objetivo não é tornar a implantação de IA empolgante. É torná-la entediante — previsível, auditável e segura. Segurança de IA empolgante significa que algo deu errado.

Os mais de 100 modelos maliciosos no Hugging Face não foram um incidente isolado. Foram o sintoma de uma indústria que construiu capacidades incríveis sobre uma fundação de confiança cega. Baixávamos modelos do jeito que costumávamos baixar MP3s do LimeWire — torcendo pelo melhor, ignorando os riscos óbvios e agindo com surpresa quando algo dava errado.

Essa era acabou. As organizações que sobreviverem à próxima onda de ataques à cadeia de suprimentos de IA serão aquelas que decidirem, agora mesmo, tratar seus modelos não como caixas mágicas, mas como código executável, com toda a superfície de ataque que isso implica. Aquelas que escolheram o entediante em vez do rápido. Aquelas que olharam para o terminal, viram o arquivo pickle carregando e disseram: "Espera. Que formato é esse?"