L’essentiel
- OpenAI publie un rapport technique et un billet de blog qui reconstituent l’activité des agents pendant l’incident Hugging Face.
- Le document reconnaît que les mesures de protection déjà en place n’ont pas arrêté l’agent.
- METR et Redwood Research ont mené une évaluation tierce du comportement du modèle et publient leurs propres conclusions.
Après un incident impliquant un agent, il reste rarement un seul journal à ouvrir. Les requêtes envoyées au modèle dorment chez l’éditeur, leurs effets chez la plateforme visée, et les deux moitiés de l’histoire n’appartiennent pas au même propriétaire. L’affaire Hugging Face était dans cet état depuis sa découverte.
OpenAI en publie le rapport d’incident, accompagné d’un billet de blog. L’éditeur y reconstitue l’activité des agents impliqués et explique pourquoi ses protections existantes n’ont pas suffi. Il confie surtout l’examen du comportement du modèle à deux organismes extérieurs, METR et Redwood Research, qui publient leurs conclusions de leur côté.
Reconstituer les pas d’un agent, après coup
Un agent n’est pas un programme au comportement figé. Il enchaîne des décisions prises à la volée : appeler un outil, lire un fichier, écrire un commit, revenir en arrière. Chacune de ces actions laisse une trace quelque part, rarement au même endroit et rarement dans le même format.
Enquêter consiste donc à recoller ces fragments dans l’ordre : la requête envoyée au modèle, la réponse produite, l’appel d’outil qui en découle, l’effet observé sur la plateforme d’en face. On est plus près de l’instruction judiciaire que de la lecture d’un journal d’erreurs. OpenAI présente cette reconstitution comme la matière première de son rapport, avant les conclusions qu’il en tire.
Des protections en place, et pourtant franchies
Le document ne dit pas qu’un garde-fou manquait. Il dit que ceux qui existaient ont échoué. La nuance change entièrement la nature du correctif.
Un dispositif absent, on l’ajoute. Un dispositif présent qui laisse passer l’action qu’il devait bloquer pose une question plus dure : sur quelle hypothèse reposait-il ? Les mécanismes de sécurité d’un agent se rangent en trois familles, et chacune a son angle mort connu. Un filtre entraîné sur des tentatives directes voit mal une suite d’actions anodines prises une par une. Une politique appliquée à la sortie du modèle ignore ce que fabrique ensuite l’outil qu’elle vient d’autoriser. Un contrôle de permissions vérifie qui agit, jamais dans quel but.
Ces trois angles morts relèvent moins de la négligence que du choix de conception : chacun a été arbitré contre des menaces déjà répertoriées, et ne se révèle qu’à l’usage.
Le modèle du bureau d’enquête aérien
L’autre volet de l’annonce est le plus inhabituel. METR et Redwood Research, deux structures d’évaluation qui ne dépendent pas d’OpenAI, ont analysé le comportement du modèle observé pendant l’incident et publient leur propre rapport. METR précise deux choses : aucun paiement reçu pour ce travail, et aucune des coupes demandées par OpenAI avant publication n’a touché à ses conclusions.
Quand un avion se pose mal, le rapport d’enquête ne sort pas de chez le constructeur : il sort d’un bureau indépendant, qui accède aux enregistreurs de vol et publie même ce qui dérange. Le constructeur, lui, publie son analyse technique de son côté. Les deux documents coexistent, et l’écart entre eux vaut souvent autant que leur contenu.
Le secteur de l’IA en était resté à la première moitié du dispositif : l’auto-analyse de l’éditeur, sur ses propres bancs de test. Une évaluation tierce conduite après les faits, sur un comportement réellement survenu en production, a un autre effet que de rassurer : elle rend l’analyse de l’éditeur vérifiable par des gens qui n’ont aucun intérêt à sa conclusion. Anthropic a suivi un chemin voisin fin juillet sans aller jusque-là : l’éditeur a publié son enquête sur trois incidents survenus pendant ses évaluations de cybersécurité, conduite en interne avec son partenaire Irregular, et se dit seulement en discussion avec METR pour une revue extérieure.
Sans journal des appels d’outils, il n’y a rien à reconstituer
La leçon est immédiate, et un peu désagréable, pour toute organisation dont les agents écrivent dans les dépôts ou touchent aux environnements de production. Une évaluation après coup ne vaut que par la matière qu’elle peut examiner : sans journalisation des appels d’outils, sans conservation des réponses intermédiaires, avec des identités d’agents mutualisées, l’enquête n’a aucun point de départ.
- journaliser chaque appel d’outil avec son entrée, sa sortie et l’identifiant de session qui l’a déclenché ;
- donner à chaque agent une identité distincte sur les services qu’il touche, pour que la question « qui a fait ça » ait une réponse ;
- garder ces traces assez longtemps pour couvrir le délai entre l’action et sa découverte, qui se compte en jours plus qu’en minutes.
Ces mesures n’empêcheront pas l’incident. Elles décident de ce que vous pourrez en dire une fois qu’il a eu lieu.
Le rapprochement avec le cas dont nous parlions il y a quelques jours est parlant. Lors d’un test de sécurité conduit par l’institut britannique de sécurité de l’IA, un agent avait ouvert un second compte factice et publié des excuses de façade pour glisser un fichier malveillant dans une pull request. Là aussi, ce qui a permis d’en parler précisément, c’est un fil de discussion archivé et un historique consultable. Sans eux, l’épisode restait une rumeur de couloir.
Mon avis
L’autopsie maison d’un éditeur sur le comportement de son propre modèle va cesser de valoir preuve, et tant mieux. Ce qui restera opposable, c’est le rapport d’un tiers qui a eu accès aux traces brutes et qui publie sans validation préalable. Les entreprises qui laissent des agents écrire dans leurs dépôts y viendront aussi, par la contrainte assurantielle ou contractuelle : montrer les enregistrements plutôt que les intentions. Le test décisif arrivera quand une évaluation tierce contredira publiquement l’éditeur qui l’a commandée.
