Memory and Context Poisoning
The only attack surface that survives logout. A poisoned memory is a prompt injection with a fuse — and the fuse crosses the session boundary. B2's five layers all live inside the context window and die with the session; memory persists, and it is loaded as trusted by default, so a poisoned entry routes around every B2 layer. This module attacks the memory and the retrieval store (sleeper attack, RAG poisoning, context-window flooding, cascading hallucination — OWASP ASI04 and ASI06), then builds the defense: harness-managed writes (model proposes, harness validates, only the harness commits) and a provenance-tagging read path that makes B2's layers apply to the memory surface.
Persistence is the property that makes memory a categorically different attack surface from the context window. Long-term memory survives logout/login/refresh/version bump; the context window dies with the session. An injection in the context window lives one session; an injection in memory lives until someone finds it. This is why OWASP ranks Memory Poisoning (ASI04) as distinct from prompt injection (ASI01) — injection is the delivery mechanism, memory is the persistence mechanism. A prompt injection that reaches memory is a permanent backdoor, and it routes around all five B2 layers because memory is loaded as trusted before the tagger runs.
The sleeper attack (Course 1 Module 4.3) is the canonical memory poisoning — and its load-bearing failure is the unvalidated READ, not the injection. Inject in session 1 (inert seed), persist across the boundary, activate in session 2. The seed survives because the memory loader trusts its own store and never re-checks a poisoned entry before promoting it to the context window. The two events may be days apart, in different contexts — which makes the attack harder to attribute than a same-session injection. The persistence amplification is real: one delivery fires on N sessions (or N users for shared retrieval).
The defense is harness-managed writes: the model PROPOSES, the harness VALIDATES, only the harness COMMITS. Three checks in order — provenance (where did it come from), trust level (derived from provenance), content (does it look like an injection). The load-bearing line is the conjunction: if (untrusted AND instruction-like) → DENY. This catches the sleeper seed's signature deterministically while passing a trusted user preference and an untrusted factual chunk. The model never touches the store directly; there is no save_to_memory tool. Every write goes through the gate, tagged with provenance, trust, writer, and validation result for audit.
Defense in depth: gate the writes, tag the reads, connect to B2. The write gate reduces volume; the read path tags entries by trust level (untrusted AND semi_trusted get B2 Layer 1 tags) so B2's Layer 3 taint gate applies on the next session — catching any residual that slipped through. Retrieved-content taint tagging is the connection point: B3 is the memory-surface extension of B2's L1. A poisoned memory that cannot be written cannot wake; one that slipped through is tagged on read and hits the taint gate deterministically.