"What is the central thesis of B8, and what does 'necessary but insufficient' mean for per-turn detection?"	"Per-turn detection is NECESSARY (it catches the long tail of single-shot attacks — direct injections, obvious policy violations, single-output leakage) but INSUFFICIENT (it misses the multi-step injection chain from B2 and the zero-click HITL bypass chain from the Microsoft Taxonomy, because no single turn is malicious in isolation). The unit of malicious intent is the SESSION, not the turn. You need per-turn AND session-level detection — drop either and you lose a class of coverage."	c2b::b8::recall
"Name the two attack classes that are invisible to a per-turn detector and the shared property that defeats per-turn analysis."	"(1) The MULTI-STEP INJECTION (B2): a chain of individually-benign turns whose compound effect is malicious (summarize → translate → email → attach ~/.ssh/id_rsa). (2) The ZERO-CLICK HITL BYPASS CHAIN (Microsoft Taxonomy v2.0): a single external input triggers a chain where EVERY step passes a human approval but the compound intent is malicious. SHARED PROPERTY: malicious intent is distributed across individually-benign units ('compound intent') — benign atoms, poison molecule. Visible only at the session level."	c2b::b8::recall
"What is the zero-click HITL bypass chain, and why is it the Microsoft Taxonomy's CRITICAL finding?"	"A single external input (email/fetched page/retrieved doc/MCP response) carries an indirect injection that sets up a multi-step plan. Each step is individually defensible and PASSES its human approval gate (read config, patch billing, draft email, send). The compound effect is malicious. CRITICAL because per-step HITL is the control being DEFEATED — the human is not bypassed in any single step, they are COMPOSED across steps. The finding does NOT say HITL is useless; it says per-step HITL WITHOUT session-level intent detection is insufficient against a chain that composes benign steps."	c2b::b8::recall
"What is a session intent model, and how does it differ from the system prompt and the latest user turn?"	"A running representation of what the agent is supposed to be doing across the WHOLE conversation — the evolving objective ('Q3 finance review prep'). It is NOT the system prompt (static) and NOT the latest user turn (local). It is seeded from the initial user request + configured role, updated as the session progresses, and serves as the YARDSTICK against which candidate actions are scored for drift. The drift score ('does this action belong to the session the agent is running?') is the core detection signal."	c2b::b8::recall
"Describe the two-layer architecture of the session intent model and why each layer exists."	"(1) DETERMINISTIC SKELETON: structured JSON seeded from trusted system prompt + first user turn; carries resource scope, egress policy, task class; accepts updates ONLY from trusted sources (user_turn, system_prompt) — immune to indirect injection. (2) CONSTRAINED LLM UPDATE LAYER: proposes semantic updates ('user switched to Q4'); bounded to ≤0.2 of drift score so it cannot single-handedly flip a decision; validated against the skeleton's schema. This is B7's 'deterministic backbone, constrained LLM' pattern applied to detection — pure-LLM intent models are themselves injection targets."	c2b::b8::recall
"What are the three outcomes of the drift gate, and what triggers each?"	"(1) ALLOW: drift < 0.6 (action within session objective). (2) REQUIRE_FRESH_APPROVAL: drift ≥ 0.6 from a TRUSTED source — show the drift reason to the approver (user may have legitimately changed topics, but force a fresh look). (3) HARD_BLOCK: drift ≥ 0.6 from an UNTRUSTED source — the single most valuable signal in the module; catches the zero-click chain at its exfiltration step because that step is the one whose source is the untrusted injected input. Three outcomes, not two — provenance is load-bearing."	c2b::b8::recall
"What is action provenance, and what question does it answer that per-turn logging cannot?"	"For every action the agent takes, provenance logs the SOURCE INPUT that caused it: source_type (user_turn/system_prompt/tool_output/retrieved_chunk/mcp_response/model_self), source_id (pointer to the specific turn/tool-result/chunk), and source_trust (trusted vs untrusted). It answers 'WHICH INPUT CAUSED THIS ACTION?' — e.g., 'the agent emailed the SSH key at turn 4; what caused that?' → source_type=retrieved_chunk, source_id=doc_42_chunk_7. Without provenance the investigator sees actions and guesses the chain; with it, the chain is reconstructed. Provenance is also a DETECTION input (untrusted-source high-drift is a stronger signal)."	c2b::b8::recall
"Why must provenance be captured at prompt-assembly time, and what happens if a harness pipes an undifferentiated context blob into the model?"	"The harness must tag every context item with a stable source identity and trust level WHEN ASSEMBLING THE PROMPT, and emit the winning source identity with the resulting action. A harness that pipes an undifferentiated blob of context into the model and logs only 'the model called tool X' has THROWN PROVENANCE AWAY AT THE MOMENT OF CAPTURE. No amount of after-the-fact log analysis recovers it — the causal link between action and source was never recorded. This is a harness-instrumentation requirement, not a logging-config afterthought."	c2b::b8::recall
"Distinguish drift detection from anomaly detection."	"DRIFT is LOCAL: does this action fit THIS SESSION's objective? Scored against the session intent model. Catches the chain whose steps don't belong to the task. ANOMALY is GLOBAL: does this action fit THIS AGENT's normal behavior across ALL sessions? Scored against statistical baselines (action frequency, tool-call distribution, parameter distributions, sequence patterns). Catches the novel attack that stays inside the session's nominal objective but manifests as unusual sequences/tools/params. You need BOTH because adversaries rotate — drift catches 'doesn't fit the session,' anomaly catches 'doesn't fit the agent.'"	c2b::b8::recall
"Name the four anomaly-detection baseline signals and an example deviation for each."	"(1) ACTION FREQUENCY — bursts (10 file reads in 2s during summarization = a chain executing its payload). (2) TOOL-CALL DISTRIBUTION — a read-heavy research agent suddenly spiking writes/sends; a code agent sending external email. (3) PARAMETER DISTRIBUTIONS — a file read of ~/.ssh/* or /etc/shadow when baseline is /reports/*; an external email domain when baseline is internal. (4) SEQUENCE PATTERNS — N-gram/transition models: 'read_secret → encode → send_external' is anomalous, especially sensitive-resource-then-external-egress."	c2b::b8::recall
"What is the escalation-fatigue attack (DD-20 IronCurtain), and why does it work?"	"Floods the human approver with approval requests at machine speed until they rubber-stamp. The naive approval model treats each request as independent with a binary approve/reject and NO cost to the requester for being rejected. Under volume, the human's marginal cost of careful review rises past their willingness to pay attention, and they default to APPROVE — the chain then walks its malicious steps through the rubber-stamped gate. Volume defeats vigilance. It does not try to BYPASS the approver; it tries to EXHAUST them. Well-documented alert-fatigue effect, acute in agentic systems where a coerced agent generates requests at loop speed."	c2b::b8::recall
"State the three defenses against escalation fatigue and what each defeats. Why must they compose?"	"(1) RATE LIMITS — cap approval requests per session/action type; surplus is AUTO-BLOCKED not auto-approved → defeats the volume attack. (2) BATCH APPROVALS — show the CHAIN as one reviewed object ('read .env → patch billing → email → send') → defeats per-step composition (makes compound intent visible at approval time). (3) FRESHNESS WINDOWS — approval for X valid N seconds only → defeats approval harvesting and harvest-and-replay. NONE ALONE IS SUFFICIENT: rate limits w/o batching let a chain walk through one-at-a-time (slowly); batching w/o freshness allows replay; freshness w/o rate limits does nothing about a single fast chain."	c2b::b8::recall
"How does OWASP ASI06 (Cascading Hallucination) map to B8, and why does one detector catch both it and the adversarial chains?"	"ASI06 names the UNINTENTIONAL twin of the multi-step injection: an early error or compromise propagates through subsequent steps, compounding into a confidently-corrupted downstream action. It is NOT adversarial, but the failure shape is identical — the agent's actions have drifted from a coherent objective across a chain of steps. A detector built only to catch INJECTION misses the cascading-hallucination version; a SESSION-LEVEL INTENT TRACKER catches BOTH for the price of one, because the signal ('actions have drifted from a coherent objective') fires whether the cause is an adversary or an accident. This is the detection-layer reason ASI06 maps to B8."	c2b::b8::recall
"How does B8 tie to Course 1 Module 10 (Observability) and Module 9 (Verification)?"	"M10 (Observability) provides the PLUMBING — structured logs, traces, replay — for the question 'is the agent working?' (performance/correctness/latency). B8 adds the ADVERSARIAL DETECTORS (drift, anomaly, provenance, approval freshness) on that same plumbing for the question 'is the agent being STEERED?' M9 (Verification) is the AFTER-THE-FACT layer: 'did the agent do the task, and only that task?' With the provenance log, verification becomes an AUDIT, not a guess — every action's source is known, every drift score recorded, every objective snapshot shows whether the agent stayed on task."	c2b::b8::recall
"What does the B7→B8 observability handoff look like, and why do the two overlap deliberately?"	"B7's out-of-band sidecar monitor emits four signal classes — RESOURCE (CPU/mem/disk), SYSCALL, NETWORK, BEHAVIORAL — into B8's anomaly pipeline at the EXECUTION layer. The session-level anomaly detector (B8) sees 'the agent called curl to an unknown host'; the sidecar (B7) sees 'the sandbox made an outbound connection to 198.51.100.7.' Either alone is a signal; together, with matching timestamps, they are a HIGH-CONFIDENCE finding. The overlap is deliberate — defense in depth across the reasoning layer (B8) and the execution layer (B7)."	c2b::b8::recall
"What is the role of the LLM update layer in the session intent model, and why is it bounded to ≤0.2 of the drift score?"	"The LLM update layer PROPOSES semantic updates to the objective ('the user has switched from Q3 to Q4 forecasting') from user turns, subject to deterministic validation by the skeleton's schema/policy. It is bounded to ≤0.2 of the drift score so a MANIPULATED coherence score CANNOT SINGLE-HANDEDLY FLIP a decision. Rationale: a pure-LLM intent model is itself an injection target (the adversary's goal is to manipulate the agent's reasoning). The bound ensures the deterministic resource-scope (0.4) and egress (0.4) signals dominate — security-critical decisions need a deterministic backbone, with the LLM in a constrained role. B7's pattern, applied to detection."	c2b::b8::analysis
"A candidate action has drift 0.7. Its source is a retrieved chunk (untrusted). Walk through the drift gate's decision and reasoning."	"HARD_BLOCK. Drift ≥ 0.6 (here 0.7) AND source_trust == untrusted → hard block with reason 'high drift from untrusted source — possible chain step.' This is the single most valuable signal: it catches the zero-click chain at its exfiltration step because (a) the setup steps are designed to look normal (low drift) and pass, (b) the exfiltration step is high-drift (it sends data outside the session objective), and (c) its source is the untrusted input that seeded the chain. If the same action had a TRUSTED user_turn source, the gate would REQUIRE_FRESH_APPROVAL instead (the user may have legitimately changed topics)."	c2b::b8::analysis
"You are designing the approval UX for a chain that reads a config file, patches a billing method, drafts an email, and sends it. How do per-step approval and batched approval differ in what the human sees, and which defends the zero-click chain?"	"PER-STEP: the human sees four isolated 'approve Y/N' prompts over time — 'read config?' 'patch billing?' 'draft email?' 'send?' Each looks routine in isolation; the compound intent (credential exfiltration via billing swap) is invisible. This is what the zero-click chain defeats. BATCHED: the human sees ONE approval showing the entire chain — 'read /app/.env → PATCH /billing/method → draft email to attacker@ → SEND' — with the drift and anomaly scores per step. The compound intent is visible at approval time. Batching is the direct counter: it makes the session-level intent visible to the human, which is exactly what per-step approval hides. (Plus rate limits + freshness windows per B8.3.)"	c2b::b8::analysis
"An attacker obtains a human approval for a benign-looking 'read config' action early in a session, then attempts to redeem it 45 minutes later as part of an exfiltration chain. Which defense defeats this, and how?"	"APPROVAL FRESHNESS WINDOWS. An approval for action X is valid for N seconds only (e.g. 30s, context-appropriate). The 45-minute-old 'read config' approval is STALE and cannot be redeemed into the new chain. This defeats the APPROVAL HARVESTING / harvest-and-replay variant: the adversary cannot bank a benign approval early and weave it into a later chain. Freshness forces the adversary to keep the human approving THROUGHOUT the chain, which raises the chance the human notices. Note: freshness alone is insufficient — it must compose with rate limits (bound volume) and batching (make the chain visible)."	c2b::b8::analysis
"Why is logging 'the agent called tool X at turn N' insufficient, and what must the log additionally capture? Design the minimal provenance record."	"Per-turn logs record WHAT happened, not WHY/CAUSED-BY. They cannot answer 'which input made the agent do that?' — the forensic question after a compromise. The minimal provenance record per action: action_id, timestamp(UTC,monotonic), action_type, action_args(structured), source_type (user_turn/system_prompt/tool_output/retrieved_chunk/mcp_response/model_self), source_id (pointer to the specific turn/tool-result/chunk), source_trust (trusted/untrusted), intent_drift_score (at decision time), session_objective_snapshot. The load-bearing additions over a naive log are source_type/source_id/source_trust — without them the chain cannot be reconstructed and the drift signal cannot be weighted by provenance."	c2b::b8::analysis
"A research-assistant agent's baseline is 95% read actions (file reads, search). In one session it issues 3 reads then 7 external email sends in 4 seconds. Which detector fires, what is the signal, and what is the appropriate gate?"	"ANOMALY DETECTION fires (drift may also fire if sends violate the session's egress policy). Signals: (1) TOOL-CALL DISTRIBUTION — a read-heavy agent spiking sends (7 of 10 actions are sends vs 5% baseline); (2) ACTION FREQUENCY — a burst (10 actions in 4s vs a summarization-session baseline of ~1/min). Both are out-of-distribution. GATE: if the sends' source is untrusted (e.g. a retrieved chunk), HARD_BLOCK on high anomaly+untrusted. If trusted, REQUIRE_FRESH_APPROVAL with the anomaly evidence shown. The session-level drift detector alone might miss this if the sends are nominally 'in task' — anomaly catches the behavioral deviation. The two compose."	c2b::b8::analysis
"You are asked to justify adding session-level detection to a system that already has a per-turn guard. Frame the argument in terms of the attacks that per-turn misses and the cost of the miss."	"Per-turn catches single-shot attacks but is structurally blind to the two highest-impact attack classes: the multi-step injection (B2) and the zero-click HITL bypass chain (Microsoft Taxonomy). Both distribute malicious intent across individually-benign units — no single turn is detectable, so a perfect per-turn detector still passes every step. The cost of the miss is exactly the cost of a successful exfiltration/swapped-payment/irreversible-send. Session-level intent tracking closes this at the cost of one deterministic-skeleton data structure + a constrained LLM update layer + a provenance-tagged action log — modest, deterministic-backbone engineering (B7's pattern). The ROI is coverage on the attack class that actually compromises production agents. Per-turn is necessary; session-level is what makes the chains detectable."	c2b::b8::analysis