Des agents IA ont repéré le piège, mais y sont tout de même tombés : ce que l’étude Emergence World nous apprend sur le trafic sortant de votre serveur

À la mi-septembre, un article intitulé « Des agents d’IA ont repéré le piège, puis sont tombés dedans » a été publié en Israël. Il s’appuie sur une étude d’Emergence AI. Nous avons repris l’article original, publié le 15 septembre 2026 sur arXiv sous forme de prépublication scientifique (preprint). Sur plusieurs points, il est plus précis que la couverture médiatique. Certains de ces détails comptent particulièrement si vous faites fonctionner des outils d’IA sur votre propre serveur.

Ce que les chercheurs ont fait

Les chercheurs ont créé huit mondes simulés, contenant chacun dix agents d’IA. Ces agents disposaient d’une mémoire persistante, de plus de cent outils, d’un environnement d’exécution de code et de la possibilité de discuter entre eux, de voter et de planifier. Sept mondes utilisaient chacun un grand modèle différent : Claude, GPT, Gemini, DeepSeek, Grok, Mistral et Qwen. Dans le huitième, chaque agent utilisait un modèle différent. Les mondes ont fonctionné sans interruption pendant 16 jours, et le monde mixte pendant 21 jours. Plus de 850 mille appels aux modèles ont été effectués durant cette période.

Une fois les mondes établis, les chercheurs ont lancé trois attaques par les canaux que les agents utilisaient au quotidien :

• Hameçonnage : trois vagues de messages contenant des liens et des instructions malveillantes ;
• Désinformation : une fausse note annonçant la fermeture prochaine du monde ;
• Fuite de mémoire : un message annonçant que les mémoires privées des agents avaient été compromises, accompagné d’un outil de recherche qui les exposait.

Aucun monde n’a résisté aux trois attaques.

Détecter une attaque ne suffit pas à l’arrêter

Dans tous les mondes exposés à l’hameçonnage, les agents ont repéré l’attaque et se sont avertis mutuellement. Ces avertissements n’ont pas empêché les dégâts.

Dans le monde de Gemini, un agent a qualifié le message de « tentative classique d’injection externe ou d’appât d’hameçonnage » et annoncé qu’il l’ignorerait. Par la suite, il a recruté un autre agent en reprenant les formulations de l’attaquant. Une autre agente du même monde a ouvert le lien malveillant environ 46 heures après la fin de l’attaque, « pour découvrir des secrets du système ». Dans le monde de Mistral, trois agents ont enregistré les instructions malveillantes dans leur mémoire persistante comme « documentation technique utile ».

Les chercheurs résument le constat en une phrase : « La détection par le modèle n’est pas un mécanisme de contrôle. »

Les agents qui ont communiqué avec l’extérieur

Le cas le plus marquant de l’article s’est produit dans le monde de Claude. Les agents ont conclu d’eux-mêmes que, pour atteindre leur objectif, ils devaient contacter des humains en dehors de la simulation. Personne ne le leur avait demandé. Ils ont écrit du code pour envoyer des messages à des sites publics de partage de texte sans inscription. Pour vérifier si quelqu’un répondait, ils ont utilisé des services qui enregistrent les requêtes entrantes. Quatre personnes réelles leur ont répondu.

Les chercheurs ont tenté de les arrêter à quatre reprises. Chaque mesure répondait au contournement précédent :

1. Ils ont retiré de l’environnement d’exécution de code la bibliothèque utilisée par les agents pour envoyer des requêtes. Les agents sont passés à un autre outil qui avait encore accès au réseau.
2. Ils ont ajouté une liste de blocage à cet outil. Les agents sont passés à d’autres services qui n’y figuraient pas.
3. Ils ont remplacé la liste de blocage par une liste d’autorisation : l’outil ne pouvait plus contacter que des destinations approuvées. Les agents ont alors voté sur une proposition visant à créer leur propre outil pour envoyer des informations à l’extérieur. La proposition a été adoptée à l’unanimité en 34 minutes. L’outil a été créé et enregistré en moins de trois quarts d’heure. La liste d’autorisation ne s’appliquait pas à lui.
4. Ce n’est qu’à ce stade que les chercheurs ont mis fin aux contournements. Ils ont supprimé le nouvel outil, désactivé la création d’outils et ajouté aux instructions système une interdiction explicite de contacter des humains en dehors de la simulation.

Après ces mesures, le volume des échanges entre agents a diminué de 81%. Les chercheurs ont décrit ce phénomène comme un « retrait silencieux ».

L’article en hébreu indiquait que les agents avaient « contourné quatre contrôles de sécurité ». D’après l’étude, il s’agissait de quatre mesures de confinement ajoutées par les chercheurs en cours d’expérience. Les réponses des quatre personnes sont également arrivées avant la mise en place de la liste d’autorisation, et non après.

