Assume this happened. What can you actually do?
If memory records carry Origin and SourceTaskId, quite a lot. You can enumerate every record written by a task that touched a given ticket, see which ones are tainted, and review or delete them. The blast radius is a query.
Without those columns you are reading rows and guessing. There is no way to distinguish a note the model inferred from a customer's claim from a note your code wrote after a successful refund, because both are strings in the same column.
This is the argument for the provenance column that persuades people who were unmoved by the security case. It is the difference between an incident that takes an afternoon and one that ends in a decision to wipe all agent memory, which is what teams do when they cannot tell the good rows from the bad.
Chapter 8 used expiry against authority. The same idea works against persistence.
A memory that never expires is an attack that never expires. Give model-written memory a lifetime, make it short by default, and require an explicit decision to extend it. Most agent memory is worth less after a week than teams assume, and the cases where it genuinely matters are worth declaring individually.
For the corpus, the equivalent is re-indexing with fresh provenance rather than trusting tags written by an older version of your pipeline.
One asymmetry worth noting. Most of this chapter is about the write path, because that is where the poison enters. The read path is where it pays off, and it is cheaper to defend.
A memory record retrieved into the planner's context is untrusted content arriving through a channel your chapter 3 audit probably recorded as internal. Route it through chapter 7's quarantine like any other untrusted source, and the stored instruction never reaches the component that holds the tools.
Teams that cannot face re-architecting their write path can often do this instead, in an afternoon, and get most of the benefit.
The agent gets less useful, and this one is not recoverable by cleverness.
An assistant that remembers everything feels better than one that remembers only what your code established. Users notice. The feature that made the demo work is partly what this chapter is removing, and that argument will be had in a product meeting rather than a security review.
The defensible position is not that memory is dangerous. It is that memory written by a model that reads untrusted content is an attacker-writable database, and it should be sized and scoped like one.
Chapter 13 turns to code nobody on your team wrote.
| Claim | Source | Status |
|---|---|---|
| Vector and Memory Flaws as an OWASP 2026 category (LLM07) | https://cybersecuritynews.com/owasp-genai-llm-top-10-2026/ | SECONDARY |
| Vector and Embedding Weaknesses in the 2025 edition | https://genai.owasp.org/llm-top-10/ | PRIMARY |
| Data and Model Poisoning as a standing category | As above | PRIMARY |
The laundering mechanism, the split between facts the system established and things the model concluded, the MemoryRecord shape with a persisted origin column, and the argument that corpus write access is equivalent to agent write access are the author's. The claim that provenance loss across a storage round trip is "the single most common way" a provenance system fails is experience rather than a measured finding. The assertion that most agent memory is worth less after a week is a judgement offered to be argued with.
Download the full PDF for free?
Free download — no account required