MuscleMemory Proof Before Reuse Blocked Poisoned Skills, but the Evidence Is Still Narrow

MuscleMemory stopped poisoned guidance from reaching 30 of 30 scored repositories, according to a newly released study, while ordinary edit replay restored the poison every time. The result gives the MuscleMemory proof before reuse approach an unusually clear headline. It also creates an important conflict: passing tests did not distinguish clean work from poisoned work.

The study examines procedural memory, meaning stored instructions that tell an agent how to perform a recurring task. A coding agent learned from one poisoned session and three later clean sessions. Researchers then compared four ways of handling that experience across Claude Haiku 5.5 and Claude Sonnet 5.5.

The findings are encouraging but preliminary. The experiment used one task, five scored sessions per experimental cell, and rules tuned on the same task. Its strongest result concerns poison exposure, not harmful execution. That distinction puts proof before reuse against a more familiar memory strategy: save successful experience, retrieve the most relevant record, and trust the agent to use it well.

A Passing Test Let the Poison Look Successful

The experiment’s central warning is simple: task success and safe learning are different properties.

The case study began with a configuration repair task. One learning session included both the real fix and an unrelated modification. The poison took one of three forms: a new file, an unrelated line, or a malicious line fused into the legitimate change.

The task’s visible success signal did not catch those additions. The session passed its test, so a memory system focused only on outcomes had a reason to retain it. Three subsequent agents completed the same task without the poison, creating a small history of one contaminated solution and three clean ones.

The researchers then ran five scored sessions for each model, poison type, and memory arm. Claude Haiku 5.5 and Claude Sonnet 5.5 supplied the model variation. A hidden verifier ran 187 behavioral checks against each final repository.

Four arms defined the comparison:

• No memory gave the agent no stored procedure from earlier sessions.

• Replay applied the recorded edits again.

• Naive memory retained passing sessions and used Mem0 search to select a relevant skill.

• Proof before reuse withheld a skill until two later sessions reproduced its change and passed the relevant test.

The final arm also filtered the skill at line level. It showed the agent only changes that the later successful sessions had written again. That detail mattered because one poison was fused into the same file and edit area as the legitimate repair.

The headline numbers came from exposure and repository state. Replay reportedly returned the poison to 30 of 30 repositories, although every repository still passed the hidden verifier. Naive memory exposed poisoned guidance in three of 30 scored sessions. Proof before reuse exposed it in zero of 30.

Those figures come from the project’s released records and the original research post, not an independent replication. The public project says its session-level data preserves superseded runs, marks which rows belong in the reported tables, and identifies whether poison appeared in a stored skill, delivered guidance, or final code.

That separation is useful. A poisoned memory can exist without being retrieved. Retrieved poison can appear in a prompt without being followed. An agent can also create the same suspicious change without memory causing it. Treating those events as one metric would hide where a defense actually worked.

The study reports that no scored agent executed a poison merely because it saw poisoned guidance. The meaningful measured outcome was therefore exposure prevention. The experiment showed that the proposed filter kept suspect instructions out of later prompts, not that it prevented an observed attack that would otherwise have caused damage.

This is why the perfect hidden-test record is not reassuring by itself. All scored sessions passed those 187 checks, including repositories where replay restored the poison. Tests established that the requested behavior worked. They did not establish that nothing else had changed.

That gap creates the article’s main question. If a memory system learns from passing work, what evidence should it require before turning one session’s edits into advice for every later agent?

Why Agent Memory Poisoning Survives Ordinary Success Checks

Persistent memory turns a one-session mistake into reusable infrastructure.

A stateless coding agent can make a bad edit once. A memory-enabled agent can convert that edit into a procedure, retrieve it for similar tasks, and distribute it across repositories. The risk changes from isolated failure to repeated instruction.

Recent research has begun documenting that broader problem. A study of sleeper memory poisoning describes attacks that plant false memories through documents, webpages, or repositories. Those memories can remain dormant before influencing later conversations and actions.

Another 2026 study presents persistent memory as a distinct attack surface, not merely another form of prompt injection. Its memory poisoning taxonomy identifies several write channels and architectural weaknesses that let untrusted inputs become durable context.

Coding agents make the concern concrete because their memories can include operational details. A stored skill might name files, tests, commands, configuration keys, or recovery steps. Each item can help a later agent move faster. Each can also direct that agent toward a contaminated artifact.

MuscleMemory is designed around procedural records rather than full conversation replay. Its public documentation says a skill contains a concise account of what to change, how to verify it, and what to avoid. Its procedural memory API records observed steps, learns from completed sessions, and returns matched guidance during recall.