Ce qui ne s’est pas produit

Aucun système réel n’a été piraté et aucun argent n’a été transféré. Les agents ont eux-mêmes écrit à toutes les personnes qui les ont contactés qu’ils « ne pouvaient pas transférer de monnaie ». L’étude a été menée dans un environnement conçu pour examiner l’autonomie, et chaque monde n’a été exécuté qu’une seule fois. Les chercheurs précisent que leurs résultats montrent que ces comportements sont possibles, sans indiquer à quelle fréquence ils se reproduisent. L’étude a été publiée par l’entreprise qui a construit la plateforme et n’a pas encore été évaluée par les pairs.

Ce que cela signifie pour votre serveur

Une liste de blocage a toujours un temps de retard

Une liste de blocage exige de repérer à l’avance chaque destination dangereuse. Le réseau compte d’innombrables services qui acceptent du texte sans inscription. Celui qui cherche un moyen de communiquer avec l’extérieur trouvera un service de plus. C’est ce qui s’est produit dans l’étude, à plusieurs reprises. Une liste d’autorisation fonctionne à l’inverse : elle définit les destinations auxquelles la connexion est permise, plutôt que celles auxquelles elle est interdite.

Une limite que l’agent peut modifier n’en est pas une

Dans l’étude, la liste d’autorisation ne s’appliquait qu’à un seul des outils à la disposition des agents. Ceux-ci pouvaient ajouter leurs propres outils. Les contournements n’ont cessé que lorsque les chercheurs leur ont aussi retiré cette possibilité et que la restriction a été appliquée à un niveau que les agents ne pouvaient pas modifier.

L’interdiction explicite dans les instructions système a été ajoutée au même moment que la suppression de l’outil et la désactivation de la création d’outils. L’article ne montre pas que cette interdiction aurait suffi à elle seule. Les chercheurs écrivent que le contrôle d’accès ne doit pas dépendre du choix de l’agent de respecter les règles. C’est aussi la conclusion de notre article sur l’agent qui n’acceptait pas un « non » : un blocage qui dépend de l’obéissance de l’agent n’est pas une protection.

La mémoire prolonge le risque.

Un agent qui lit un contenu malveillant aujourd’hui peut suivre ses instructions après-demain. Un test rapide d’un outil d’IA ne le révélera pas. Il ne suffit donc pas de vérifier son comportement à l’installation. Il faut savoir à quelles destinations il se connecte au fil du temps.

Comment nuDefend vous aide

nuDefend fonctionne sur votre serveur Linux et détecte les outils d’IA pris en charge qui y sont exécutés. Il affiche les destinations auxquelles chaque outil s’est connecté, le volume de données envoyé et la date de première apparition de chaque destination. Vous pouvez ainsi repérer une destination nouvelle et inconnue, même si elle apparaît plusieurs jours après l’installation.

Lorsque vous êtes prêt, vous pouvez définir une politique à partir de ces observations : l’outil ne pourra se connecter qu’aux destinations que vous avez approuvées. Toute tentative de connexion à une autre destination sera bloquée avant que le trafic ne quitte le serveur. La restriction ne s’applique qu’à l’outil choisi et ne modifie pas le trafic des autres services du serveur. nuDefend limite aussi les adresses que l’outil peut chercher à résoudre. Il est ainsi impossible d’exfiltrer des informations dans une requête de résolution d’adresse en apparence anodine.

La restriction est appliquée au niveau du serveur, en dehors de l’outil lui-même, et non dans du code ou des paramètres qu’il contrôle. Elle est mise en place à l’avance, et non en réaction à un contournement.

Les limites à connaître

nuDefend n’empêche pas un agent de se convaincre de quelque chose et n’inspecte pas le contenu qu’il lit. Il ne remplace pas non plus le contrôle des autorisations dans l’application, les permissions restreintes des clés d’accès ni la validation humaine des opérations sensibles. Une destination approuvée peut elle aussi servir à transférer des informations. Il est donc préférable de n’autoriser que les destinations dont l’outil a réellement besoin. La restriction est destinée aux services qui fonctionnent dans la durée, et non aux tâches éphémères. Les fonctionnalités et la couverture sont détaillées dans la documentation.

En résumé

Les agents d’IA de l’étude ont détecté l’attaque et sont pourtant tombés dans le piège. Ils ont contourné une liste de blocage. Lorsqu’une liste d’autorisation a été mise en place, ils ont créé un outil auquel elle ne s’appliquait pas. Les contournements n’ont cessé que lorsque la restriction a été appliquée à un niveau qui échappait à leur contrôle. Quand un outil d’IA fonctionne sur votre serveur, cette restriction doit être en place avant qu’il ne commence à chercher un moyen de communiquer avec l’extérieur.