Agentic attacker. Ce que l'incident HuggingFace nous apprend sur les risques des agents IA en entreprise

Il y a quelques jours, Hugging Face a repéré une activité inhabituelle sur une partie de son infrastructure de production.

En remontant le fil, ses équipes ont découvert une attaque menée presque entièrement par un système d'agents IA : des milliers d'actions, des déplacements entre environnements, des identifiants récupérés et des machines compromises. L'ensemble semblait avoir été exécuté de manière autonome. Hugging Face savait qu'un agent était à l'œuvre, mais ignorait encore quel modèle le pilotait et qui avait lancé l'opération.

Le 16 juillet, l'entreprise publie un premier rapport. Elle explique avoir stoppé l'attaque, puis analysé plus de 17 000 événements avec ses propres agents IA. Pour reconstituer l'incident, elle utilise notamment GLM 5.2, un modèle open weight exécuté sur son infrastructure. Hugging Face avait d'abord essayé des modèles commerciaux, mais ceux-ci bloquaient certaines requêtes. Les logs contenaient de véritables commandes d'attaque et des exploits, que leurs systèmes de sécurité interprétaient comme des demandes malveillantes.

À ce stade, l'origine de l'attaque restait inconnue. Le 21 juillet, OpenAI publie à son tour un rapport et contacte Hugging Face. L'incident prend alors une tournure inattendue : les agents utilisaient une combinaison de modèles qu'OpenAI évaluait, dont GPT-5.6 Sol et un modèle interne plus performant.

Le modèle est sorti du cadre du test

OpenAI testait ces modèles sur ExploitGym, un benchmark consacré aux capacités en cybersécurité. Les modèles devaient résoudre des scénarios d'exploitation complexes dans un environnement très isolé, sans accès normal à Internet. OpenAI avait aussi réduit certaines protections contre les usages cyber offensifs afin de mesurer leurs capacités maximales.
Les agents ne se sont pas limités au terrain prévu pour l'évaluation. Ils ont cherché un autre moyen d'obtenir les réponses.
Ils ont d'abord consacré beaucoup de calcul à la recherche d'une sortie de leur environnement isolé. Ils ont découvert une vulnérabilité zero-day, jusque-là inconnue, dans un logiciel utilisé comme proxy pour installer des packages. Les modèles ont exploité la faille, élevé leurs privilèges et circulé entre plusieurs machines de l'environnement de recherche d'OpenAI. Ils ont fini par atteindre une machine connectée à Internet. Ils ont alors déduit que Hugging Face pouvait héberger des modèles, des jeux de données ou les solutions d'ExploitGym. Ils se sont rendus sur la plateforme et ont poursuivi l'attaque. En combinant plusieurs vulnérabilités, des identifiants dérobés et un chemin d'exécution de code à distance, ils ont accédé à des informations présentes dans l'infrastructure de production de Hugging Face.

Des modèles évalués sur un benchmark cyber ont donc réussi à sortir de leur bac à sable, à exploiter une faille inconnue, à obtenir un accès à Internet, puis à compromettre une entreprise extérieure pour améliorer leur résultat.

Un point important : OpenAI avait volontairement placé les modèles dans une évaluation offensive et réduit certains refus de sécurité. Il ne s'agit pas d'un assistant grand public qui aurait spontanément décidé d'attaquer une entreprise.

Le cadre expérimental n'enlève toutefois rien au principal enseignement. Des capacités longtemps décrites comme théoriques ont fonctionné dans un environnement réel : poursuivre un objectif pendant une longue séquence d'actions, découvrir une faille inconnue, combiner plusieurs techniques d'attaque, contourner des obstacles et agir sur une infrastructure qui ne faisait pas partie du test.

Les défenseurs auront eux aussi besoin de modèles puissants

Hugging Face a utilisé l'IA à deux étapes de l'incident : pour détecter l'attaque, puis pour comprendre son déroulement. Selon l'entreprise, ses agents basés sur GLM 5.2 ont analysé plus de 17 000 événements en quelques heures. Une équipe humaine aurait pu consacrer plusieurs jours au même travail.

Cette attaque révèle une nouvelle asymétrie. Des attaquants peuvent lancer des modèles puissants, peu ou pas restreints, capables d'exécuter des milliers d'actions à la vitesse d'une machine. Les défenseurs, eux, risquent de se heurter aux garde-fous de leurs propres outils. Ils peuvent également devoir transmettre des journaux, des identifiants compromis et d'autres données sensibles à des API externes. Hugging Face a choisi un modèle open weight hébergé en interne. Cette solution lui permettait d'éviter les blocages tout en conservant les données de l'incident dans son propre environnement.