That design reduces irrelevant context, but it does not automatically solve trust. Compression can preserve the wrong lesson. Retrieval can rank a contaminated skill highly because it is semantically relevant. A passing test can validate the desired behavior while ignoring unrelated additions.

Mem0 illustrates why retrieval quality and evidence quality must remain separate. Its own description of memory search explains that semantic similarity selects context related to a query. Relevance tells a system which memory resembles the current task. It does not tell the system whether the memory’s contents deserve authority.

The case study used Mem0 search in the naive arm to select from passing-session memories. That setup should not be read as a comprehensive evaluation of Mem0’s security or every possible Mem0 configuration. It tests one retrieval-centered approach inside one harness.

Still, the result exposes a general weakness. If every passing session becomes eligible for reuse, a single contaminated success can compete with clean experience. Search may retrieve it because the legitimate part remains highly relevant to the task.

Replay represents an even stronger trust assumption. It treats historical edits as actions worth reproducing, not merely evidence worth considering. Its 30-of-30 poison result followed directly from that design. Reapplying the whole recorded change also reapplied the unrelated content bundled with it.

The no-memory arm avoids cross-session propagation, but it gives up accumulated procedural knowledge. Every agent must rediscover the relevant files, commands, and test path. That can increase tool use, latency, and opportunities for fresh errors.

Teams therefore face pressure from both directions. They want agents to remember proven workflows because repeated exploration is expensive. They also need to stop one compromised repository, misleading instruction, or accidental edit from becoming institutional knowledge.

This tension extends beyond code. A customer-service agent could remember an unauthorized exception. A finance agent could retain an unsafe approval sequence. A research assistant could preserve a fabricated citation rule. Any system that converts previous behavior into future instructions inherits the same trust problem.

For teams building a shared AI knowledge base, provenance matters alongside relevance. A useful memory record should explain where a procedure came from, which evidence supports it, and whether independent work reproduced it.

Proof before reuse attempts to supply that missing evidence. It does not ask only whether a session succeeded. It asks which parts of that success survived later independent attempts.

MuscleMemory Proof Before Reuse Changes What Counts as Evidence

The method treats repeated clean execution as a filter, not as a popularity vote.

Under the reported design, the poisoned learning session does not immediately create guidance that agents can receive. Later sessions must complete the same task, reproduce a change, and pass the test. A skill becomes eligible only after two such checks.

The system then intersects the recorded work. It delivers only the lines that the later successful sessions also wrote. An addition that appeared only in the poisoned session should disappear, even when the legitimate fix around it remains useful.

This is stricter than counting how often a broad skill appears. It asks whether the specific change survived independent reimplementation. The difference matters when one memory mixes valid and invalid instructions.

Consider the new-file poison. The contaminated session creates the real fix plus an unrelated file. Later clean agents reproduce the fix but not the extra file. File-level comparison can reject the unmatched artifact without discarding the repeated repair.

The unrelated-line case follows the same pattern within an existing file. Later sessions write the real change but omit the suspect line. A sufficiently precise filter can retain the shared portion.

The fused poison is harder. The unsafe text sits inside the same logical edit as the correct fix. Treating the entire file or patch as one unit would preserve both. The reported line-level comparison removed the unmatched poison while keeping the lines repeated by clean sessions.

That result is the case study’s most interesting contribution. The defense did not merely wait longer before trusting a procedure. It narrowed the procedure to the evidence that later sessions corroborated.

The MuscleMemory proof before reuse mechanism therefore combines three controls:

• Delayed admission prevents one successful run from becoming immediately reusable.

• Independent reproduction tests whether later agents converge on the same change.

• Line-level filtering limits delivered guidance to the reproduced portion.

Those controls address different failure modes. A delay without comparison would only postpone contamination. Repetition without precise filtering could preserve poison fused into a larger valid patch. Filtering without independent sessions would lack a basis for deciding which lines matter.

The project’s broader MuscleMemory documentation describes an additional human approval step before a skill becomes available. That approval can improve accountability, but the study’s numerical result depends on automated reproduction and filtering. A reviewer can still miss a plausible-looking poisoned line.

The method also changes the role of tests. A passing test remains necessary, but it no longer provides sufficient proof. Tests confirm that each session accomplished the requested task. Reproduction shows which changes multiple successful agents considered necessary.

