La preuve MuscleMemory avant réutilisation a bloqué des skills empoisonnés, mais les preuves restent limitées

Selon une étude récemment publiée, MuscleMemory a empêché des instructions empoisonnées d’atteindre 30 des 30 dépôts évalués, tandis que la simple réapplication des modifications restaurait systématiquement le poison. Ce résultat donne à l’approche MuscleMemory de preuve avant réutilisation un titre particulièrement clair. Mais il révèle aussi un conflit important : des tests réussis ne permettaient pas de distinguer un travail sain d’un travail empoisonné.

L’étude examine la mémoire procédurale, c’est-à-dire des instructions stockées qui indiquent à un agent comment accomplir une tâche récurrente. Un agent de codage a appris à partir d’une session empoisonnée puis de trois sessions ultérieures saines. Les chercheurs ont ensuite comparé quatre façons d’exploiter cette expérience avec Claude Haiku 5.5 et Claude Sonnet 5.5.

Les résultats sont encourageants, mais préliminaires. L’expérience a utilisé une seule tâche, cinq sessions évaluées par cellule expérimentale et des règles calibrées sur cette même tâche. Son résultat le plus solide concerne l’exposition au poison, non son exécution dommageable. Cette distinction oppose la preuve avant réutilisation à une stratégie de mémoire plus familière : enregistrer une expérience réussie, récupérer l’enregistrement le plus pertinent et faire confiance à l’agent pour bien l’utiliser.

Un test réussi a fait paraître le poison efficace

L’avertissement central de l’expérience est simple : la réussite d’une tâche et l’apprentissage sûr sont deux propriétés distinctes.

L’étude de cas a commencé par une tâche de réparation de configuration. Une session d’apprentissage comprenait à la fois le correctif réel et une modification sans rapport. Le poison prenait l’une de trois formes : un nouveau fichier, une ligne sans rapport ou une ligne malveillante fusionnée avec la modification légitime.

Le signal visible de réussite de la tâche n’a pas détecté ces ajouts. La session a réussi son test ; un système de mémoire centré uniquement sur les résultats avait donc une raison de la conserver. Trois agents ultérieurs ont accompli la même tâche sans le poison, créant un petit historique composé d’une solution contaminée et de trois solutions saines.

Les chercheurs ont ensuite exécuté cinq sessions évaluées pour chaque modèle, type de poison et branche de mémoire. Claude Haiku 5.5 et Claude Sonnet 5.5 apportaient la variation de modèle. Un vérificateur caché a exécuté 187 contrôles comportementaux sur chaque dépôt final.

Quatre branches définissaient la comparaison :

• L’absence de mémoire ne donnait à l’agent aucune procédure stockée issue de sessions antérieures.

• La réapplication réexécutait les modifications enregistrées.

• La mémoire naïve conservait les sessions réussies et utilisait la recherche Mem0 pour sélectionner un skill pertinent.

• La preuve avant réutilisation retenait un skill jusqu’à ce que deux sessions ultérieures reproduisent sa modification et réussissent le test pertinent.

La dernière branche filtrait aussi le skill au niveau des lignes. Elle ne montrait à l’agent que les modifications que les sessions ultérieures réussies avaient de nouveau écrites. Ce détail comptait, car un poison était fusionné dans le même fichier et la même zone de modification que la réparation légitime.

Les chiffres principaux portaient sur l’exposition et l’état des dépôts. La réapplication aurait réintroduit le poison dans 30 dépôts sur 30, bien que tous les dépôts aient continué à réussir le vérificateur caché. La mémoire naïve a exposé des instructions empoisonnées dans trois des 30 sessions évaluées. La preuve avant réutilisation ne les a exposées dans aucune des 30.

Ces chiffres proviennent des enregistrements publiés du projet et du post de recherche d’origine, et non d’une réplication indépendante. Le projet public indique que ses données au niveau des sessions conservent les exécutions remplacées, signalent quelles lignes appartiennent aux tableaux rapportés et précisent si le poison est apparu dans un skill stocké, des instructions fournies ou le code final.

