Module: B10 — Microsoft Failure Mode Taxonomy as Red Team Framework Diagram count: 5 Tool: Mermaid (primary). Each diagram validated in Mermaid Live Editor.
Type: Taxonomy map / radial Purpose: The full surface of the v2.0 update at a glance. The Microsoft AI Red Team's twelve months of deployed agentic red teaming produced seven failure modes that map imperfectly onto OWASP ASI — the imperfection is the point. These are the patterns that show up in production when you red-team an agent built to OWASP, not an agent on paper. Each mode names where the controls a builder installed do not compose the way the builder assumed. Reading the diagram: The center is the deployed agentic system; the seven modes radiate as the surfaces a red team probes. The mode numbers are this module's ordering, not Microsoft's. Each mode is annotated with the OWASP ASI risk it overlaps — and the overlap is partial by design.
flowchart TB
CENTER["DEPLOYED AGENTIC SYSTEM<br/>built to OWASP ASI (B9)<br/>still fails in production"]:::center
M1["MODE 1<br/>AGENTIC SUPPLY CHAIN COMPROMISE<br/>malicious tools, MCP servers, skills<br/>≈ ASI08 / ASI05"]:::mode
M2["MODE 2<br/>GOAL HIJACKING<br/>objective redirected via injection<br/>≈ ASI01 (drift, not single-shot)"]:::mode
M3["MODE 3<br/>INTER-AGENT TRUST ESCALATION<br/>sub-agent forges msgs to orchestrator<br/>≈ ASI07 / ASI10"]:::mode
M4["MODE 4<br/>COMPUTER-USE VISUAL ATTACKS<br/>steganographic content via vision<br/>≈ ASI07 (new modality)"]:::mode
M5["MODE 5<br/>SESSION CONTEXT CONTAMINATION<br/>cross-turn context poisoning<br/>≈ ASI04 / ASI06"]:::mode
M6["MODE 6<br/>MCP / PLUGIN ABUSE<br/>dispatch-layer exploitation<br/>≈ ASI05 (registration, not call)"]:::mode
M7["MODE 7<br/>CAPABILITY DISCLOSURE<br/>agent leaks its toolset/prompt<br/>≈ ASI02 (enabler, not impact)"]:::mode
CENTER --- M1
CENTER --- M2
CENTER --- M3
CENTER --- M4
CENTER --- M5
CENTER --- M6
CENTER --- M7
classDef center fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
classDef mode fill:#101018,stroke:#f0a868,color:#e4e4e8
Note: The "≈ ASIxx" annotations are overlaps, not equivalences. The divergence is the value: each mode names the chain that defeats the OWASP control in production, not the risk the control was built for. A team that reads this diagram as "we already covered these in B9" has made the synthesis error.
Type: Sequence / chain with approval gates Purpose: The single most important visual in the module. A single external input triggers a multi-step chain where each individual step passes its human-in-the-loop approval gate — because each step is benign in isolation — but the compound of the steps is data exfiltration. Per-step approval is structurally insufficient to stop this. The malice lives in the compound, not in any step. This is why session-level intent detection is required, layered above per-step approval. Reading the diagram: Left-to-right as time. Each step has its own approval gate (green) that passes. The red bar at the bottom shows the compound intent that no individual gate could see. The dotted session-level detector (top) is the control that would catch it — it evaluates the compound, not the step.
flowchart LR
EXT["EXTERNAL INPUT<br/>one email / webhook / doc"]:::entry
subgraph CHAIN["THE FIVE-STEP CHAIN — each step benign in isolation"]
direction LR
S1["1. Receive email<br/>'reconcile Q3 vendors<br/>vs billing, send discrepancies'"]:::step
S2["2. Read vendor list<br/>+ billing records<br/>APPROVED — routine access"]:::stepok
S3["3. Find engineered<br/>'discrepancy'; draft email<br/>CC billing-auditor addr<br/>APPROVED — drafting"]:::stepok
S4["4. Send the email<br/>APPROVED — routine send<br/>human sees reasonable note"]:::stepok
S5["5. Impact: vendor list<br/>+ billing details<br/>exfiltrated to attacker"]:::impact
S1 --> S2 --> S3 --> S4 --> S5
end
EXT --> S1
COMPOUND["COMPOUND INTENT (invisible to any single gate):<br/>external input → data access → engineered artifact → exfil channel → sensitive data out<br/>No approver saw steps 1+3+5 together"]:::compound
CHAIN -. the malice lives here .-> COMPOUND
DETECTOR["SESSION-LEVEL INTENT DETECTOR<br/>tracks goal across session · evaluates compound<br/>flags exfil/escalation/lateral patterns<br/>HALTS at step 4 — the compound is exfiltration"]:::detector
DETECTOR -. watches the compound, not the step .-> CHAIN
classDef entry fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
classDef step fill:#101018,stroke:#9494a0,color:#e4e4e8
classDef stepok fill:#101018,stroke:#82e0aa,color:#82e0aa
classDef impact fill:#14141f,stroke:#f08080,stroke-width:2px,color:#f08080
classDef compound fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
classDef detector fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
Note: Every green gate passed correctly. The human who approved step 4 saw a reasonable billing email — they did not see step 1's injected payload, step 3's engineered discrepancy, or the composition. Per-step approval is the right control for a single malicious action and the wrong control for a chain of individually-benign actions. The session-level detector sits above per-step approval, not instead of it. You need both — defense in depth across two scales. This is the direct line to B8: the observability layer extended across the session boundary.
Type: Comparison / overlay Purpose: The thesis made visual. OWASP ASI (B9) and the Microsoft Taxonomy v2.0 (B10) are not redundant — they are complementary by function. OWASP is a defense checklist read as a builder; this taxonomy is a red-team framework read as an attacker. The same named risk (Goal Hijacking, Supply Chain) appears in both, but as different artifacts: one is a control, the other is the procedure that finds the gap between the control on paper and the control in production. A mature program runs both. Reading the diagram: Two columns. Left = OWASP (B9), the defense checklist — the question is "what do I defend?" Right = Microsoft (B10), the red-team framework — the question is "how do attackers chain?" The arrows show the cross-references: each OWASP row is the control; the matching taxonomy entry is the chain that crosses it.
flowchart LR
subgraph OWASP["OWASP ASI (B9) — DEFENSE CHECKLIST"]
direction TB
O_Q["Read as: a BUILDER"]
O_U["Unit: the RISK<br/>(one row, one control, one test)"]
O_OUT["Output: scored report<br/>PASS / FAIL / MEASURED per row"]
O_ASK["What do I defend?<br/>How do I prove the control is present?"]
end
subgraph MSFT["MICROSOFT TAXONOMY v2.0 (B10) — RED-TEAM FRAMEWORK"]
direction TB
M_Q["Read as: an ATTACKER"]
M_U["Unit: the CHAIN<br/>(multi-step, compound intent)"]
M_OUT["Output: reproduced chain<br/>+ the session-level gap identified"]
M_ASK["How do systems fail in production?<br/>How do I chain those failures?"]
end
OWASP ---|"same named risk,<br/>DIFFERENT artifact"| MSFT
O1["ASI01 Goal Hijacking<br/>control: taint gate, isolation"]:::ctrl
M1["Mode 2: the DRIFT chain<br/>that defeats the taint gate<br/>across turns"]:::chain
O1 -. control vs chain .-> M1
O2["ASI08 Supply Chain<br/>control: provenance checks"]:::ctrl
M2["Mode 1: the ENTIRE tool-registration<br/>layer IS the supply chain"]:::chain
O2 -. control vs chain .-> M2
classDef ctrl fill:#101018,stroke:#5eead4,color:#e4e4e8
classDef chain fill:#101018,stroke:#f0a868,color:#e4e4e8
style OWASP fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style MSFT fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
Note: The last row of the complementarity table in the teaching doc is the entire relationship: OWASP assumes controls, if present and passing, compose into security. The Microsoft taxonomy assumes they do not — and the gap is where the attacker lives. A program that runs only B9 misses every failure mode that lives between the rows; a program that runs only B10 misses the missing taint gate, the absent canary, the unscoped credential. You need both, layered. B12 packages them as one engagement.
Type: Process / procedure Purpose: How a red-team engagement is designed around this taxonomy. The unit is not the row (B9) but the chain. The procedure: reconnaissance via capability disclosure, surface selection, chain construction (each step must pass its control individually), compound delivery via a single external input, and gap identification (the deliverable is the session-level gap, not "the chain worked"). This is the methodology B12 turns into a service. Reading the diagram: Top-to-bottom as the engagement. Note that step 3 (chain construction) explicitly requires each step to pass its OWASP control — the chain is designed against a system built to B9, which is why both are needed. The deliverable at step 5 is the gap the client patches.
flowchart TB
R["1. RECONNAISSANCE<br/>via Capability Disclosure (Mode 7)<br/>enumerate actual tools, prompts, config"]:::recon
SS["2. SURFACE SELECTION<br/>pick entry point:<br/>supply chain · inter-agent · vision<br/>session-context · dispatch · indirect-inj"]:::select
CC["3. CHAIN CONSTRUCTION<br/>sequence the steps — each must pass<br/>its OWASP control INDIVIDUALLY<br/>(taint gate, approval gate, schema validator)<br/>malice lives in the COMPOUND"]:::build
CD["4. COMPOUND DELIVERY<br/>trigger via single external input<br/>(zero-click) or minimum human interaction"]:::deliver
GI["5. GAP IDENTIFICATION<br/>deliverable = the session-level gap<br/>that let the compound pass<br/>(missing intent check, absent freshness window,<br/>per-step approval that saw only its step)"]:::gap
R --> SS --> CC --> CD --> GI
GI -->|client patches the gap| B8EXT["extends B8 across<br/>the session boundary"]:::outcome
classDef recon fill:#101018,stroke:#5eead4,color:#e4e4e8
classDef select fill:#101018,stroke:#5eead4,color:#e4e4e8
classDef build fill:#101018,stroke:#f0a868,color:#e4e4e8
classDef deliver fill:#101018,stroke:#f08080,color:#e4e4e8
classDef gap fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
classDef outcome fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
Note: Step 3 is the design constraint that makes this taxonomy a red-team framework rather than a re-labeling of OWASP: each step in the chain must pass the control B9 built for it. The chain is engineered to slip between the controls, not through a missing one. If a step fails its control, the red-teamer has found a B9 row-level failure (good, report it), but not a chain. The chain is the compound that no single control catches.
Type: Control architecture / layered defense Purpose: Why per-step approval (the control B8 built) is necessary and insufficient, and how session-level intent detection layers above it. Two scales of defense: per-step approval stops the single malicious action; session-level detection stops the chain of benign actions. A deployed agent needs both — an agent with only per-step approval is vulnerable to zero-click chains; an agent with only session-level detection is vulnerable to the single malicious action the pattern matcher does not recognize. Reading the diagram: Two stacked layers. The bottom (per-step) evaluates each action in isolation — correct for single malicious actions, blind to compounds. The top (session-level) evaluates the compound — catches chains, must sit above per-step, not replace it. The zero-click HITL bypass chain is the threat that motivates the top layer.
flowchart TB
subgraph SESSION["SESSION-LEVEL INTENT DETECTION (the required extension)"]
direction TB
IT["INTENT TRACKING<br/>record user's original goal<br/>re-derive sub-goal each turn<br/>from SOURCE, not contaminated context"]
CAD["COMPOUND-ACTION DETECTION<br/>evaluate each new action as the next<br/>element of the session's sequence<br/>flag exfil / escalation / lateral patterns"]
AFW["APPROVAL FRESHNESS WINDOWS<br/>approval valid for bounded window + scope<br/>out-of-window re-triggers with COMPOUND context"]
end
subgraph STEP["PER-STEP APPROVAL (the control B8 built — necessary, insufficient)"]
direction TB
GA["APPROVAL GATE per high-impact action<br/>human sees the step in isolation"]
RES["Result: stops the SINGLE malicious action<br/>BLIND to chains of benign actions"]
end
SESSION -->|"sits ABOVE, not instead of"| STEP
STEP -->|"each step passes individually"| ACTION["individual agent action"]
VULN1["vulnerable to:<br/>zero-click HITL bypass chains<br/>(compound invisible to any single gate)"]:::vuln
VULN2["vulnerable to:<br/>single malicious action<br/>the pattern matcher doesn't recognize"]:::vuln
STEP -. without session layer .-> VULN1
SESSION -. without per-step layer .-> VULN2
classDef vuln fill:#14141f,stroke:#f08080,color:#f08080
style SESSION fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style STEP fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
style IT fill:#101018,stroke:#5eead4,color:#e4e4e8
style CAD fill:#101018,stroke:#5eead4,color:#e4e4e8
style AFW fill:#101018,stroke:#5eead4,color:#e4e4e8
style GA fill:#101018,stroke:#f0a868,color:#e4e4e8
style RES fill:#101018,stroke:#f0a868,color:#e4e4e8
style ACTION fill:#101018,stroke:#9494a0,color:#e4e4e8
Note: The two vulnerability callouts (red) are the argument for running both layers. Per-step approval alone misses the zero-click chain — the compound is invisible to any gate that evaluates a step in isolation. Session-level detection alone misses the novel single malicious action that the pattern matcher was not trained to recognize. Defense in depth, across two scales. This is the direct extension of B8: the observability layer is the substrate; per-turn reasoning-chain detection is the bottom layer; the session-level detector is the top layer the zero-click finding forces into existence.
# Diagrams — Module B10: Microsoft Failure Mode Taxonomy as Red Team Framework
**Module**: B10 — Microsoft Failure Mode Taxonomy as Red Team Framework
**Diagram count**: 5
**Tool**: Mermaid (primary). Each diagram validated in [Mermaid Live Editor](https://mermaid.live).
---
## Diagram 1 — The Seven New Agentic Failure Modes
**Type**: Taxonomy map / radial
**Purpose**: The full surface of the v2.0 update at a glance. The Microsoft AI Red Team's twelve months of deployed agentic red teaming produced seven failure modes that map *imperfectly* onto OWASP ASI — the imperfection is the point. These are the patterns that show up in production when you red-team an agent built to OWASP, not an agent on paper. Each mode names where the controls a builder installed do not compose the way the builder assumed.
**Reading the diagram**: The center is the deployed agentic system; the seven modes radiate as the surfaces a red team probes. The mode numbers are this module's ordering, not Microsoft's. Each mode is annotated with the OWASP ASI risk it overlaps — and the overlap is partial by design.
```mermaid
flowchart TB
CENTER["DEPLOYED AGENTIC SYSTEM<br/>built to OWASP ASI (B9)<br/>still fails in production"]:::center
M1["MODE 1<br/>AGENTIC SUPPLY CHAIN COMPROMISE<br/>malicious tools, MCP servers, skills<br/>≈ ASI08 / ASI05"]:::mode
M2["MODE 2<br/>GOAL HIJACKING<br/>objective redirected via injection<br/>≈ ASI01 (drift, not single-shot)"]:::mode
M3["MODE 3<br/>INTER-AGENT TRUST ESCALATION<br/>sub-agent forges msgs to orchestrator<br/>≈ ASI07 / ASI10"]:::mode
M4["MODE 4<br/>COMPUTER-USE VISUAL ATTACKS<br/>steganographic content via vision<br/>≈ ASI07 (new modality)"]:::mode
M5["MODE 5<br/>SESSION CONTEXT CONTAMINATION<br/>cross-turn context poisoning<br/>≈ ASI04 / ASI06"]:::mode
M6["MODE 6<br/>MCP / PLUGIN ABUSE<br/>dispatch-layer exploitation<br/>≈ ASI05 (registration, not call)"]:::mode
M7["MODE 7<br/>CAPABILITY DISCLOSURE<br/>agent leaks its toolset/prompt<br/>≈ ASI02 (enabler, not impact)"]:::mode
CENTER --- M1
CENTER --- M2
CENTER --- M3
CENTER --- M4
CENTER --- M5
CENTER --- M6
CENTER --- M7
classDef center fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
classDef mode fill:#101018,stroke:#f0a868,color:#e4e4e8
```
> **Note**: The "≈ ASIxx" annotations are overlaps, not equivalences. The divergence is the value: each mode names the chain that defeats the OWASP control in production, not the risk the control was built for. A team that reads this diagram as "we already covered these in B9" has made the synthesis error.
---
## Diagram 2 — The Zero-Click HITL Bypass Chain (the centerpiece)
**Type**: Sequence / chain with approval gates
**Purpose**: The single most important visual in the module. A single external input triggers a multi-step chain where *each individual step passes its human-in-the-loop approval gate* — because each step is benign in isolation — but the *compound* of the steps is data exfiltration. Per-step approval is structurally insufficient to stop this. The malice lives in the compound, not in any step. This is why session-level intent detection is required, layered above per-step approval.
**Reading the diagram**: Left-to-right as time. Each step has its own approval gate (green) that passes. The red bar at the bottom shows the compound intent that no individual gate could see. The dotted session-level detector (top) is the control that *would* catch it — it evaluates the compound, not the step.
```mermaid
flowchart LR
EXT["EXTERNAL INPUT<br/>one email / webhook / doc"]:::entry
subgraph CHAIN["THE FIVE-STEP CHAIN — each step benign in isolation"]
direction LR
S1["1. Receive email<br/>'reconcile Q3 vendors<br/>vs billing, send discrepancies'"]:::step
S2["2. Read vendor list<br/>+ billing records<br/>APPROVED — routine access"]:::stepok
S3["3. Find engineered<br/>'discrepancy'; draft email<br/>CC billing-auditor addr<br/>APPROVED — drafting"]:::stepok
S4["4. Send the email<br/>APPROVED — routine send<br/>human sees reasonable note"]:::stepok
S5["5. Impact: vendor list<br/>+ billing details<br/>exfiltrated to attacker"]:::impact
S1 --> S2 --> S3 --> S4 --> S5
end
EXT --> S1
COMPOUND["COMPOUND INTENT (invisible to any single gate):<br/>external input → data access → engineered artifact → exfil channel → sensitive data out<br/>No approver saw steps 1+3+5 together"]:::compound
CHAIN -. the malice lives here .-> COMPOUND
DETECTOR["SESSION-LEVEL INTENT DETECTOR<br/>tracks goal across session · evaluates compound<br/>flags exfil/escalation/lateral patterns<br/>HALTS at step 4 — the compound is exfiltration"]:::detector
DETECTOR -. watches the compound, not the step .-> CHAIN
classDef entry fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
classDef step fill:#101018,stroke:#9494a0,color:#e4e4e8
classDef stepok fill:#101018,stroke:#82e0aa,color:#82e0aa
classDef impact fill:#14141f,stroke:#f08080,stroke-width:2px,color:#f08080
classDef compound fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
classDef detector fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
```
> **Note**: Every green gate passed correctly. The human who approved step 4 saw a reasonable billing email — they did not see step 1's injected payload, step 3's engineered discrepancy, or the composition. Per-step approval is the right control for a single malicious action and the wrong control for a chain of individually-benign actions. The session-level detector sits *above* per-step approval, not instead of it. You need both — defense in depth across two scales. This is the direct line to B8: the observability layer extended across the session boundary.
---
## Diagram 3 — How the Taxonomy Maps to OWASP (the complementarity)
**Type**: Comparison / overlay
**Purpose**: The thesis made visual. OWASP ASI (B9) and the Microsoft Taxonomy v2.0 (B10) are not redundant — they are complementary by *function*. OWASP is a defense checklist read as a builder; this taxonomy is a red-team framework read as an attacker. The same named risk (Goal Hijacking, Supply Chain) appears in both, but as different artifacts: one is a control, the other is the procedure that finds the gap between the control on paper and the control in production. A mature program runs both.
**Reading the diagram**: Two columns. Left = OWASP (B9), the defense checklist — the question is "what do I defend?" Right = Microsoft (B10), the red-team framework — the question is "how do attackers chain?" The arrows show the cross-references: each OWASP row is the control; the matching taxonomy entry is the chain that crosses it.
```mermaid
flowchart LR
subgraph OWASP["OWASP ASI (B9) — DEFENSE CHECKLIST"]
direction TB
O_Q["Read as: a BUILDER"]
O_U["Unit: the RISK<br/>(one row, one control, one test)"]
O_OUT["Output: scored report<br/>PASS / FAIL / MEASURED per row"]
O_ASK["What do I defend?<br/>How do I prove the control is present?"]
end
subgraph MSFT["MICROSOFT TAXONOMY v2.0 (B10) — RED-TEAM FRAMEWORK"]
direction TB
M_Q["Read as: an ATTACKER"]
M_U["Unit: the CHAIN<br/>(multi-step, compound intent)"]
M_OUT["Output: reproduced chain<br/>+ the session-level gap identified"]
M_ASK["How do systems fail in production?<br/>How do I chain those failures?"]
end
OWASP ---|"same named risk,<br/>DIFFERENT artifact"| MSFT
O1["ASI01 Goal Hijacking<br/>control: taint gate, isolation"]:::ctrl
M1["Mode 2: the DRIFT chain<br/>that defeats the taint gate<br/>across turns"]:::chain
O1 -. control vs chain .-> M1
O2["ASI08 Supply Chain<br/>control: provenance checks"]:::ctrl
M2["Mode 1: the ENTIRE tool-registration<br/>layer IS the supply chain"]:::chain
O2 -. control vs chain .-> M2
classDef ctrl fill:#101018,stroke:#5eead4,color:#e4e4e8
classDef chain fill:#101018,stroke:#f0a868,color:#e4e4e8
style OWASP fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style MSFT fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
```
> **Note**: The last row of the complementarity table in the teaching doc is the entire relationship: OWASP assumes controls, if present and passing, compose into security. The Microsoft taxonomy assumes they do *not* — and the gap is where the attacker lives. A program that runs only B9 misses every failure mode that lives *between* the rows; a program that runs only B10 misses the missing taint gate, the absent canary, the unscoped credential. You need both, layered. B12 packages them as one engagement.
---
## Diagram 4 — The Red-Team Engagement Flow Using the Taxonomy
**Type**: Process / procedure
**Purpose**: How a red-team engagement is designed around this taxonomy. The unit is not the row (B9) but the *chain*. The procedure: reconnaissance via capability disclosure, surface selection, chain construction (each step must pass its control individually), compound delivery via a single external input, and gap identification (the deliverable is the session-level gap, not "the chain worked"). This is the methodology B12 turns into a service.
**Reading the diagram**: Top-to-bottom as the engagement. Note that step 3 (chain construction) explicitly requires each step to pass its OWASP control — the chain is designed *against a system built to B9*, which is why both are needed. The deliverable at step 5 is the gap the client patches.
```mermaid
flowchart TB
R["1. RECONNAISSANCE<br/>via Capability Disclosure (Mode 7)<br/>enumerate actual tools, prompts, config"]:::recon
SS["2. SURFACE SELECTION<br/>pick entry point:<br/>supply chain · inter-agent · vision<br/>session-context · dispatch · indirect-inj"]:::select
CC["3. CHAIN CONSTRUCTION<br/>sequence the steps — each must pass<br/>its OWASP control INDIVIDUALLY<br/>(taint gate, approval gate, schema validator)<br/>malice lives in the COMPOUND"]:::build
CD["4. COMPOUND DELIVERY<br/>trigger via single external input<br/>(zero-click) or minimum human interaction"]:::deliver
GI["5. GAP IDENTIFICATION<br/>deliverable = the session-level gap<br/>that let the compound pass<br/>(missing intent check, absent freshness window,<br/>per-step approval that saw only its step)"]:::gap
R --> SS --> CC --> CD --> GI
GI -->|client patches the gap| B8EXT["extends B8 across<br/>the session boundary"]:::outcome
classDef recon fill:#101018,stroke:#5eead4,color:#e4e4e8
classDef select fill:#101018,stroke:#5eead4,color:#e4e4e8
classDef build fill:#101018,stroke:#f0a868,color:#e4e4e8
classDef deliver fill:#101018,stroke:#f08080,color:#e4e4e8
classDef gap fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
classDef outcome fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
```
> **Note**: Step 3 is the design constraint that makes this taxonomy a red-team framework rather than a re-labeling of OWASP: each step in the chain must pass the control B9 built for it. The chain is engineered to slip *between* the controls, not through a missing one. If a step fails its control, the red-teamer has found a B9 row-level failure (good, report it), but not a chain. The chain is the compound that no single control catches.
---
## Diagram 5 — Per-Step Approval vs. Session-Level Intent Detection
**Type**: Control architecture / layered defense
**Purpose**: Why per-step approval (the control B8 built) is necessary and insufficient, and how session-level intent detection layers above it. Two scales of defense: per-step approval stops the single malicious action; session-level detection stops the chain of benign actions. A deployed agent needs both — an agent with only per-step approval is vulnerable to zero-click chains; an agent with only session-level detection is vulnerable to the single malicious action the pattern matcher does not recognize.
**Reading the diagram**: Two stacked layers. The bottom (per-step) evaluates each action in isolation — correct for single malicious actions, blind to compounds. The top (session-level) evaluates the compound — catches chains, must sit above per-step, not replace it. The zero-click HITL bypass chain is the threat that motivates the top layer.
```mermaid
flowchart TB
subgraph SESSION["SESSION-LEVEL INTENT DETECTION (the required extension)"]
direction TB
IT["INTENT TRACKING<br/>record user's original goal<br/>re-derive sub-goal each turn<br/>from SOURCE, not contaminated context"]
CAD["COMPOUND-ACTION DETECTION<br/>evaluate each new action as the next<br/>element of the session's sequence<br/>flag exfil / escalation / lateral patterns"]
AFW["APPROVAL FRESHNESS WINDOWS<br/>approval valid for bounded window + scope<br/>out-of-window re-triggers with COMPOUND context"]
end
subgraph STEP["PER-STEP APPROVAL (the control B8 built — necessary, insufficient)"]
direction TB
GA["APPROVAL GATE per high-impact action<br/>human sees the step in isolation"]
RES["Result: stops the SINGLE malicious action<br/>BLIND to chains of benign actions"]
end
SESSION -->|"sits ABOVE, not instead of"| STEP
STEP -->|"each step passes individually"| ACTION["individual agent action"]
VULN1["vulnerable to:<br/>zero-click HITL bypass chains<br/>(compound invisible to any single gate)"]:::vuln
VULN2["vulnerable to:<br/>single malicious action<br/>the pattern matcher doesn't recognize"]:::vuln
STEP -. without session layer .-> VULN1
SESSION -. without per-step layer .-> VULN2
classDef vuln fill:#14141f,stroke:#f08080,color:#f08080
style SESSION fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style STEP fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
style IT fill:#101018,stroke:#5eead4,color:#e4e4e8
style CAD fill:#101018,stroke:#5eead4,color:#e4e4e8
style AFW fill:#101018,stroke:#5eead4,color:#e4e4e8
style GA fill:#101018,stroke:#f0a868,color:#e4e4e8
style RES fill:#101018,stroke:#f0a868,color:#e4e4e8
style ACTION fill:#101018,stroke:#9494a0,color:#e4e4e8
```
> **Note**: The two vulnerability callouts (red) are the argument for running both layers. Per-step approval alone misses the zero-click chain — the compound is invisible to any gate that evaluates a step in isolation. Session-level detection alone misses the novel single malicious action that the pattern matcher was not trained to recognize. Defense in depth, across two scales. This is the direct extension of B8: the observability layer is the substrate; per-turn reasoning-chain detection is the bottom layer; the session-level detector is the top layer the zero-click finding forces into existence.