How do I prevent stale or poisoned agent memory?

Scope

Use this lifecycle for persistent agent memory that can influence later sessions, users, tools, or decisions. It covers the platform controls around memory. The separate security guide explains how poisoning survives across sessions; the observability guide covers memory lineage telemetry.

Why it happens

Memory APIs make a write look like a convenience function: extract a preference or lesson and place it in a store. The stored sentence loses the conditions that made it valid. A one-time user instruction becomes a permanent rule, an outdated deployment fact survives a release, or untrusted document text is promoted as an organizational preference.

Retrieval then creates implicit trust. The model sees memory beside system-managed context and may not know which record came from a verified owner, an old session, a tool result, or an attacker-controlled page. Similarity ranking is not an authorization or freshness check.

Diagnosis

Select ten records that influenced recent decisions. For each, answer:

1. Who or what proposed the write?
2. Which source event or artifact supports it?
3. Who authorized its scope and retention?
4. When was it valid, observed, and last verified?
5. Which users, agents, tasks, and tools may retrieve it?
6. What conflicts with or supersedes it?
7. Which outputs and effects used it?
8. Can the platform quarantine, correct, expire, and delete it transitively?

If these answers cannot be reconstructed, the store is a text cache rather than governed memory.

Solution

Create at least three zones: session scratch, candidate memory, and promoted memory. Session scratch expires quickly and remains scoped to one task. Candidate memory has full provenance but cannot affect high-impact actions. Promotion requires policy checks and, for sensitive or cross-user records, a qualified reviewer.

At retrieval, filter by tenant, subject, task purpose, sensitivity, valid time, expiry, and policy before semantic ranking. Return record IDs and provenance with the text. Surface conflicting active records instead of asking the model to silently choose. Revalidate action-relevant facts against an authoritative source at commit time.

Keep append-only change history for governance while ensuring the serving path honors correction and deletion. Test rollback by seeding a poisoned record, observing where it propagates, and proving that invalidation removes its influence.

Artifact

Apply this checklist to every memory class:

Lifecycle point	Required control
Proposal	Capture proposer, source artifact, task, and exact candidate content
Admission	Validate type, authorization, sensitivity, provenance, and prohibited content
Scope	Bind tenant, subject, purpose, agent, tools, and audience
Time	Record observed, valid-from/to, expiry, review, and supersession
Promotion	Separate policy and reviewer for broader or higher-impact reuse
Retrieval	Filter scope/time/policy before similarity; return conflicts and lineage
Use	Log record version, decision, and resulting effect reference
Correction	Append new version and stop serving superseded content
Quarantine/rollback	Disable affected lineage and rebuild derived indexes
Deletion	Propagate to caches, summaries, embeddings, exports, and backups by policy

Common mistakes

• Saving a model-generated summary without the source record.
• Treating user-provided text as authorized cross-user memory.
• Ranking by similarity before applying tenant and time filters.
• Overwriting a record and losing the history needed to trace bad effects.
• Testing memory recall while never testing poisoning, expiry, conflict, and deletion.