Nobody Forbade It. The Filter Refused Anyway.

Dezassete mil eventos, e a API disse que não

O momento que importa na divulgação da Hugging Face não é a intrusão. É um elemento da equipa de resposta sentado diante de uma API paga com as provas na mão e a ser recusado. A 16 de Julho de 2026 a empresa publicou o relato de um incidente de segurança no qual, diz, os atacantes usaram aquilo que descreve textualmente como "(a remote-code dataset loader and a template-injection in a dataset configuration)" para correr código num worker de processamento. O que a equipa tinha depois era, nas palavras da própria Hugging Face, "the full attacker action log, comprised of more than 17,000 recorded events". Noutro ponto, a publicação refere "tens of thousands of automated actions".

A recusa é a notícia, e a frase foi escrita pela própria Hugging Face. A publicação declara: "This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker." A última oração é a que suporta todo o peso. O sistema não estava a julgar a Hugging Face e a errar. Não tinha forma alguma de fazer esse julgamento.

Tudo o que fica acima assenta na palavra da Hugging Face, e queremos dizê-lo com clareza. Não temos fonte primária independente para nenhum dos factos do incidente. Nenhum órgão os corroborou; todo o relato que encontrámos limita-se a repetir a publicação da empresa. A Hugging Face não dá data de intrusão nem de detecção, apenas "Earlier this week" e "over a weekend". Não nomeia qualquer fornecedor. E declara o seu próprio trabalho por concluir: "We are still completing our assessment of whether any partner or customer data was affected." Este artigo não é cobertura do incidente. É uma leitura do que os contratos publicados dos fornecedores dizem de facto, confrontada com a conduta que a Hugging Face descreve.

Lemos as três políticas à procura da proibição

Não existe. Obtivemos as políticas de utilização publicadas da Anthropic, da OpenAI e da Google, e nenhuma das três proíbe analisar material hostil proveniente de uma violação do seu próprio sistema. Não é uma leitura de conveniência. Toda a proibição cibernética nos três documentos está delimitada por uma qualificação, e a conduta que a Hugging Face descreve cai fora de todas elas.

A política de utilização da Anthropic, em vigor desde 15 de Setembro de 2025, proíbe o trabalho destinado a "Discover or exploit vulnerabilities in systems, networks, or applications without authorization of the system owner", e proíbe separadamente os utilizadores de "Create or distribute malware, ransomware, or other types of malicious code". A Hugging Face era a proprietária do sistema, pelo que a primeira cláusula não a alcança. Analisava payloads que já existiam, não os criava nem os distribuía, pelo que a segunda também não. Não há excepção de investigação de segurança, resposta a incidentes ou defesa em lado algum do documento. O trabalho de jailbreak e injecção de prompts só é proibido "without prior authorization from Anthropic", o que contempla uma autorização mas não remete para qualquer processo publicado para a obter.

As políticas de utilização da OpenAI, em vigor desde 29 de Outubro de 2025, proíbem a "destruction, compromise, or breach of another's system or property, including malicious or abusive cyber activity". A qualificação está na palavra another's. O sistema em causa era o da própria Hugging Face. Não encontrámos excepção de investigação de segurança; o único crivo de revisão documentado diz respeito a "national security or intelligence purposes without our review and approval".

A Generative AI Prohibited Use Policy da Google, alterada pela última vez a 17 de Dezembro de 2024, diz: "Do not compromise the security of others' or Google's services. This includes generating or distributing content that facilitates: Spam, phishing, or malware." De novo é a qualificação que faz o trabalho. Submeter payloads capturados para análise não é gerá-los nem distribuí-los. Não há excepção de segurança, apenas uma cláusula geral de excepções: "We may make exceptions to these policies based on educational, documentary, scientific, or artistic considerations, or where harms are outweighed by substantial benefits to the public." Não está documentada qualquer via de pedido, contacto ou processo. As três políticas estavam em vigor antes do incidente.

O contrato do seu fornecedor não é o seu controlo

Esta é a frase que colocaríamos diante de um conselho de administração. A falha aqui não é o contrato e o classificador contradizerem-se. É o contrato nunca ter abordado a situação, enquanto o classificador se comportou como se ela fosse proibida. A equipa de resposta da Hugging Face, pelo seu próprio relato, embateu numa recusa por trabalho que nenhuma política publicada de qualquer dos três grandes fornecedores proíbe.

