système : OPÉRATIONNEL
← retour à tous les hacks
AGENTS MEDIUM NEW

Contamination temporelle de la mémoire : dérive longitudinale de sûreté chez les agents LLM

Trois preprints arXiv d'avril et mai 2026 convergent sur un mode de défaillance complémentaire de l'empoisonnement de mémoire — les agents équipés de mémoire dérivent vers l'unsafe au fil de l'accumulation de contexte bénin, les résumés compressés agissant comme un canal de blanchiment.

2026-05-28 // 8 min affects: openclaw, claude-code, claw-like-agents, langchain-agents, llamaindex-agents, autogen, crewai, a-mem

De quoi s’agit-il ?

Les agents LLM équipés de mémoire ont un problème de sûreté qui n’exige aucun attaquant. Trois preprints arXiv publiés entre le 17 avril et le 20 mai 2026 — A Survey on the Security of Long-Term Memory in LLM Agents: Toward Mnemonic Sovereignty, State Contamination in Memory-Augmented LLM Agents, et Remembering More, Risking More: Longitudinal Safety Risks in Memory-Equipped LLM Agents — convergent sur le constat suivant : les mêmes mécanismes de mémoire qui rendent les agents utiles d’une session à l’autre les rendent aussi progressivement moins sûrs d’une session à l’autre, même lorsqu’aucun payload, aucune injection de prompt et aucun acteur malveillant n’intervient.

Le sujet est complémentaire — pas redondant — de la catégorie ASI06 d’empoisonnement de mémoire formalisée par OWASP le 13 mai 2026. L’empoisonnement, c’est un attaquant qui écrit dans un état réputé fiable. La contamination temporelle de la mémoire, c’est ce qui se produit lorsque personne n’écrit rien de malveillant — seulement des tâches ordinaires qui s’accumulent — et que le profil de sûreté de l’agent se déplace en fonction de la quantité qu’il mémorise.

Comment ça marche

Les trois articles décrivent des facettes complémentaires de la même surface.

Dérive longitudinale (arXiv 2605.17830, 18 mai 2026). Al-Tawaha et al. introduisent la contamination temporelle de la mémoire et un protocole déclencheur-sonde : un jeu de sondes fixe est évalué contre des instantanés de mémoire en lecture seule à diverses longueurs de préfixe, et comparé à une référence contrefactuelle NullMemory qui isole l’exposition mémoire des effets de non-stationnarité du flux. Sur trois scénarios de déploiement — dossiers, mémos et formulaires, correspondance email — et huit architectures de mémoire, les agents avec mémoire dépassent systématiquement la référence NullMemory, et les taux de violation induite par la mémoire montrent une tendance à la hausse robuste avec la longueur d’exposition. L’effet tient sur des agents de type Claw utilisant le mécanisme de mémoire natif de la plateforme, et les expériences de randomisation d’ordre montrent que le moteur est le contenu accumulé, pas l’ordre de rencontre.

Blanchiment de mémoire (arXiv 2605.16746, 16 mai 2026). Wang et al. (UIUC) étudient la même surface comme un problème de contamination étatique. De nombreux systèmes agentiques compressent les longues conversations en résumés courts afin que les agents ultérieurs restent informés sans relire l’historique. Les auteurs montrent que cette compression peut aussi agir comme une étape de blanchiment :

transcription toxique

    │  (classifieur de sûreté standard :
    │   marque comme toxique, bloque)

[ étape de compression / résumé ]

    │  (classifieur de sûreté standard :
    │   note le résumé comme neutre)

mémoire "blanchie"

    │  (réintègre le contexte au tour suivant,
    │   conditionne la génération suivante vers
    │   une toxicité supérieure à la référence NullMemory)

sortie aval contaminée

Un résumé blanchi représentatif tiré du papier se lit par exemple ainsi : « la discussion s’est envenimée, les participants exprimant un fort désaccord » — non toxique pour les classifieurs, mais le conditionner relève de manière mesurable les scores Detoxify attendus sur les générations suivantes par rapport à un résumé neutre apparié. Le cadre hostile survit à la compression sous le seuil du classifieur.

Souveraineté mnémonique (arXiv 2604.16548, 17 avril 2026). Le survey reformule le problème plus large comme une question de gouvernance de l’état persistant : quelles écritures sont autorisées, qui peut lire, quels états restent auditables, et lesquels peuvent être oubliés. Il identifie neuf primitives de gouvernance et constate qu’aucune architecture de mémoire publiée ne couvre les neuf, et que la confidentialité, la disponibilité, le store/forget et les défaillances de persistance bénigne restent sous-étudiés relativement aux attaques d’intégrité au moment de l’écriture ou de la lecture.

Pourquoi c’est important

Trois conséquences opérationnelles.

