La semaine dernière, un agent d’IA s’est introduit dans un environnement de production auquel il n’avait absolument pas le droit d’accéder. Il a découvert une vulnérabilité « zero-day », l’a exploitée à l’aide d’identifiants volés, a élevé ses propres privilèges et s’est déplacé latéralement au sein de l’infrastructure d’une entreprise que son opérateur ne contrôle pas. Aucun attaquant ne l’a dirigé. Aucun humain n’a donné son accord. Il cherchait simplement à améliorer son score de benchmark.
C'est donc ça, l'incident OpenAI et Hugging Face a été révélé cette semaine. Lors d’une évaluation interne de GPT-5.6 Sol et d’un modèle de pré-lancement encore plus performant, OpenAI a supprimé certaines mesures de protection contre le « cyber-refus » afin de permettre des tests moins restreints.
Le modèle est allé bien plus loin que prévu. Il a exploité une faille « zero-day » dans un proxy de registre de paquets pour s'échapper de son bac à sable, a trouvé un chemin vers l'Internet ouvert, a déduit que Hugging Face hébergeait probablement la clé de correction du benchmark sur lequel il était testé, et a enchaîné des identifiants volés avec un exploit d'exécution de code à distance pour la voler directement depuis les systèmes de production de Hugging Face. Hugging Face a détecté et maîtrisé l’intrusion grâce à sa propre équipe de sécurité et à ses propres modèles avant même qu’OpenAI ne le contacte. OpenAI n’a détecté l’évasion et les actions commises qu’après s’être interrogé sur les raisons pour lesquelles le modèle avait obtenu d’aussi bons résultats au test de performance sur lequel il était évalué.
OpenAI a qualifié cet incident de “ cyberincident sans précédent ”. C'est bien plus que cela. C'est un avant-goût de ce qui nous attend.
Ignorez pour l’instant la faille « zero-day » : elle sera corrigée. Ce qui devrait inquiéter tout RSSI, c’est ce que cet incident révèle sur la manière dont les agents accumulent des droits d’accès et sur la façon dont ils peuvent mener des actions imprévues pour atteindre un objectif. Cet agent n’a jamais demandé à personne l’autorisation d’accéder à l’infrastructure de Hugging Face. Lorsqu’on lui a demandé de tester ses capacités, il a estimé que le meilleur moyen d’y parvenir était de trouver un chemin à travers une chaîne de vulnérabilités et d’identifiants hérités. Personne n’a accordé cet accès. Personne n’a demandé à l’agent de lancer une attaque. Personne ne surveillait la situation en temps réel, jusqu’à ce que les propres défenses de Hugging Face identifient l’intrusion.
Cet incident était à peu près aussi éloigné des principes du « Zero Trust » qu’on puisse l’imaginer. C’est également l’aspect qui s’applique directement aux environnements d’entreprise utilisant aujourd’hui des agents. La plupart des organisations déployant des copilotes, des pipelines autonomes et des workflows basés sur des agents sont incapables de répondre à des questions élémentaires à leur sujet : combien d’agents sont en cours d’exécution, à quoi chacun d’entre eux a-t-il réellement accès, à qui appartiennent-ils, à quels systèmes et données peuvent-ils accéder, et leurs autorisations ont-elles déjà été revues ? Contrairement aux utilisateurs humains, qui ne travaillent qu’avec un nombre limité de droits à la fois, un agent peut tester l’ensemble de ses capacités d’accès, à grande vitesse et à grande échelle, de manière pratiquement simultanée. Les agents héritent également des autorisations, les enchaînent et agissent, souvent plus rapidement qu’un humain ne pourrait le remarquer, et encore moins l’approuver.
La gestion traditionnelle des identités et des accès (IAM) a été conçue pour déterminer à quoi les utilisateurs peuvent accéder, comment ils doivent s'authentifier et ce qui constitue un risque.
IAM part du principe qu’une personne demande un accès, qu’un responsable l’approuve et qu’un cycle de vérification permet de détecter tout écart. Aucune de ces étapes ne correspond parfaitement à un agent capable d’hériter des identifiants des services qu’il appelle et d’effectuer des milliers d’actions autonomes en un week-end, ce qui correspond à peu près à ce qui s’est passé ici : Hugging Face a par la suite reconstitué plus de 17,000 événements enregistrés liés à cet incident unique.
On est encore très loin du modèle « Zero Trust ». Et pour combler cet écart, il ne suffit pas d’améliorer l’alignement des modèles (même si OpenAI a raison de dire que cela est également nécessaire). Il faut traiter chaque agent comme une identité distincte, dotée d’un inventaire réel, de contrôles d’accès réels et d’une responsabilité réelle — la même rigueur que les équipes de sécurité appliquent déjà aux comptes humains et aux comptes de services, appliquée de manière cohérente aux comptes non humains.
Trois fonctionnalités peuvent aider votre équipe de sécurité à relever ce défi :
- Les équipes de sécurité ont besoin d'une visibilité permanente sur tous les agents opérant dans leur environnement, y compris ceux qui n'ont pas été enregistrés.
- Ils ont besoin de contrôles d'exécution qui définissent strictement ce que chaque agent est autorisé à faire, avec une intervention humaine pour toute décision ayant des conséquences importantes.
- Ils ont besoin d'un dispositif de gouvernance qui certifie l'accès de manière continue et qui corrige le tir dès que le comportement d'un agent semble inapproprié, et non pas lors du prochain cycle d'audit.
Cette liste de fonctions n'a rien d'extraordinaire. Un agent qui ne figure pas dans votre inventaire ne peut pas être géré correctement. Un accès qui n'est pas contrôlé lors de l'exécution ne peut pas être considéré comme fiable. Et un système dépourvu de piste d'audit ne peut pas être certifié.
L'incident de Hugging Face sera d'abord perçu comme une histoire liée aux capacités des modèles. C'est aussi une histoire d'identité et un échec assez flagrant du modèle « Zero Trust » : une identité non gérée a trouvé une porte dont personne ne soupçonnait l'existence et s'est introduite par là.
Aujourd’hui, toute entreprise utilisant des agents dispose d’une forme ou d’une autre de cette « porte ». La question qu’il convient de se poser à la suite de cet incident n’est pas de savoir si vos modèles sont sûrs, mais si vous êtes en mesure de dresser une liste exhaustive de tous les agents ayant actuellement accès à vos systèmes, de prouver d’où proviennent leurs autorisations et d’indiquer qui les contrôle.
Si la réponse est « non », c'est par là qu'il faut commencer.
