# Diagrams — Module B12: Harness Security Assessments as a Service

**Module**: B12 — Harness Security Assessments as a Service
**Diagram count**: 5
**Tool**: Mermaid (primary). Each diagram validated in [Mermaid Live Editor](https://mermaid.live).

---

## Diagram 1 — The Six-Phase Assessment Methodology

**Type**: Cyclic flowchain
**Purpose**: The backbone of the module. An agent security assessment is a *loop*, not a pipeline — six phases that feed back into each other across releases. Each phase ties to the prior module that supplies its content. The diagram makes the capstone synthesis visible: B0 (scope), B1 (recon), B9+B10 (discovery), B0 (validation), B9 output (report), B0.2 (retest). A retest feeds the next engagement's scoping.
**Reading the diagram**: Read clockwise as the engagement cycle. The dashed arrow from Retest back to Scoping is the recurring-engagement loop — the long-term value of the service. The teal callouts mark the module that supplies each phase's content.

```mermaid
flowchart LR
  P1["1. SCOPING<br/>surfaces · model versions<br/>provider authorizations · exclusions<br/>→ SOW + scope file"]:::phase
  P2["2. RECONNAISSANCE<br/>map the agent's surfaces<br/>B1 threat-model template<br/>B10 capability disclosure"]:::phase
  P3["3. DISCOVERY<br/>B9 OWASP checklist (10 rows)<br/>B10 attack chains (7 modes<br/>+ zero-click HITL bypass)"]:::phase
  P4["4. EXPLOITATION / VALIDATION<br/>B0 minimum-proof discipline<br/>reproduce · measure N/M<br/>evidence field set"]:::phase
  P5["5. REPORTING<br/>exec summary · findings<br/>control matrix · roadmap<br/>= B9 scored output packaged"]:::phase
  P6["6. RETESTING<br/>same harness · same sampling<br/>same pinned version<br/>residual risk before/after"]:::phase

  P1 --> P2 --> P3 --> P4 --> P5 --> P6
  P6 -. recurring engagement .-> P1

  M1["B0 legal control plane"]:::mod
  M2["B1 threat model"]:::mod
  M3["B9 checklist + B10 chains"]:::mod
  M4["B0 minimum-evidence"]:::mod
  M5["B9 executor output"]:::mod
  M6["B0.2 residual-risk"]:::mod

  P1 -. supplied by .-> M1
  P2 -. supplied by .-> M2
  P3 -. supplied by .-> M3
  P4 -. supplied by .-> M4
  P5 -. supplied by .-> M5
  P6 -. supplied by .-> M6

  classDef phase fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  classDef mod fill:#101018,stroke:#f0a868,color:#f0a868
```

> **Note**: Only two of the six phases (Discovery + Validation) are the testing that B9 and B10 supply. Scoping is where the legal plane gets set; Reporting is where the output becomes a deliverable; Retesting is where the residual gets measured. An engagement that runs only the testing phases is "run B9 and hand over the output" — half an engagement.

---

## Diagram 2 — Scoping to SOW Flow (with B0 clauses)

**Type**: Process flow with mandated clauses
**Purpose**: Scoping is where B0's legal control plane gets written into the engagement contract. The four-point surface enumeration (B1 template, model versions, provider authorizations, exclusions) flows into the SOW, which must carry B0's seven clauses — three of them AI-specific (provider authorization, dual-use/disclosure, DMCA waiver). An SOW missing any clause fails at the moment a serious finding appears.
**Reading the diagram**: Top = the scoping enumeration. Middle = the SOW with its seven clauses. The red callouts mark the three AI-specific clauses a traditional pentest SOW does not carry. The provider-authorization check is a gating step — surfaces that fail B0's three conditions are out of scope until the gap closes.

```mermaid
flowchart TB
  subgraph ENUM["SCOPING — four-point surface enumeration"]
    direction TB
    E1["SURFACES (B1 template)<br/>inputs · tools · memory · provider<br/>identity · sandbox · inter-agent edges"]
    E2["MODEL VERSIONS (pinned)<br/>gpt-model-v3-2026-05-01<br/>claude-opus-4-1-20260605"]
    E3["PROVIDER AUTHORIZATIONS<br/>per technique: ToS / waiver / self-hosted"]
    E4["EXCLUSIONS<br/>prod PII · shared infra<br/>forbidden techniques"]
    E1 --- E2 --- E3 --- E4
  end

  GATE{"provider_authorization<br/>check (B0)"}
  BLOCK["OUT OF SCOPE<br/>until gap closes"]:::danger
  ALLOW["IN SCOPE"]:::good

  ENUM --> GATE
  GATE -->|"all 3 conditions fail"| BLOCK
  GATE -->|"≥1 condition holds"| ALLOW

  subgraph SOW["SOW — seven clauses (B0 + B12)"]
    direction TB
    C1["1. Systems in scope (pinned versions)"]
    C2["2. PROVIDER AUTHORIZATION / ToS compliance"]:::ai
    C3["3. Techniques permitted / prohibited<br/>(weight-read = minimum-proof only)"]
    C4["4. DUAL-USE & DISCLOSURE<br/>180d model-level · 90d harness-level<br/>recipe suppressed by default"]:::ai
    C5["5. DMCA § 1201 WAIVER<br/>(if bypassing a model access control)"]:::ai
    C6["6. Data handling<br/>(Public / Provider-Only /<br/>Restricted / Destroy-on-Report)"]
    C7["7. Residual-risk measurement protocol<br/>(never binary 'fixed')"]
  end

  ALLOW --> SOW

  classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  classDef good fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
  classDef ai fill:#101018,stroke:#f08080,color:#f08080
  style ENUM fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style SOW fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style GATE fill:#101018,stroke:#f0a868,color:#f0a868
  style C1 fill:#101018,stroke:#5eead4,color:#e4e4e8
  style C3 fill:#101018,stroke:#5eead4,color:#e4e4e8
  style C6 fill:#101018,stroke:#5eead4,color:#e4e4e8
  style C7 fill:#101018,stroke:#5eead4,color:#e4e4e8
```

> **Note**: The three red clauses (provider authorization, dual-use/disclosure, DMCA waiver) are the AI-specific additions to a traditional pentest SOW. A client's counsel signs this before testing begins; the clauses resolve B0's risks contractually rather than in the moment. The provider-authorization check at the top is a gating step — it is the engineering realization of "the deployer cannot authorize what the provider forbids."

---

## Diagram 3 — The Engagement Report Structure

**Type**: Section map / data flow
**Purpose**: The report is the deliverable, and it is the same scored artifact B9's checklist executor produces — formatted into five sections a CISO can read and a regulator can audit. The diagram shows how the B9 output and B10 chains flow into the findings section, how the B9 risk-to-module mapping becomes the control matrix, and how the report generator (lab) enforces the field set.
**Reading the diagram**: Left = the inputs (B9 executor JSON, B10 chain findings, B1 surface map, B0 scope). Middle = the five report sections. Right = the validation layer that refuses to ship an unclassified or incomplete finding.

```mermaid
flowchart LR
  subgraph IN["INPUTS"]
    direction TB
    I1["B9 CHECKLIST EXECUTOR<br/>8 PASS/FAIL + 2 MEASURED<br/>(JSON)"]
    I2["B10 CHAIN FINDINGS<br/>7 modes + zero-click HITL<br/>bypass chain"]
    I3["B1 SURFACE MAP<br/>(reconnaissance output)"]
    I4["B0 SCOPE FILE + SOW<br/>(the authorization plane)"]
  end

  subgraph REPORT["ENGAGEMENT REPORT — 5 sections"]
    direction TB
    S1["1. EXECUTIVE SUMMARY<br/>residual posture · findings count<br/>ship recommendation (never 'secure')"]:::sec
    S2["2. FINDINGS<br/>taxonomy ref · attack procedure<br/>evidence · residual risk · remediation"]:::sec
    S3["3. CONTROL MATRIX<br/>controls × surfaces<br/>Present / Absent / Partial / Mismeasured"]:::sec
    S4["4. REMEDIATION ROADMAP<br/>prioritized · routed to B2-B8<br/>owner + effort estimate"]:::sec
    S5["5. APPENDIX<br/>methodology · scope · evidence index"]:::sec
  end

  subgraph VAL["VALIDATION (report generator)"]
    direction TB
    V1["finding with no taxonomy ref<br/>→ REJECTED"]:::danger
    V2["MEASURED without success rate<br/>→ REJECTED"]:::danger
    V3["Critical without remediation<br/>→ REJECTED"]:::danger
  end

  I1 --> S2
  I2 --> S2
  I3 --> S3
  I4 --> S5
  S2 -. enforced by .-> VAL
  I1 -. risk→module map .-> S3
  S2 -. routes to .-> S4

  classDef sec fill:#14141f,stroke:#5eead4,color:#e4e4e8
  classDef danger fill:#101018,stroke:#f08080,color:#f08080
  style IN fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
  style REPORT fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style VAL fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
```

> **Note**: B9's checklist executor output *is* the findings section's backbone. B12 does not re-test; it packages. The validation layer is what prevents the "10/10 PASS" lie — the report generator refuses to emit a finding that lacks a taxonomy reference, a MEASURED finding without a success rate, or a Critical finding without a remediation route. The strictness is the honesty, enforced at the output layer.

---

## Diagram 4 — Retesting: Residual-Risk Before/After Comparison

**Type**: Comparison / measurement
**Purpose**: Retesting measures residual risk, not binary "fixed." The same harness, the same sampling parameters, the same pinned model version, re-run after remediation. The verdict is Resolved / Improved / Unchanged / Regressed — never "fixed." The diagram shows the before/after comparison and the four verdicts, plus the regression risk (a B10 chain may reroute through a different gap after a patch).
**Reading the diagram**: Left = the original assessment residual. Middle = the retest under identical conditions. Right = the four possible verdicts. The red path (Regressed) is why the retest re-runs discovery, not just the original finding — a patch can open a new gap.

```mermaid
flowchart TB
  ORIG["ORIGINAL ASSESSMENT<br/>Finding F-04: injection success<br/>60% over 100 attempts<br/>(pinned model · sampling params)"]
  RETEST["RETEST — identical conditions<br/>same B9/B10 test cases<br/>same sampling params<br/>same pinned model version"]
  COMPARE{"compare<br/>before / after"}
  ORIG --> RETEST --> COMPARE

  V1["RESOLVED<br/>residual → 0%<br/>(deterministic control added)"]:::good
  V2["IMPROVED<br/>60% → 4%<br/>(mitigation reduced,<br/>did not eliminate)"]:::warn
  V3["UNCHANGED<br/>60% → 60%<br/>(remediation ineffective)"]:::danger
  V4["REGRESSED<br/>a PASS row → FAIL<br/>or chain rerouted<br/>through a new gap"]:::danger

  COMPARE --> V1
  COMPARE --> V2
  COMPARE --> V3
  COMPARE --> V4

  NOTE["The verdict is NEVER 'fixed.'<br/>The retest report is a delta document:<br/>original residual · post-remediation residual · verdict.<br/>A regulator reads it to verify the client fixed<br/>what they said they fixed."]:::note

  COMPARE --> NOTE

  classDef good fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
  classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
  classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  classDef note fill:#101018,stroke:#5eead4,color:#5eead4
  style ORIG fill:#14141f,stroke:#5eead4,color:#e4e4e8
  style RETEST fill:#14141f,stroke:#5eead4,color:#e4e4e8
  style COMPARE fill:#101018,stroke:#f0a868,color:#f0a868
```

> **Note**: "Is it fixed?" is the wrong question; the answer is never yes. The right question is "did the residual move, and by how much, under identical conditions?" The Regressed verdict (bottom) is why the retest re-runs the full B9 checklist and re-attempts the B10 chains — patching one step of a chain can reroute it through a different gap. A retest that checks only the original finding misses regressions.

---

## Diagram 5 — The Service Packaging Stack

**Type**: Layered stack
**Purpose**: The difference between a one-off assessment (a project) and a repeatable assessment practice (a service) is packaging. Four layers — methodology, tooling, templates, evidence — make the engagement run the same way across clients and releases. Comparability across releases is the long-term value a CISO buys.
**Reading the diagram**: Read bottom-to-top as the layers that make the practice repeatable. The evidence layer (B0 + B11) makes it defensible; the template layer makes it consistent; the tooling layer makes it scalable; the methodology layer is the playbook. Drift in any layer breaks the comparability that makes the residual-trend-over-releases valuable.

```mermaid
flowchart BT
  L1["METHODOLOGY LAYER<br/>the six-phase playbook<br/>phase → module mapping<br/>(PTES / NIST SP 800-115 adapted)"]:::layer
  L2["TOOLING LAYER<br/>B9 checklist executor · B10 chain harness<br/>report generator (B12 lab)<br/>scope-file validator (B0 lab)"]:::layer
  L3["TEMPLATE LAYER<br/>SOW (7 clauses) · scope file<br/>report (5 sections) · retest delta<br/>CVD timeline (B0 lab)"]:::layer
  L4["EVIDENCE LAYER<br/>B0 evidence store (4 retention classes)<br/>B11 audit trail · B11 AI BOM<br/>the defensible foundation"]:::layer

  L4 --> L3 --> L2 --> L1

  OUT["COMPARABLE ARTIFACTS ACROSS RELEASES<br/>injection success rate over 6 releases<br/>the long-term value the CISO buys"]:::out
  L1 --> OUT

  classDef layer fill:#14141f,stroke:#5eead4,color:#e4e4e8
  style L1 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style L2 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style L3 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style L4 fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
  classDef out fill:#101018,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
```

> **Note**: The evidence layer (B0's retention classes + B11's audit trail and AI BOM) is the foundation — it is what makes every finding trace to scoped, authorized, minimum-proof evidence that survives a regulator's review. Without it, the layers above produce artifacts that cannot be audited. The methodology is a cycle, not a pipeline: a static playbook document is the cycle frozen at phase 1.