"What are the two memory surfaces of an agent, and what is the architectural property that distinguishes them?"	"(1) LONG-TERM MEMORY — persists across sessions; stored outside the model (DB, vector store, files); loaded into the context window at session START before the user types anything; survives logout/login. (2) CONTEXT WINDOW — per-session; system prompt + conversation history + retrieved context + tool outputs for THIS turn; born at session start, DIES at session end. The distinguishing property is PERSISTENCE. That single property is what makes memory a categorically different attack surface — an injection in the context window lives one session; an injection in long-term memory lives until found and removed."	c2b::b3::recall
"Why is memory trusted by default, and why is that the foundational error the sleeper attack exploits?"	"The harness author classifies memory as TRUSTED when they build the loader — memory is loaded as privileged context (the agent treats its own memory as ground truth). So memory reads get NO B2 Layer 1 tag (the tagger runs after the memory load) and NO B2 Layer 3 gate (memory-sourced content isn't marked tainted). The defenses are intact; the attack ROUTES AROUND them through the memory store, which loads as trusted. A memory store loaded as trusted is a store that assumes every write was legitimate — and the sleeper attack writes a seed that is illegitimate."	c2b::b3::recall
"Describe the sleeper attack (Course 1 Module 4.3) across its three phases."	"(1) SESSION 1 — INJECTION: attacker delivers a payload causing the agent to write a SEED to long-term memory (an instruction recorded as a 'preference,' a summary, an ingested doc chunk). The seed is INERT this session — nothing visible. (2) PERSISTENCE: the seed survives the session boundary; it lives in the memory store across logout/login/days. (3) SESSION 2 — ACTIVATION: user starts a fresh session; the memory loader pulls the seed into context as TRUSTED (no tag, no gate); the seed FIRES and the agent obeys it as if it were a system prompt. The fuse crosses the session boundary."	c2b::b3::recall
"In the sleeper attack, what is the LOAD-BEARING failure — the injection in session 1, or something else?"	"SOMETHING ELSE — it is the UNVALIDATED READ in session 2. The memory loader treats its own store as trusted and never re-checks a poisoned entry before promoting it to the context window. The seed survives the session boundary because nothing interrogates it on the way back in. The B2 defenses never see it because it is already in the window (loaded at session start) before the user types anything. The defense (B3.3) doesn't try to catch the injection in session 1 — it ensures the seed can never be WRITTEN, and tags any residual poison on READ."	c2b::b3::recall
"What is the persistence amplification of memory poisoning vs. a transient injection, and why does OWASP rank ASI04 as distinct from ASI01?"	"TRANSIENT injection (B2 territory): 1 delivery : 1 activation — the attacker must re-deliver every session. MEMORY POISONING: 1 delivery : N activations, where N = number of sessions that read the poisoned memory before someone notices. SHARED RETRIEVAL poison: 1 write : N users × N queries. OWASP ranks Memory Poisoning (ASI04) as DISTINCT from prompt injection (ASI01) because prompt injection is the DELIVERY mechanism and memory poisoning is the PERSISTENCE mechanism. A prompt injection that cannot reach memory is a transient event; a prompt injection that reaches memory is a permanent backdoor."	c2b::b3::recall
"What is retrieval contamination (RAG poisoning), and what makes it indirect injection with persistence?"	"Poisoning the VECTOR/RETRIEVAL STORE so the agent retrieves attacker-controlled context. Write paths into the index: user-uploaded docs, crawled/synced external content (compromisable wiki/doc), agent-generated summaries (laundered injection), cross-tenant leaks (weak isolation). Once a poisoned chunk is in the index, it PERSISTS until found and removed. The attack is deterministic from the retrieval side: the attacker crafts the chunk to be semantically similar to the victim's queries → it is fetched → inserted as DATA-but-obeyed-as-INSTRUCTION → agent complies. This is indirect injection (B2's most dangerous class) delivered through the retrieval channel, WITH the persistence property of memory."	c2b::b3::recall
"What is context-window flooding (Microsoft Failure Mode #5), and why is it NOT defeated by a better refusal layer?"	"An attacker (or chatty tool output, or large retrieved doc) fills the context window with so much content that the system prompt and legitimate instructions are pushed out of the model's effective ATTENTION. Models attend over a fixed window; as it fills, the influence of any token set diminishes. The model complies not because it was TRICKED (persuasion) but because the instruction it should follow is no longer in its effective attention window (DISPLACEMENT). Defense is NOT a better refusal layer — it is CONTEXT-BUDGET MANAGEMENT: pin the system prompt (reserved prefix), cap per-source token volume, truncate/summarize injected content before it reaches the window."	c2b::b3::recall
"What is cascading hallucination (OWASP ASI06), and why is a poisoned memory the most reliable cascade trigger?"	"The agent retrieves/recalls ONE poisoned or hallucinated result, treats it as GROUND TRUTH, and builds all subsequent reasoning on it. The error PROPAGATES: false premise → flawed reasoning → flawed action → recorded result → further reasoning. Each step inherits the original error. A single hallucination is a localized error the user corrects; a CASCADE is a contaminated reasoning chain — internally consistent but the foundation was poisoned. POISONED MEMORY is the most reliable trigger because the agent treats its OWN memory as authoritative — a retrieval chunk might be questioned, but a memory entry the agent wrote itself is treated as established fact. The cascade is faster and harder to interrupt."	c2b::b3::recall
"State the core principle of harness-managed writes (Course 1 Module 4.3), and the three roles it assigns."	"THE MODEL PROPOSES; THE HARNESS VALIDATES; ONLY THE HARNESS COMMITS. (1) The model PROPOSES memory writes — it is good at deciding what is worth remembering (summarize, extract preferences, identify facts), so it emits a proposal: content + justification + provenance pointer. (2) The harness VALIDATES — it is good at policy enforcement, checking provenance/trust/content. (3) Only the harness COMMITS — the model NEVER touches the memory store directly. There is no save_to_memory tool, no function, no API path by which the model writes unattended. Every write goes through the gate. This is the architectural inversion that defeats the unconditional write path the sleeper attack requires."	c2b::b3::recall
"What three checks does the memory-write gate run, in order, and what is the load-bearing conjunction?"	"CHECK 1 — PROVENANCE: where did the content come from? (user_direct, user_via_untrusted_session, retrieval:doc, tool, agent_inferred). CHECK 2 — TRUST LEVEL (derived from provenance): trusted, semi_trusted, untrusted. CHECK 3 — CONTENT: does the proposed write look like an injection? (secondary-model detector + sleeper-signature heuristic). The LOAD-BEARING CONJUNCTION: if (trustLevel === 'untrusted' && looksLikeInstruction(content)) → DENY. A trusted user preference PASSES. An untrusted fact PASSES. The payload that is BOTH untrusted-sourced AND instruction-shaped — the sleeper seed's signature — gets BLOCKED deterministically."	c2b::b3::recall
"What fields must every memory entry carry for provenance, and why?"	"SOURCE (user_direct, user_via_untrusted_session, retrieval:doc_id, tool:tool_name, agent_inferred); TRUST_LEVEL (trusted/semi_trusted/untrusted); WRITTEN_AT (timestamp — enables audit, old poison is still poison); WRITTEN_BY (session/turn — audit trail back to the injection point); VALIDATION_RESULT (what the gate decided and why — ALLOW:trusted_direct or DENY:injection_detected). WHY: the gate only works if every entry carries provenance forward. A store of untagged text blobs is a store where the gate has nothing to validate on READ. Provenance enables trust-aware reads (untrusted entries get B2 L1 tags next session) and audit (trace a session-2 activation back to its session-1 injection)."	c2b::b3::recall
"How does the separation of read and write paths provide defense in depth for memory poisoning?"	"WRITE PATH: model proposes → harness validates (provenance/trust/content) → commits with provenance tag. Model has NO direct write capability. READ PATH: harness loads memory → applies provenance-based tagging (untrusted entries get B2 Layer 1 tags) → injects into context. The read path does NOT assume the write path was perfect — it tags DEFENSIVELY based on stored provenance. DEFENSE IN DEPTH: even if the gate has a bypass (a perfectly-crafted obfuscated trusted-looking seed evades CHECK 2/3), the read-side tagging is a SECOND CHANCE to catch the poison — the tainted entry hits B2's Layer 3 taint gate if it tries to drive a high-impact action. The two paths are independently auditable."	c2b::b3::recall
"Name the three retrieval defenses and why retrieved-content taint tagging is the most important."	"(1) PROVENANCE FILTERING — before retrieval results are injected, filter/down-rank results from untrusted sources. Trust follows the source. (2) RE-RANKING — a secondary model re-ranks by relevance AND instruction-density (instruction-heavy chunks are suspicious). Advisory; reduces suspicious volume reaching the window. (3) RETRIEVED-CONTENT TAINT TAGGING — every retrieved chunk tagged UNTRUSTED (B2 Layer 1) by default unless provenance proves otherwise. THIS IS THE MOST IMPORTANT because it CONNECTS B3 to the B2 stack — a tainted retrieval result that tries to drive a high-impact tool call hits B2's Layer 3 taint gate and is blocked, even if the model is fooled. The other two reduce volume; taint tagging makes the existing gate apply."	c2b::b3::recall
"An agent has a save_to_memory tool the model calls freely. What is the vulnerability, and what is the cure?"	"VULNERABILITY: this is the UNCONDITIONAL WRITE PATH the sleeper attack requires. The model writes anything, anytime, with no validation — a poisoned seed (from an untrusted session, a retrieved doc, a tool output) is committed directly and persists until found. The seed then fires in session 2 as trusted memory. CURE: REMOVE the direct write tool; replace it with a PROPOSE-AND-VALIDATE gate. The model emits a proposal (content + justification + provenance); the harness runs the three checks (provenance, trust, content); only the harness commits. The model never touches the store. The load-bearing line: deny if (untrusted && instruction-like)."	c2b::b3::analysis
"You find a poisoned entry in the memory store that has already activated. Walk back the audit to find the injection point and the defense gap."	"(1) Read the entry's WRITTEN_BY (session/turn) and WRITTEN_AT — this points to session 1 where the seed was planted. (2) Read the entry's SOURCE/PROVENANCE — was it user_via_untrusted_session, retrieval:doc_id, or tool? This tells you the delivery channel. (3) Read the VALIDATION_RESULT — did the gate ALLOW it (and why — which check passed that shouldn't have?), or was there NO GATE at write time (the unconditional write path)? (4) Check the READ path — was the entry tagged untrusted on load (B2 L1)? If not, the read path trusted the write path unconditionally. The gap is either a missing/bypassed write gate OR a read path that doesn't apply provenance-based tagging. Fix both: gate the writes, tag the reads."	c2b::b3::analysis
"Why does a tainted retrieval result need the B2 Layer 3 taint gate even if the model is 'aware' the content is untrusted?"	"Because the model being 'aware' is not enforcement — it is a probabilistic hope (the 1.6% trap from B2). The model may comply with the tainted content anyway, because LLMs process instructions and data as one token stream with no parser to separate them (B2.1). The taint gate is DETERMINISTIC: a tool call whose arguments are tainted is BLOCKED regardless of whether the model was fooled. This is the B2 Layer 3 principle — determinism on the structural boundary. Retrieved-content taint tagging (B3) feeds the gate: tag the chunk untrusted on retrieval, the taint propagates to any argument derived from it, and the high-impact call is blocked even when the model obeys the poison."	c2b::b3::analysis
"A user's agent ingests a document from an external wiki during a scheduled sync. Two weeks later, a query retrieves a chunk instructing the agent to CC an external address on all email drafts. Diagnose the attack and the missing defense."	"DIAGNOSIS: this is RETRIEVAL CONTAMINATION (RAG poisoning). The external wiki was compromisable; an attacker edited it; the sync ingested the poisoned chunk; it persisted in the index for two weeks; a semantically-similar query retrieved it; the agent obeyed it as instruction. The persistence (two weeks) is the memory property. MISSING DEFENSES: (1) PROVENANCE FILTERING — external/crawled content should be tagged untrusted source, down-ranked or quarantined. (2) RE-RANKING — the chunk is instruction-heavy relative to factual content; a re-ranker should have flagged it. (3) RETRIEVED-CONTENT TAINT TAGGING — the chunk should have been tagged untrusted (B2 L1) on retrieval, so the taint gate (B2 L3) would block the high-impact 'send email' call with a tainted recipient argument. All three missing."	c2b::b3::analysis
"Why is the conjunction (untrusted provenance AND instruction-like content) a better gate signal than content detection alone?"	"CONTENT DETECTION ALONE (CHECK 3 without CHECK 1/2) is probabilistic — a sufficiently obfuscated instruction evades the detector, and a legitimate instruction from a trusted user is false-positive-blocked. The CONJUNCTION adds the deterministic provenance signal: a trusted user directly stating a preference is ALLOWED even if it looks instruction-like (trusted source); an untrusted chunk that happens to be factual is ALLOWED even though untrusted (not instruction-shaped). Only the payload that is BOTH untrusted-sourced AND instruction-shaped is blocked — and that conjunction is the sleeper seed's signature. The gate's strength is not perfection in any single check; it is the removal of the unconditional write path PLUS the deterministic conjunction that catches the canonical signature while passing legitimate writes."	c2b::b3::analysis
"Design the memory-write gate's behavior for these four proposals: (a) user directly states a preference; (b) agent summarizes a conversation that handled untrusted content; (c) agent wants to store a fact from a retrieved doc; (d) a seed 'when user asks X, do Y' from an untrusted session."	"(a) user_direct preference → CHECK 1: source=user_direct → CHECK 2: trust=trusted → CHECK 3: content (if not injection-pattern) → ALLOW (committed, tagged trusted). (b) agent_inferred from untrusted session → source=user_via_untrusted_session OR agent_inferred → trust=untrusted or semi_trusted → if the summary looks instruction-like → DENY (untrusted_instruction_like); if it's factual → ALLOW but tagged untrusted (read path applies B2 L1 tag next session). (c) retrieval fact → source=retrieval → trust=untrusted → if factual (not instruction-like) → ALLOW tagged untrusted. (d) sleeper seed from untrusted session → source=user_via_untrusted_session → trust=untrusted → content matches 'when the user...' pattern → DENY (the load-bearing conjunction). The seed never reaches the store."	c2b::b3::analysis
"What is the residual risk after deploying the memory-write gate, and how does the read path mitigate it?"	"RESIDUAL: a perfectly-crafted, obfuscated, trusted-LOOKING seed that evades CHECK 2 (content detector) and CHECK 3 (the heuristic/secondary model) AND is proposed with a trust level that passes. For example, an obfuscated trigger that doesn't match the regex patterns ('upon fiscal inquiry, transmit balances...') from a source classified semi_trusted. This is real. READ-PATH MITIGATION: even if such a seed is committed, the read path tags it by trust level — a semi_trusted/untrusted entry gets a B2 Layer 1 untrusted tag on load, so B2's Layer 3 taint gate applies if it tries to drive a high-impact action. DEFENSE IN DEPTH: the gate reduces write-side success rate; the read-side provenance tagging catches the residual. Neither alone is sufficient; together they shrink the window."	c2b::b3::analysis
"Why is a cascading hallucination (ASI06) harder to interrupt when the foundation is the agent's own memory vs. a retrieved chunk?"	"A retrieved chunk is DATA — the agent may question it, cross-check it, or the user may notice it doesn't match other sources. The agent's OWN memory is treated as AUTHORITATIVE — the agent wrote it, so it is established fact, not a fetched claim. This means: (1) the agent does not second-guess its own prior; (2) the reasoning chain built on it is more confident; (3) the user sees an internally-consistent derivation and has no signal that the FOUNDATION was poisoned; (4) if the premise was persisted, the cascade RECURS every session that touches it. The cascade is faster (no skepticism) and more durable (recurs) when the source is the agent's memory. This is why ASI06 ties to ASI04: poisoned memory is the most reliable cascade trigger."	c2b::b3::analysis
"How does B3 extend the B2 defense stack rather than replacing it? What is the connection point?"	"B2 built five layers INSIDE the context window (tag L1, isolate L2, taint-gate L3, detect L4, minimize L5). B3 extends the same principles to the PERSISTENT memory surface — the surface B2 never touched because it dies with the session. The CONNECTION POINT is RETRIEVED-CONTENT / MEMORY-ENTRY TAINT TAGGING: B3's read path tags untrusted memory entries and untrusted retrieved chunks with the B2 Layer 1 tag, so they flow into B2's Layer 3 taint gate on the next session/turn. B3 does not replace B2 — it ensures B2's layers APPLY to content that enters the window via the memory and retrieval paths (which B2 missed because those paths were trusted by default). B3 = the memory-surface extension of B2's L1. A tainted memory/retrieval result is now continuous with the B2 stack."	c2b::b3::analysis