Um operador que tivesse feito a contratação correctamente teria caído na mesma. Leu a política de utilização. Não encontrou nada a vedar a análise defensiva da sua própria violação, porque ali não há nada a encontrar. Assinou. E depois quem o recusou foi o runtime, um objecto distinto do documento, governado por nenhuma condição que tenha negociado e descrito em nenhuma cláusula que tenha revisto. O que verificou e o que decide às três da manhã não são o mesmo sistema.

Estamos a descrever uma lacuna nos termos publicados, não a acusar ninguém de os violar. Tanto a Anthropic como a OpenAI permitem adaptação contratual, e os termos empresariais não públicos podem dizer algo bastante diferente das políticas públicas; não vimos esses termos e não nos podemos pronunciar sobre eles. Também não lhe podemos dizer porque ocorreram as recusas. A Hugging Face não publica transcrições de recusas, pelo que saber se os bloqueios foram ditados pela política ou por um sobre-bloqueio vulgar do classificador é incognoscível de fora, e não vamos adivinhar. A Hugging Face também não nomeia os fornecedores que bloquearam. Diz apenas: "we are sharing this feedback with the providers concerned."

O que a Hugging Face afirmou de facto, e o que não afirmou

A avaliação de danos da empresa é mais estreita do que uma leitura rápida sugere, e a precisão merece ser conservada. A Hugging Face reporta "no evidence of tampering with public, user-facing models, datasets, or Spaces, and our software supply chain (container images and published packages) was verified clean". São duas afirmações distintas. Nenhuma evidência de adulteração é uma ausência de achados. Verified clean é uma asserção positiva sobre a cadeia de fornecimento, e é a mais forte das duas. Fundi-las numa única tranquilização é precisamente o que torna um resumo de incidente menos rigoroso do que a divulgação que resume.

O atacante estava ele próprio automatizado, e esse detalhe torna o problema de volume estrutural em vez de fortuito. A Hugging Face descreve a campanha textualmente como "run by an autonomous agent framework (appearing to be built on an agentic security-research harness - used LLM still not known)". Um agente a gerar dezenas de milhares de acções deixa um registo que uma equipa humana não consegue ler ao ritmo necessário, que é exactamente por isso que a equipa de resposta queria pôr um modelo em cima, e exactamente onde foi bloqueada. A única instrução operacional da publicação é breve: "we recommend rotating any access tokens and reviewing recent activity on your account."

E a Hugging Face antecipou-se ao argumento que alguns leitores quererão extrair disto, pelo que o citamos em vez de o contornar. A publicação declara: "This is not an argument against safety measures on hosted models". Concordamos, e este artigo não é esse argumento. Barreiras que não distinguem um responsável de resposta de um atacante continuam a fazer trabalho real contra o atacante. O achado aqui é sobre o que os termos publicados omitem e sobre o que um operador deve por isso testar, não sobre se os filtros devem existir.

Teste a recusa antes que o incidente o teste a si

Marque o exercício neste trimestre. Retire material hostil real dos seus próprios registos, submeta-o à API a que recorreria de facto durante um incidente, e escreva o que volta. O achado que quer não é tranquilidade. É uma resposta factual a uma pergunta que nenhum contrato lhe responderá, obtida num dia em que nada está a arder.

Para um operador da UE o relógio torna isto concreto em vez de teórico. Os deveres de notificação da NIS2 correm sobre um alerta precoce de 24 horas e uma notificação de 72 horas, e o DORA impõe às entidades financeiras a sua própria janela apertada de notificação inicial. Esses prazos pressupõem que consegue caracterizar o que aconteceu. Se a sua via de análise encrava à terceira hora porque um filtro não aceita as suas próprias provas, o relógio não pára enquanto o descobre. É esta a diferença entre descobri-lo num exercício de simulação e descobri-lo dentro de uma janela regulatória.

Depois, mantenha a via que não pode ser recusada. O recurso da Hugging Face, nas suas palavras: "We ran the forensic analysis instead on GLM 5.2, an open-weight model, on our own infrastructure." O GLM 5.2 vem da Z.ai, antes Zhipu, em Pequim; a própria Hugging Face não caracteriza a origem do modelo, e essa identificação é nossa, não dela. A origem não é o ponto. Pesos que possui, a correr em hardware que controla, é a única configuração em que o runtime de um terceiro não tem voto sobre se o seu incidente é analisado. Todo o operador devia saber hoje se tem uma via dessas e se ela funciona.

Leia a seguir: Dois gigantes da IA querem ser o seu integrador  |  As suas sementes MFA saíram antes da correção