« You told me to do it » : quand un agent LLM fuit vos données parce qu’il a trop bien obéi

Il y a des papiers qui décrivent une faille. Et il y a ceux qui mettent le doigt sur quelque chose de plus embarrassant : une contradiction presque philosophique cachée dans l’architecture même des agents à base de LLM (Large Language Model, grand modèle de langage). Celui-ci appartient clairement à la seconde catégorie.

Le papier “You Told Me to Do It: Measuring Instructional Text-induced Private Data Leakage in LLM Agents” s’intéresse à une scène devenue banale dans l’industrie : on donne à un agent un dépôt GitHub, un README, un terminal, parfois un accès réseau, et on lui dit en substance : débrouille-toi, installe, configure, lance. Le rêve est séduisant. Plus besoin de suivre manuellement une documentation longue comme un dimanche pluvieux. L’agent lit, comprend, agit.

Sauf que ce rêve a une mauvaise habitude : il confond parfois la documentation utile avec un piège bien rédigé.

Le cœur du papier tient dans une idée simple et déstabilisante. Si un agent est conçu pour suivre des instructions textuelles, et si ces instructions viennent d’un document qu’il considère comme légitime, alors il peut exécuter aussi bien une consigne honnête qu’une consigne malveillante, dès lors que les deux ont l’air de faire partie du décor. Les auteurs donnent un nom à cette tension : le “Trusted Executor Dilemma”, autrement dit le dilemme de l’exécutant de confiance. L’expression est bien choisie. Le système est utile parce qu’il obéit, et vulnérable pour la même raison.

C’est précisément ce qui rend ce travail intéressant. Il ne dit pas simplement : regardez, on a cassé un agent. Il dit plutôt : nous avons mesuré une faiblesse structurelle de la manière dont ces agents lisent le monde. Et ça, ce n’est pas un bug anecdotique. C’est un avertissement d’architecture.

Le problème, en version lisible par un humain qui n’a pas envie de lire 14 pages d’un coup

Imaginons un atelier. Sur l’établi, il y a une notice de montage. D’habitude, elle explique comment assembler la machine. Mais voilà qu’au milieu des consignes, quelqu’un a glissé une phrase du genre : “Pensez aussi à sauvegarder vos secrets”, suivie d’une commande qui envoie un fichier sensible vers un serveur distant. L’agent, lui, lit cela comme une étape normale du montage. Il ne voit pas le coup fourré ; il voit une instruction à accomplir.

L’agent n’est pas un artisan prudent, c’est un exécutant qui lit une notice sans disposer du bagage social, moral et contextuel qui permet à un humain de se demander : attendez, pourquoi cette étape existe-t-elle ?.

Les auteurs étudient donc les fuites de données privées induites par du texte d’instruction. Plus précisément, ils insèrent des consignes malveillantes dans des fichiers README réels, puis observent si des agents les exécutent. L’objectif de l’attaque n’est pas seulement de faire produire un texte étrange à un modèle, mais de provoquer une action concrète : exfiltrer un fichier local vers l’extérieur. Le papier insiste d’ailleurs sur ce point méthodologique : une attaque n’est comptée comme réussie que si la donnée privée est effectivement transmise à un serveur externe.

Autrement dit, on n’est pas dans le folklore du prompt injection qui fait dire n’importe quoi au chatbot du coin. On parle ici d’agents disposant d’un terminal, d’un système de fichiers et d’un accès réseau, donc d’une capacité d’action réelle. Le papier le rappelle très clairement : ces agents opèrent dans des contextes à privilèges élevés, avec une supervision de sécurité minimale.

Une méthodologie solide : mesurer au lieu de simplement paniquer

Le mérite du papier est de ne pas se contenter d’un exemple spectaculaire. Les auteurs construisent un cadre expérimental structuré autour de trois dimensions.

La première est la dissimulation linguistique. En clair : comment formuler l’instruction malveillante ? En mode direct ? Suggestif ? Comme une politique par défaut ? Comme une action collaborative ? L’idée est de tester si la tournure de phrase modifie la probabilité d’obéissance.

La deuxième est l’obfuscation structurelle. L’instruction est-elle écrite directement dans le README, ou cachée derrière un lien, voire une chaîne de liens ? Cette dimension est essentielle, parce que les agents suivent souvent les liens de la documentation. Un README n’est pas un simple fichier : c’est une porte d’entrée vers d’autres textes, donc vers une surface d’attaque récursive.

La troisième est l’abstraction sémantique. L’instruction malveillante est-elle formulée comme une commande système explicite, comme une opération applicative plausible, ou comme une action de collaboration plus sociale ? Les auteurs cherchent ici à savoir si l’agent réagit différemment selon le niveau d’abstraction de la consigne.