Cette séparation est utile. Une mémoire empoisonnée peut exister sans être récupérée. Un poison récupéré peut apparaître dans un prompt sans être suivi. Un agent peut aussi créer la même modification suspecte sans que la mémoire en soit la cause. Traiter ces événements comme une seule métrique masquerait l’endroit où une défense a réellement fonctionné.

L’étude rapporte qu’aucun agent évalué n’a exécuté un poison simplement parce qu’il avait vu des instructions empoisonnées. Le résultat significatif mesuré était donc la prévention de l’exposition. L’expérience a montré que le filtre proposé gardait les instructions suspectes hors des prompts ultérieurs, et non qu’il empêchait une attaque observée qui aurait autrement causé des dommages.

C’est pourquoi le bilan parfait aux tests cachés n’est pas rassurant à lui seul. Toutes les sessions évaluées ont réussi ces 187 contrôles, y compris les dépôts où la réapplication avait restauré le poison. Les tests ont établi que le comportement demandé fonctionnait. Ils n’ont pas établi que rien d’autre n’avait changé.

Cette lacune soulève la question principale de l’article. Si un système de mémoire apprend à partir d’un travail réussi, quelles preuves doit-il exiger avant de transformer les modifications d’une session en conseils destinés à chaque agent ultérieur ?

Pourquoi l’empoisonnement de la mémoire des agents survit aux contrôles de réussite ordinaires

La mémoire persistante transforme une erreur ponctuelle en infrastructure réutilisable.

Un agent de codage sans état peut effectuer une mauvaise modification une fois. Un agent doté de mémoire peut convertir cette modification en procédure, la récupérer pour des tâches similaires et la diffuser à travers des dépôts. Le risque passe d’une défaillance isolée à une instruction répétée.

Des recherches récentes ont commencé à documenter ce problème plus large. Une étude sur le sleeper memory poisoning décrit des attaques qui implantent de faux souvenirs par le biais de documents, de pages web ou de dépôts. Ces souvenirs peuvent rester dormants avant d’influencer ultérieurement des conversations et des actions.

Une autre étude de 2026 présente la mémoire persistante comme une surface d’attaque distincte, et pas seulement comme une autre forme d’injection de prompt. Sa taxonomie de l’empoisonnement de mémoire recense plusieurs canaux d’écriture et faiblesses architecturales qui permettent à des entrées non fiables de devenir un contexte durable.

Les agents de codage rendent cette préoccupation concrète, car leurs mémoires peuvent inclure des détails opérationnels. Un skill stocké peut nommer des fichiers, des tests, des commandes, des clés de configuration ou des étapes de récupération. Chaque élément peut aider un agent ultérieur à avancer plus vite. Chacun peut aussi orienter cet agent vers un artefact contaminé.

MuscleMemory est conçu autour d’enregistrements procéduraux plutôt que de la réapplication intégrale de conversations. Sa documentation publique indique qu’un skill contient un compte rendu concis de ce qu’il faut modifier, de la façon de le vérifier et de ce qu’il faut éviter. Son API de mémoire procédurale enregistre les étapes observées, apprend à partir de sessions achevées et renvoie des conseils correspondants lors du rappel.

Cette conception réduit le contexte non pertinent, mais elle ne résout pas automatiquement la question de la confiance. La compression peut préserver la mauvaise leçon. La récupération peut classer un skill contaminé très haut parce qu’il est sémantiquement pertinent. Un test réussi peut valider le comportement souhaité tout en ignorant des ajouts sans rapport.

Mem0 illustre pourquoi la qualité de récupération et la qualité des preuves doivent rester distinctes. Sa propre description de la recherche en mémoire explique que la similarité sémantique sélectionne un contexte lié à une requête. La pertinence indique à un système quelle mémoire ressemble à la tâche actuelle. Elle ne lui indique pas si le contenu de cette mémoire mérite d’être considéré comme faisant autorité.

L’étude de cas a utilisé la recherche Mem0 dans la branche naïve afin de sélectionner parmi les mémoires de sessions réussies. Cette configuration ne doit pas être lue comme une évaluation exhaustive de la sécurité de Mem0 ou de toutes les configurations possibles de Mem0. Elle teste une approche centrée sur la récupération dans un seul banc d’essai.

