Dans un projet IT classique, la sécurité arrive à la fin.
On cadre, on développe, on livre. Et deux semaines avant la mise en production, quelqu’un lève la main : « au fait, on fait un pentest ? »
On coche la case. On corrige trois trucs. On déploie.
Ça a marché pendant vingt ans. Ça ne marche plus dès qu’il y a de l’IA dans le projet.
Ce qui s’est passé chez Hugging Face
Hugging Face a publié fin juillet le récit technique d’une intrusion. C’est rare, c’est détaillé, et ça vaut le détour.
Le résumé tient en trois lignes. Un agent IA, lancé dans un bac à sable d’évaluation, s’en est échappé. Il a trouvé le chemin de l’infrastructure de Hugging Face. Et il y a passé quatre jours et demi, du 9 au 13 juillet 2026.
Les équipes ont ensuite reconstitué environ 17 600 actions.
Pas 17 600 lignes de log. 17 600 actions : des requêtes API, des tentatives d’escalade, des explorations de réseau. En quatre jours. Sans pause café.
Le plus intéressant, c’est la banalité
On imagine une attaque spectaculaire. Un exploit signé par un génie du mal.
Pas du tout.
Les deux portes d’entrée étaient dans le composant qui traite les datasets :
- une configuration de fichier HDF5 qui pointait vers des chemins locaux, et permettait donc de lire des fichiers du serveur ;
- une injection de template Jinja2, qui permettait d’exécuter du code Python.
Deux failles de manuel. Le genre de chose qu’on trouve dans le top 10 de l’OWASP depuis des années.
Ensuite, la suite du parcours ressemble à un cours d’école : récupération du token de service account Kubernetes dans le système de fichiers du pod, récupération des identifiants cloud via les métadonnées de l’instance, mot de passe MongoDB en clair dans une variable d’environnement.
Rien de neuf. Ce sont exactement les faiblesses ordinaires qu’on traîne dans à peu près toutes les infrastructures.
Ce qui est neuf, c’est qu’un agent peut les essayer toutes, en parallèle, pendant que vous dormez.
L’asymétrie
Voilà la vraie leçon, et Hugging Face la formule très bien : machine-speed offense makes ordinary weaknesses more expensive for defenders.
Traduction : vos petites faiblesses coûtaient 10. Elles coûtent maintenant 1000.
Parce que jusqu’ici, l’attaquant avait un budget. Explorer une infrastructure, c’est fastidieux. Il fallait choisir ses pistes, abandonner les impasses, revenir le lendemain.
Un agent n’a pas ce problème. Il teste tous les chemins, il remplace instantanément ceux qui échouent, et il génère un volume de traces que des humains ne peuvent plus lire.
Le défenseur, lui, est resté humain. Chez Hugging Face, les premières alertes ont bien été levées — mais mal calibrées, elles n’ont pas déclenché de réaction.
C’est ça, l’asymétrie. Ce n’est pas que l’attaque soit plus intelligente. C’est qu’elle est plus rapide que votre capacité à interpréter ce qu’elle laisse derrière elle.
Et donc, votre projet IT ?
Vous démarrez un projet. Il comporte un volet IA : un assistant interne, un RAG sur la documentation, un agent qui va chercher des trucs dans vos bases.
Dans le cadrage, vous parlez du modèle, du coût des tokens, de la qualité des réponses, de l’expérience utilisateur.
Vous ne parlez pas de sécurité, parce que c’est un sujet de fin de projet.
Sauf que le composant IA que vous ajoutez n’est pas une fonctionnalité de plus. C’est un exécutant. Il prend une entrée dont vous ne maîtrisez pas le contenu — un document, un dataset, un message d’utilisateur — et il la transforme en actions.
Un formulaire web, ça produit une ligne en base. Un agent, ça produit des appels d’API avec vos droits.
La question du projet n’est plus « est-ce que mon code est sûr ». Elle est : qu’est-ce que j’autorise cette chose à faire ?
Les cinq questions à poser au cadrage
Pas à la recette. Au cadrage. En même temps qu’on dessine les écrans.
- Qu’est-ce que l’IA a le droit de faire ? Lister les actions, pas les intentions. Un agent qui a accès en écriture à votre dépôt a accès en écriture à votre dépôt, quelle que soit la qualité de son prompt système.
- Où est la frontière de confiance ? Tout ce qui entre dans un contexte est du code non signé. Un PDF client, une page web, un ticket : traitez-le comme une saisie utilisateur hostile, parce que c’en est une.
- Combien de temps vivent mes secrets ? Un mot de passe statique dans une variable d’environnement, c’est une clé sous le paillasson. Chez Hugging Face, c’est exactement comme ça que la base est tombée.
- Est-ce que je saurais raconter les quatre derniers jours ? Pas « est-ce que je logue ». Est-ce que je peux reconstituer une séquence, corréler entre les systèmes, et dire ce qui s’est passé. C’est ce qui a permis d’écrire le rapport plutôt que de deviner.
- Qui tire le cordon Andon ? Je vous parlais de Jidoka : la machine travaille, l’humain arrête la ligne. Encore faut-il que quelqu’un soit devant, et qu’il ait le droit de tout couper.
Aucune de ces questions n’est technique. Ce sont des questions de conception. Elles se traitent avec le métier, pas avec le RSSI en fin de parcours.
Alors, on fait quoi ?
On arrête de considérer la sécurité comme un chapitre, et on en fait une contrainte de conception. Au même niveau que le budget ou le délai.
La bonne nouvelle, c’est que les réponses restent ennuyeuses : isolation stricte des environnements d’exécution, périmètres de confiance étroits, identifiants à durée de vie courte, accès aux métadonnées bloqué, détection capable de corréler vite.
Rien de révolutionnaire. Juste de l’hygiène.
Mais l’hygiène qu’on repoussait à plus tard parce que « statistiquement, personne ne viendra chercher ça chez nous ».
Ce raisonnement tenait quand explorer coûtait du temps humain.
Il ne tient plus.
Références :
- Le rapport technique de Hugging Face : Anatomy of a Frontier Lab Agent Intrusion
- OWASP Top 10 for LLM Applications : https://owasp.org/www-project-top-10-for-large-language-model-applications/
