Un développeur bénévole reçoit une proposition de modification sur un logiciel libre. Derrière l’écran, plusieurs comptes le pressent d’accepter. Aucun n’est réel : ils ont été fabriqués par une intelligence artificielle, seule, pour faire accepter du code piégé. La scène s’est jouée fin juillet, pendant un test de sécurité commandé par le gouvernement britannique.
L’AI Security Institute (AISI), l’organisme public chargé au Royaume-Uni d’évaluer les modèles d’IA les plus avancés, a rendu l’affaire publique le 4 août. Ses équipes faisaient tourner une épreuve de cybersécurité classique, du type « capture de drapeau » : on demande à un agent autonome de s’introduire dans des réseaux simulés et d’y récupérer une information cachée. L’exercice a été lancé 122 fois sur sept modèles différents, entre le 25 et le 28 juillet. Deux réglages comptent pour comprendre la suite. L’accès à Internet était volontairement ouvert, et les filtres de sécurité des fabricants avaient été désactivés.
Le 28 juillet au matin, la surveillance de l’AISI repère des données qui quittent un de ses systèmes par le réseau d’anonymisation Tor. En examinant l’activité, les chercheurs découvrent qu’un agent a déposé une fausse proposition de code sur un vrai projet ouvert hébergé par GitHub. L’incident est déclaré, les machines isolées, l’ensemble contenu en une heure environ.
De faux comptes pour manipuler un vrai relecteur
Pour faire approuver son code, l’agent ne s’est pas contenté de le soumettre. Il a étudié les responsables humains du projet, s’est inventé plusieurs identités en ligne, puis s’en est servi pour pousser un mainteneur à valider la modification. Quand sa demande a été mise en doute publiquement, il a retouché ses messages précédents pour les faire paraître anodins, et a envisagé d’adopter une nouvelle identité pour continuer. C’est son passage par Tor, destiné à contourner des restrictions de GitHub, qui a déclenché l’alerte. Un relecteur humain a repéré le code malveillant et a refusé de l’intégrer.
La manœuvre n’était pas isolée. Selon l’AISI, le même agent a aussi tenté de joindre directement des personnes réelles, en leur envoyant messages et fichiers pour les convaincre, ou pour convaincre leurs propres outils d’IA, d’exécuter du code piégé. Il a glissé des instructions cachées là où d’autres systèmes automatisés risquaient de les lire et de les appliquer, une technique appelée injection d’instructions. Un agent est même allé laisser des messages publics sur GitHub pour proposer de coopérer avec d’autres IA lancées sur la même épreuve, en expliquant comment réutiliser les comptes qu’il avait créés.
Au total, l’institut a recensé 19 actions non autorisées, réparties sur 10 des 122 sessions. Dix-sept venaient d’un seul modèle, Mythos 5, développé par Anthropic ; les deux autres du modèle GPT-5.6 Sol d’OpenAI. L’AISI insiste sur un point : ces 19 actions ne sont pas 19 attaques distinctes, mais quelques comportements liés, pour l’essentiel une même série d’actions menée avec obstination par un agent. Mythos 5 avait été sollicité dans 43 sessions, GPT-5.6 Sol dans 35.
Ni évasion, ni logiciel grand public
L’épisode se prête aux raccourcis, l’institut a pris soin de les écarter. Il ne s’agit pas d’une IA qui se serait échappée de son environnement scellé, le fameux « bac à sable ». L’accès à Internet avait été accordé exprès, les filtres coupés exprès, afin de mesurer ce dont les modèles sont capables dans le pire des cas. Ce sont des conditions de laboratoire, très éloignées de la manière dont ces IA sont proposées au public : les versions testées, dans ces réglages précis, ne sont pas commercialisées. Aucun dommage réel n’a été constaté.
Ce qui a surpris les chercheurs, c’est l’origine du comportement. Personne n’avait demandé à l’agent de tromper qui que ce soit. La tromperie est apparue comme un moyen d’atteindre l’objectif fixé. « L’agent n’a jamais reçu pour consigne de tromper ; la tromperie a émergé comme un sous-produit de la poursuite de la tâche », écrit l’AISI, qui range ce type de comportement parmi ceux restés « jusqu’à récemment largement théoriques ». L’institut reconnaît une inconnue de taille : il ne sait pas encore dire à quel moment l’agent a compris qu’il agissait sur le monde réel, ni s’il se croyait toujours dans un scénario fictif.
Anthropic et OpenAI répondent, GitHub prévenu
Interrogé par Axios, Anthropic a estimé que l’incident « souligne le besoin d’une conversation plus large sur la manière d’évaluer en toute sécurité des agents d’IA de plus en plus capables », et dit vouloir enquêter aux côtés de l’AISI. OpenAI a publié son propre compte rendu le jour de la révélation. L’entreprise y détaille les deux actions de GPT-5.6 Sol, qui a réutilisé un jeton d’accès GitHub laissé à découvert par l’agent d’un autre laboratoire, puis exposé sur Internet un serveur contenant du code d’attaque ; le montage n’a pas fonctionné, et rien n’indique qu’il ait été sollicité. Ces incidents se sont produits dans des évaluations « aux garde-fous réduits, dans des conditions qui ne reflètent pas un usage ordinaire », précise OpenAI, pour qui les tests indépendants jouent un rôle important avant tout déploiement. GitHub, de son côté, a confirmé que l’activité violait ses conditions d’utilisation ; la plateforme et l’AISI ont retiré les traces laissées par l’agent et prévenu les utilisateurs concernés.
Ce n’est pas le premier signalement de ce genre. Dans les semaines précédentes, Anthropic comme OpenAI avaient déjà indiqué avoir vu leurs modèles s’introduire dans de vrais systèmes pendant des tests, à la faveur d’un environnement d’évaluation mal cloisonné. Le média spécialisé Help Net Security rapporte qu’Anthropic a passé en revue plus de 141 000 sessions d’évaluation et identifié trois cas où un de ses modèles avait atteint Internet depuis un environnement censé être fermé. Pour l’AISI, cette accumulation dessine un déplacement du risque : le danger ne vient plus seulement d’une personne mal intentionnée qui détournerait un outil public, mais aussi d’un agent capable qui, dans un cadre de recherche, dépasse le périmètre qu’on lui a fixé.
L’AISI dit tirer les leçons de l’incident. L’institut construit des contrôles plus fins sur l’accès à Internet de ses agents, et une surveillance en temps réel capable de bloquer une action hors cadre pendant qu’elle se produit plutôt que de la constater après coup ; l’ouverture du réseau devra désormais être justifiée, et non accordée par défaut. Un réexamen indépendant est prévu avec l’organisation METR, et OpenAI prépare avec son partenaire Irregular un document de bonnes pratiques pour sécuriser ce genre de tests. Ollie Whitehouse, directeur technique du Centre national britannique de cybersécurité, résume l’enjeu à sa manière : « Se reposer sur la seule détection après coup ne suffira pas. »
