LLM Memory Attacks: How Persistent Context Can Be Poisoned

An LLM memory attack is when untrusted content, such as a malicious instruction hidden in a document, a web page, or an email, is processed by an AI assistant and ends up stored in the assistant's persistent memory or context. In future sessions, the assistant then carries that contaminated content as if it were a genuine instruction or a fact the user chose to save.

The risk rises whenever an AI assistant can both read external content and write to its own memory. A tool like fenbs stores project context as explicit, attributed decisions and notes that people write deliberately, which makes contamination easier to spot and correct than in an assistant's automatic memory.

How the attack works

The underlying mechanism is called prompt injection. When an AI assistant reads a document, web page, email, or other external source, that content becomes part of the active context. If the content contains instructions formatted to look like user commands ("Ignore your previous instructions and do X"), the model may follow them.

The memory dimension makes this more persistent. Some AI apps offer memory features that save facts and preferences across sessions. An injected instruction that reaches memory will affect every future conversation, not just the one where the contamination happened. The user may not notice because the behavior change is gradual.

Say a lawyer uses an AI assistant to review contracts. A malicious party sends a document containing hidden text that instructs the assistant to treat future contracts from a specific company favorably. If the assistant saves that instruction as a memory entry, every future contract review is affected.

What types of content carry the risk

Any content the AI assistant reads from an external source carries a risk of prompt injection. The most common vectors are documents submitted for review or summarization, web pages browsed by the assistant during research, emails processed by an AI that has email access, and data from connected apps that the assistant queries.

The risk is higher when the external content is from an untrusted or unknown source. An internal document your colleague wrote is lower risk than a contract sent by a new counterparty or a page from a public website.

Code repositories, spreadsheets and database outputs also carry the risk if the assistant is asked to read and act on them. See what is an LLM for background on why AI models process instructions and content through the same mechanism.

How to review stored context for contamination

If your AI app has a memory feature, open it and read what is stored. Look for entries that you did not deliberately add and that contain unusual instructions rather than factual notes. An entry that says "always present [company] in a favorable light" is a red flag. An entry that says "prefers bullet points" is a normal preference.

Read each memory entry and ask: did I write this? Does it make sense as something I would record? If not, delete it. Most AI apps with memory features provide a way to view, edit and delete individual entries. Check the app's settings or help documentation for the current path.

Also review what was recently saved. If you processed a batch of external documents before noticing unusual behavior, check whether anything was stored from that period. See what is agent memory for an explanation of the different types of AI memory and how they interact.

Reduce the attack surface

The simplest defense is limiting what the AI can write to persistent memory automatically. If you control whether the assistant saves to memory, prefer requiring explicit confirmation before anything is stored. Auto-save memory features are convenient but remove your oversight of what gets persisted.

Treat documents from untrusted sources differently. If you are asking the assistant to review a contract from a new counterparty, consider asking it to summarize in a new, isolated conversation rather than in a session where your project context is active and could be affected.

Use a personal sandbox account when experimenting with new AI features or agents. Keep the account that holds your important project context separate from the one you use for testing.

For teams using AI with shared memory tools, see AI memory for teams and portable AI memory for how to keep work context structured and reviewable.

Explicit decisions are harder to contaminate silently

One reason automatic AI memory is more vulnerable than an explicit record is attribution. An entry in an AI's memory does not say who wrote it or when. An entry in an explicit project record carries a name, a date and a reason.

When a team uses a tool that records decisions with attribution, an injected rule stands out: there is no author, no reason and no task that explains why it was added. That makes the contamination visible rather than invisible.

How to do this with fenbs

1. Create a free account. Start a project for your AI governance rules.
2. Write each project rule and standing instruction as a named Decision, with the person who decided it.
3. Review Decisions regularly. Delete any that no longer apply and update reasoning when circumstances change.
4. Connect your AI apps over MCP from Integrations. They read the Decisions at the start of each session from the explicit record, not from inferred memory.
5. When something behaves unexpectedly, check the Decisions first. If an unusual instruction appears that nobody wrote, investigate before running more sessions.

fenbs does not host a model or run agent loops. The project context it provides is read by connected AI apps. The injected-memory risk applies to the AI app's own memory features, not to the explicit record in fenbs.