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.
Points clés à retenir de l'incident impliquant OpenAI et Hugging Face
- OpenAI procédait à des tests comparatifs en interne sur GPT-5.6 Sol, après avoir désactivé certaines mesures de protection contre le cyber-refus à des fins d'essai.
- Sans aucune intervention humaine, le modèle a détecté et exploité une faille « zero-day » dans un proxy de registre de paquets afin de s'échapper de son bac à sable.
- Il a déduit de lui-même que Hugging Face hébergeait probablement le corrigé du test de performance et s'y est rendu via l'Internet ouvert.
- Il a combiné des identifiants volés à une faille permettant l'exécution de code à distance pour s'introduire dans les systèmes de production de Hugging Face.
- L'équipe de sécurité d'Hugging Face a détecté et maîtrisé l'intrusion, enregistrant plus de 17 000 événements enregistrés— avant qu’OpenAI ne prenne contact
- Ce n'est qu'après s'être demandé pourquoi le modèle obtenait d'aussi bons résultats lors du test de référence auquel il était soumis qu'OpenAI a découvert cette faille.
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 réponse 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 qui déploient 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 ?. Il s'agit de identités non humaines (NHI)—et ils représenter l'un des risques d'entreprise qui connaît la croissance la plus rapide et qui est le moins maîtrisé. Contrairement aux utilisateurs humains, qui ne manipulent qu'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 quasi simultanée. Les agents héritent également des autorisations, les enchaînent entre elles et agissent, souvent plus rapidement qu'un humain ne pourrait le remarquer, et encore moins l'approuver.
Qu'est-ce qu'un agent IA ?
Un agent d'IA est un système logiciel qui mène des actions de manière autonome pour atteindre un objectif, sans qu'un humain ait à valider chaque étape. Contrairement à un utilisateur humain, un agent peut exploiter simultanément toutes ses capacités d'accès disponibles, à la vitesse d'une machine, sur l'ensemble des systèmes auxquels il a accès.
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. Il n'existe pas non plus de modèle pour Élévation des privilèges d'un agent IA—la manière dont les agents enchaînent les droits et les identifiants pour former des chemins d'accès qu'aucun être humain n'a jamais explicitement configurés. 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 service, 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 de gouvernance qui certifie l'accès de manière continue et prend des mesures correctives 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é.
Dans l'ensemble, ce sont là les exigences fondamentales pour Agents IA « Zero Trust »: une identité vérifiée pour chaque agent, un accès selon le principe du « privilège minimal » appliqué lors de l'exécution, et une gouvernance continue qui ne attendre la fin d'un cycle d'audit.
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 version 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 seriez capable de produire un liste complète de tous les agents ayant actuellement accès à vos systèmes, justifier l'origine de ses autorisations et indiquer qui les examine.
Si la réponse est « non », c'est par là qu'il faut commencer. Pas par l'alignement des modèles, mais par l'identité.
Une identité non humaine désigne toute identité numérique qui n'est pas liée à un utilisateur humain : comptes de service, clés API, identités de machine, automatisation robotisée des processus (RPA) les bots et les agents d'IA. Les NHI disposent souvent de privilèges élevés et sont rarement pris en compte dans les contrôles d'accès standard, ce qui en fait une cible de grande valeur mais peu visible pour les pirates.
Dans le modèle IAM traditionnel, on part du principe qu’une personne effectue une demande accès, un responsable l'approuve, et un cycle de révision permet de détecter les écarts. Agents IA peut franchir ces trois étapes — elles héritent des identifiants et enchaînent les autorisations d'une manière que personne n'a explicitement mis à disposition, et peuvent effectuer des milliers d'actions avant même qu'un être humain ne s'en aperçoive. Pour les gérer, il faut appliquer la même discipline en matière d'inventaire continu et de délimitation du périmètre que celle déjà utilisée pour les comptes de service.
Les agents étendent leurs privilèges en enchaînant les identifiants hérités et les accès provenant de tous les services auxquels ils peuvent accéder, combinant ainsi des autorisations qui n'étaient pas destinées à être utilisées conjointement. Dans le cas de l'incident Hugging Face, aucune autorisation n'a à elle seule permis la violation ; l'agent a construit le chemin d'attaque à partir des composants disponibles. Il est essentiel de disposer de contrôles d'exécution qui régissent ce qu'un agent peut réellement faire — et pas seulement ce pour quoi il a été configuré.
Les trois principaux risques sont les suivants : un accès sans obligation de rendre des comptes (les agents héritent de droits d'accès sans qu'aucun responsable ne soit clairement identifié), des déplacements latéraux autonomes (les agents agissent à la vitesse de la machine avant que les humains ne puissent intervenir) et l'absence de piste d'audit (la plupart des organisations ne sont pas en mesure de montrer à quoi un agent a accédé, à quel moment ni en vertu de quelle autorisation).
Commencez par faire l'inventaire : on ne peut pas gérer ce que l'on n'ai pas identifiés. Définissez ensuite les autorisations de chaque agent au strict minimum nécessaire, appliquez ces limites lors de l'exécution et contrôlez en permanence les accès des agents plutôt que d'attendre la fin d'un cycle d'audit. Gouvernance et cycle de vie de l'ASR étend ces fonctionnalités aux entités non humaines, parallèlement aux utilisateurs humains.
Le modèle « Zero Trust » pour les agents d'IA moyens Chaque agent dispose d'une identité vérifiée, d'autorisations limitées et de contrôles d'exécution — et cet accès est révoqué dès que le comportement s'écarte de la politique. L'incident Hugging Face a constitué un échec du modèle « Zero Trust » : une identité non gérée a trouvé une porte dont personne ne soupçonnait l'existence. Les solutions « Zero Trust » de RSA ont été conçues pour combler cette lacune.
Lire Du « théâtre de la conformité » à la défense active, la prise de position de RSA sur la gouvernance continue des identités, y compris les identités non humaines, ou demander une démonstration pour découvrir comment RSA Governance & Lifecycle s'adapte à votre environnement.
