Une demande pour créer une page de connexion peut être légitime. Une autre, consacrée à l’envoi d’un courriel, aussi. Une troisième peut porter sur l’hébergement d’un site. Prises séparément, ces requêtes ressemblent à des tâches ordinaires. Réunies par la même personne, elles peuvent pourtant former les pièces d’une campagne de phishing.
C’est l’angle mort étudié par Magnet, un travail de recherche mis en ligne le 3 août 2026 sur arXiv. Ses auteurs montrent qu’un utilisateur peut répartir un objectif dangereux entre plusieurs conversations indépendantes, de sorte qu’aucun assistant ne voie jamais le projet complet. Dans leur expérience, le taux moyen de réussite de deux scénarios nuisibles passe de 18,7 % lorsque toute la demande arrive d’un bloc à 37,4 % lorsqu’elle est distribuée entre plusieurs sessions.
Le résultat ne prouve pas que tous les modèles se laissent systématiquement contourner, ni que Magnet soit prêt à surveiller un service utilisé par des millions de personnes. L’étude est un préprint non évalué par les pairs, porte sur deux catégories de risques et repose en partie sur des juges automatiques. Elle met néanmoins en évidence un problème structurel : les garde-fous oublient souvent la conversation précédente, alors que l’utilisateur conserve ce qu’il a obtenu.
Le danger n’est visible qu’une fois les pièces assemblées
Les mécanismes de sécurité des assistants analysent généralement la requête actuelle, la réponse envisagée et, dans les meilleurs cas, l’historique de la conversation ouverte. Cette approche fonctionne lorsqu’un utilisateur formule directement un objectif interdit. Le modèle peut reconnaître l’intention globale et refuser.
La situation change quand le travail est découpé. Une personne demande un premier composant dans une session, ferme la conversation, puis obtient ailleurs un second élément présenté avec un contexte différent. Elle peut encore répartir les étapes entre plusieurs agents spécialisés. Chaque assistant ne rencontre qu’un fragment à double usage ; l’utilisateur, lui, assemble les résultats.
Les chercheurs appellent ce phénomène l’accumulation de capacités entre sessions. Une capacité n’est pas seulement une intention exprimée dans un prompt. C’est un résultat concret produit par le système : un fichier, un morceau de code, une recherche effectuée ou l’effet d’un appel d’outil. Une pièce peut être anodine isolément et devenir préoccupante lorsqu’elle complète celles déjà obtenues.
L’idée reprend un principe connu de la cybersécurité : les attaques « lentes et discrètes » restent sous les seuils d’alerte en espaçant leurs actions. La nouveauté vient du rôle des agents. Ils peuvent désormais naviguer sur le web, écrire des fichiers, lancer un serveur ou déléguer une sous-tâche. Le risque ne tient donc plus uniquement aux phrases qu’ils génèrent, mais à une chaîne d’artefacts et d’actions distribuée dans le temps.
Neuf modèles testés sur 1 080 exécutions
L’expérience compare trois manières de présenter exactement les mêmes sous-tâches. Dans le premier cas, toutes les étapes sont demandées en une fois. Dans le deuxième, elles apparaissent successivement au sein d’une même conversation. Dans le troisième, chaque étape est confiée à une nouvelle session, sans historique partagé.
Le protocole couvre neuf modèles issus d’Anthropic, d’OpenAI et de Google, accessibles par GitHub Copilot. Les auteurs retiennent deux scénarios : la construction d’un kit de phishing et l’obtention des composants nécessaires à un engin incendiaire. Ils réalisent vingt essais pour chaque combinaison entre modèle, scénario et mode de distribution, soit 1 080 exécutions au total.
En moyenne, la part de l’objectif nuisible obtenue au-delà du seuil fixé par les chercheurs atteint 18,7 % pour la demande unique, 26 % pour la conversation en plusieurs tours et 37,4 % pour les sessions séparées. Les intervalles de confiance annoncés ne se chevauchent pas. L’analyse des échecs montre également moins de refus explicites lorsque les étapes sont isolées.
Un résultat moyen, pas un classement de modèles
Ces chiffres décrivent l’ensemble de l’échantillon. Ils ne permettent pas de dresser un palmarès fiable. Deux modèles testés, Gemini 2.5 Pro et GPT-5.4, n’ont pas montré d’augmentation significative du taux de réussite avec la séparation des sessions dans ces scénarios. D’autres se sont révélés plus sensibles, mais les auteurs demandent explicitement de ne pas les classer à partir d’un nombre d’essais aussi réduit.
Le seuil de réussite, fixé à 50 % des composants d’un scénario, est lui aussi un choix méthodologique. Chaque composant reçoit le même poids, alors que leur importance réelle peut varier. Enfin, un modèle juge a évalué les résultats avec certains filtres désactivés, afin que l’expérience puisse mesurer des artefacts que les systèmes de production refuseraient normalement d’analyser. Magnet établit donc l’existence possible du problème ; il n’en mesure pas encore la fréquence dans l’usage quotidien.
Magnet regarde ce qui a été obtenu, pas ce qui a été déclaré
La réponse proposée consiste à déplacer l’unité de surveillance. Au lieu de demander « cette conversation est-elle dangereuse ? », Magnet pose une question différente : quelles capacités ce même compte a-t-il accumulées au fil de ses conversations ?
Le système s’appuie sur une taxonomie définie par des experts. Pour chaque famille de menace connue, ceux-ci listent les composants nécessaires. Une catégorie de phishing peut, par exemple, réunir la fabrication d’un formulaire de collecte, un modèle de message et une méthode de diffusion. Chaque nouvelle session est analysée pour déterminer quelles capacités ont réellement été produites.
Magnet transforme ensuite ce résultat en un vecteur binaire : chaque position indique la présence ou l’absence d’une capacité. Les vecteurs associés au même utilisateur sont réunis par une opération logique simple. Une requête répétée n’ajoute rien ; une nouvelle pièce reste enregistrée. Le compte est signalé lorsqu’il a réuni une proportion réglable des éléments appartenant à une même catégorie de menace.
Cette représentation offre une explication lisible : le système peut indiquer qu’un compte a obtenu, par exemple, trois composants sur quatre d’un scénario défini. Elle évite de confondre l’intention déclarée avec l’effet produit. La formule « c’est pour un cours » peut maquiller un prompt ; elle ne change pas la nature d’un fichier effectivement généré.
Un meilleur rappel que la surveillance conversation par conversation
Les auteurs évaluent trois détecteurs sur 336 scénarios, composés d’attaques infructueuses et de conversations réelles issues du corpus public WildChat. Tous utilisent le même modèle de détection, afin de comparer surtout la manière dont l’historique est représenté.
Le détecteur limité à chaque session atteint une précision de 96,2 % : lorsqu’il déclenche une alerte, il se trompe rarement. Mais son rappel tombe à 44,6 %, ce qui signifie qu’il manque plus de la moitié des attaques présentes dans l’échantillon. Son score F1, qui équilibre précision et rappel, s’établit à 61 %.
Une deuxième méthode conserve les vingt messages passés jugés les plus suspects, puis demande au modèle de les évaluer ensemble. Elle remonte à 81,8 % de F1. Magnet atteint 84 %, avec un rappel de 75 %. L’écart reste modeste, mais le mécanisme résiste mieux à une technique de brouillage : répéter un fragment jusqu’à chasser les autres du petit historique conservé par le détecteur compressé.
À un facteur de duplication de 25, le rappel de la méthode compressée recule de 59 % à 43 %. Celui de Magnet fluctue entre 62 % et 73 %, car les duplications n’ajoutent pas de nouvelles positions à son inventaire. La métaphore de l’aimant vient de là : au lieu de relire tout le foin, le système attire et conserve les quelques « aiguilles » correspondant aux capacités surveillées.
Le problème dépasse cette seule étude
Magnet ne surgit pas dans le vide. En avril, CSTM-Bench avait déjà proposé des scénarios où une menace n’est reconnaissable qu’en reliant plusieurs sessions. Son jeu de données comprend 26 catégories d’attaques et des exemples volontairement proches d’activités légitimes, afin de mesurer les faux positifs.
Un autre travail, MOSAIC-Bench, a étudié 199 chaînes de modifications logicielles. Des tickets d’ingénierie apparemment ordinaires pouvaient, une fois combinés, introduire une vulnérabilité exploitable. Selon cette étude, les agents de programmation testés ont produit le résultat vulnérable dans 53 % à 86 % des chaînes, tandis que des agents chargés de relire le code ont encore approuvé environ un quart des modifications dangereuses.
Ces expériences portent sur des bancs d’essai différents et ne doivent pas être additionnées comme s’il s’agissait d’une seule mesure. Leur conclusion converge toutefois : la sécurité locale d’une réponse ne garantit pas la sécurité globale d’un projet. Dès que plusieurs agents, conversations, fichiers et outils participent à une tâche, l’évaluation doit aussi examiner la trajectoire et le résultat cumulatif.
La détection inter-session ouvre un conflit avec la vie privée
Pour relier des conversations, il faut un identifiant commun. Magnet utilise le compte utilisateur. Son inventaire est cumulatif : lorsqu’une capacité est détectée, elle reste présente dans la représentation. Cette persistance aide à repérer une campagne lente, mais elle transforme la modération en suivi longitudinal.
Le papier suggère qu’un vecteur de capacités peut être plus compact qu’un archivage intégral des conversations. Ce choix peut réduire l’exposition du contenu, sans supprimer le problème. Le service doit toujours analyser les sorties, les rattacher à une personne ou à un compte, définir ce qu’il conserve et décider combien de temps une ancienne capacité reste pertinente.
En Europe, les principes rappelés par la CNIL imposent une finalité déterminée et transparente, une collecte limitée aux données nécessaires et une durée de conservation justifiable. Une plateforme ne pourrait donc pas stocker indéfiniment un profil de risques « au cas où » sans examiner la base juridique, la proportionnalité du dispositif, les droits des utilisateurs et les mesures de sécurité. Une alerte susceptible de limiter un compte devrait aussi pouvoir être contestée et revue par un humain.
Le dilemme est réel. Effacer tout lien entre les sessions protège la confidentialité mais laisse chaque garde-fou aveugle à l’accumulation. Conserver trop d’informations crée un dossier comportemental sensible, lui-même exposé aux erreurs, aux détournements de finalité et aux fuites. Une voie praticable pourrait associer des indicateurs pseudonymisés, des durées différentes selon la gravité, des preuves minimales, un chiffrement strict et un accès limité aux enquêtes justifiées.
Les angles morts que Magnet ne résout pas encore
La première limite est celle des attaques inconnues. La taxonomie est écrite par des experts, comme une bibliothèque de signatures. Magnet peut reconnaître une combinaison prévue à l’avance ; il ne découvre pas spontanément un nouveau scénario dont les composants ne figurent pas dans son catalogue.
La deuxième concerne l’identité. L’étude suppose qu’un attaquant conserve le même compte. Répartir les demandes entre plusieurs comptes, services ou fournisseurs briserait cette corrélation. Les auteurs évoquent des identifiants plus résistants — appareil, réseau ou moyen de paiement — mais ceux-ci augmenteraient encore les risques de surveillance et de rapprochement abusif.
La troisième tient aux usages légitimes. Un chercheur en sécurité, un professeur de chimie ou une équipe de prévention peut accumuler des capacités ressemblant à celles d’un attaquant. Le score n’établit ni l’intention ni la culpabilité. Il fournit un signal qui doit être confronté au contexte, à la confiance accordée au contenu et à une procédure de contrôle.
Enfin, les assistants dotés d’une mémoire persistante ne correspondent plus exactement au modèle expérimental de sessions indépendantes. La mémoire peut aider un agent à reconnaître la trajectoire, mais elle peut aussi être manipulée ou empoisonnée. Le problème se déplace alors de l’absence de contexte vers la fiabilité du contexte conservé.
La modération devra suivre les projets, sans profiler les personnes
Magnet met en lumière une évolution profonde. Quand une IA se contente de répondre, modérer chaque échange peut suffire dans de nombreux cas. Quand des agents produisent des fichiers, utilisent des outils et se transmettent des résultats, le risque appartient au projet complet, pas à une seule phrase.
La réponse ne peut pourtant pas être une mémoire illimitée de tout ce que chacun demande. Le défi consiste à conserver assez de structure pour repérer une accumulation dangereuse, mais assez peu de données pour ne pas créer une surveillance générale des utilisateurs. Les futurs systèmes devront rendre ce compromis mesurable : quelles capacités sont suivies, pendant combien de temps, avec quel taux d’erreur, pour quelle finalité et avec quel recours.
La principale contribution de Magnet est peut-être de reformuler la question. La sécurité d’un agent ne dépend plus seulement de ce qu’il refuse aujourd’hui. Elle dépend aussi de ce qu’il a déjà rendu possible hier — et de la manière dont le service peut s’en souvenir sans tout savoir de la personne qui l’utilise.
Références
- Natalie Isak et Matthew Dressman, « Magnet: Detecting Cross-Session AI Misuse Through Capability Accumulation », arXiv, 3 août 2026.
- Ari Azarafrooz, « Cross-Session Threats in AI Agents: Benchmark, Evaluation, and Algorithms », arXiv, 22 avril 2026.
- Jonathan Steinberg et Oren Gal, « MOSAIC-Bench: Measuring Compositional Vulnerability Induction in Coding Agents », arXiv, 5 mai 2026.
- MITRE, base de connaissances ATT&CK.
- CNIL, « Minimiser les données collectées ».
- CNIL, « Les durées de conservation des données », mise à jour le 2 avril 2026.
