Module: B9 — OWASP Agentic Top 10 as Engineering Checklist Diagram count: 6 Tool: Mermaid (primary). Each diagram validated in Mermaid Live Editor.
Type: Attack-surface map / boundary grouping Purpose: The single most important conceptual visual in the module. The ten OWASP ASI risks are not ten independent items; they are ten named failure points grouped into five boundaries (input, permission, state, tool, output/resource), each defended by a course module. This diagram is what makes the checklist a synthesis rather than a list. An attack chain crosses multiple boundaries — a goal-hijacking payload (input) delivers through a tool output (tool), writes a poisoned memory (state), and reaches impact through an over-privileged tool (permission). Reading the diagram: Five teal boundary clusters, each containing two red ASI risks. The module defending each boundary is labeled. The warning node at the bottom states the synthesis thesis: the risks are entangled, and the checklist tests all five boundaries.
flowchart TB
subgraph INPUT["INPUT BOUNDARY — untrusted content becomes instruction"]
direction TB
ASI01["ASI01 · GOAL HIJACKING<br/>prompt injection redirects objective"]:::risk
ASI02["ASI02 · PROMPT LEAKAGE<br/>system prompt / memory extracted"]:::risk
end
subgraph PERM["PERMISSION BOUNDARY — agent acts beyond its scope"]
direction TB
ASI03["ASI03 · EXCESSIVE AGENCY<br/>more permissions than task requires"]:::risk
ASI10["ASI10 · BROKEN ACCESS CONTROL<br/>acts on wrong / unauth principal"]:::risk
end
subgraph STATE["STATE BOUNDARY — persisted facts corrupt reasoning"]
direction TB
ASI04["ASI04 · MEMORY POISONING<br/>attacker writes false facts to memory"]:::risk
ASI06["ASI06 · CASCADING HALLUCINATION<br/>one hallucinated result corrupts downstream"]:::risk
end
subgraph TOOL["TOOL BOUNDARY — tools misused or malicious"]
direction TB
ASI05["ASI05 · TOOL / SKILL ABUSE<br/>legitimate tools, unintended purpose"]:::risk
ASI08["ASI08 · SUPPLY CHAIN ATTACKS<br/>malicious MCP server / tool / skill package"]:::risk
end
subgraph OUT["OUTPUT / RESOURCE BOUNDARY — output & compute misuse"]
direction TB
ASI07["ASI07 · INSECURE OUTPUT HANDLING<br/>agent output used unsanitized downstream"]:::risk
ASI09["ASI09 · RESOURCE EXHAUSTION<br/>induced to run indefinitely"]:::risk
end
DEF_INPUT["DEFENDED BY<br/>B2 — Prompt Injection Defense"]:::def
DEF_PERM["DEFENDED BY<br/>B5 — Identity & Permission"]:::def
DEF_STATE["DEFENDED BY<br/>B3 + B8 — Memory & Observability"]:::def
DEF_TOOL["DEFENDED BY<br/>B4 — Tool & MCP Security"]:::def
DEF_OUT["DEFENDED BY<br/>B7 — Sandbox Execution"]:::def
INPUT --> DEF_INPUT
PERM --> DEF_PERM
STATE --> DEF_STATE
TOOL --> DEF_TOOL
OUT --> DEF_OUT
THESIS["SYNTHESIS: the risks are entangled.<br/>An attack chain crosses boundaries —<br/>injection (input) via a tool (tool),<br/>poisons memory (state), reaches impact<br/>through over-privilege (permission).<br/>The checklist tests all five boundaries."]:::thesis
DEF_INPUT --> THESIS
DEF_PERM --> THESIS
DEF_STATE --> THESIS
DEF_TOOL --> THESIS
DEF_OUT --> THESIS
classDef risk fill:#101018,stroke:#f08080,stroke-width:1.5px,color:#f08080
classDef def fill:#101018,stroke:#5eead4,color:#5eead4
classDef thesis fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
style INPUT fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style PERM fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style STATE fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style TOOL fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style OUT fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
Note: The ten risks group into five boundaries because they fail at the same structural points. ASI01 and ASI02 both fail at the input boundary (untrusted content becoming instruction or extracting the prompt). ASI03 and ASI10 both fail at the permission boundary (the agent acting beyond scope). Grouping them this way is what makes the checklist a synthesis: testing both risks at a boundary verifies the boundary's defense, and the defense module (B2, B5, B3+B8, B4, B7) is the same for both risks at that boundary. A harness that defends all five boundaries has a defensible position across the entire agentic attack surface.
Type: Mapping / cross-reference matrix Purpose: The core synthesis visual. Every ASI risk maps to a module in this course (B2–B8) where the defense is built in depth, and to a Course 1 layer. This is what makes B9 a synthesis module rather than a new surface — the student has already built every defense the checklist requires. The diagram is the proof: ten risks, seven modules, every risk routed. Reading the diagram: Left = the ten ASI risks (red). Right = the seven defense modules (teal). Each risk routes to its module. B2 and B5 each defend two risks (the input and permission boundaries carry two each); B4 defends two (tool boundary); B7 defends two (output/resource boundary); B3 and B8 split the state boundary. No risk is orphaned.
flowchart LR
subgraph RISKS["OWASP AGENTIC TOP 10 (2026)"]
direction TB
R01["ASI01 Goal Hijacking"]:::risk
R02["ASI02 Prompt Leakage"]:::risk
R03["ASI03 Excessive Agency"]:::risk
R04["ASI04 Memory Poisoning"]:::risk
R05["ASI05 Tool/Skill Abuse"]:::risk
R06["ASI06 Cascading Hallucination"]:::risk
R07["ASI07 Insecure Output Handling"]:::risk
R08["ASI08 Supply Chain Attacks"]:::risk
R09["ASI09 Resource Exhaustion"]:::risk
R10["ASI10 Broken Access Control"]:::risk
end
subgraph MODULES["DEFENSE MODULES (B2–B8)"]
direction TB
M2["B2 · Prompt Injection Defense<br/>taint gate · isolation · capability min<br/>Course 1: 6.3, layer 9"]:::mod
M3["B3 · Memory & Context Poisoning<br/>harness-managed writes · retrieval tagging<br/>Course 1: 4.3"]:::mod
M4["B4 · Tool & MCP Security<br/>tool contracts · provenance · MCP hygiene<br/>Course 1: 2.4, 2.3"]:::mod
M5["B5 · Identity & Permission<br/>scoped principals · principal binding<br/>Course 1: 5.3, 6.1"]:::mod
M7["B7 · Sandbox Execution<br/>limits · circuit breakers · output sanitization<br/>Course 1: 5.3, 5.4, 7.2"]:::mod
M8["B8 · Observability & Detection<br/>verification · provenance · chain detection<br/>Course 1: 9"]:::mod
end
R01 --> M2
R02 --> M2
R03 --> M5
R04 --> M3
R05 --> M4
R06 --> M8
R07 --> M7
R08 --> M4
R09 --> M7
R10 --> M5
SYNTH["EVERY RISK ROUTED.<br/>B9 tests the defenses B2–B8 built.<br/>No new control introduced in this module."]:::synth
MODULES --> SYNTH
classDef risk fill:#101018,stroke:#f08080,color:#f08080
classDef mod fill:#101018,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
classDef synth fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
style RISKS fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#e4e4e8
style MODULES fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
Note: This is the diagram that distinguishes B9 from every other module in the course. B2 through B8 each build a defense; B9 proves those defenses are present and working. The mapping is the proof of completeness: if every risk routes to a module that built its defense, then running the checklist's ten tests verifies the entire B2–B8 defense-in-depth architecture in a single scored report. A risk with no defense module would be a gap in the course; there is none. The canonical numbering (ASI01 Goal Hijacking through ASI10 Broken Access Control) is verified against the OWASP primary source and Course 1 Module 11.
Type: Process / card format Purpose: Shows the fixed four-part treatment every ASI risk receives in B9.2. This is the module's signature contribution: not a risk description, but an attack procedure, a defense architecture, a course module, and a concrete test. The test is what makes the row executable — it is what the lab encodes and what the checklist runs. Reading the diagram: Each risk flows through four stages (the columns). The attack procedure is the red-team action. The defense architecture is the control. The course module is where the control is built. The test is the runnable assertion. The output is a checklist row with a result type (PASS/FAIL or MEASURED).
flowchart LR
RISK["ASIxx<br/>THE RISK<br/>defined in engineering terms<br/>(what fails, where, which layer)"]:::risk
subgraph TREATMENT["THE FOUR-PART TREATMENT (B9.2)"]
direction LR
A["(b) ATTACK PROCEDURE<br/>the specific red-team action<br/>not a category — a procedure<br/>(plant payload, enumerate, induce)"]:::attack
D["(c) DEFENSE ARCHITECTURE<br/>the control that stops it<br/>+ the Course 1 layer it specializes<br/>(taint gate, allowlist, sandbox)"]:::def
M["(d) COURSE MODULE<br/>where the control is<br/>built in depth<br/>(B2, B3, B4, B5, B7, B8)"]:::mod
T["(e) THE TEST<br/>the runnable assertion<br/>the lab encodes<br/>(block? gated? halted? leaked?)"]:::test
end
RISK --> A --> D --> M --> T
ROW["CHECKLIST ROW<br/>risk · attack · control · module · test<br/>RESULT TYPE: PASS/FAIL (deterministic)<br/>or MEASURED (probabilistic residual)"]:::row
T --> ROW
classDef risk fill:#101018,stroke:#f08080,stroke-width:1.5px,color:#f08080
classDef attack fill:#101018,stroke:#f08080,color:#f08080
classDef def fill:#101018,stroke:#5eead4,color:#5eead4
classDef mod fill:#101018,stroke:#5eead4,color:#5eead4
classDef test fill:#101018,stroke:#82e0aa,color:#82e0aa
classDef row fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
style TREATMENT fill:#14141f,stroke:#9494a0,color:#e4e4e8
Note: The four-part format is what turns a risk-awareness list into an engineering checklist. Without the attack procedure, you cannot test. Without the defense architecture, you do not know what to verify. Without the course module, you do not know where to build the fix if the test fails. Without the test, the row is not executable. Every one of the ten treatments in B9.2 follows this exact shape, and the lab's executor runs the test column for all ten.
Type: Stacked defense architecture Purpose: The Course 1 Module 11 nine-layer defense stack, specialized to show which layers defend which ASI risks. This is the defense-in-depth architecture the checklist verifies. Read top-to-bottom as the layers an attack must cross. The right column shows which ASI risks each layer catches. Reading the diagram: Nine teal layers (from Course 1's stack), each annotated with its Course 1 layer number and the ASI risks it defends. The deterministic layers (taint gate, capability, sandbox, identity) are highlighted — they are the layers that report PASS/FAIL. The probabilistic layers (detection, verification) report MEASURED.
flowchart TB
subgraph STACK["THE 9-LAYER DEFENSE STACK (Course 1 M11) — SPECIALIZED TO ASI RISKS"]
direction TB
L1["L1 · INPUT VALIDATION<br/>untrusted-content tagging<br/>Course 1: 6.3<br/>defends: ASI01, ASI02 (input boundary)"]:::prob
L2["L2 · INSTRUCTION HIERARCHY<br/>system prompt in privileged role<br/>Course 1: instruction hierarchy<br/>defends: ASI01, ASI02"]:::prob
L3["L3 · POLICY ENFORCEMENT — TAINT GATE<br/>mark, propagate, gate high-impact<br/>DETERMINISTIC CORE<br/>Course 1: policy enforcement<br/>defends: ASI01 (the load-bearing control)"]:::det
L4["L4 · OUTPUT GOVERNANCE — DETECTION<br/>secondary-model injection detector<br/>Course 1: CrabTrap (DD-19)<br/>defends: ASI01 (encoded class)"]:::prob
L5["L5 · CAPABILITY / SANDBOX<br/>tools scoped to minimum, sandboxed<br/>DETERMINISTIC FLOOR<br/>Course 1: IronCurtain (DD-20), 5.3, 5.4<br/>defends: ASI03, ASI07, ASI09"]:::det
L6["L6 · IDENTITY / ACCESS<br/>scoped non-human principals, principal binding<br/>DETERMINISTIC<br/>Course 1: 5.3, 6.1<br/>defends: ASI03, ASI10"]:::det
L7["L7 · RESOURCE CONTROL — CIRCUIT BREAKERS<br/>token/time/cost ceilings, loop detection<br/>DETERMINISTIC<br/>Course 1: 5.4, 7.2<br/>defends: ASI09"]:::det
L8["L8 · MEMORY GOVERNANCE<br/>harness-managed writes, retrieval-time tagging<br/>DETERMINISTIC GATE<br/>Course 1: 4.3<br/>defends: ASI04"]:::det
L9["L9 · VERIFICATION / OBSERVABILITY<br/>provenance tagging, reasoning-chain detection<br/>PROBABILISTIC<br/>Course 1: 9<br/>defends: ASI02 (egress), ASI06 (hallucination)"]:::prob
end
LEGEND["LEGEND:<br/>DETERMINISTIC (teal, bold) → PASS/FAIL<br/>PROBABILISTIC (teal) → MEASURED residual<br/>8 rows binary, 2 rows measured (ASI01, ASI06)"]:::legend
STACK --> LEGEND
classDef det fill:#101018,stroke:#5eead4,stroke-width:2px,color:#5eead4
classDef prob fill:#101018,stroke:#5eead4,color:#e4e4e8
classDef legend fill:#14141f,stroke:#9494a0,color:#9494a0
style STACK fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
Note: The stack's specialization to ASI risks is the defense-in-depth argument made concrete. An attack must cross L1 (tag), L2 (isolation), L3 (taint gate — deterministic), L4 (detector), L5 (capability/sandbox — deterministic), L6 (identity — deterministic), L7 (resource — deterministic), L8 (memory gate — deterministic), and L9 (verification). The deterministic layers (L3, L5, L6, L7, L8) are why eight of the ten checklist rows report PASS/FAIL — the control is a gate with no bypass rate. The probabilistic layers (L1, L2, L4, L9) are why ASI01 and ASI06 report MEASURED — the model's compliance and the detector's miss rate are numbers, not booleans. The split is the B2.3 resolution applied across all ten risks.
Type: Classification / result-type matrix Purpose: The B9.3 thesis made visual. Eight of the ten checklist rows report PASS/FAIL because their controls are deterministic (gates with no bypass rate). Two report MEASURED because their controls are probabilistic (nonzero bypass rate). A checklist that reported PASS/FAIL on all ten would be lying about ASI01 and ASI06. This diagram is the rule that prevents the false certainty. Reading the diagram: Left = the deterministic rows (eight risks, PASS/FAIL). Right = the probabilistic rows (two risks, MEASURED). The warning node is the anti-pattern: collapsing a measured row into a binary.
flowchart TB
subgraph DET["DETERMINISTIC CONTROLS — PASS/FAIL (8 rows)"]
direction TB
D02["ASI02 Prompt Leakage<br/>canary substring match + egress filter"]:::det
D03["ASI03 Excessive Agency<br/>capability allowlist — present or absent"]:::det
D04["ASI04 Memory Poisoning<br/>harness-managed write gate — gated or not"]:::det
D05["ASI05 Tool/Skill Abuse<br/>argument validators — pass or fail"]:::det
D07["ASI07 Insecure Output Handling<br/>output sanitization — escaped or not"]:::det
D08["ASI08 Supply Chain Attacks<br/>provenance check — signature verifies or not"]:::det
D09["ASI09 Resource Exhaustion<br/>hard ceiling — count crosses or not"]:::det
D10["ASI10 Broken Access Control<br/>principal binding — tenant matches or not"]:::det
end
subgraph PROB["PROBABILISTIC CONTROLS — MEASURED (2 rows)"]
direction TB
P01["ASI01 Goal Hijacking<br/>taint gate is deterministic, BUT<br/>detector + model compliance are probabilistic<br/>→ measured residual rate"]:::prob
P06["ASI06 Cascading Hallucination<br/>verification catches unverified claims, BUT<br/>hallucination-detection has a miss rate<br/>→ measured block rate"]:::prob
end
RULE["THE RULE (B2.3 applied to all 10):<br/>determinism where the question is structural & enumerable<br/>(in the allowlist? principal match? signature valid?)<br/>measurement where the question is semantic & open<br/>(did injection succeed? did hallucination propagate?)"]:::rule
ANTIPATTERN["ANTI-PATTERN: collapsing a MEASURED row<br/>into PASS/FAIL claims certainty where the<br/>control is probabilistic. ASI01 'PASS' is a lie —<br/>the honest result is 'residual 2%, the encoded class.'"]:::bad
DET --> RULE
PROB --> RULE
RULE --> ANTIPATTERN
classDef det fill:#101018,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
classDef prob fill:#101018,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
classDef rule fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
classDef bad fill:#101018,stroke:#f08080,stroke-width:1.5px,color:#f08080
style DET fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style PROB fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
Note: The 8/2 split is not arbitrary — it follows directly from which Course 1 layers defend which risks. The deterministic layers (L3 taint gate, L5 capability, L6 identity, L7 resource, L8 memory gate) defend eight risks with gates. The probabilistic layers (L1/L2 input, L4 detection, L9 verification) defend ASI01 and ASI06 with judgments that have a bypass rate. The checklist's Result-type column enforces the honesty: a row's result type is determined by the kind of control that defends it, not by the tester's preference. B2.3's resolution (determinism on the structural boundary, probability on the semantic boundary) is the principle; this diagram is its application across the full top 10.
Type: Flow / engagement pipeline Purpose: Shows how the ten-row checklist becomes the engagement contract for B12 (Harness Security Assessments as a Service). The checklist is the scope; the scored report is the deliverable. The two measured rows become the recurring value (the residual trend over engagements). This is the operational payoff of treating the Top 10 as a checklist rather than a reading list. Reading the diagram: Top = the ten checklist rows (the scope). Middle = the engagement (run each test, capture evidence per B0, produce scored report). Bottom = the deliverable (8 PASS/FAIL + 2 MEASURED) and the recurring value (residual trend). The warning node is the scope-completeness rule: a skipped row is an untested row.
flowchart TB
subgraph SCOPE["THE CHECKLIST = ENGAGEMENT SCOPE (10 rows)"]
direction LR
S1["ASI01–05<br/>input, permission,<br/>state, tool boundaries"]:::scope
S2["ASI06–10<br/>state, tool,<br/>output, resource, access"]:::scope
end
ENG["B12 ENGAGEMENT<br/>per row: run the test (B9.2 attack procedure)<br/>capture evidence (B0: model version, success rate, scope ref)<br/>verify the control (B9.2 defense architecture)<br/>record result (PASS/FAIL or MEASURED)"]:::eng
SCOPE --> ENG
subgraph DELIVERABLE["THE SCORED REPORT (deliverable)"]
direction TB
D1["8 rows PASS/FAIL<br/>(deterministic controls)"]:::det
D2["2 rows MEASURED<br/>ASI01 residual rate<br/>ASI06 block-miss rate"]:::prob
end
ENG --> DELIVERABLE
RECURRING["RECURRING VALUE (B12 methodology)<br/>quarterly engagement tracks the residual trend —<br/>did ASI01 drop 4%→1% after L4 tuned?<br/>did ASI06 rise 3%→8% after a new tool?<br/>the trend is the signal; the point is the data"]:::recur
DELIVERABLE --> RECURRING
WARN["SCOPE-COMPLETENESS RULE:<br/>an assessment covers all 10 rows.<br/>A genuinely-absent surface reports N/A with<br/>justification — never silently skipped.<br/>A skipped row is an untested row."]:::warn
SCOPE -.-> WARN
classDef scope fill:#101018,stroke:#5eead4,color:#5eead4
classDef eng fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
classDef det fill:#101018,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
classDef prob fill:#101018,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
classDef recur fill:#14141f,stroke:#82e0aa,stroke-width:2px,color:#82e0aa
classDef warn fill:#101018,stroke:#f08080,stroke-width:1.5px,color:#f08080
style SCOPE fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style DELIVERABLE fill:#14141f,stroke:#9494a0,color:#e4e4e8
Note: This is the diagram that connects B9 to B12 and to the course's assessment capstone. The checklist is not an academic exercise; it is the scope document a tester hands a client. The scored report is not a slide deck; it is the deliverable a CISO acts on. The two measured rows are where the recurring engagement earns its keep — a single assessment reports a point; a quarterly engagement reports a trend, and the trend is what tells the client whether their defenses are degrading. The scope-completeness rule (no silently skipped rows) is what makes the assessment defensible: a client who receives a report with nine rows tested and one silently absent has a gap they do not know about. The checklist's structure forces the absence to be explicit (N/A with justification), not hidden.
# Diagrams — Module B9: OWASP Agentic Top 10 as Engineering Checklist
**Module**: B9 — OWASP Agentic Top 10 as Engineering Checklist
**Diagram count**: 6
**Tool**: Mermaid (primary). Each diagram validated in [Mermaid Live Editor](https://mermaid.live).
---
## Diagram 1 — The Ten Risks as One Attack-Surface Map
**Type**: Attack-surface map / boundary grouping
**Purpose**: The single most important conceptual visual in the module. The ten OWASP ASI risks are not ten independent items; they are ten named failure points grouped into five boundaries (input, permission, state, tool, output/resource), each defended by a course module. This diagram is what makes the checklist a synthesis rather than a list. An attack chain crosses multiple boundaries — a goal-hijacking payload (input) delivers through a tool output (tool), writes a poisoned memory (state), and reaches impact through an over-privileged tool (permission).
**Reading the diagram**: Five teal boundary clusters, each containing two red ASI risks. The module defending each boundary is labeled. The warning node at the bottom states the synthesis thesis: the risks are entangled, and the checklist tests all five boundaries.
```mermaid
flowchart TB
subgraph INPUT["INPUT BOUNDARY — untrusted content becomes instruction"]
direction TB
ASI01["ASI01 · GOAL HIJACKING<br/>prompt injection redirects objective"]:::risk
ASI02["ASI02 · PROMPT LEAKAGE<br/>system prompt / memory extracted"]:::risk
end
subgraph PERM["PERMISSION BOUNDARY — agent acts beyond its scope"]
direction TB
ASI03["ASI03 · EXCESSIVE AGENCY<br/>more permissions than task requires"]:::risk
ASI10["ASI10 · BROKEN ACCESS CONTROL<br/>acts on wrong / unauth principal"]:::risk
end
subgraph STATE["STATE BOUNDARY — persisted facts corrupt reasoning"]
direction TB
ASI04["ASI04 · MEMORY POISONING<br/>attacker writes false facts to memory"]:::risk
ASI06["ASI06 · CASCADING HALLUCINATION<br/>one hallucinated result corrupts downstream"]:::risk
end
subgraph TOOL["TOOL BOUNDARY — tools misused or malicious"]
direction TB
ASI05["ASI05 · TOOL / SKILL ABUSE<br/>legitimate tools, unintended purpose"]:::risk
ASI08["ASI08 · SUPPLY CHAIN ATTACKS<br/>malicious MCP server / tool / skill package"]:::risk
end
subgraph OUT["OUTPUT / RESOURCE BOUNDARY — output & compute misuse"]
direction TB
ASI07["ASI07 · INSECURE OUTPUT HANDLING<br/>agent output used unsanitized downstream"]:::risk
ASI09["ASI09 · RESOURCE EXHAUSTION<br/>induced to run indefinitely"]:::risk
end
DEF_INPUT["DEFENDED BY<br/>B2 — Prompt Injection Defense"]:::def
DEF_PERM["DEFENDED BY<br/>B5 — Identity & Permission"]:::def
DEF_STATE["DEFENDED BY<br/>B3 + B8 — Memory & Observability"]:::def
DEF_TOOL["DEFENDED BY<br/>B4 — Tool & MCP Security"]:::def
DEF_OUT["DEFENDED BY<br/>B7 — Sandbox Execution"]:::def
INPUT --> DEF_INPUT
PERM --> DEF_PERM
STATE --> DEF_STATE
TOOL --> DEF_TOOL
OUT --> DEF_OUT
THESIS["SYNTHESIS: the risks are entangled.<br/>An attack chain crosses boundaries —<br/>injection (input) via a tool (tool),<br/>poisons memory (state), reaches impact<br/>through over-privilege (permission).<br/>The checklist tests all five boundaries."]:::thesis
DEF_INPUT --> THESIS
DEF_PERM --> THESIS
DEF_STATE --> THESIS
DEF_TOOL --> THESIS
DEF_OUT --> THESIS
classDef risk fill:#101018,stroke:#f08080,stroke-width:1.5px,color:#f08080
classDef def fill:#101018,stroke:#5eead4,color:#5eead4
classDef thesis fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
style INPUT fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style PERM fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style STATE fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style TOOL fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style OUT fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
```
> **Note**: The ten risks group into five boundaries because they fail at the same structural points. ASI01 and ASI02 both fail at the input boundary (untrusted content becoming instruction or extracting the prompt). ASI03 and ASI10 both fail at the permission boundary (the agent acting beyond scope). Grouping them this way is what makes the checklist a synthesis: testing both risks at a boundary verifies the boundary's defense, and the defense module (B2, B5, B3+B8, B4, B7) is the same for both risks at that boundary. A harness that defends all five boundaries has a defensible position across the entire agentic attack surface.
---
## Diagram 2 — Risk-to-Defense-Module Mapping
**Type**: Mapping / cross-reference matrix
**Purpose**: The core synthesis visual. Every ASI risk maps to a module in this course (B2–B8) where the defense is built in depth, and to a Course 1 layer. This is what makes B9 a synthesis module rather than a new surface — the student has already built every defense the checklist requires. The diagram is the proof: ten risks, seven modules, every risk routed.
**Reading the diagram**: Left = the ten ASI risks (red). Right = the seven defense modules (teal). Each risk routes to its module. B2 and B5 each defend two risks (the input and permission boundaries carry two each); B4 defends two (tool boundary); B7 defends two (output/resource boundary); B3 and B8 split the state boundary. No risk is orphaned.
```mermaid
flowchart LR
subgraph RISKS["OWASP AGENTIC TOP 10 (2026)"]
direction TB
R01["ASI01 Goal Hijacking"]:::risk
R02["ASI02 Prompt Leakage"]:::risk
R03["ASI03 Excessive Agency"]:::risk
R04["ASI04 Memory Poisoning"]:::risk
R05["ASI05 Tool/Skill Abuse"]:::risk
R06["ASI06 Cascading Hallucination"]:::risk
R07["ASI07 Insecure Output Handling"]:::risk
R08["ASI08 Supply Chain Attacks"]:::risk
R09["ASI09 Resource Exhaustion"]:::risk
R10["ASI10 Broken Access Control"]:::risk
end
subgraph MODULES["DEFENSE MODULES (B2–B8)"]
direction TB
M2["B2 · Prompt Injection Defense<br/>taint gate · isolation · capability min<br/>Course 1: 6.3, layer 9"]:::mod
M3["B3 · Memory & Context Poisoning<br/>harness-managed writes · retrieval tagging<br/>Course 1: 4.3"]:::mod
M4["B4 · Tool & MCP Security<br/>tool contracts · provenance · MCP hygiene<br/>Course 1: 2.4, 2.3"]:::mod
M5["B5 · Identity & Permission<br/>scoped principals · principal binding<br/>Course 1: 5.3, 6.1"]:::mod
M7["B7 · Sandbox Execution<br/>limits · circuit breakers · output sanitization<br/>Course 1: 5.3, 5.4, 7.2"]:::mod
M8["B8 · Observability & Detection<br/>verification · provenance · chain detection<br/>Course 1: 9"]:::mod
end
R01 --> M2
R02 --> M2
R03 --> M5
R04 --> M3
R05 --> M4
R06 --> M8
R07 --> M7
R08 --> M4
R09 --> M7
R10 --> M5
SYNTH["EVERY RISK ROUTED.<br/>B9 tests the defenses B2–B8 built.<br/>No new control introduced in this module."]:::synth
MODULES --> SYNTH
classDef risk fill:#101018,stroke:#f08080,color:#f08080
classDef mod fill:#101018,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
classDef synth fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
style RISKS fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#e4e4e8
style MODULES fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
```
> **Note**: This is the diagram that distinguishes B9 from every other module in the course. B2 through B8 each build a defense; B9 proves those defenses are present and working. The mapping is the proof of completeness: if every risk routes to a module that built its defense, then running the checklist's ten tests verifies the entire B2–B8 defense-in-depth architecture in a single scored report. A risk with no defense module would be a gap in the course; there is none. The canonical numbering (ASI01 Goal Hijacking through ASI10 Broken Access Control) is verified against the OWASP primary source and Course 1 Module 11.
---
## Diagram 3 — The Per-Risk Treatment Format (Attack + Defense + Test)
**Type**: Process / card format
**Purpose**: Shows the fixed four-part treatment every ASI risk receives in B9.2. This is the module's signature contribution: not a risk description, but an attack procedure, a defense architecture, a course module, and a concrete test. The test is what makes the row executable — it is what the lab encodes and what the checklist runs.
**Reading the diagram**: Each risk flows through four stages (the columns). The attack procedure is the red-team action. The defense architecture is the control. The course module is where the control is built. The test is the runnable assertion. The output is a checklist row with a result type (PASS/FAIL or MEASURED).
```mermaid
flowchart LR
RISK["ASIxx<br/>THE RISK<br/>defined in engineering terms<br/>(what fails, where, which layer)"]:::risk
subgraph TREATMENT["THE FOUR-PART TREATMENT (B9.2)"]
direction LR
A["(b) ATTACK PROCEDURE<br/>the specific red-team action<br/>not a category — a procedure<br/>(plant payload, enumerate, induce)"]:::attack
D["(c) DEFENSE ARCHITECTURE<br/>the control that stops it<br/>+ the Course 1 layer it specializes<br/>(taint gate, allowlist, sandbox)"]:::def
M["(d) COURSE MODULE<br/>where the control is<br/>built in depth<br/>(B2, B3, B4, B5, B7, B8)"]:::mod
T["(e) THE TEST<br/>the runnable assertion<br/>the lab encodes<br/>(block? gated? halted? leaked?)"]:::test
end
RISK --> A --> D --> M --> T
ROW["CHECKLIST ROW<br/>risk · attack · control · module · test<br/>RESULT TYPE: PASS/FAIL (deterministic)<br/>or MEASURED (probabilistic residual)"]:::row
T --> ROW
classDef risk fill:#101018,stroke:#f08080,stroke-width:1.5px,color:#f08080
classDef attack fill:#101018,stroke:#f08080,color:#f08080
classDef def fill:#101018,stroke:#5eead4,color:#5eead4
classDef mod fill:#101018,stroke:#5eead4,color:#5eead4
classDef test fill:#101018,stroke:#82e0aa,color:#82e0aa
classDef row fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
style TREATMENT fill:#14141f,stroke:#9494a0,color:#e4e4e8
```
> **Note**: The four-part format is what turns a risk-awareness list into an engineering checklist. Without the attack procedure, you cannot test. Without the defense architecture, you do not know what to verify. Without the course module, you do not know where to build the fix if the test fails. Without the test, the row is not executable. Every one of the ten treatments in B9.2 follows this exact shape, and the lab's executor runs the test column for all ten.
---
## Diagram 4 — The Layered Defense Stack Covering All 10 (Course 1's 9-Layer Stack, Specialized)
**Type**: Stacked defense architecture
**Purpose**: The Course 1 Module 11 nine-layer defense stack, specialized to show which layers defend which ASI risks. This is the defense-in-depth architecture the checklist verifies. Read top-to-bottom as the layers an attack must cross. The right column shows which ASI risks each layer catches.
**Reading the diagram**: Nine teal layers (from Course 1's stack), each annotated with its Course 1 layer number and the ASI risks it defends. The deterministic layers (taint gate, capability, sandbox, identity) are highlighted — they are the layers that report PASS/FAIL. The probabilistic layers (detection, verification) report MEASURED.
```mermaid
flowchart TB
subgraph STACK["THE 9-LAYER DEFENSE STACK (Course 1 M11) — SPECIALIZED TO ASI RISKS"]
direction TB
L1["L1 · INPUT VALIDATION<br/>untrusted-content tagging<br/>Course 1: 6.3<br/>defends: ASI01, ASI02 (input boundary)"]:::prob
L2["L2 · INSTRUCTION HIERARCHY<br/>system prompt in privileged role<br/>Course 1: instruction hierarchy<br/>defends: ASI01, ASI02"]:::prob
L3["L3 · POLICY ENFORCEMENT — TAINT GATE<br/>mark, propagate, gate high-impact<br/>DETERMINISTIC CORE<br/>Course 1: policy enforcement<br/>defends: ASI01 (the load-bearing control)"]:::det
L4["L4 · OUTPUT GOVERNANCE — DETECTION<br/>secondary-model injection detector<br/>Course 1: CrabTrap (DD-19)<br/>defends: ASI01 (encoded class)"]:::prob
L5["L5 · CAPABILITY / SANDBOX<br/>tools scoped to minimum, sandboxed<br/>DETERMINISTIC FLOOR<br/>Course 1: IronCurtain (DD-20), 5.3, 5.4<br/>defends: ASI03, ASI07, ASI09"]:::det
L6["L6 · IDENTITY / ACCESS<br/>scoped non-human principals, principal binding<br/>DETERMINISTIC<br/>Course 1: 5.3, 6.1<br/>defends: ASI03, ASI10"]:::det
L7["L7 · RESOURCE CONTROL — CIRCUIT BREAKERS<br/>token/time/cost ceilings, loop detection<br/>DETERMINISTIC<br/>Course 1: 5.4, 7.2<br/>defends: ASI09"]:::det
L8["L8 · MEMORY GOVERNANCE<br/>harness-managed writes, retrieval-time tagging<br/>DETERMINISTIC GATE<br/>Course 1: 4.3<br/>defends: ASI04"]:::det
L9["L9 · VERIFICATION / OBSERVABILITY<br/>provenance tagging, reasoning-chain detection<br/>PROBABILISTIC<br/>Course 1: 9<br/>defends: ASI02 (egress), ASI06 (hallucination)"]:::prob
end
LEGEND["LEGEND:<br/>DETERMINISTIC (teal, bold) → PASS/FAIL<br/>PROBABILISTIC (teal) → MEASURED residual<br/>8 rows binary, 2 rows measured (ASI01, ASI06)"]:::legend
STACK --> LEGEND
classDef det fill:#101018,stroke:#5eead4,stroke-width:2px,color:#5eead4
classDef prob fill:#101018,stroke:#5eead4,color:#e4e4e8
classDef legend fill:#14141f,stroke:#9494a0,color:#9494a0
style STACK fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
```
> **Note**: The stack's specialization to ASI risks is the defense-in-depth argument made concrete. An attack must cross L1 (tag), L2 (isolation), L3 (taint gate — deterministic), L4 (detector), L5 (capability/sandbox — deterministic), L6 (identity — deterministic), L7 (resource — deterministic), L8 (memory gate — deterministic), and L9 (verification). The deterministic layers (L3, L5, L6, L7, L8) are why eight of the ten checklist rows report PASS/FAIL — the control is a gate with no bypass rate. The probabilistic layers (L1, L2, L4, L9) are why ASI01 and ASI06 report MEASURED — the model's compliance and the detector's miss rate are numbers, not booleans. The split is the B2.3 resolution applied across all ten risks.
---
## Diagram 5 — The Unified Checklist: Result Types (Deterministic vs Probabilistic)
**Type**: Classification / result-type matrix
**Purpose**: The B9.3 thesis made visual. Eight of the ten checklist rows report PASS/FAIL because their controls are deterministic (gates with no bypass rate). Two report MEASURED because their controls are probabilistic (nonzero bypass rate). A checklist that reported PASS/FAIL on all ten would be lying about ASI01 and ASI06. This diagram is the rule that prevents the false certainty.
**Reading the diagram**: Left = the deterministic rows (eight risks, PASS/FAIL). Right = the probabilistic rows (two risks, MEASURED). The warning node is the anti-pattern: collapsing a measured row into a binary.
```mermaid
flowchart TB
subgraph DET["DETERMINISTIC CONTROLS — PASS/FAIL (8 rows)"]
direction TB
D02["ASI02 Prompt Leakage<br/>canary substring match + egress filter"]:::det
D03["ASI03 Excessive Agency<br/>capability allowlist — present or absent"]:::det
D04["ASI04 Memory Poisoning<br/>harness-managed write gate — gated or not"]:::det
D05["ASI05 Tool/Skill Abuse<br/>argument validators — pass or fail"]:::det
D07["ASI07 Insecure Output Handling<br/>output sanitization — escaped or not"]:::det
D08["ASI08 Supply Chain Attacks<br/>provenance check — signature verifies or not"]:::det
D09["ASI09 Resource Exhaustion<br/>hard ceiling — count crosses or not"]:::det
D10["ASI10 Broken Access Control<br/>principal binding — tenant matches or not"]:::det
end
subgraph PROB["PROBABILISTIC CONTROLS — MEASURED (2 rows)"]
direction TB
P01["ASI01 Goal Hijacking<br/>taint gate is deterministic, BUT<br/>detector + model compliance are probabilistic<br/>→ measured residual rate"]:::prob
P06["ASI06 Cascading Hallucination<br/>verification catches unverified claims, BUT<br/>hallucination-detection has a miss rate<br/>→ measured block rate"]:::prob
end
RULE["THE RULE (B2.3 applied to all 10):<br/>determinism where the question is structural & enumerable<br/>(in the allowlist? principal match? signature valid?)<br/>measurement where the question is semantic & open<br/>(did injection succeed? did hallucination propagate?)"]:::rule
ANTIPATTERN["ANTI-PATTERN: collapsing a MEASURED row<br/>into PASS/FAIL claims certainty where the<br/>control is probabilistic. ASI01 'PASS' is a lie —<br/>the honest result is 'residual 2%, the encoded class.'"]:::bad
DET --> RULE
PROB --> RULE
RULE --> ANTIPATTERN
classDef det fill:#101018,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
classDef prob fill:#101018,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
classDef rule fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
classDef bad fill:#101018,stroke:#f08080,stroke-width:1.5px,color:#f08080
style DET fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style PROB fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
```
> **Note**: The 8/2 split is not arbitrary — it follows directly from which Course 1 layers defend which risks. The deterministic layers (L3 taint gate, L5 capability, L6 identity, L7 resource, L8 memory gate) defend eight risks with gates. The probabilistic layers (L1/L2 input, L4 detection, L9 verification) defend ASI01 and ASI06 with judgments that have a bypass rate. The checklist's Result-type column enforces the honesty: a row's result type is determined by the kind of control that defends it, not by the tester's preference. B2.3's resolution (determinism on the structural boundary, probability on the semantic boundary) is the principle; this diagram is its application across the full top 10.
---
## Diagram 6 — The Checklist as Assessment Scope (B9 → B12)
**Type**: Flow / engagement pipeline
**Purpose**: Shows how the ten-row checklist becomes the engagement contract for B12 (Harness Security Assessments as a Service). The checklist is the scope; the scored report is the deliverable. The two measured rows become the recurring value (the residual trend over engagements). This is the operational payoff of treating the Top 10 as a checklist rather than a reading list.
**Reading the diagram**: Top = the ten checklist rows (the scope). Middle = the engagement (run each test, capture evidence per B0, produce scored report). Bottom = the deliverable (8 PASS/FAIL + 2 MEASURED) and the recurring value (residual trend). The warning node is the scope-completeness rule: a skipped row is an untested row.
```mermaid
flowchart TB
subgraph SCOPE["THE CHECKLIST = ENGAGEMENT SCOPE (10 rows)"]
direction LR
S1["ASI01–05<br/>input, permission,<br/>state, tool boundaries"]:::scope
S2["ASI06–10<br/>state, tool,<br/>output, resource, access"]:::scope
end
ENG["B12 ENGAGEMENT<br/>per row: run the test (B9.2 attack procedure)<br/>capture evidence (B0: model version, success rate, scope ref)<br/>verify the control (B9.2 defense architecture)<br/>record result (PASS/FAIL or MEASURED)"]:::eng
SCOPE --> ENG
subgraph DELIVERABLE["THE SCORED REPORT (deliverable)"]
direction TB
D1["8 rows PASS/FAIL<br/>(deterministic controls)"]:::det
D2["2 rows MEASURED<br/>ASI01 residual rate<br/>ASI06 block-miss rate"]:::prob
end
ENG --> DELIVERABLE
RECURRING["RECURRING VALUE (B12 methodology)<br/>quarterly engagement tracks the residual trend —<br/>did ASI01 drop 4%→1% after L4 tuned?<br/>did ASI06 rise 3%→8% after a new tool?<br/>the trend is the signal; the point is the data"]:::recur
DELIVERABLE --> RECURRING
WARN["SCOPE-COMPLETENESS RULE:<br/>an assessment covers all 10 rows.<br/>A genuinely-absent surface reports N/A with<br/>justification — never silently skipped.<br/>A skipped row is an untested row."]:::warn
SCOPE -.-> WARN
classDef scope fill:#101018,stroke:#5eead4,color:#5eead4
classDef eng fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
classDef det fill:#101018,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
classDef prob fill:#101018,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
classDef recur fill:#14141f,stroke:#82e0aa,stroke-width:2px,color:#82e0aa
classDef warn fill:#101018,stroke:#f08080,stroke-width:1.5px,color:#f08080
style SCOPE fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style DELIVERABLE fill:#14141f,stroke:#9494a0,color:#e4e4e8
```
> **Note**: This is the diagram that connects B9 to B12 and to the course's assessment capstone. The checklist is not an academic exercise; it is the scope document a tester hands a client. The scored report is not a slide deck; it is the deliverable a CISO acts on. The two measured rows are where the recurring engagement earns its keep — a single assessment reports a point; a quarterly engagement reports a trend, and the trend is what tells the client whether their defenses are degrading. The scope-completeness rule (no silently skipped rows) is what makes the assessment defensible: a client who receives a report with nine rows tested and one silently absent has a gap they do not know about. The checklist's structure forces the absence to be explicit (N/A with justification), not hidden.