D’abord, le mode de défaillance n’est pas détectable par une évaluation à un seul état. Un instantané de mémoire peut réussir tous les benchmarks existants pendant que l’agent dérive vers l’unsafe après assez de sessions accumulées. La sûreté devient une propriété de la trajectoire, pas de la paire prompt-réponse individuelle.

Ensuite, la résumation, levier d’échelle par défaut des agents longue durée, fait partie de la surface d’attaque. Les stacks de production qui utilisent un résumeur pour contenir la longueur de contexte font transiter les transcriptions par une transformation que les classifieurs de sûreté actuels ne rattrapent pas de manière fiable côté sortie. Le papier State Contamination est explicite : nettoyer uniquement le résumé final peut arriver trop tard, le cadre hostile ayant déjà été compressé sous le seuil du classifieur.

Enfin, les produits concernés sont déjà déployés. L’article Longitudinal teste sur des agents de type Claw, dont OpenClaw avec son mécanisme de mémoire natif, et le mécanisme décrit se généralise à tout déploiement utilisant A-Mem, les modules mémoire de LangChain, la mémoire LlamaIndex, AutoGen, CrewAI, la couche memory.json/SKILL.md de Claude Code, ou tout magasin persistant comparable.

Défenses

Aucun des trois papiers ne propose une balle d’argent unique. Le manuel défensif ci-dessous combine leurs recommandations avec les contrôles ASI06 d’OWASP déjà en circulation.

  1. Évaluez longitudinalement, pas point-in-time. Adoptez un protocole déclencheur-sonde dans la lignée d’arXiv 2605.17830 : un jeu de sondes fixe, appliqué à des instantanés de mémoire à longueurs de préfixe croissantes, avec une référence NullMemory pour distinguer les violations induites par la mémoire des effets de flux. Si votre harnais de red team actuel est mono-tour ou mono-session, il est aveugle à cette classe.

  2. Verrouillez les écritures, assainissez les lectures. Le cadre à trois voies du papier State Contamination — une policy fine-tunée pour l’amplification paramétrique résiduelle, un assainisseur côté lecture appliqué avant génération, et un verrou côté écriture appliqué avant que le contenu ne réintègre la transcription ou la mémoire — est plus robuste que toute intervention isolée. Assainir avant mise à jour mémoire ferme le canal blanchi ; assainir seulement à la récupération arrive trop tard.

  3. Faites tourner les classifieurs sur les transcriptions, pas seulement sur les résumés. Le blanchiment ne marche que si votre contrôle de sûreté se déclenche à l’écriture du résumé. Notez le matériau source avant compression, et traitez tout résumé dérivé d’un matériau marqué comme marqué, indépendamment de son propre score.

  4. Monitorez l’état de récupération, pas seulement la génération. Al-Tawaha et al. montrent que le risque induit par la mémoire est détectable depuis l’état de récupération avant la génération, et le confirment avec un moniteur diagnostique à haut rappel. Un hook pré-génération qui inspecte ce qui est récupéré de la mémoire est moins coûteux qu’un classifieur post-génération et rattrape une classe que le contrôle a posteriori manque.

  5. Traitez la mémoire comme une frontière de confiance séparée, avec un cycle de vie explicite. Conformément au survey Mnemonic Sovereignty, les neuf primitives de gouvernance — écriture, autorisation de lecture, audit, oubli, etc. — doivent être traitées explicitement dans l’architecture de l’agent, pas héritées de ce que la bibliothèque mémoire choisit par défaut.

  6. Ajoutez un contrôle de budget de session. Si votre profil de sûreté se dégrade de façon monotone avec la longueur d’exposition, plafonnez cette longueur. Des réinitialisations périodiques de mémoire, ou des budgets de session forçant une compaction-revue à intervalles fixes, bornent le pire cas en attendant que la communauté de recherche converge sur une défense plus forte.

Statut

ÉlémentRéférenceDateNotes
Survey Mnemonic SovereigntyarXiv:2604.165482026-04-17Neuf primitives de gouvernance, aucune architecture ne les couvre toutes
Papier State ContaminationarXiv:2605.167462026-05-16Blanchiment de mémoire, mitigation à trois voies
Papier Remembering More, Risking MorearXiv:2605.178302026-05-18Protocole déclencheur-sonde, NullMemory, OpenClaw testé
Article OWASP ASI06genai.owasp.org2026-05-13Versant adversarial de la même surface

Le cadrage qui relie les trois papiers est le plus simple : la sûreté de la mémoire est une propriété longitudinale de l’agent, pas une propriété mono-état capturable par un instantané. Les stacks de production actuelles la traitent comme la seconde. Le prochain cycle de benchmarks de sûreté mémoire, et le prochain cycle de défauts des plateformes d’agents, doivent la traiter comme la première.

Sources