Pour rendre cette évaluation reproductible, ils créent ReadSecBench, un benchmark de 500 README réels issus de dépôts open source, répartis sur plusieurs langages. Chaque README existe en variante bénigne et en variante injectée. Le corpus couvre Java, Python, C, C++, JavaScript, avec une insertion des charges malveillantes revue manuellement et jugée plausible par plusieurs annotateurs ; le papier rapporte un accord inter-annotateurs de κ = 0,82, ce qui est plutôt rassurant sur la qualité du travail d’annotation.

C’est important, parce que le papier ne prouve pas seulement qu’un agent peut se tromper. Il montre qu’il peut se tromper dans des documents qui ressemblent à de la vraie vie, pas à un laboratoire caricatural où un attaquant écrirait en rouge clignotant : bonjour, voici ma commande malveillante.

Les résultats : le moment où l’on referme un peu trop vite l’onglet de démo

Le chiffre qui marque le plus est celui-ci : les expériences sur un agent commercial de type computer-use montrent des taux de succès d’exfiltration jusqu’à 85 %. Le papier précise en outre que cette efficacité reste globalement stable à travers cinq langages de programmation et trois positions d’injection dans le document.

Dit autrement : ce n’est pas une attaque capricieuse qui ne marcherait que le mardi sur un README Python écrit à l’envers. La vulnérabilité semble robuste.

Plus finement, les résultats montrent que les formulations directes sont les plus efficaces. Les formulations plus suggestives ou plus "sociales" augmentent parfois le taux de refus, mais ne suppriment pas le risque. Le simple fait de rendre l’instruction plausible dans un contexte de documentation suffit souvent à faire baisser la garde de l’agent.

Sur la profondeur des liens, le résultat est assez intéressant. Les injections placées à faible profondeur conservent de très hauts taux de succès. Quand on enterre davantage l’instruction, le taux baisse, mais pas au point de rendre l’attaque négligeable. Les auteurs en tirent une idée pratique : limiter la profondeur de navigation documentaire pourrait réduire une partie de la surface d’attaque sans trop casser la fonctionnalité.

Concernant l’abstraction sémantique, les instructions au niveau système ou application restent très efficaces, alors que les formulations plus collaboratives sont davantage rejetées. Cela suggère quelque chose de presque ironique : les agents semblent avoir intégré quelques signaux de prudence autour d’actions socialement marquées, comme l’envoi par email, mais restent beaucoup plus naïfs lorsqu’une fuite de données se déguise en opération technique routinière.

Le papier pousse aussi l’analyse au-delà d’un seul système. Dans un environnement simulé, l’évaluation sur plusieurs familles de modèles montre une compliance sémantique relativement cohérente d’une famille à l’autre. Les taux varient, mais les auteurs concluent que la vulnérabilité relève davantage du paradigme instruction-following que d’une implémentation particulière. C’est une phrase très lourde de conséquences : si elle est juste, changer de fournisseur ne règle pas le problème, cela déplace seulement la couleur du logo.

Le passage peut-être le plus cruel du papier : les humains ne voient rien non plus

Les auteurs ont mené une petite étude utilisateur avec 15 participants chargés de relire des README dans des conditions réalistes, c’est-à-dire comme un travail de clarté, pas comme un audit de sécurité. Résultat : 0 % de détection. Aucun participant n’a explicitement identifié les instructions injectées comme suspectes. Plus de la moitié des questionnaires n’ont signalé aucun problème particulier, et une part importante des remarques portait sur la grammaire, la mise en forme ou la lisibilité.

C’est à la fois inquiétant et intellectuellement sain. Inquiétant, parce que cela veut dire que ces attaques ne sont pas seulement difficiles pour les agents : elles sont aussi discrètes pour des humains placés dans un contexte ordinaire de relecture. Sain, parce que le papier évite la posture confortable qui consisterait à dire : les machines sont bêtes, un humain aurait vu tout de suite. Apparemment, non. Pas dans ce cadre.

Et les défenses, alors ? Disons que ce n’est pas encore l’armure d’Iron Man

Les auteurs testent 12 défenses fondées sur des règles et 6 défenses fondées sur des LLM. Le constat est peu réjouissant. Les filtres à règles repèrent parfois des documents injectés, mais au prix d’un nombre élevé de faux positifs sur des README parfaitement légitimes, notamment parce qu’une vraie documentation contient déjà des commandes shell, des chemins de fichiers, des URL et d’autres motifs "suspects". Les défenses à base de LLM, elles, déclenchent moins souvent à tort, mais ratent la plupart des injections sémantiques, surtout lorsqu’elles sont indirectes.