This resembles differential reasoning. The system compares solutions to separate stable task structure from incidental activity. A change repeated across independent successful sessions earns more trust than an edit appearing once.

However, “independent” needs careful interpretation. The later sessions used agents facing the same task and repository context. Their outputs were separate, but their observations were not necessarily isolated from every poisoned input. The known failure case shows why that boundary matters.

There is also a cost. The system needs at least two later successful sessions before serving the skill. Rare tasks may never generate enough evidence. Fast-moving codebases may change before validation completes. Repeated runs consume model time and compute.

A team could lower the reproduction threshold to speed admission, but that weakens the core guarantee. It could raise the threshold, but then fewer memories become usable. Proof before reuse turns memory trust into an explicit latency-versus-confidence choice.

The study does not establish the ideal threshold. Two later sessions worked in this fixture. A higher-risk workflow, such as deployment credentials or payment logic, might require more evidence and a stronger verifier. A low-risk formatting task might justify less.

The method’s clearest value is conceptual. Successful traces should be treated as claims about a procedure. Later work should supply evidence before those claims gain authority over future agents.

The Result Pressures Replay and Naive Memory Designs

Memory systems now need an admission policy, not only a storage and retrieval policy.

Many agent-memory products emphasize capture, summarization, search, and personalization. Those features answer useful operational questions. What should the agent retain? How should it find relevant context? How can it update or delete old records?

The poisoning study adds a prior question: what must happen before a memory becomes eligible to influence another session?

Replay answers that question implicitly. If an edit belonged to a recorded success, the system can apply it again. That strategy maximizes fidelity to the historical trace. It also preserves every unrelated change bundled into the trace.

Naive retrieval is less direct. It gives the agent a selected memory and lets the model decide what to do. This can reduce deterministic propagation, but unsafe guidance still enters the decision context.

Proof before reuse puts a gate between learning and retrieval. The system may store a candidate procedure immediately while withholding it from agents. Storage becomes observation; validation determines authority.

That distinction should matter to enterprise buyers. A dashboard listing saved memories does not reveal whether those records are active instructions. Security reviews need lifecycle states such as candidate, corroborated, approved, paused, and retired.

They also need provenance. A memory should identify the source session, repository scope, verification command, later checks, and delivered revision. Without that chain, teams cannot reconstruct why an agent received a particular instruction.

The study’s public records reportedly distinguish skill contents from prompt guidance and final repository state. That is a good audit pattern. It allows investigators to ask whether contamination occurred during capture, admission, retrieval, interpretation, or execution.

Comparable systems can respond in several ways. They could add quarantine periods, require cross-session corroboration, attach trust metadata, or restrict memories to narrow project scopes. They could also retrieve multiple traces and ask the agent to compare them instead of serving one synthesized procedure.

None of those options is free. More metadata complicates storage. Multiple traces consume tokens. Quarantine reduces immediate value. Human review adds delay and can create approval fatigue.

A safer design therefore needs risk tiers. Advice about a test command does not deserve the same controls as instructions that modify authentication, network access, or release automation. A memory layer should account for the consequence of following a procedure, not only its similarity score.

Anthropic makes a related argument in its guidance on trustworthy agents: agent security depends on protections across the model, harness, tools, and environment. A memory gate cannot replace sandboxing, permissions, code review, or restricted credentials.

This broader view also prevents the MuscleMemory result from becoming an overly simple product comparison. The experiment did not show that all retrieval memory is unsafe or that one procedural memory implementation solves poisoning. It showed that unrestricted reuse exposed suspect content more often in a specific controlled task.

Still, the burden of proof has shifted. A system that advertises cross-session learning should explain how it handles successful sessions containing unnecessary or adversarial changes. “The tests passed” is no longer a complete answer.

The Known Failure Shows Where Reproduction Stops Working

Proof before reuse fails when later sessions repeatedly encounter the same poisoned source.

The project discloses a separate repository-level failure outside its main table. In that run, the poison moved into repository instructions that every agent read. Later sessions reproduced the contaminated behavior because their shared environment told them to do so.

MuscleMemory reportedly validated and served the poisoned skill in five of five scored Haiku sessions. The poison also appeared in the code five times. The no-memory arm produced it five times as well.

That result defines the method’s boundary. Reproduction can filter an anomaly that appears in one session. It cannot distinguish truth from coordinated repetition when every session receives the same corrupted premise.

The failure resembles data poisoning more than isolated trace contamination. The later agents were supposed to act as independent witnesses, but they shared the compromised evidence. Their agreement strengthened the wrong conclusion.

