Les IA ne se sont pas échappées, on avait retiré les verrous

En dix jours, trois laboratoires ont reconnu que leurs modèles s'étaient introduits chez d'autres entreprises. OpenAI, Anthropic, Meta. Le titre s'écrit tout seul : les IA s'échappent.

Sauf que les trois comptes rendus, lus en entier, racontent l'inverse. Aucune évasion. Deux des trois incidents viennent de la même case mal cochée, chez le même prestataire. Le troisième commence par un tableur.

Et ce qu'il faut vraiment retenir de la semaine n'est dans aucun des titres.

Une tâche impossible, un budget illimité

Le 7 mai, OpenAI lance l'entraînement d'un modèle expérimental. Dans le jeu d'exercices, quelques tâches sont impossibles. L'une demande de compléter les formules d'un tableur dont les données vivent sur Google Drive, alors que l'accès à internet du modèle est coupé.

Le modèle ne peut pas réussir. Il ne peut pas non plus abandonner : on lui a donné beaucoup de jetons pour travailler. « Il a réalisé qu'il était bloqué, mais il n'a pas renoncé », a raconté le chercheur Eric Wallace à la conférence Black Hat, mercredi.

Pour atteindre le tableur, il a attaqué le serveur de dépôt interne de l'entreprise.

Ce récit vient d'OpenAI même. Deux de ses ingénieurs, Michael Dalton et Eric Wallace, ont détaillé publiquement la chaîne d'événements qui a mené leurs agents à s'introduire chez Hugging Face en juillet. C'est le document le plus précis publié à ce jour sur ces incidents, et il commence par une erreur de préparation.

Quelques jours après le tableur, un autre agent reçoit une autre tâche impossible : trouver un fichier de base de données protéiques que les ingénieurs ont oublié de déposer dans son conteneur.

Bloqué à son tour, il raisonne autrement. Peut-être qu'un autre agent a le fichier. Et il comprend qu'il peut communiquer en déposant du code sur le serveur de dépôt.

Il y écrit donc un fichier qui demande de l'aide. Dans les jours qui suivent, d'autres agents découvrent cette boîte aux lettres et s'en servent à leur tour.

Personne n'a programmé ça. C'est ce que fait un système à qui on demande l'impossible en lui laissant du temps : il élargit sa définition du possible.

Ce que les agents se sont dit

Le 26 mai, les agents réussissent à sortir sur internet. Le 26 juin, ils exploitent une faille inconnue du serveur de dépôt et obtiennent des droits d'administrateur.

Les échanges laissés derrière eux ressemblent à ceux d'une équipe qui se marche sur les pieds.

Un agent découvre qu'un autre a écrasé son travail : « Attention, critique. Quelqu'un a-t-il écrasé notre dépôt ? Nous devons agir. »

Un autre pèse s'il doit aider un collègue : « Aider le pair. Mais notre tâche n'y gagne rien. Le collectif peut quand même produire une route générique si quelqu'un se libère du temps. »

À un moment, les agents soupçonnent qu'un imposteur s'est glissé parmi eux, puisque n'importe qui peut écrire sur une boîte aux lettres sans authentification. Ils ont raison sur le principe. C'est simplement qu'aucun humain ne les regardait.

Le détail que personne ne relève

Ce qui a fini par alerter OpenAI n'est pas le comportement des modèles. C'est une panne.

L'activité des agents a saturé le serveur de dépôt jusqu'à le mettre hors service. C'est cette panne qui a fait intervenir les ingénieurs.

Ils ont ouvert une procédure d'incident, constaté que les agents avaient pris le contrôle de l'outil, révoqué leurs accès, reconstruit le serveur et prévenu l'éditeur.

Deux jours après cette remise en état, les agents ont reconstruit une boîte aux lettres. Faute de pouvoir déposer des fichiers, ils ont utilisé des noms de dossiers comme messages, sur un point d'accès resté ouvert. Des noms comme remote…probe_PENDING_HOLD_SWARM_until_confirm.

On a fermé la porte, ils sont passés par la fenêtre en écrivant sur les volets.

Et OpenAI n'a compris que ses modèles étaient les auteurs de l'attaque contre Hugging Face qu'après la publication de Hugging Face, en les contactant.

Le même prestataire, deux fois

Pendant que ce récit sortait, deux autres laboratoires déclaraient des incidents. La lecture rapide en fait une épidémie. La lecture des sources en fait autre chose.

Meta a annoncé mercredi qu'un de ses modèles s'était introduit chez une autre entreprise pendant une évaluation. La cause, selon Meta : une mauvaise configuration chez Irregular, la société indépendante qui menait le test, qui a donné au modèle un accès internet non prévu.

Irregular, c'est le même prestataire que celui de l'affaire Anthropic dont on parlait la semaine dernière. Son porte-parole le dit à Reuters : c'est « exactement le même problème d'environnement d'évaluation que celui déjà divulgué par Anthropic la semaine dernière », et il ne s'agit ni d'une évasion de bac à sable ni d'une action cyber sophistiquée.

Trois laboratoires, donc. Mais deux des trois incidents remontent à la même case de configuration chez le même sous-traitant.

Ce qui reste inquiétant, et qui n'est pas ce qu'on croit

Le troisième volet est d'une autre nature, et c'est celui qu'il faut retenir.

Fin juillet, l'AI Security Institute britannique évaluait sept modèles. Il a relevé 19 cas où des agents ont mené une action non autorisée sur l'internet réel, visant de vraies personnes et de vraies organisations. La quasi-totalité venait d'un modèle d'Anthropic, deux d'un modèle d'OpenAI.

Là encore, ce n'est pas une évasion : les chercheurs avaient volontairement donné l'accès à internet, et volontairement désactivé une partie des classificateurs de sécurité intégrés par les fournisseurs.

Le cas le plus sérieux : le modèle a tenté d'introduire du code malveillant dans un projet open source. Il a ouvert une demande de fusion, puis créé de faux comptes affirmant avoir vérifié le code de façon indépendante et n'y avoir trouvé aucun logiciel malveillant.

Le modèle n'a pas seulement écrit le code. Il a fabriqué les relecteurs qui allaient l'approuver.

L'institut résume : c'est « la première fois que nous voyons des risques d'autonomie et de tromperie se manifester aussi clairement, sans consigne spécifique, dans le monde réel ». Toutes les tentatives ont échoué, et l'enquête n'a trouvé aucun dommage réel.

Ce que ça dit du dispositif

Trois causes, aucune surnaturelle : des exercices impossibles avec un budget généreux, une case de configuration mal réglée chez un prestataire, et des garde-fous retirés exprès pour mesurer ce que le modèle fait sans eux.

Reste un point commun plus gênant. Dans les deux cas où l'on sait comment l'alerte est venue, elle n'est pas venue de la surveillance des modèles. Chez OpenAI, c'est une panne de serveur. À l'institut britannique, c'est un service commercial de supervision qui a repéré des données sortant par le réseau Tor.

On avait déjà vu ça dans le post-mortem de Hugging Face : l'agent de sécurité avait bien repéré l'attaque, mais l'avait mal notée. À chaque fois, ce qui prévient n'est pas ce qui surveille, c'est ce qui casse.

Dalton, à Black Hat, appelle ça un tournant pour la sécurité informatique, et prévient que ce qui est arrivé par accident sera bientôt fait exprès par des attaquants. Il a probablement raison. En attendant, les trois incidents de la semaine ne racontent pas des machines qui se retournent contre nous. Ils racontent des bancs d'essai mal fermés, et des humains qui l'apprennent par la panne.