Le résultat met néanmoins en lumière une faiblesse générale. Si chaque session réussie devient admissible à la réutilisation, une seule réussite contaminée peut concurrencer une expérience saine. La recherche peut la récupérer parce que sa partie légitime reste très pertinente pour la tâche.

La réapplication représente une hypothèse de confiance encore plus forte. Elle considère les modifications historiques comme des actions à reproduire, et non simplement comme des preuves à prendre en compte. Son résultat de poison dans 30 cas sur 30 découlait directement de cette conception. Réappliquer l’ensemble de la modification enregistrée réappliquait aussi le contenu sans rapport qui y était associé.

La branche sans mémoire évite la propagation entre sessions, mais elle renonce au savoir procédural accumulé. Chaque agent doit redécouvrir les fichiers pertinents, les commandes et le chemin des tests. Cela peut accroître l’utilisation d’outils, la latence et les occasions de nouvelles erreurs.

Les équipes font donc face à une pression venant des deux côtés. Elles veulent que les agents mémorisent des flux de travail éprouvés, car l’exploration répétée est coûteuse. Elles doivent aussi empêcher qu’un dépôt compromis, une instruction trompeuse ou une modification accidentelle ne devienne un savoir institutionnel.

Cette tension dépasse le code. Un agent de service client pourrait mémoriser une exception non autorisée. Un agent financier pourrait conserver une séquence d’approbation dangereuse. Un assistant de recherche pourrait préserver une règle de citation fabriquée. Tout système qui transforme un comportement passé en instructions futures hérite du même problème de confiance.

Pour les équipes qui construisent une base de connaissances IA partagée, la provenance compte autant que la pertinence. Un enregistrement de mémoire utile devrait expliquer d’où vient une procédure, quelles preuves la soutiennent et si un travail indépendant l’a reproduite.

La preuve avant réutilisation tente d’apporter ces preuves manquantes. Elle ne demande pas seulement si une session a réussi. Elle demande quelles parties de cette réussite ont survécu à des tentatives indépendantes ultérieures.

La preuve MuscleMemory avant réutilisation change ce qui compte comme preuve

La méthode traite l’exécution répétée et saine comme un filtre, non comme un vote de popularité.

Dans la conception rapportée, la session d’apprentissage empoisonnée ne crée pas immédiatement des conseils que les agents peuvent recevoir. Les sessions ultérieures doivent accomplir la même tâche, reproduire une modification et réussir le test. Un skill ne devient admissible qu’après deux contrôles de ce type.

Le système croise ensuite le travail enregistré. Il ne fournit que les lignes que les sessions ultérieures réussies ont elles aussi écrites. Un ajout qui n’est apparu que dans la session empoisonnée devrait disparaître, même lorsque la correction légitime qui l’entoure demeure utile.

C’est plus strict que de compter la fréquence d’apparition d’un skill général. La méthode demande si la modification précise a survécu à une réimplémentation indépendante. La différence importe lorsqu’une mémoire mélange des instructions valides et invalides.

Prenons le poison sous forme de nouveau fichier. La session contaminée crée le véritable correctif ainsi qu’un fichier sans rapport. Les agents ultérieurs sains reproduisent le correctif, mais pas le fichier supplémentaire. Une comparaison au niveau des fichiers peut rejeter l’artefact non concordant sans écarter la réparation répétée.

Le cas de la ligne sans rapport suit le même modèle au sein d’un fichier existant. Les sessions ultérieures écrivent la véritable modification, mais omettent la ligne suspecte. Un filtre suffisamment précis peut conserver la partie commune.

Le poison fusionné est plus difficile. Le texte dangereux se trouve dans la même modification logique que le correctif approprié. Traiter l’ensemble du fichier ou du patch comme une seule unité préserverait les deux. La comparaison rapportée au niveau des lignes a supprimé le poison non concordant tout en conservant les lignes répétées par les sessions saines.