Cette question concerne déjà les équipes de cybersécurité, mais elle touchera aussi les États, les infrastructures critiques et un nombre croissant d'entreprises. Celles-ci devront se demander si elles disposent des outils nécessaires pour affronter des attaquants humains assistés par des systèmes autonomes.

Le modèle n'a pas besoin de « vouloir » tricher

Dire que le modèle a voulu tricher serait lui prêter une intention morale comparable à celle d'un humain. Rien ne permet de l'affirmer. Il avait reçu un objectif : réussir l'évaluation. Il a trouvé une stratégie efficace pour y parvenir, même si cette stratégie dépassait largement ce qu'OpenAI avait prévu ou souhaité. Ce comportement se rapproche de plusieurs notions connues dans la recherche en IA : le specification gaming, le reward hacking et la convergence instrumentale (pour en savoir plus). On donne au système un résultat à atteindre. Celui-ci découvre qu'une action imprévue améliore ses chances de réussite et l'utilise comme un moyen au service de son objectif. L'expérience de pensée du « maximiseur de trombones » illustre une version extrême du même problème : un système très capable optimise une consigne apparemment simple d'une façon que ses concepteurs n'avaient pas anticipée.

Dans le cas d'ExploitGym, chaque étape servait directement l'objectif initial. L'accès à Internet facilitait la recherche des solutions. Les données de Hugging Face pouvaient contenir ces solutions. L'exploitation de vulnérabilités permettait d'atteindre ces données. Un système n'a donc pas besoin d'être malveillant pour devenir dangereux. Il suffit qu'il soit capable, autonome, trop libre d'agir et chargé d'un objectif mal défini.

Le risque existe aussi à l'intérieur des entreprises

L'IA va accélérer les cyberattaques existantes. Les attaquants pourront viser davantage de cibles, agir plus vite et combiner un nombre croissant de vulnérabilités. Mais les entreprises devront aussi surveiller les agents qu'elles installent dans leurs propres systèmes. Elles commencent à déployer des assistants capables de consulter des documents, d'utiliser des outils, d'accéder au système d'information, d'envoyer des messages ou de modifier des dossiers. Tant que ces assistants s'arrêtent lorsqu'une autorisation leur manque, le risque reste relativement facile à encadrer. Un agent plus autonome peut réagir autrement.

Prenons un assistant chargé de traiter des dossiers de sinistres. On lui demande de clôturer rapidement un dossier, mais un document nécessaire lui est inaccessible.
Un assistant classique signale le blocage et demande l'intervention d'un humain. Un système plus autonome peut continuer à chercher. Il peut essayer une autre API, utiliser les droits d'un service voisin, exploiter une mauvaise configuration ou récupérer un jeton trouvé dans un log. Personne ne lui a demandé de pirater le système d'information. On lui a demandé de terminer le dossier. Si ses limites techniques sont insuffisantes, il peut traiter tout obstacle comme un problème à résoudre.

Ce scénario paraît encore extrême pour un assistant métier ordinaire. L'incident entre OpenAI et Hugging Face montre cependant que le mécanisme général fonctionne déjà dans certaines conditions.

Un prompt demandant à l'agent de « bien se comporter » ne suffit pas. Les entreprises devront limiter ses droits, isoler ses environnements et contrôler les outils auxquels il peut accéder. Les opérations sensibles devront passer par une validation humaine. Chaque action devra être journalisée, et les tests devront vérifier ce que fait l'agent lorsqu'il rencontre un obstacle.

J'avais détaillé ces fondations dans un précédent article sur ce que les agents IA changent pour le SI des assureurs : identités non humaines, droits restreints, traçabilité, couches d'accès documentées et supervision humaine.

Développer des agents utiles ne suffit plus. Il faut pouvoir les gouverner et garantir qu'ils ne dépasseront pas leur mandat, y compris lorsqu'ils trouvent une méthode ingénieuse pour atteindre leur objectif.

Cet incident ne justifie pas l'arrêt du développement des agents. Il révèle plutôt le décalage entre leurs capacités et les dispositifs de sécurité qui les entourent.

Quand nous confions un objectif à un système autonome, nous devons vérifier s'il peut l'atteindre, mais aussi quels moyens il est autorisé à employer.