Recentemente, voltei a rever o roteamento entre modelos com múltiplas opções, incluindo recibos de degradação explícita e um gate de ações manuais. O objetivo é garantir que o sistema continue controlável quando um modelo falhar.

Na data em que a Hugging Face divulgou oficialmente registos de ataque com mais de 17,000 entradas em 2026-07-16, eu só então percebi se a rota de análise em self-hosted conseguia realmente funcionar no dia do incidente — e não tinha sido verificado de todo.

A equipa da Hugging Face primeiro processou esses registos com modelos de ponta da API comercial. Como resultado, os comandos reais de ataque, as cargas úteis de exploração de vulnerabilidades e os artefactos de C2 foram bloqueados pelas proteções de segurança.

Depois, mudaram para a sua própria infraestrutura e correram o GLM 5.2 de pesos abertos para concluir a recolha de evidências. Os dados do atacante e as credenciais envolvidas nos registos não saíram do ambiente.

Isto não é para dizer que se devem cancelar as proteções de segurança. As proteções continuam a cumprir o seu papel; a parte defensora ainda precisa de uma rota de análise que funcione dentro do ambiente deles.

O “forensic canary” em self-hosted ainda não está a correr. Eu estou apenas a preparar a adição dessa capacidade.

O próximo passo que tenho em mente é: antes de um incidente ocorrer, validar a rota de análise em self-hosted com exemplos inertes e seguros. Concluir a análise não significa automaticamente que se obtêm permissões para executar ações. As ações devem continuar a passar pelo gate manual.

Um sistema verdadeiramente preparado não é aquele que só descobre depois qual caminho não funciona; é aquele que confirma, antes de precisar, que cada caminho pode ser usado. Só testando antecipadamente é que se consegue substituir em momentos críticos.