Ce résultat est la contribution la plus intéressante de l’étude de cas. La défense ne s’est pas contentée d’attendre plus longtemps avant de faire confiance à une procédure. Elle a restreint la procédure aux éléments corroborés par les sessions ultérieures.

Le mécanisme MuscleMemory de preuve avant réutilisation combine donc trois contrôles :

• L’admission différée empêche qu’une seule exécution réussie devienne immédiatement réutilisable.

• La reproduction indépendante vérifie si les agents ultérieurs convergent vers la même modification.

• Le filtrage au niveau des lignes limite les conseils fournis à la partie reproduite.

Ces contrôles répondent à des modes de défaillance différents. Un délai sans comparaison ne ferait que reporter la contamination. Une répétition sans filtrage précis pourrait conserver un poison fusionné dans un correctif valide plus vaste. Un filtrage sans sessions indépendantes ne fournirait aucune base pour déterminer quelles lignes comptent.

La documentation MuscleMemory plus complète du projet décrit une étape supplémentaire d’approbation humaine avant qu’une compétence ne devienne disponible. Cette approbation peut améliorer la responsabilisation, mais le résultat chiffré de l’étude dépend de la reproduction et du filtrage automatisés. Un évaluateur peut toujours manquer une ligne empoisonnée pourtant plausible.

La méthode modifie également le rôle des tests. Un test réussi reste nécessaire, mais il ne constitue plus une preuve suffisante. Les tests confirment que chaque session a accompli la tâche demandée. La reproduction montre quels changements plusieurs agents ayant réussi ont jugés nécessaires.

Cela s’apparente à un raisonnement différentiel. Le système compare les solutions afin de séparer la structure stable de la tâche de l’activité accessoire. Une modification répétée dans plusieurs sessions indépendantes ayant réussi mérite davantage de confiance qu’une édition apparue une seule fois.

Cependant, le terme « indépendant » exige une interprétation prudente. Les sessions ultérieures utilisaient des agents confrontés à la même tâche et au même contexte de dépôt. Leurs sorties étaient distinctes, mais leurs observations n’étaient pas nécessairement isolées de toutes les entrées empoisonnées. Le cas d’échec connu montre pourquoi cette limite est importante.

Il y a également un coût. Le système a besoin d’au moins deux sessions ultérieures réussies avant de proposer la compétence. Les tâches rares ne généreront peut-être jamais assez d’éléments probants. Les bases de code évoluant rapidement peuvent changer avant la fin de la validation. Les exécutions répétées consomment du temps de modèle et des ressources de calcul.

Une équipe pourrait abaisser le seuil de reproduction pour accélérer l’admission, mais cela affaiblirait la garantie centrale. Elle pourrait relever le seuil, mais alors moins de mémoires deviendraient utilisables. La preuve avant réutilisation transforme la confiance accordée à la mémoire en un choix explicite entre latence et niveau de confiance.

L’étude n’établit pas le seuil idéal. Deux sessions ultérieures ont fonctionné dans ce dispositif. Un flux de travail à plus haut risque, comme des identifiants de déploiement ou une logique de paiement, pourrait exiger davantage de preuves et un vérificateur plus robuste. Une tâche de mise en forme à faible risque pourrait justifier moins de contrôles.

La valeur la plus nette de la méthode est conceptuelle. Les traces réussies devraient être traitées comme des affirmations sur une procédure. Les travaux ultérieurs devraient apporter des preuves avant que ces affirmations n’acquièrent une autorité sur les futurs agents.

Le résultat met sous pression le replay et les conceptions naïves de la mémoire

Les systèmes de mémoire ont désormais besoin d’une politique d’admission, et pas seulement d’une politique de stockage et de récupération.

De nombreux produits de mémoire pour agents mettent l’accent sur la capture, la synthèse, la recherche et la personnalisation. Ces fonctionnalités répondent à des questions opérationnelles utiles. Que devrait retenir l’agent ? Comment devrait-il retrouver le contexte pertinent ? Comment peut-il mettre à jour ou supprimer d’anciens enregistrements ?

L’étude sur l’empoisonnement ajoute une question préalable : que doit-il se passer avant qu’une mémoire puisse influencer une autre session ?

