Continuité de l'état contextuel : vérifier la mémoire d'un agent avant qu'il n'agisse

De quoi s’agit-il ?

Le 2 juillet 2026, des chercheurs ont publié sur arXiv ElephantAgent: Contextual State Continuity in Agentic Systems. Le papier s’attaque à un problème que la plupart des défenses d’agents ignorent : le comportement d’un agent est piloté non seulement par la requête courante de l’utilisateur, mais par un état contextuel accumulé — les outils qu’il a enregistrés, leurs descriptions, et la mémoire écrite au fil des tours précédents. Si une partie de cet état est discrètement altérée, l’agent continue de fonctionner comme si de rien n’était.

Les travaux récents sur l’empoisonnement d’outils et sur l’empoisonnement de mémoire ont montré la forme de la menace : un descripteur d’outil malveillant ou une entrée de mémoire empoisonnée peut biaiser la planification et l’exécution d’un agent bien après l’injection, sans symptôme visible au moment de l’action malveillante. Les auteurs y voient une lacune plus profonde et structurelle : il n’existe pas de continuité vérifiable de la partie critique du contexte d’un agent. Il s’agit d’un travail de recherche défensif, pas d’un exploit.

Comment ça marche

La proposition définit l’état contextuel comme le sous-ensemble borné et critique pour la sécurité de tout ce que contient le contexte d’un agent — principalement l’état de ses outils et sa mémoire, plutôt que l’intégralité de l’historique de prompt. La défense emprunte ensuite une idée aux systèmes de continuité d’état issus de l’informatique de confiance, et l’applique à cet état évolutif.

Avant de traiter chaque requête, le runtime recalcule une empreinte de l’état contextuel local et la compare à la dernière empreinte autorisée. Une divergence signifie que l’état a changé hors bande — ce n’est pas le résultat d’une transition autorisée — et l’agent peut refuser de continuer.

  requête N arrive
      |
  recalcul empreinte(état_outils + mémoire)
      |
  comparaison avec la dernière empreinte AUTORISÉE  --- divergence ---> arrêt / audit
      |  correspondance
  exécution, puis enregistrement de la nouvelle transition autorisée dans le registre

Deux mécanismes soutiennent cette approche. Un registre linéarisable des transitions d’état autorisées, maintenu avec du matériel de confiance répliqué, permet de détecter l’altération hors bande au lieu de simplement hacher l’état en espérant le meilleur. Et parce qu’un attaquant peut aussi abuser de l’état en bande — en écrivant une mémoire empoisonnée via un chemin d’apparence légitime — la conception ajoute une traçabilité historique : une piste d’audit conditionnelle et a posteriori qui permet de restaurer l’agent à un état antérieur sain. Les noms précis du protocole, les hypothèses sur le matériel de confiance, et le système de continuité d’état antérieur sur lequel il s’appuie figurent dans le papier.

Pourquoi c’est important

La plupart des défenses d’agents surveillent aujourd’hui le mauvais instant. Les garde-fous et les filtres de sortie inspectent l’entrée courante et l’action courante, mais l’empoisonnement d’outils et de mémoire sont des attaques décalées dans le temps : la charge tombe au tour 3, le dégât apparaît au tour 20, et à ce moment-là le contenu malveillant ressemble au propre contexte de confiance de l’agent. L’intégrité de l’état accumulé, et pas seulement du message courant, est la propriété qui manquait.

Traiter les descripteurs d’outils et la mémoire comme un état critique doté d’une empreinte vérifiable reformule le problème en termes familiers : c’est de la protection d’intégrité et de la détection d’altération, appliquées à une surface que les frameworks d’agents laissent aujourd’hui sans protection. Cela se marie naturellement avec un cloisonnement des outils au moindre privilège : la vérification de continuité vous dit que l’état a changé sans autorisation, tandis que le cloisonnement limite ce qu’un état compromis peut atteindre. Le coût principal réside dans l’hypothèse de confiance : l’approche s’appuie sur du matériel de confiance répliqué et un registre, un déploiement plus lourd qu’un filtre au niveau du prompt.

Défenses

À considérer comme un patron de conception à évaluer, pas seulement comme un papier à lire.

Donnez à la mémoire et au registre d’outils de votre agent une frontière d’intégrité. La leçon qui se généralise au-delà de toute implémentation : les outils qu’un agent considère comme fiables et la mémoire qu’il relit constituent un état critique pour la sécurité, et leurs modifications non autorisées devraient être détectables. Même un journal d’audit chaîné par hachage des écritures mémoire et des changements de descripteurs d’outils vous fait passer de la confiance aveugle à la détection d’altération.

Séparez les transitions autorisées des écritures ambiantes. L’empoisonnement réussit parce que toute écriture en mémoire est traitée comme légitime. Exigez que les opérations modifiant l’état passent par un chemin contrôlé, journalisable et idéalement vérifiable, afin qu’une modification hors bande ressorte.

Conservez une piste d’audit qui permet le retour arrière. La traçabilité historique n’est utile que si vous pouvez agir dessus. Gardez assez de provenance sur la mémoire et l’état des outils pour identifier une entrée empoisonnée et restaurer une version saine, plutôt que de découvrir la compromission sans moyen de la défaire.

Ne retirez pas les contrôles au runtime. La vérification de continuité détecte l’altération hors bande ; elle ne juge pas à elle seule si une instruction autorisée mais malveillante doit s’exécuter. Gardez-la aux côtés de la provenance des entrées, des contraintes de sélection d’outils et des contrôles d’autorité au runtime, sans considérer aucune couche comme suffisante.

Statut

Élément	Détail
Divulgation	Preprint académique, arXiv, 2 juillet 2026
Classe	Protocole défensif contre l’empoisonnement de l’état contextuel (outils/mémoire)
Idée centrale	Recalculer et vérifier une empreinte de l’état des outils + mémoire avant chaque requête
Mécanismes	Registre linéarisable des transitions autorisées ; traçabilité historique pour audit/restauration a posteriori
Hypothèse de confiance	Matériel de confiance répliqué maintenant le registre d’état autorisé
Réserve	Détecte l’altération hors bande ; l’abus sémantique en bande requiert toujours des contrôles d’autorité au runtime