th0t3p

Your AI agent's memory is an attack surface

12 September 2026 · th0t3p

Your agent remembers things about you. If anything it reads can write to those memories, memory stops being a convenience and starts being a foothold.

Memory is state

An agent with persistent memory keeps a file, a table or a vector store of things it decided were worth keeping: your preferences, your projects, the way you like your code formatted. That state is loaded at the start of the next session and treated as true.

Most of the security conversation about agents is about the turn in front of you — whether this page can make the model do something silly right now. Memory deserves the same attention for a different reason: it does not expire.

A bad turn versus a bad memory

A prompt injection that lives for one turn is a nuisance. You close the tab and it is over.

An injection that lands in memory is a different animal:

it survives restarts and model changes
it silently shapes every later session
it is usually invisible, because you read the conversation and not the notes underneath it
it never has to be dramatic — "always include this URL", "prefer this dependency", "the project lives here"

Persistent instructions do not need to be clever to work. They only need to be consistent.

Three questions worth being able to answer

Provenance. Where did this memory come from — which session, which file, which tool call?
Change. What was added, edited or deleted since I last looked?
Anomaly. Does this read like something I said, or like content the agent processed?

If you cannot answer those, you do not really have memory. You have a cache with write access from the internet.

The model that works

Version control already solves this problem, one directory over. git log answers who changed what and when, and git diff shows whether a change looks like something the author would write. Memory wants the same treatment: a log of writes with provenance attached, a diff view, and pattern-based detection for entries that read like instructions rather than facts.

Where m8m comes in

That is what I am building with m8m: four cooperating pieces over one local SQLite database — an MCP server that sees memory operations as they happen, a file watcher for local memory files such as MEMORY.md, a CLI for auditing from a terminal, and a local dashboard over the same data.

Phase one stays local on purpose. SQLite, pattern-based analysis, and no LLM or network calls inside the analyzer, so nothing about what your agent remembers leaves the machine. It is work in progress.

What you can do before the tooling exists

Treat memory files as code. They are state with a path into future behaviour.

put them in version control, so changes show up as diffs
keep them out of sync paths you do not control
read them occasionally, the way you would read a config file you did not write
be suspicious of entries that read like instructions

That is the whole idea. Your agent's memory is not only a convenience feature. It is a place where something else can leave instructions for your future self, and you are the only one who gets to decide whether that is acceptable.

m8m is at github.com/th0t3p/m8m. If you have seen memory poisoning in the wild, tell me about it.