Do we have memory if we never built a memory feature?

Possibly. Conversation summaries, cached retrievals, stored embeddings and saved user preferences are all content written now and read later, which is the property that matters. The label on the feature is not what makes it a store.

Why re-check content we already validated?

Because the check that let it in was written against the attacks known at the time, and the entry may outlive that by a long way. Re-checking on recall is what makes storage stop being an implicit trust decision.

Is this the same as data poisoning?

Not in the usual sense of the term, though usage varies. Data poisoning generally means corrupting the data a model is trained on, which changes the model itself. Context poisoning leaves the model alone and corrupts what you hand it at run time, which is why the remedy is removing entries rather than retraining, provided you can find every place the entry was copied to.

How would we find a poisoned entry?

Through provenance and an audit trail of what entered the store. Without a record of where an entry came from you can see that answers changed and not which entry changed them, which usually ends in clearing the whole store.

Does expiry actually help?

It bounds how long a missed entry keeps working, which is a real reduction, not a prevention. It is most valuable where the stored content is a convenience and not a record, because there the cost of losing it is close to zero.

What is context poisoning?

Context poisoning is when content the system should not have trusted gets written into memory, a cache or a summary, and is later recalled and treated as trustworthy because it is already stored. It turns a single successful injection into a persistent one. The mistake underneath it is treating storage as a trust boundary: something does not become reliable by having been saved.

How a single attempt becomes a standing one

A system that summarizes a conversation, remembers a preference, or caches a retrieved passage is writing down something derived from content it read. If that content carried an instruction and the summary preserved it, the instruction is now in a store the system consults by default.

The next session does not look like an attack. There is no hostile document in the retrieval results, because the payload is already inside, in a place the system reads without suspicion.

The two controls that matter

Validate at the write path, so untrusted content does not enter the store unchecked in the first place. Then re-check at recall, so that being stored does not confer trust. The second is the one that gets skipped, because it feels redundant, and it is the one that catches everything the first missed.

Both are needed. Validating only on write assumes your write-path check is complete, which is the same assumption input filtering makes and fails for the same reason.

Scope and expiry

Memory shared across users means one person's content becomes another's context, which is a boundary failure before it is an injection. Scope per user or per session, and keep anything system-level read-only to the model, so it cannot edit the instructions it will later obey.

Then give entries a life span. A store with no expiry accumulates everything that ever entered it, including the thing you would remove if you knew it was there.

Common questions

Do we have memory if we never built a memory feature?: Possibly. Conversation summaries, cached retrievals, stored embeddings and saved user preferences are all content written now and read later, which is the property that matters. The label on the feature is not what makes it a store.
Why re-check content we already validated?: Because the check that let it in was written against the attacks known at the time, and the entry may outlive that by a long way. Re-checking on recall is what makes storage stop being an implicit trust decision.
Is this the same as data poisoning?: Not in the usual sense of the term, though usage varies. Data poisoning generally means corrupting the data a model is trained on, which changes the model itself. Context poisoning leaves the model alone and corrupts what you hand it at run time, which is why the remedy is removing entries rather than retraining, provided you can find every place the entry was copied to.
How would we find a poisoned entry?: Through provenance and an audit trail of what entered the store. Without a record of where an entry came from you can see that answers changed and not which entry changed them, which usually ends in clearing the whole store.
Does expiry actually help?: It bounds how long a missed entry keeps working, which is a real reduction, not a prevention. It is most valuable where the stored content is a convenience and not a record, because there the cost of losing it is close to zero.

Find out where you stand

The assessment on this site asks up to 21 questions about what your system can reach, and returns a score, a verdict and, where a control is short, the one thing to fix first. It takes about ten minutes, and questions your deployment shape has no surface for are dropped rather than scored against you.

It is a self-assessment of design and evidence, not a penetration test, not an audit of a running system, and not a certification.

Run the assessment