Module B8 — Observability and Attack Detection

Observability and Attack Detection

Per-turn detection is necessary but insufficient. The attacks that actually compromise production agents — the multi-step injection (B2) and the zero-click HITL bypass chain (Microsoft Taxonomy) — are invisible to any system that inspects each turn independently. Each step looks benign; the compound intent is malicious. The unit of malicious intent is the session, not the turn. Detection must move to the session.

60
minutes
8
artifacts
3
sub-sections
Course 1 Module 10 taught you to observe an honest agent. B8 teaches you what the observability pipeline must look for when an adversary is steering it. Two attack classes defeat per-turn analysis by distributing malicious intent across individually-benign steps: the multi-step injection and the zero-click human-in-the-loop bypass chain. The defense is session-level intent tracking (a model of the agent's evolving objective that flags action drift), action provenance (which input caused this action), anomaly detection on the action stream, and approval freshness that defeats escalation fatigue. Compound intent is only visible at the session level.
Key Claims
Load-Bearing Claims

Per-turn detection is necessary but insufficient. The two highest-impact attack classes — the multi-step injection (B2) and the zero-click HITL bypass chain (Microsoft Taxonomy v2.0) — distribute malicious intent across individually-benign steps so that no single turn is malicious in isolation. A perfect per-turn detector passes every step. The unit of malicious intent is the session, not the turn; detection must raise its scope to the session. Per-turn stays (it catches the long tail of single-shot attacks); session-level is what makes chains detectable.

The zero-click HITL bypass chain is the Microsoft Taxonomy's critical finding, and it defeats per-step approval by construction. A single external input triggers a multi-step chain in which EVERY step passes its human approval gate (each step is individually defensible) yet the compound intent is malicious. The human is not bypassed in any single step — they are COMPOSED across steps. Per-step approval is the control being defeated. The defense requires a session-level model of intent (to evaluate the chain, not the step) AND batching (to make the compound intent visible to the human at approval time).

Session-level intent tracking is the detection counterpart to B2's session-level defense, and it must be built deterministic-backbone + constrained-LLM. A deterministic skeleton (updated only from trusted sources — user turns, system prompt) carries the resource scope and egress policy and is immune to indirect injection; a constrained LLM layer proposes semantic updates bounded to ≤0.2 of the drift score so it cannot single-handedly flip a decision. The three-outcome gate (ALLOW / REQUIRE_FRESH_APPROVAL / HARD_BLOCK) hard-blocks high-drift actions from untrusted sources — the move that catches the zero-click chain at its exfiltration step. Provenance is required at capture time: which input caused this action.

Approval freshness defends the human approver against the escalation-fatigue attack (DD-20 IronCurtain), and three controls must compose. Rate limits bound the volume attack (surplus auto-blocked, not auto-approved); batching makes the chain visible at approval time (the direct counter to per-step composition); freshness windows defeat approval harvesting and harvest-and-replay. None alone is sufficient. Anomaly detection on the action stream (frequency, tool distribution, parameters, sequences) catches the novel attack you did not write a rule for, and consumes B7's sidecar signals correlated on timestamp.

After This Module
01
Explain why per-turn detection fails against the multi-step injection (B2) and the zero-click HITL bypass chain (Microsoft Taxonomy) — the compound intent is malicious even when every individual step is benign — and articulate why per-turn analysis remains necessary but is no longer sufficient.
02
Implement a session-level intent tracker that maintains a model of the agent's evolving objective across the whole conversation, scores each candidate action against it via a deterministic skeleton plus a bounded LLM update layer, and flags action drift as the detection counterpart to B2's session-level defense.
03
Build an action-provenance logger that records, for every action, the source input (turn, tool, retrieval) that caused it with a trust level — enabling reconstruction of an attack chain and answering 'which input made the agent do that?' which per-turn logs cannot.
04
Apply anomaly detection to the action stream — statistical baselines for action frequency, tool-call patterns, and parameter distributions — with deviation alerts for unusual sequences, unexpected tool calls, and out-of-distribution arguments, consuming B7's sidecar signals.
05
Defend against the escalation-fatigue attack (DD-20 IronCurtain) using approval rate limits, batch approvals, and freshness windows (an approval for action X is valid for N seconds only), and design the approval UX to show drift, anomaly, and the chain rather than an isolated approve/reject.
06
Assemble the observability stack — structured logging with provenance, session-level intent tracking, anomaly detection on the action stream, and a human-reviewable audit trail — and connect it to Course 1 Module 10 (Observability) and Module 9 (Verification).
Artifacts
01
Teaching Document
~4,800 words; 3 sub-sections — why per-turn detection fails (multi-step injection + zero-click HITL chain + ASI06), session-level intent tracking and action provenance (deterministic skeleton + bounded LLM + three-outcome drift gate + provenance logger), anomaly detection/approval freshness/observability stack; with TypeScript SessionIntentTracker reference code, anti-patterns, key terms, 12 references
READ
02
Diagrams
5 Mermaid diagrams — why per-turn fails (the multi-step chain sequence), session-level intent tracking (two-layer architecture + three-outcome gate), the zero-click HITL bypass chain (per-step approval defeated), action-provenance logging (forensic reconstruction), the escalation-fatigue attack and its three composed defenses
READ
03
Slide Deck
15 slides — reveal.js, dark theme, design-system teal; covers the Course 1 M10→B8 inversion, the two attacks, per-turn necessary-but-insufficient, the zero-click chain, ASI06, the session intent model, provenance, anomaly detection, approval freshness, the assembled observability stack
READ
04
Teaching Script
~17-min verbatim teaching script with [SLIDE N] cues at ~140 wpm; mirrors the 15-slide deck
READ
05
Flashcards
22 flashcards (TSV) — 16 recall / 6 analysis; covers per-turn insufficiency, zero-click chain, session intent model, two-layer architecture, three-outcome gate, provenance, anomaly baselines, escalation fatigue + three defenses, ASI06, B7→B8 handoff, Course 1 M9/M10 ties
TEST
06
Exam
15 exam questions, 20/40/40 Bloom (3 recall / 6 application / 6 analysis); covers per-turn insufficiency, zero-click chain, intent model architecture, drift gate outcomes, provenance, escalation fatigue defenses, ASI06 detection, drift vs anomaly, the assembled stack
TEST
07
Lab Spec
Build the Session-Level Detector — 7 phases: types + trusted/untrusted source model, SessionIntentTracker with deterministic skeleton + bounded LLM + three-outcome gate, ActionProvenanceLogger with chainFrom/causeOf, AnomalyDetector with frequency/tool/parameter baselines, the zero-click chain replay climax (per-turn passes 5/5, session-level HARD_BLOCKs the exfil), ApprovalGate with rate-limit/batching/freshness. TypeScript, type hints, no GPU, ~60-75 min
DO
08
Module Web Page
Single-file HTML hub
HERE