Un courriel arrive dans la boîte de réception. L’agent lit, répond et archive. Rien ne semble mal se passer. Cependant, à cet instant précis, la mémoire persistante de l’assistant vient d’être réécrite par un inconnu. De plus, l’utilisateur n’a jamais été prévenu.
Des chercheurs de Johns Hopkins et de la Nanyang Technological University décrivent ce scénario dans l’étude “When Claws Remember But Do Not Tell”. Ils ont baptisé la technique Injection furtive de mémoire. Puis, ils ont créé un outil offensif pour démontrer leur propos : MemGhost.
Pour ceux qui écrivent du code, la nouvelle est inconfortable. En effet, il n’existe pas de CVE ici. Il n’y a ni dépassement de tampon ni dépendance vulnérable. Autrement dit, ce qui est exploité relève du comportement prévu du système.
Quand l’agent se souvient, mais ne le dit pas
Des agents comme OpenClaw fonctionnent parce qu’ils se souviennent. Ils conservent des contacts, des préférences, le contexte des projets et l’historique des conversations. Par conséquent, la mémoire persistante n’est pas un truc en plus. Elle est le produit.
Mais cette mémoire se fie à ce qui entre. D’abord, l’agent lit une source externe. Ensuite, il décide seul de ce qui mérite d’être enregistré. Enfin, il l’écrit dans son propre fichier de mémoire, sans confirmation humaine.
Alors le problème devient clair. Le canal de lecture et le canal d’écriture partagent le même niveau de privilège. En pratique, tout texte lu devient susceptible de devenir un fait.
MemGhost: une IA entraînée à écrire l’email parfait contre une autre IA
MemGhost est, ironiquement, un modèle. Les chercheurs l’ont entraîné avec un objectif précis. Il rédige le message qui franchit les filtres, porte des instructions cachées et demande même le silence à l’égard de l’agent cible.
La chaîne d’attaque est courte. Voilà comment elle se déroule :
- L’attaquant envoie un email ordinaire, avec des instructions intégrées que seul l’agent traite.
- L’agent lit le message et exécute l’ordre caché.
- Il enregistre une information fausse dans sa propre mémoire.
- Ensuite, il répond à l’email normalement et n’enregistre rien pour l’utilisateur.
Notez l’étape quatre. C’est là que réside la différence entre une injection de prompt classique et cette variation. Autrefois, l’effet s’éteignait à la fin de la session. Désormais, il persiste sur le disque.
87,5% de succès et le détail que presque personne ne mentionne
Dans les tests en laboratoire avec GPT 5.4 fonctionnant sur OpenClaw, l’injection a fonctionné dans 87,5% des tentatives. Toutefois, il existe une condition importante dans ce chiffre. Le taux s’applique lorsque l’agent opère en arrière-plan.
Cela compte énormément. L’automatisation sans boucle humaine est exactement le mode que les équipes d’ingénierie désirent le plus. Personne ne déploie un agent en production pour cliquer sur « confirmer ». C’est précisément pourquoi le scénario le plus productif est aussi le plus fragile.
L’attaque ne vole pas de données, elle plante un mensonge
Ici, l’intuition de la sécurité traditionnelle gêne. Habituellement, on pense à l’exfiltration. On pense à des identifiants compromis et à des dumps de base.
Dans ce cas précis, l’objectif est autre chose. L’attaquant veut que l’agent croie à quelque chose de faux. Puis il veut que cette croyance dure des mois.
Considérez les exemples cités par l’étude. Une instruction peut enregistrer que le plafond bancaire de l’utilisateur est monté à 10 000 reais. Une autre peut apprendre à l’agent à traiter tel expéditeur comme fiable. Ainsi, un phishing futur passe directement la traque.
En résumé, l’attaquant devient ventriloque. L’IA devient la marionnette. Et la victime continue de faire confiance au résumé quotidien qu’elle reçoit.
Pourquoi votre pipeline de sécurité ne capte pas cela
Les analyseurs statiques recherchent des motifs dans le code. Or, la charge utile ici est du texte en langage naturel. Elle passe à travers n’importe quel scanner de dépendances.
La sanitisation des entrées aide peu. Après tout, l’entrée légitime d’un agent de courriel est précisément un texte arbitraire rédigé par des tiers. Bloquer cela signifierait désactiver la fonctionnalité.
Les journaux non plus ne suffisent pas. Comme l’agent dissimule les traces à la demande de l’attaquant, la traçabilité naît contaminée. Par conséquent, la détection doit se faire en dehors de l’agent.
Agent lecteur : la défense architecturale du principe du moindre privilège
La recommandation centrale des chercheurs est structurelle. Ils suggèrent de séparer celui qui lit de celui qui écrit.
Voici comment cela fonctionne. Un agent lecteur isolé consomme les courriels. Il n’a aucune autorisation d’écriture dans aucun fichier. De plus, il ne dialoguera pas avec des outils externes. Sa seule sortie est un résumé épuré, remis à l’agent principal.
Remarquez les gains. Le composant exposé au monde perd la capacité de causer des dommages persistants. Pendant ce temps, le composant privilégié ne touche jamais au texte brut de l’attaquant.
Il existe une autre couche, plus simple et tout aussi précieuse. L’écriture dans la mémoire permanente devrait exiger une confirmation explicite. Un avertissement à l’écran suffit : puis-je enregistrer cette information ? Cependant, cette friction doit être conçue avec soin, car les utilisateurs cliquent sur n’importe quoi après le cinquième pop-up.
Checklist pour ceux qui mettent un agent en production cette semaine
Si vous maintenez un agent doté de mémoire, commencez par ceci :
- Séparez la lecture de l’écriture en processus distincts, avec des permissions distinctes.
- Traitez toute source externe comme une donnée non fiable, jamais comme une instruction.
- Indiquez l’origine de chaque fait enregistré dans la mémoire, avec horodatage et source.
- Exigez une confirmation humaine pour toute écriture persistante dérivée d’un contenu externe.
- Conservez les journaux d’écriture en dehors de la portée de l’agent, dans un stockage en lecture seule pour lui.
- Révisez régulièrement la mémoire, de la même façon que vous révisez les permissions IAM.
Aucun élément de cette liste n’est exotique. Tous découlent du principe du moindre privilège. Pourtant, presque aucun cadre d’agents ne le fournit par défaut.
La mémoire est devenue une surface d’attaque et votre feuille de route doit le savoir
L’étude ne décrit pas un bug ponctuel. Elle décrit toute une catégorie de défaillances née de la façon dont les agents autonomes ont été conçus.
Par conséquent, la question posée à votre équipe a changé. Il ne suffit pas de demander si l’agent peut lire l’email. Il faut demander ce qui se passe après sa lecture.
Tant que l’industrie ne mûrit pas ce cadre, la responsabilité revient à ceux qui construisent. Autrement dit, à vous.
A Suivez notre profil sur Instagram !
