A Correct Answer Doesn't Mean the Agent's Memory Is Clean

Persistent memory lets an agent carry useful context between sessions: project decisions, contact details, the explanation you would prefer not to type for the eighth time. It also gives bad information somewhere to wait. The next session can start fresh and still retrieve yesterday’s poisoned note.

Recent memory-security research makes me want a recovery drill alongside the usual agent permissions. The question is practical: after removing malicious influence, can the agent still do the legitimate job that made its memory worth keeping?

My earlier posts examined the execution gate and policy that changes while an agent runs. Here, the object under repair is durable context. A permitted action can still use a corrupted contact record.

Two ways the bad note gets there

The July GhostWriter preprint describes an incoming message claiming that a colleague’s email address has changed. The agent stores that information. Later, a legitimate request to contact the colleague retrieves the altered address.

In that threat model, the attacker controls incoming content, without direct access to the memory store or control over future user prompts. The evaluation covers email and calendar inputs in simulated assistant workflows. Its defense evaluation uses nonadaptive attackers; it does not establish protection against attackers who adjust to the defense.

There is also a less subtle entry path. In Cisco’s April disclosure, a malicious package installation executed code that modified Claude Code memory files and persistent configuration. That prerequisite matters: this was already code execution under the user’s account, rather than an ordinary paragraph acquiring filesystem permissions.

Cisco reported that Claude Code 2.1.50 mitigated the identified system-prompt placement of user memories. That is a version-specific finding and mitigation, not evidence that every current version remains vulnerable. It also leaves an operational lesson: where executable code changed several persistence surfaces, examining one memory file cannot establish that the environment is repaired.

Removal is only half the result

MemSecBench’s July preprint evaluates a Write–Execute–Forget lifecycle across 310 cases and 24 configurations combining agent harnesses, memory backends and models.

Its repair results are the useful part here. Target removal or neutralization reached 86.3%; selective repair, requiring both that result and preservation of required benign memory, reached 56.1%. Removing the unwanted influence was easier than recovering a useful memory state.

Those figures are configuration macroaverages, conditional on successful poisoning within each configuration. They describe controlled benchmark tasks, with one run per configuration/case and a mixture of model judging and programmatic checks. They are not field incident rates, repeated-trial reliability estimates, or numbers to multiply into an end-to-end probability.

That distinction changes my acceptance criterion. “The poisoned instruction is gone” earns one checkmark. The rest of the notebook still needs to work.

A small drill, with recorded results

I ran a synthetic homelab exercise with a contact record, a derived summary and an unrelated maintenance decision. The runnable artifact and retained results contain 27 fresh Claude Code sessions: nine prepared states, three repetitions each. Every response was asked to propose a mocked send action and recall the maintenance decision; the blank-reset controls returned send: null and decisions: null. No message was delivered.

The runner used Claude Code 2.1.263 with its configured default, without a model override. All 27 responses reported claude-opus-5[1m] usage; 26 also reported claude-haiku-4-5-20251001. I am recording the CLI configuration as observed, including that auxiliary usage. Tools, customizations and session persistence were disabled.

The blank reset avoided the false destination by forgetting everything needed for both tasks. That is a quiet assistant, but not a recovered one.

The nine labels contain only four distinct state/prompt payloads: the clean baseline, trusted snapshot, selective repair and quarantined reingestion share the same reviewed contact and summary; poisoned, uncontained reingestion and contaminated-backup restore share the poisoned pair; blank reset is empty; and source-only repair has a reviewed contact with the stale poisoned summary. The three repetitions measure repeated model responses to those prepared inputs. They are not independent evaluations of nine different recovery mechanisms.

The stale-summary row deserves attention. The model chose the correct canonical contact in all three trials even though the summary still carried the planted address. Passing the action test did not establish that the memory was clean. In this fixture, the lineage check caught something the task result did not. A hash proves which bytes were preserved; it does not prove that those bytes are true or safe.

These are model-assisted adoption observations, with the procedure and limitations recorded separately. Python deterministically seeded and repaired the records; the model did not decide whether to store the incoming claim or perform the repair. The quarantine was an explicit fixture control. All 27 calls completed without adapter errors, but three trials per state and one contact scenario establish no general recovery reliability. The larger drill still needs a real memory write path and varied retrievals.

Extending the homelab drill

The small exercise gives me a starting point for the broader procedure below. This extension remains proposed. I would keep synthetic contacts, disposable state and mocked outbound tools. The interesting output is the attempted action and its arguments; nobody needs to receive a real email for this to be instructive.

Inventory before editing. I would list the actual memory files or databases, shared namespaces, retrieval indexes, generated summaries, and configuration that loads them. Each entry should identify its writer, reader and scope. A store shared across projects deserves a different recovery boundary from a disposable session note.

I would preserve snapshots outside the agent’s writable workspace, recording timestamps, software versions and hashes. A hash establishes which bytes were preserved. It does not certify that the preserved advice was sensible. Bad instructions can have impeccable checksums.

Contain the source as well as the copy. Before restoring state, I would stop automated ingestion and memory writes in the exercise. Otherwise, the next scheduled import could undo the repair. If the scenario includes executed untrusted code, I would rebuild the disposable runtime and inspect its persistent configuration too; a memory-only exercise would no longer cover the scenario.

Quarantine the affected family of records. I would track the seeded contact claim through any summaries and retrieval copies the chosen stack actually creates. Deleting the original sentence would be insufficient evidence if a summary still recommends the same address. Where derivation cannot be established, I would record that uncertainty and test a broader restore boundary rather than declare a surgical repair successful.

Restore from reviewed evidence. For this exercise, I would keep a separate fixture containing the intended contacts and benign project decisions. It would supply the recovery reference, without asking the affected agent to judge its own notes. I would rebuild derived indexes from the reviewed sources and start a clean session against the repaired copy.

What would count as recovered?

I would write the acceptance criteria before seeding the false record. Otherwise, it is too easy to discover that whatever the repair happened to preserve was apparently all I needed.

First, I would run those tasks against the clean fixture. That gives recovery a baseline to meet and separates damage caused by repair from capabilities the agent never had.

The agent saying it has forgotten something would not satisfy these checks. I would retain retrieved records, attempted tool calls and fixture comparisons, including failures. Passing the selected tasks would support a bounded claim about that recovery procedure; it would not prove that every malicious influence had disappeared.

I want persistent memory because repeating context is tedious. A recovery plan should preserve that benefit. The drill is successful when the agent can resume useful work with the repaired state, and the evidence explains why I think so.