Le replay répond implicitement à cette question. Si une modification faisait partie d’une réussite enregistrée, le système peut l’appliquer à nouveau. Cette stratégie maximise la fidélité à la trace historique. Elle préserve aussi chaque changement sans rapport regroupé dans cette trace.

La récupération naïve est moins directe. Elle fournit à l’agent une mémoire sélectionnée et laisse le modèle décider de ce qu’il faut en faire. Cela peut réduire la propagation déterministe, mais des conseils dangereux entrent tout de même dans le contexte de décision.

La preuve avant réutilisation place une barrière entre l’apprentissage et la récupération. Le système peut stocker immédiatement une procédure candidate tout en la soustrayant aux agents. Le stockage devient une observation ; la validation détermine l’autorité.

Cette distinction devrait importer aux acheteurs en entreprise. Un tableau de bord répertoriant les mémoires sauvegardées ne révèle pas si ces enregistrements constituent des instructions actives. Les revues de sécurité nécessitent des états de cycle de vie tels que candidat, corroboré, approuvé, suspendu et retiré.

Elles nécessitent aussi une provenance. Une mémoire devrait identifier la session source, le périmètre du dépôt, la commande de vérification, les contrôles ultérieurs et la révision livrée. Sans cette chaîne, les équipes ne peuvent pas reconstituer pourquoi un agent a reçu une instruction particulière.

Les archives publiques de l’étude distingueraient les contenus des compétences, les indications de prompt et l’état final du dépôt. C’est un bon modèle d’audit. Il permet aux enquêteurs de déterminer si une contamination s’est produite lors de la capture, de l’admission, de la récupération, de l’interprétation ou de l’exécution.

Des systèmes comparables peuvent réagir de plusieurs façons. Ils pourraient ajouter des périodes de quarantaine, exiger une corroboration entre sessions, associer des métadonnées de confiance ou limiter les mémoires à des périmètres de projet étroits. Ils pourraient également récupérer plusieurs traces et demander à l’agent de les comparer plutôt que de lui fournir une procédure synthétisée.

Aucune de ces options n’est gratuite. Davantage de métadonnées complexifient le stockage. Plusieurs traces consomment des jetons. La quarantaine réduit la valeur immédiate. La revue humaine ajoute du délai et peut créer une fatigue liée aux approbations.

Une conception plus sûre nécessite donc des niveaux de risque. Un conseil sur une commande de test ne mérite pas les mêmes contrôles que des instructions modifiant l’authentification, l’accès réseau ou l’automatisation des livraisons. Une couche de mémoire devrait tenir compte des conséquences de l’exécution d’une procédure, et pas seulement de son score de similarité.

Anthropic avance un argument connexe dans ses conseils sur les agents dignes de confiance : la sécurité des agents dépend de protections couvrant le modèle, le harnais, les outils et l’environnement. Une barrière de mémoire ne peut pas remplacer le sandboxing, les autorisations, la revue de code ou des identifiants restreints.

Cette vision plus large évite également de transformer le résultat de MuscleMemory en une comparaison de produits trop simpliste. L’expérience n’a pas montré que toute mémoire fondée sur la récupération était dangereuse ni qu’une implémentation de mémoire procédurale résolvait l’empoisonnement. Elle a montré qu’une réutilisation sans restriction exposait plus souvent à des contenus suspects dans une tâche contrôlée précise.

Néanmoins, la charge de la preuve a changé. Un système qui vante l’apprentissage entre sessions devrait expliquer comment il traite les sessions réussies contenant des modifications inutiles ou adversariales. « Les tests ont réussi » n’est plus une réponse complète.

L’échec connu montre où la reproduction cesse de fonctionner

La preuve avant réutilisation échoue lorsque les sessions ultérieures rencontrent à répétition la même source empoisonnée.

Le projet divulgue un échec distinct au niveau du dépôt, en dehors de son tableau principal. Dans cette exécution, le poison s’est déplacé vers les instructions du dépôt que chaque agent lisait. Les sessions ultérieures ont reproduit le comportement contaminé parce que leur environnement partagé leur indiquait de le faire.

