Persistent memory turns one bad write into a future input. Memory poisoning is not only a prompt-injection problem: it is a storage, identity, provenance, and retrieval problem.
This guide covers controls AllSource users can verify. It does not claim an event store makes hostile content safe by itself.
Threat model
Four failures matter most:
- Untrusted writer: a user, tool, document, or compromised agent writes a false instruction as durable memory.
- Cross-tenant recall: a query returns another tenant's events or derived memory.
- Provenance loss: a summary survives but observation and transformation that created it cannot be inspected.
- Over-broad recall: a semantically similar result enters a high-impact workflow without scope or verification.
Separate observation from instruction
Store external text as observation with source identity. Do not silently promote it into instruction. A document saying “ignore previous policy” is evidence about that document, not authority over agent.
Use distinct event types for observed content, approved decisions, and policy changes. Restrict policy-changing writers more tightly than ordinary memory writers.
Scope every operation
Every write and read needs tenant identity, entity or workspace scope, and tool-level authorization. Prefer one named key per agent. Analysis agents usually need read-only history; ingestion workers need narrow write surface; administration belongs in separate connector and credential.
Test isolation with negative cases. Attempt read using another tenant identifier and verify rejection. Do not infer isolation from successful same-tenant query.
Preserve provenance
A recalled item should point to source events, timestamps, and transformations. If memory is summary, retain references to observations it summarizes. If decision changes, append correction or superseding event instead of rewriting history.
Provenance supports correction and investigation. Current memory can derive from latest valid decision while original sequence remains available to show how poisoned state entered system.
Bound recall
Set result limits, event-type filters, time windows, entity scope, and minimum relevance. Broad “give me anything similar” queries are unsafe in consequential workflows. Financial, legal, permission, or deployment decisions should require source inspection before action.
Handle “no result” explicitly. Empty recall can mean no memory, stale projection, failed embedding, wrong tenant, expired key, or overly strict filters. MCP memory server guide separates those checks.
Audit writes and tool calls
Record who wrote memory, which tool accepted it, source identity, tenant, timestamp, and correlation ID. Monitor repeated writes, unusual event types, sudden graph expansion, privilege changes, and cross-workspace lookup attempts.
Event history helps because investigation does not depend on attacker leaving current state untouched. Replay still needs controlled scope; use replay analysis contract.
Response checklist
When poisoning is suspected:
- revoke affected writer credentials,
- identify first untrusted event and downstream derivations,
- append correction or invalidation events,
- rebuild affected projections or memory indexes,
- verify active generation against known-good events,
- retain audit evidence according to policy,
- add regression test for input path.
Durability makes evidence available. Scoped identity, provenance, and controlled replay make that evidence operationally useful.
