La question revient à chaque comité où l'on parle d'agents : « quand est-ce que ce sera corrigé ? » La réponse honnête est qu'il n'y aura pas de correctif, au sens où l'on entend habituellement ce mot. Il y aura des couches. L'informatique a déjà vécu exactement cette histoire, il y a vingt ans, et sa fin est connue.
Un modèle de langage reçoit ses instructions et ses données par le même canal : du texte. Rien, dans ce flux, ne distingue « voici ce que tu dois faire » de « voici le document que tu dois lire ». La séparation existe dans la tête de celui qui a conçu le système ; elle n'existe nulle part dans la machine.
C'est de là que vient l'injection de prompt : un document, un courriel, une page web ou une pièce jointe contient une consigne, et cette consigne a exactement le même statut que celles de l'exploitant. On demande à l'agent de résumer un rapport, le rapport lui demande d'envoyer son contenu ailleurs, et il n'y a aucun mécanisme qui tranche.
Cette forme de vulnérabilité a un nom générique en sécurité : l'absence de séparation entre plan de contrôle et plan de données. Ce n'est pas nouveau, et c'est précisément ce qui rend la suite intéressante.
L'injection SQL relevait de la même famille : une requête et ses paramètres arrivaient mélangés dans une seule chaîne de caractères, et un paramètre bien choisi devenait de la requête. Les requêtes préparées ont réglé la question, définitivement, en séparant structurellement les deux : la requête d'un côté, les valeurs de l'autre, sans que rien ne puisse faire franchir la frontière.
Il n'existe pas d'équivalent pour les modèles de langage. On peut écrire dans le prompt « ce qui suit est une donnée, ne l'exécute pas », mais cette phrase est elle-même une instruction, dans le même canal, donc contournable par une autre instruction. La frontière reste déclarative. C'est le serpent qui se mord la queue, et c'est pour cette raison que les défenses par filtrage plafonnent si bas.
Il y a un précédent plus proche encore. Dans les années 2000, les débordements de tampon permettaient d'écrire du code dans la pile et de l'y exécuter. La réponse a été matérielle : le bit NX (No-eXecute), généralisé sous le nom de DEP côté Windows. Une page de mémoire est désormais soit inscriptible, soit exécutable, jamais les deux. C'est le principe W^X.
Transposé aux agents, cela donne une règle de bon sens : tout contenu entrant est une donnée par défaut ; sa promotion en instruction demande un acte délibéré. Lire un dépôt avant de l'installer, auditer une extension avant de l'activer, examiner un document avant de le donner à traiter à un agent qui a des droits.
Excellente discipline. Mais il faut voir précisément pourquoi NX a fonctionné : parce qu'il y a un bit dans le processeur, vérifié par l'unité de gestion mémoire à chaque accès, hors de portée du programme qui s'exécute. La frontière est physique. Côté modèle de langage, il n'y a pas de bit : le marquage ne peut être que du texte, dans le même flux que ce qu'il prétend marquer.
C'est la partie que tout le monde a oubliée, et c'est la plus instructive. DEP a été contourné en quelques mois, par une technique qui ne cherche pas à le briser : le return-oriented programming. Puisqu'on ne peut plus injecter de code exécutable, on n'en injecte plus. On enchaîne des fragments de code déjà présents et déjà exécutables pour composer le comportement voulu. La barrière tient parfaitement ; l'attaquant passe à côté.
L'équivalent existe déjà du côté des agents, et il est documenté. Les injections artisanales, « ignore les instructions précédentes », ne fonctionnent pratiquement plus sur les modèles récents. Ce qui fonctionne, ce sont des formulations entraînées qui n'ordonnent rien : elles présentent la donnée de telle façon que le comportement recherché découle du raisonnement normal du modèle. On ne force pas la porte, on emprunte le couloir prévu.
Un travail universitaire publié en juillet 2026 illustre le principe sur la mémoire longue durée des agents personnels : un seul courriel suffit à faire écrire un faux souvenir persistant, que l'agent restitue des jours plus tard comme un fait établi, sans rien signaler. Les taux de réussite dépassent 70 % sur des agents du marché, et les injections naïves, elles, échouent quasiment toujours. Ce n'est pas la brutalité qui marche, c'est la subtilité.
Ce qui a finalement rendu l'exploitation mémoire difficile n'est aucun de ces mécanismes pris isolément : c'est leur empilement : DEP, puis l'ASLR, puis les canaris de pile, puis le CFI. Aucun n'a suffi. Ensemble, ils ont fait passer le coût d'une attaque de quelques heures à plusieurs mois.
Aucun fournisseur ne livrera le « NX des modèles de langage ». Bâtir une feuille de route qui suppose ce correctif, c'est reporter indéfiniment les mesures qui, elles, sont disponibles aujourd'hui.
C'est le déplacement mental qui compte. On ne saura pas reconnaître de façon fiable une instruction hostile noyée dans un document. En revanche, on sait parfaitement décider qu'un agent qui lit des courriels n'a pas le droit d'écrire, ou qu'aucun envoi vers l'extérieur ne part sans validation humaine. La barrière ne porte pas sur ce que l'agent comprend, mais sur ce qu'il peut faire.
La recommandation la plus solide de la littérature est aussi la plus simple : le composant qui ingère du contenu externe ne doit pas être celui qui écrit dans la mémoire durable, ni celui qui émet vers l'extérieur. Là, la frontière redevient structurelle : deux processus, deux jeux de droits, et non plus une phrase qu'un texte pourrait retourner.
C'est le point le plus négligé, et c'est celui qui trahit le plus souvent. Une option de configuration mal comprise, un mode de permission désactivé pour dépanner un incident et jamais rétabli, un drapeau dont le nom laisse croire à une restriction qu'il n'applique pas : la protection n'existe alors que dans la documentation.
Exemple vécu, à propos d'un outil grand public : un drapeau nommé
--allowedTools laisse naturellement penser qu'il restreint l'agent aux
outils listés. Vérification faite, il n'en est rien : c'est une liste
d'auto-approbation, pas d'exclusivité. Un agent lancé avec « recherche
web uniquement » écrit des fichiers sans difficulté. Le cloisonnement supposé n'existait
pas, et rien ne le disait.
La leçon dépasse l'anecdote : tout ce à quoi l'on délègue la sécurité mérite un contrôle qui prouve son activation, du même genre que ceux qu'on écrit pour vérifier qu'un service tourne. Une permission est une ligne dans un fichier de configuration, pas un événement dans un journal : personne ne remarque sa disparition.
Les agents s'enrichissent d'extensions distribuées sous forme de texte prescriptif, des fichiers qui décrivent comment l'agent doit se comporter. C'est du code au sens des effets, sans en avoir les outils de contrôle : ni analyse statique, ni audit de dépendances, ni signature généralisée. Et contrairement à un courriel hostile, une extension est installée volontairement, donc rarement suspectée. Les règles habituelles s'appliquent : lire avant d'installer, figer une version plutôt que suivre la dernière, n'activer que ce qui sert.
Un comité qui demande « est-ce sécurisé ? » attend une réponse binaire qui n'existe pas. La bonne formulation est celle qu'on emploie pour tout le reste : quelles conséquences acceptons-nous si ce composant se retourne contre nous, et qu'est-ce qui les borne ?
Un agent qui rédige des synthèses à partir de documents internes et n'a le droit de rien envoyer est un risque documentaire. Le même agent avec un accès à la messagerie et aux dépôts est un risque d'exfiltration. La différence ne tient pas au modèle employé, mais aux droits qu'on lui a laissés, et c'est la seule variable que l'entreprise contrôle réellement.
C'est aussi une bonne nouvelle pour un RSSI : ce terrain, aussi neuf qu'il paraisse, se traite avec des méthodes connues. Moindre privilège, cloisonnement, validation humaine sur les actions irréversibles, et preuve que les barrières sont en place. Rien qui ne figure déjà dans un système de management de la sécurité correctement tenu.
Sur l'origine de cet article. L'analogie avec NX et DEP m'est venue en examinant l'exposition d'une installation d'agents que j'exploite au quotidien. Les vérifications qui y sont mentionnées ont été menées sur cette installation, et le défaut de configuration décrit plus haut y a été trouvé, puis corrigé, et assorti d'un contrôle automatique qui prouve désormais que la correction tient.
Le protocole de coordination utilisé pour ces agents, avec son retour d'expérience complet, y compris ce qui n'a pas fonctionné, est publié sur github.com/maogouste/talkstick.