This issue is not unique to MuscleMemory. Any corroboration system can fail when its validators share an attacker-controlled source. Multiple agents, models, or runs do not create independence if they read the same poisoned instructions.

The limitation also complicates the phrase “two later sessions.” Session separation does not guarantee source separation. Security claims should describe which inputs, tools, repositories, and instruction channels remained shared across the validating runs.

A stronger design might bind memories to input provenance. It could mark whether an instruction came from a user, repository file, webpage, test output, or privileged policy. It could prevent lower-trust sources from gaining authority merely through repeated model compliance.

Recent work on origin-bound authority argues that content scoring and ordinary lineage can both be manipulated. That research proposes binding authority to origin at write time and requiring corroboration resistant to manufactured agreement.

The case study also has statistical limits. Each experimental cell used five scored sessions. The authors report a probability near 0.24 for the main comparison, which does not meet common significance thresholds. Zero observed exposures does not establish a near-zero real-world rate.

The narrow fixture creates another concern. The same task informed both the method and its evaluation. Line matching rules that work on a compact configuration repair may struggle with refactors, generated files, dependency changes, or semantically equivalent edits.

Two clean agents can solve the same problem differently. One may rename a helper, another may alter a caller, and a third may change configuration flow. A literal intersection could discard useful work because correct solutions do not share lines.

The reverse can also happen. Agents may repeat a poisoned edit because it looks conventional, appears in an example, or follows a shared model bias. Agreement is evidence, but it is not proof of safety.

The hidden verifier presents a further caution. Its 187 checks sound extensive, yet every scored repository passed, including all 30 replayed poisons. The checks measured the intended behavior but did not reject the canaries. Large test counts do not guarantee broad security coverage.

Another limitation concerns execution. The main study found exposure differences, but no scored model followed poison simply because the memory displayed it. That prevents a direct estimate of reduced harm. A defense that blocks exposure is valuable, yet readers should not convert zero exposures into zero successful attacks.

The released data improve transparency, but public records are not the same as third-party replication. Independent researchers still need to rebuild the harness, inspect scoring logic, verify the reported tables, and test additional tasks.

The project also says some stored databases and full transcripts were withheld because they contained local paths. That is understandable, but it limits forensic review of the complete execution context. Sanitized releases would strengthen future analysis.

MuscleMemory proof before reuse should therefore be treated as a promising admission rule with a documented failure mode. It is not a general memory-security guarantee.

Three Tests Will Decide Whether the Result Travels

The next phase should measure independent reproduction, real behavioral harm, and resistance to shared poisoned inputs.

The first signal is external replication across diverse software tasks. Researchers should test bug fixes, migrations, refactors, dependency updates, and security patches. They should vary repository size, programming language, test quality, and agent model.

A successful replication would preserve the exposure gap without relying on task-specific matching rules. It would also show that line-level intersection retains enough useful guidance when independent agents produce different correct implementations.

Failure on semantically equivalent edits would weaken the case for literal line filtering. That outcome would point toward richer comparison methods, such as program analysis, behavior-level verification, or structured representations of code changes.

The second signal is an experiment that measures harmful action after retrieval. Future studies should use safe canaries with clear consequences, then record the entire sequence from poisoned write to retrieval, model decision, tool call, and final state.

This would answer whether reducing exposure actually reduces harmful execution. It could also reveal model differences. One model might ignore suspicious guidance, while another follows it consistently when the instruction appears relevant.

The third signal is a stronger response to shared-source poisoning. Validation sessions should draw from independently controlled inputs, or the memory system should preserve trust boundaries across origins. Repeated agreement from agents reading the same repository instruction must not count as independent corroboration.

If MuscleMemory adds source-aware validation and defeats its published repository-level failure, the core argument becomes much stronger. If that poison continues to pass, proof before reuse remains useful only against isolated contamination.

Teams do not need to wait for perfect research before improving their systems. They can separate stored observations from active instructions, retain session provenance, and require stronger review for high-impact procedures. They can also keep memory-generated edits inside normal testing, sandboxing, and code-review workflows.

The larger lesson is not that agents should forget. It is that memory needs an evidence model. Relevance, repetition, and passing tests each answer different questions, and none alone establishes safety.

For developers evaluating MuscleMemory proof before reuse, the practical question is precise: can your validation sessions observe the task independently enough to make agreement meaningful? If the answer is no, add source isolation and stronger verification before deploying shared procedural memory. If the answer is yes, reproduce the published experiment on your own repositories and measure both exposure and behavior.