A poisoned preference line in agent memory reloads itself into every session

What a coding agent stores is a markdown file with a bullet list in it, and that file loads into the front of every later session ^[2]. The format holds the text of each line and nothing about where it came from or when it arrived. The post's worked example inserts two entries between three real preferences. One tells the agent to include full file paths and environment variables whenever it shares a code snippet; the other names an outside email address that should receive copies of any financial analysis ^[6]. Both parse as preferences.

For MemGhost's success rate to mean anything on your machine, your agent has to read attacker-controlled email and run an extraction step that promotes what it read into a stored fact. A Claude Code install that only ever reads your own repository does not have that path. MemoryGraft is the result that lands closer to a working developer. You clone a repository, the agent reads the README, and weeks later it is still following the planted instructions because they sit in memory as learned experience ^[4].

Divide the Microsoft figure and it comes to about 1.6 attempts per affected company, and fewer than one a day across the whole set ^[13]. The 87.5 percent is exactly seven eighths, so the trial count is a multiple of eight, and the post does not state it ^[14]. In my view the case for auditing memory rests on persistence. An input filter sees one request. A memory file is read at the start of every session after the write.

The author describes the gap in tooling people have already adopted. MCP scanners check tool descriptions. Injection detectors scan inputs in real time and do not catch an injection that happened last week and now lives in persistent storage. Configuration auditors check whether the agent is set up safely ^[9]. The named examples are Snyk Agent Scan and Cisco mcp-scanner, Seclai and prompt-shield-ai, and AgentShield ^[8]. "Memory sits in a blind spot between all these tools," the author wrote ^[10].

The memory platforms are pointed elsewhere. Mem0 has 61,000 GitHub stars and has raised $24.5m, and the post argues security is not part of its architecture, with its extraction pipeline vulnerable to the same prompt injection it ingests ^[11].

The tool the post announces, m8m, is four cooperating pieces over one local SQLite database, including an MCP server that runs alongside the agent, monitoring what is stored, tracking where each memory came from and flagging anything suspicious ^[12]. Per-memory provenance is the part worth having, and it is the part a bullet list cannot supply. "There was no way to see what Claude Code had stored about me, when it changed, or whether any of it had been tampered with," the author wrote of checking their own agent after reading the Microsoft finding ^[7].

One caveat on the evidence. All of this comes through a single dev.to post written by the engineer who built the monitoring tool, and the Microsoft count and both attack papers are relayed there, unlinked ^[15]. The vector does not depend on the count. Putting the memory file under version control costs nothing and gives you a diff and an author per line. It still will not tell you which session wrote the line, or what the agent was reading at the time.