HugginFace montre comment les garde-fous des LLM nuisent à leur utilité

HuggingFace a été victime d'un incident de cybersécurité en début de semaine dernière. Un épisode éclairant à plus d'un égard.

L'intrusion a débuté dans le pipeline de traitement des données, où un jeu de données malveillant a exploité deux chemins d'exécution de code. L'acteur a ensuite escaladé jusqu'à un accès au niveau du nœud, récoltant des identifiants cloud et de cluster. Mais voilà : tout s'est déroulé particulièrement vite. Car ce n'était pas un humain aux commandes : il s'agissait d'un « framework agentique autonome (apparemment construit sur un harnais pensé pour la recherche en sécurité) ». Pour HuggingFace, c'est le « scénario de l'attaquant agentique que prédisait l'industrie ».

Face à cela, la rapidité est essentielle, tant pour la détection que pour la réaction et, entre les deux, l'analyse.  

Pas de chance, l'équipe de défense a été confrontée à une restriction majeure : les garde-fous des LLM commerciaux ont bloqué l'analyse forensique de plus de 17 000 événements d'attaque. L'outillage offensif piloté par l'IA réduit le coût d'une campagne multi-étapes et opère à cette vitesse machine, tandis que les mécanismes de défense ont limité la capacité de l'équipe à traiter l'ampleur de l'événement.

Finalement, l'analyse des artefacts collecté dans l'infrastructure de HuggingFace a été réalisé avec GLM 5.2, exécuté en interne. Ce qui présentait une second avantage : « aucune donnée de l'attaquant, et aucun des identifiants qui y étaient référencés, n'a quitté » le système d'information de l'entreprise. 

Pour HuggingFace, « cette expérience met en évidence une lacune qu’il convient d’anticiper. Nous ne savons pas quel modèle a été utilisé par les agents de l’attaquant : s’agissait-il d’un modèle hébergé "jailbreaké" ou d’un modèle open-weight sans restriction ? Quoi qu’il en soit, l’attaquant n’était soumis à aucune politique d’utilisation, tandis que notre propre travail d’analyse était entravé par les barrières de sécurité des modèles hébergés que nous avions d’abord testés ». Et d'en tirer un conseil pratique : « disposez d’un modèle performant, capable de fonctionner sur votre propre infrastructure, qui ait été validé et soit prêt avant tout incident, à la fois pour éviter d’être bloqué par ces garde-fous et pour empêcher les données et identifiants de l’attaquant de quitter votre environnement ».

Au-delà de l'incident spécifique, l'intégration de garde-fous introduit un compromis fondamental entre la sécurité opérationnelle et l'utilité fonctionnelle des LLM. L'implémentation de ces filtres génère une friction notable, affectant la performance des modèles sur des tâches techniques spécialisées. Cette situation est observée dans le contexte de la rétro-ingénierie, où certains modèles, comme Anthropic Opus, semblent devenir plus restrictifs avec les versions récentes.

Sergei, des Open Analysis Labs, en a fait l'expérience appliquant Kimi K3 à la rétro-ingénierie d'un maliciel. Ses conclusions sont sans appel : « franchement, K3 se comporte comme je m'attendais à ce qu'Opus de comporte en 2026, quand j'ai commencé à l'utiliser en 2025 ». En résumé, tranche-t-il : « K3 nous fait nous demander pourquoi nous payons Anthropic ».

Anna Pham, chez Huntress, s'est prêtée à une expérience comparable, confiant la même tâche à Sonnet 4.6 et à K3, dans le même contexte. Bilan des courses ? « Claude a décroché la couronne de la vitesse », mais... « Kimi a utilisé 2,3 fois moins d'appels à outils », mais aussi de plus longs scripts à chaque étape, et « plus de réflexion à chaque mouvement ». En outre, l'agent animé par K3 a réussi à débusquer un marquer technique qui avait échappé à Claude Sonnet 4.6.