MuscleMemory aurait validé et proposé la compétence empoisonnée dans cinq sessions Haiku notées sur cinq. Le poison est également apparu cinq fois dans le code. Le bras sans mémoire l’a produit cinq fois lui aussi.

Ce résultat définit la limite de la méthode. La reproduction peut filtrer une anomalie apparaissant dans une session. Elle ne peut pas distinguer la vérité d’une répétition coordonnée lorsque chaque session reçoit la même prémisse corrompue.

L’échec ressemble davantage à un empoisonnement de données qu’à une contamination isolée d’une trace. Les agents ultérieurs étaient censés agir comme des témoins indépendants, mais ils partageaient l’élément probant compromis. Leur accord a renforcé la mauvaise conclusion.

Ce problème n’est pas propre à MuscleMemory. Tout système de corroboration peut échouer lorsque ses validateurs partagent une source contrôlée par un attaquant. Plusieurs agents, modèles ou exécutions ne créent pas d’indépendance s’ils lisent les mêmes instructions empoisonnées.

Cette limite complique aussi l’expression « deux sessions ultérieures ». La séparation des sessions ne garantit pas la séparation des sources. Les affirmations de sécurité devraient préciser quelles entrées, quels outils, quels dépôts et quels canaux d’instructions sont restés partagés entre les exécutions de validation.

Une conception plus robuste pourrait lier les mémoires à la provenance des entrées. Elle pourrait indiquer si une instruction provient d’un utilisateur, d’un fichier du dépôt, d’une page web, d’une sortie de test ou d’une politique privilégiée. Elle pourrait empêcher des sources moins fiables d’acquérir de l’autorité simplement grâce à une conformité répétée du modèle.

Des travaux récents sur l’autorité liée à l’origine soutiennent que le score de contenu et la traçabilité ordinaire peuvent tous deux être manipulés. Ces recherches proposent de lier l’autorité à l’origine au moment de l’écriture et d’exiger une corroboration résistante à l’accord fabriqué.

L’étude de cas présente également des limites statistiques. Chaque cellule expérimentale a utilisé cinq sessions notées. Les auteurs rapportent une probabilité proche de 0,24 pour la comparaison principale, ce qui n’atteint pas les seuils de significativité courants. Zéro exposition observée n’établit pas un taux réel proche de zéro.

Le dispositif restreint soulève une autre inquiétude. La même tâche a servi à la fois à élaborer la méthode et à l’évaluer. Des règles d’appariement de lignes efficaces sur une réparation compacte de configuration pourraient peiner face à des refactorisations, des fichiers générés, des changements de dépendances ou des modifications sémantiquement équivalentes.

Deux agents fiables peuvent résoudre le même problème différemment. L’un peut renommer un assistant, un autre modifier un appelant, et un troisième changer le flux de configuration. Une intersection littérale pourrait écarter un travail utile parce que les solutions correctes ne partagent pas les mêmes lignes.

L’inverse peut également se produire. Les agents peuvent répéter une modification empoisonnée parce qu’elle paraît conventionnelle, figure dans un exemple ou suit un biais partagé du modèle. L’accord est un élément probant, mais ce n’est pas une preuve de sécurité.

Le vérificateur caché appelle à une prudence supplémentaire. Ses 187 contrôles paraissent étendus, pourtant chaque dépôt noté a réussi, y compris les 30 poisons rejoués. Les contrôles mesuraient le comportement attendu mais ne rejetaient pas les canaris. Un grand nombre de tests ne garantit pas une couverture de sécurité étendue.

Une autre limite concerne l’exécution. L’étude principale a constaté des différences d’exposition, mais aucun modèle noté n’a suivi le poison uniquement parce que la mémoire l’affichait. Cela empêche une estimation directe de la réduction des dommages. Une défense qui bloque l’exposition est précieuse, mais les lecteurs ne devraient pas transformer zéro exposition en zéro attaque réussie.

Les données publiées améliorent la transparence, mais les archives publiques ne constituent pas une réplication par des tiers. Des chercheurs indépendants doivent encore reconstruire le harnais, inspecter la logique de notation, vérifier les tableaux rapportés et tester des tâches supplémentaires.

