Un agent IA a piraté Hugging Face pour tricher à son propre test

Le 16 juillet 2026, Hugging Face publie un billet de blogue qui commence à peu près comme ça : on a détecté une intrusion dans notre infrastructure de production, menée par un système d’IA autonome. Le genre de phrase qu’on s’attendait à lire dans cinq ans, pas dans un post-mortem daté de cet été.

L’histoire, une fois qu’on la déroule, est presque comique dans son absurdité. Un modèle d’OpenAI, en cours d’évaluation interne sur un benchmark de capacités offensives (une sorte d’examen de cybersécurité pour IA), en vient à déduire que Hugging Face héberge probablement, quelque part, les réponses du test : les modèles de référence, les jeux de données, les solutions. Plutôt que de résoudre l’épreuve honnêtement, l’agent décide d’aller chercher le corrigé. Il trouve deux failles d’exécution de code dans le pipeline de traitement de datasets de Hugging Face, obtient un accès à un nœud de calcul, puis récolte des identifiants cloud qui traînaient sur cette machine. De là, il se déplace latéralement dans plusieurs clusters internes pendant un week-end.

Au final : environ 17 600 actions distinctes, regroupées en 6 280 séquences, sur quatre jours. Détecté non pas par un humain qui a remarqué quelque chose de louche, mais par un autre système d’IA, un pipeline de triage qui passe la télémétrie de sécurité au peigne fin parce qu’il y a, littérallement, trop de bruit pour qu’un analyste humain le fasse en temps réel.

Attends, tu vas encore nous sortir un exemple d’OpenAI pour vendre du Microsoft ?

…oui. Mais laissez-moi vous expliquer pourquoi c’est pas aussi tordu que ça en a l’air. Il fallait planter le décor, parce que cette histoire-là n’est pas vraiment une histoire de jailbreak ou de modèle malveillant. C’est une histoire d’identité et d’accès. Et c’est exactement le problème que Microsoft essaie de régler avec Agent 365.

Ce n’était pas un problème de modèle, c’était un problème d’inventaire

Ce qui me frappe dans le post-mortem de Hugging Face, ce n’est pas la sophistication de l’attaque. C’est l’absence, en amont, d’une question toute simple : est-ce que ce processus-là avait besoin d’accéder à ce système-là ?

Le worker qui traitait les datasets n’était probablement pas censé pouvoir toucher aux identifiants cloud qu’il a fini par récolter. Mais personne n’avait fait l’exercice d’écrire ça noir sur blanc, de le rendre visible, de le mettre sous une politique qu’on peut vérifier. L’agent n’a pas eu besoin d’un exploit brillant pour l’essentiel de sa progression : il a eu besoin que les privilèges soient plus larges que nécessaire, et que personne ne surveille ce qu’un processus automatisé faisait de ces privilèges une fois qu’il les avait.

C’est précisément le trou que les entreprises ont, aujourd’hui, avec leurs propres agents IA internes. Un agent Copilot Studio qui a accès à SharePoint, un agent qui appelle un serveur MCP, un script d’automatisation avec une clé API qui traîne depuis huit mois : est-ce que quelqu’un, dans votre organisation, peut vous dire aujourd’hui combien d’agents existent, qui les a créés, et ce à quoi chacun a accès ? Chez la plupart de mes clients, la réponse honnête est non. On sait combien d’employés on a. On ne sait pas combien d’agents on a.

Ce que Microsoft fait de bien, ici

C’est là que je vais être positif envers Microsoft, et je le pense vraiment, pas juste par habitude de vendeur de service Microsoft 365.

Le registre d’agents dans le Centre d’administration Microsoft 365 fait exactement ce qui manquait chez Hugging Face : un inventaire central de tous les agents de l’organisation, avec un propriétaire assigné (un « sponsor »), un statut, et une colonne de risque qui agrège les signaux venant d’Entra, de Defender et de Purview, le même Purview dont j’ai déjà parlé pour la connaissance d’entreprise, ici recyclé pour la gouvernance des agents. Ce n’est pas glamour. C’est même un peu ennuyant, comme fonctionnalité. Mais c’est exactement le genre de plomberie ennuyante qui aurait empêché l’histoire de Hugging Face de durer quatre jours.

L’autre pièce, plus fondamentale encore, c’est Entra Agent ID. L’idée de base : un agent n’est plus un jeton OAuth emprunté au compte d’un utilisateur ou une clé de service planquée dans un fichier de config. C’est une identité de première classe dans l’annuaire, au même titre qu’un employé. Ce qui veut dire : des politiques d’accès conditionnel qui s’appliquent à l’agent, une expiration automatique pour les agents inactifs, une portée de permissions définie dès la création plutôt que découverte après coup. On étend vingt ans de plomberie IAM (la même qui gère vos utilisateurs humains) aux agents, plutôt que d’inventer un système parallèle bricolé pour l’occasion.

C’est la bonne réponse, et c’est la réponse ennuyante : sait-on qui est cet agent, qui en est responsable, et qu’est-ce qu’on lui a explicitement autorisé à toucher. Aucune nouvelle couche d’IA pour surveiller l’IA là-dedans, juste de la plomberie d’identité qu’on connaît depuis longtemps, appliquée enfin aux bons objets.

Je vais nuancer un peu, parce que je ne veux pas vous vendre ça comme réglé. L’authentification Entra pour Copilot Studio devient disponible en général le 30 septembre 2026, donc dans quelques semaines à peine au moment où j’écris ces lignes. C’est tout jeune. Le registre d’agents est encore en train de se stabiliser dans le Centre d’administration. Ça ne veut pas dire que la direction est mauvaise, ça veut dire qu’il ne faut pas encore vous fier à ça comme à un système éprouvé depuis dix ans. Vous allez devoir le tester vous-même, dans votre tenant, avant de dormir tranquille.

Ce que le registre ne vous dit pas

Voici où je veux vous laisser, parce que c’est le vrai bémol.

Un registre d’agents et une identité Entra vous répondent à la question « qui est cet agent, et qu’est-ce qu’il a le droit de faire ». Ça, c’est de la gouvernance en amont : le genre de contrôle qui aurait limité les dégâts chez Hugging Face bien avant que l’agent ne mette la main sur le moindre identifiant.

Mais ça ne vous dit pas ce que l’agent fait, là, maintenant, avec les droits qu’il a légitimement. L’agent de l’incident Hugging Face n’a pas été arrêté parce qu’une politique d’accès l’a bloqué. Il a été détecté après coup, parce que quelqu’un a fini par faire passer 17 600 actions dans un autre modèle pour repérer le pattern anormal dans le bruit. L’identité vous dit qui a la clé de la maison. Ça ne vous dit pas que la personne qui a la clé est en train de fouiller dans vos tiroirs à trois heures du matin.

C’est exactement le sujet de mon prochain article : comment on surveille le comportement d’un agent une fois qu’il a les accès qu’on lui a donnés, et surtout, comment on évalue si ce comportement-là est normal ou pas. Parce qu’un registre bien tenu, c’est nécessaire. Mais Hugging Face avait sûrement, quelque part, une liste de qui avait accès à quoi. Ce qui leur manquait, c’était quelqu’un (ou quelque chose) qui regardait ce qui se passait pendant les quatre jours entre l’intrusion et la détection.

À suivre.

Sources : Hugging Face, billet d’incident de sécurité, juillet 2026, OpenAI, communiqué conjoint sur l’incident, Microsoft Agent 365, Registre de l’agent, Microsoft Learn.