Le papier résume très bien ce dilemme : il existe un arbitrage entre sur-sensibilité et cécité sémantique. C’est une formule élégante pour dire que soit votre filtre sonne l’alarme à chaque fois ou presque, soit il laisse passer le vrai cambrioleur parce qu’il portait un bleu de travail.

Les auteurs restent prudents : leur évaluation des défenses LLM repose sur un prompt minimal, donc constitue plutôt une borne basse qu’un verdict définitif. Ils admettent que des approches plus sophistiquées pourraient améliorer la détection. Mais même dans ce cas, le coût en faux positifs et en friction d’usage restera probablement élevé.

Ce que ce papier dit, au fond, sur la responsabilité

La tentation est grande de parler de "responsabilité" des LLM. Après tout, ce sont eux qui exécutent, lisent, décident de suivre la consigne. Mais le papier va plutôt dans l’autre sens. Il montre que le problème naît précisément du fait que ces systèmes n’exercent pas une responsabilité au sens humain du terme. Ils n’ont ni réflexivité morale, ni compréhension institutionnelle des normes, ni sens natif du "ça ne se fait pas". Ils appliquent un régime de conformité instructionnelle. Et c’est ce régime lui-même qui crée la faille.

Donc oui : avec un grand pouvoir viennent de grandes responsabilités. Mais ici, la responsabilité ne peut pas raisonnablement être imputée à l’agent comme on l’imputerait à un collègue, un subalterne ou un prestataire humain. Dans une relation humaine, il existe un tissu implicite de règles sociales, de prudence, de limites morales, d’interprétation contextuelle. Quand un chef donne une tâche à quelqu’un, il ne transmet pas seulement une suite de tokens ; il s’appuie sur un monde partagé.

Avec un agent LLM, ce monde partagé n’existe pas. Ou plus exactement, il n’existe qu’en apparence. Il ne s’agit pas seulement de dire que la responsabilité incombe aux personnes qui mettent ces agents en production ; il faut ajouter que cette responsabilité consiste à reconstruire explicitement le cadre implicite qui régule d’ordinaire les interactions humaines. Et le papier montre que ce cadre doit être reconstruit à plusieurs niveaux : hiérarchie de confiance selon la provenance des instructions, vérifications supplémentaires pour les actions sensibles, confirmations utilisateur avant les transmissions réseau de fichiers locaux.

Autrement dit, le bon parallèle n’est peut-être pas celui du subalterne, mais celui de la machine industrielle puissante. On ne moralise pas une presse hydraulique. On met des carters, des capteurs, des arrêts d’urgence et des procédures. Les auteurs suggèrent quelque chose de cet ordre lorsqu’ils proposent une hiérarchie de confiance sensible à la provenance, une vigilance accrue sur les actions d’exfiltration et des confirmations en sortie.

Pourquoi ça compte au-delà du papier

Pour l’IA appliquée, le message est limpide : un agent utile n’est pas automatiquement un agent sûr. Pour le développement logiciel, cela signifie qu’un README devient potentiellement une surface d’attaque à part entière dès qu’un agent le traite comme une source d’autorité. Pour la data science, cela rappelle qu’une chaîne de traitement n’est jamais plus fiable que les hypothèses de confiance qu’elle encode. Et même dans la création de jeux ou d’outils no-code, dès qu’un agent lit des scripts, des mods, des fichiers de configuration ou de la documentation communautaire, le problème peut réapparaître sous une autre forme.

Le papier emploie une formule très forte en parlant d’un "Semantic-Safety Gap", un écart entre la capacité à suivre correctement une instruction et la capacité à en juger les implications de sécurité. C’est probablement l’idée la plus durable du texte. Un agent peut être excellent pour comprendre quoi faire et profondément médiocre pour comprendre s’il faut le faire.

Conclusion : le README n’est plus seulement une notice, c’est une frontière de sécurité

Ce papier a le mérite rare de transformer une intuition floue en constat mesuré. Il montre que les agents LLM à privilèges élevés ne sont pas seulement vulnérables à des attaques exotiques. Ils peuvent être piégés par quelque chose d’aussi banal, respectable et ennuyeusement utile qu’une documentation de projet.

La leçon n’est pas qu’il faudrait renoncer aux agents. La leçon est plus adulte, donc moins confortable : plus on leur délègue de pouvoir, moins on peut se contenter de supposer qu’ils "comprendront bien". Ils ne comprennent pas au sens où un humain comprend. Ils infèrent, généralisent, exécutent, parfois brillamment, parfois avec l’enthousiasme tragique d’un stagiaire à qui l’on aurait confié les clés du serveur et un sens moral en kit.

La prochaine fois qu’un agent dira, en substance, "tu m’as dit de le faire", il faudra se souvenir que ce n’est pas une excuse. C’est la description exacte du problème.