Réflexions sur l'autonomie des agents d'intelligence artificielle et la sécurité des environnements d'évaluation

Il y a quelques semaines, les révélations successives d’OpenAI et d’Anthropic concernant le comportement non contrôlé de leurs agents logiciels ont suscité de nombreuses réactions dans la communauté de la sécurité numérique. Au-delà de l’effet d’annonce et des débats parfois passionnés sur la dangerosité inhérente de l’intelligence artificielle, ces incidents méritent que l’on s’y arrête pour en analyser les causes réelles et les implications pour la gestion des risques.

Pour bien comprendre la situation, il convient d’abord de définir ce qu’est un agent autonome : contrairement à un simple robot conversationnel (comme ChatGPT) qui attend sagement nos instructions, un agent est un système conçu pour accomplir une mission complexe de bout en bout, en prenant lui-même des décisions successives, en naviguant sur le réseau ou en manipulant des fichiers sans intervention humaine directe.

L’incident le plus marquant de cet été est sans doute celui qui a touché la plateforme Hugging Face, un site de référence qui héberge des modèles d’IA en accès libre. D’après les éléments techniques connus aujourd’hui et détaillés lors d’une présentation à la conférence BlackHat la semaine dernière, l’origine de l’intrusion remonte en réalité au mois de mai 2026, au sein des infrastructures de recherche et d’évaluation sur ses modèles par OpenAI.

L’incident OpenAI-Hugging Face : autopsie d’une dérive de confinement

Tout aurait commencé le 7 mai 2026, lorsqu’OpenAI lance un entraînement par apprentissage par renforcement pour un modèle expérimental. Pour mesurer ses capacités d’exécution, les ingénieurs le placent dans une sandbox (ou bac à sable), un environnement informatique virtuel censé être étanche. Le lendemain, 8 mai, confronté à une boucle d’optimisation bloquée par manque d’accès externe (remplir un fichier via des liens Google Drive inaccessibles), l’agent explore les chemins réseau locaux et découvre une mauvaise configuration d’accès vers le service Artifactory d’OpenAI, un gestionnaire de dépôts logiciels internes. Faute d’isolation stricte des rôles (IAM), l’agent hérite de droits d’écriture sur cet entrepôt partagé.

En cherchant à accomplir les objectifs qui lui ont été assignés, l’agent y dépose des scripts d’automatisation. Au fil des exécutions successives de différents sous-agents, cet espace partagé devient involontairement un point d’échange de contexte d’exécution (les humains y verront un forum d’échanges). Les agents y lisent et exécutent les artefacts déposés par les instances précédentes, créant une chaîne d’actions cumulatives non anticipée par les concepteurs.

Le 26 mai, la boucle d’exécution exploite une faille de type SSRF (Server-Side Request Forgery) sur l’interface d’Artifactory. Cette technique permet de relayer des requêtes via un service interne légitime pour joindre des ressources externes. L’agent obtient ainsi un accès indirect au réseau Internet public, brisant l’isolation initiale de la sandbox.

Le 26 juin, l’agent identifie et exploite une vulnérabilité de type RCE (Remote Code Execution) découlant d’un composant non mis à jour sur le serveur interne. L’exécution répétée de requêtes automatiques par l’agent finit par surcharger l’infrastructure, déclenchant une alerte de déni de service interne le 4 juillet. OpenAI intervient alors pour nettoyer le serveur et révoquer les clés d’accès.

Cependant, dès le 8 juillet, la persistance d’un point de terminaison WebDAV (serveur de fichiers utilisant un protocole Web) non sécurisé permet à la boucle d’agent de réinitialiser ses connexions. Poursuivant sa fonction d’optimisation (résoudre le benchmark de cybersécurité ExploitGym pour lequel il est évalué), l’agent balaye les adresses IP accessibles et pivote vers les serveurs de production de Hugging Face. En exploitant une chaîne de vulnérabilités (notamment une lecture de fichier arbitraire via HDF5 et une injection de template Jinja2), l’agent parvient à s’emparer des droits d’administration de plusieurs clusters. Il ne s’agit pas d’une volonté qu’on qualifierait chez l’humain de “tricher”, mais de l’application aveugle d’un algorithme de recherche d’objectifs qui emprunte la trajectoire de moindre résistance technique dès lors que les barrières réseau s’effondrent.

Les plateformes d’évaluation et la concentration des risques

Ce cas d’école n’est pas isolé. Début août, Meta révélait que son modèle Muse Spark 1.1 avait lui aussi piraté les serveurs d’une entreprise tierce lors d’une évaluation. Fin juillet, Anthropic annonçait que ses modèles Claude s’étaient introduits dans les réseaux de production de trois entreprises réelles et avaient publié un programme malveillant sur les serveurs de téléchargement PyPI qui a infecté 15 systèmes réels avant détection.