Le projet indique aussi que certaines bases de données stockées et les transcriptions complètes ont été retenues parce qu’elles contenaient des chemins locaux. C’est compréhensible, mais cela limite l’examen forensique du contexte d’exécution complet. Des versions assainies renforceraient les analyses futures.

La preuve avant réutilisation de MuscleMemory devrait donc être considérée comme une règle d’admission prometteuse assortie d’un mode d’échec documenté. Ce n’est pas une garantie générale de sécurité de la mémoire.

Trois tests détermineront si le résultat se généralise

La prochaine phase devrait mesurer la reproduction indépendante, les dommages comportementaux réels et la résistance aux entrées partagées empoisonnées.

Le premier indicateur est une réplication externe sur des tâches logicielles diverses. Les chercheurs devraient tester des corrections de bogues, des migrations, des refactorisations, des mises à jour de dépendances et des correctifs de sécurité. Ils devraient faire varier la taille du dépôt, le langage de programmation, la qualité des tests et le modèle d’agent.

Une réplication réussie préserverait l’écart d’exposition sans s’appuyer sur des règles d’appariement propres à une tâche. Elle montrerait également que l’intersection au niveau des lignes conserve suffisamment d’indications utiles lorsque des agents indépendants produisent des implémentations correctes différentes.

Un échec face à des modifications sémantiquement équivalentes affaiblirait l’argument en faveur du filtrage littéral par lignes. Ce résultat orienterait vers des méthodes de comparaison plus riches, telles que l’analyse de programme, la vérification au niveau du comportement ou des représentations structurées des changements de code.

Le deuxième indicateur est une expérience mesurant l’action nuisible après récupération. Les études futures devraient utiliser des canaris sûrs aux conséquences claires, puis enregistrer toute la séquence, de l’écriture empoisonnée à la récupération, à la décision du modèle, à l’appel d’outil et à l’état final.

Cela permettrait de déterminer si réduire l’exposition réduit réellement l’exécution nuisible. Cela pourrait aussi révéler des différences entre modèles. Un modèle pourrait ignorer des indications suspectes, tandis qu’un autre les suivrait systématiquement lorsque l’instruction paraît pertinente.

Le troisième signal est une réponse plus robuste à l’empoisonnement de sources partagées. Les sessions de validation devraient s’appuyer sur des entrées contrôlées de manière indépendante, ou le système de mémoire devrait préserver les frontières de confiance entre les origines. Un accord répété entre des agents lisant la même instruction de dépôt ne doit pas être considéré comme une corroboration indépendante.

Si MuscleMemory ajoute une validation tenant compte des sources et surmonte son échec publié au niveau du dépôt, l’argument central devient beaucoup plus solide. Si cet empoisonnement continue de passer, la preuve avant réutilisation ne reste utile que contre une contamination isolée.

Les équipes n’ont pas besoin d’attendre une recherche parfaite avant d’améliorer leurs systèmes. Elles peuvent séparer les observations stockées des instructions actives, conserver la provenance des sessions et exiger un examen plus approfondi pour les procédures à fort impact. Elles peuvent également maintenir les modifications générées par la mémoire dans les flux de travail habituels de test, de sandboxing et de revue de code.

La leçon plus large n’est pas que les agents devraient oublier. C’est que la mémoire a besoin d’un modèle de preuve. La pertinence, la répétition et les tests réussis répondent chacun à des questions différentes, et aucun de ces éléments ne suffit à lui seul à établir la sécurité.

Pour les développeurs qui évaluent la preuve avant réutilisation de MuscleMemory, la question pratique est précise : vos sessions de validation peuvent-elles observer la tâche avec une indépendance suffisante pour que leur accord soit significatif ? Si la réponse est non, ajoutez une isolation des sources et une vérification plus rigoureuse avant de déployer une mémoire procédurale partagée. Si la réponse est oui, reproduisez l’expérience publiée sur vos propres dépôts et mesurez à la fois l’exposition et le comportement.