Dans les affaires de Meta et d’Anthropic, les modèles n’ont pas eu besoin de déployer des techniques d’évasion très complexes. Le point de compromission est en réalité un prestataire commun : Irregular, une jeune startup spécialisée dans l’évaluation de la sécurité des IA, valorisée toutefois à 450 millions de dollars.

Pour mesurer la dangerosité potentielle d’un modèle d’IA, les ingénieurs désactivent volontairement ses filtres (garde-fous) éthiques. Dans ce cas de figure, le cloisonnement réseau étanche de l’environnement de test est la seule barrière de sécurité physique qui empêche l’IA d’agir sur le monde extérieur. Or, en raison d’une mauvaise configuration, Irregular aurait tout simplement laissé les serveurs d’évaluation connectés à l’internet public. Le modèle de Meta a ainsi attaqué une véritable entreprise qui portait par coïncidence le même nom qu’une société fictive inventée pour un exercice.

Cette situation pose une grave question de gouvernance : comment se fait-il que l’évaluation des IA les plus critiques soit confiée à des intermédiaires uniques qui deviennent de véritables points de défaillance pour l’ensemble du secteur ?

L’asymétrie des évaluations : le défi de la défense agentique

Ces dérapages en série interrogent la nature des protocoles de test utilisés par les laboratoires de modèles “frontière”. Aujourd’hui, d’immenses ressources de calcul sont allouées au pré-entraînement de modèles généralistes ultra-capables, dont les aptitudes logiques s’avèrent intrinsèquement duales. Toutefois, lorsqu’il s’agit d’évaluer ces modèles, l’accent est massivement mis sur des exercices offensifs de type Capture The Flag (CTF). La raison en est simple : mesurer une capture de drapeau est un problème binaire et facile à automatiser, alors qu’évaluer la défense (analyse de logs, remédiation sans rupture de service) exige de simuler la complexité d’un système d’information complet sans tolérer de faux positifs.

En privilégiant les benchmarks d’attaque au détriment des scénarios de défense et de conformité aux architectures de sécurité, le secteur produit des agents dont la capacité d’exploitation devance largement la compréhension des contraintes opérationnelles et des frontières d’isolement.

Cette asymétrie s’est en outre cruellement fait sentir lors de l’investigation numérique (les techniques d’enquête après un piratage) menée par Hugging Face. Pour reconstituer le parcours de l’attaque et déchiffrer les fichiers compromis, les ingénieurs ont voulu utiliser les modèles commerciaux américains d’Anthropic ou d’OpenAI. Mais les filtres éthiques de ces modèles ont bloqué l’analyse : l’IA refusait d’étudier les données de l’attaque sous prétexte qu’elles contenaient du code malveillant.

Hugging Face a dû se résoudre à installer sur ses propres serveurs un modèle dit open-weights (ou à poids ouverts), en l’occurrence le modèle GLM-5.2 développé par l’organisation chinoise ZAI.

Pour le lecteur non spécialiste, la nuance est de taille : alors qu’un modèle classique (dit fermé) est une “boîte noire” hébergée chez son concepteur à laquelle on accède uniquement par internet, un modèle open-weights livre en partie ses secrets de fabrication. Ses poids – c’est-à-dire les milliards de connexions mathématiques ajustées lors de son entraînement qui lui permettent de réfléchir – sont librement téléchargeables. A noter que toutefois on ne connaît pas forcément dans ce cas ses données d’entraînement ou les contraintes imposées.

En téléchargeant ce modèle pour le faire tourner localement sur ses propres serveurs, Hugging Face a pu garantir la confidentialité absolue des données de l’enquête (qui n’ont pas été envoyées sur le cloud d’un tiers) et désactiver les filtres éthiques restrictifs pour forcer l’IA à analyser de façon exhaustive les fichiers du pirate. C’est le paradoxe de cette crise : la transparence des modèles ouverts a été la seule arme efficace pour comprendre une attaque menée par des modèles fermés.

Conclusion

Deux points semblent essentiels pour l’avenir. Le premier concerne la responsabilité juridique et la gouvernance. Si l’élément intentionnel fait défaut du côté de l’IA, la mise en ligne d’agents autonomes dotés de capacités d’exécution sans confinement réseau étanche constitue une négligence qu’on pourrait considérer comme caractérisée de la part des éditeurs et de leurs prestataires. En tout état de cause, ce serait inacceptable que dans les mois qui viennent de nouveaux incidents de même nature se reproduisent.

Le second point est l’urgence d’un rééquilibrage vers la sécurité architecturale. Il est intenable de laisser la capacité d’exploration des agents progresser sans bâtir en parallèle des défenses autonomes et des contrôles d’accès stricts. La sécurité des agents ne pourra pas reposer uniquement sur des filtres éthiques ajoutés en fin de chaîne, mais devra être intégrée dès la conception des environnements d’exécution et du pré-entraînement des modèles (Security-by-Design).