li_maestro_evaluate — Interactive Q&A Threat Modeling

This skill implements the MAESTRO threat modeling process as an interactive conversation with two analysis modes:

1. MVTM Checklist Mode — A structured 10-item Minimum Viable Threat Model checklist, extended with Chinese regulatory requirements (《网络安全法》《数据安全法》《个人信息保护法》《人工智能安全治理框架》2.0, GB/T 45654-2025). Best for: quick assessments, low-risk systems, initial scoping. Delivers: pass/fail evaluation against the MVTM standard with compliance mapping.

2. Full Assessment Mode — The complete MAESTRO 10-phase threat modeling process with interactive Q&A through all phases. Delivers a comprehensive risk assessment with multi-format outputs.

Both modes produce .md (Markdown), .docx (Word), .xlsx (Excel) outputs with AI risk classification mapping to China's 《人工智能安全治理框架》2.0 版 (three categories, nine subcategories).

Targets two types of systems:

1. Agentic AI systems — LLM-based agents, multi-agent systems, MCP/A2A ecosystems
2. OpenCode Skills — "code + prompt" hybrid artifacts distributed via clawhub.ai or local install. Skills are unique threat modeling targets because they contain both machine-executable code AND model-executable prompts. Traditional code scanning misses prompt injection; prompt review misses code-level data exfiltration. MAESTRO's layered architecture decomposes skill risk across all 7 layers plus Layer S0 (Skill Content meta-layer), which explicitly checks for combined code+prompt attacks, runtime remote content loading, and multi-skill collusion.

Phases 6-10 can be auto-completed by AI. When Phase 5 is complete, the agent will ask whether you want to auto-complete the remaining phases. If you choose auto-complete, the AI generates all outputs without further interactive Q&A — you review the results at the end.

Reference: OWASP MAESTRO Threat Modeling Playbook v1.0 Source: https://github.com/agentic-threat-modeling/MAESTRO

Conversation Architecture

                ┌──────────────────────────────────┐
                │  PRE-ENGAGEMENT                  │  Step 0: Mode selection
                │  (5-10 min)                      │  Steps 1-4: decision tree + consent + setup
                └─────────┬────────────────────────┘
                          │
          ┌───────────────┴───────────────┐
          ▼                               ▼
┌─────────────────────┐       ┌──────────────────────────┐
│ MVTM CHECKLIST MODE │       │  FULL ASSESSMENT MODE    │
│ 10-item checklist   │       │  10-phase interactive Q&A│
└─────────┬───────────┘       └──────────┬───────────────┘
          │                              │
          ▼                              ▼
┌─────────────────────┐       ┌──────────────────────┐
│ Check 1: Business   │       │ PHASE 1: Business    │
│ Context (5 items)   │       │ Context              │
├─────────────────────┤       ├──────────────────────┤
│ Check 2:            │       │ PHASE 2:             │
│ Architecture (7 L)  │       │ Architecture         │
├─────────────────────┤       ├──────────────────────┤
│ Check 3-5: Actors,  │       │ PHASES 3-5:          │
│ Boundaries, Assets  │       │ Actors/Boundaries/   │
│                     │       │ Assets (any order)   │
├─────────────────────┤       ├──────────────────────┤
│ Check 6: Per-Layer  │       │ PHASE 6: Threat      │
│ Threats (L1-L6)     │──► AI │ Identification       │──► AI
├─────────────────────┤Derives├──────────────────────┤Derives
│ Check 7: Cross-Layer│       │ PHASE 7: Mitigation  │
│ Patterns            │       │ Planning             │
├─────────────────────┤       ├──────────────────────┤
│ Check 8: Mitigations│       │ PHASE 8: Code        │
│ (≥5)                │       │ Validation           │
├─────────────────────┤       ├──────────────────────┤
│ Check 9: Residual   │       │ PHASE 9: Residual    │
│ Risk                │       │ Risk                 │
├─────────────────────┤       ├──────────────────────┤
│ Check 10: Output    │       │ PHASE 10: Output     │
│ .md/.docx/.xlsx     │       │ .md/.docx/.xlsx      │
└─────────────────────┘       └──────────────────────┘

Pre-Engagement Protocol

Step 0 — Analysis Mode Selection

Before the decision tree, ask the user which analysis mode to use:

[Pre-Engagement — Mode Selection]

This session supports two analysis modes:

A) **MVTM Checklist (Minimum Viable Threat Model)**
   Structured 10-item checklist extended with Chinese regulatory requirements
   (《网络安全法》《数据安全法》《个人信息保护法》《人工智能安全治理框架》2.0).
   Best for: quick assessments, low-risk systems, initial scoping.
   Delivers: pass/fail evaluation with compliance mapping.

B) **Full Risk Assessment**
   Complete MAESTRO 10-phase threat modeling process with interactive Q&A.
   Best for: critical systems, high-risk deployments, compliance evidence.
   Delivers: comprehensive risk assessment with multi-format outputs.

Which mode would you like? (A / B)

After selection, the user enters the project name in Step 2. At that point, record this selection by setting analysis_mode in the state.json created in Step 2:

• If A → "analysis_mode": "mvtm_checklist"
• If B → "analysis_mode": "full_assessment"

Then proceed to Step 1.

Step 1 — Dual Decision Tree (MAESTRO + China-Specific)

Ask these 10 questions in two stages:

Stage A — MAESTRO 5 Questions (risk-driven, one at a time):

Q1: Is the system business-critical or safety-related?
    (Would downtime or compromise cause major revenue loss or safety risk?)
Q2: Does it process Confidential or Restricted data?
    (PII, financial records, health data, trade secrets, credentials?)
Q3: Is it externally facing?
    (Accessed by public users or partner APIs over the internet?)
Q4: Does it operate with full autonomy?
    (No human-in-the-loop for decisions or actions?)
Q5: Is this a multi-agent system?
    (Multiple AI agents communicating and coordinating?)

Decision Tree — MAESTRO:

Stage B — China-Specific 5 Criteria (regulatory-driven, ask after Stage A):

Q6: Is this system part of Critical Information Infrastructure (CII)?
    (Per 《网络安全法》Art.31 and 《关键信息基础设施安全保护条例》)
Q7: Does the system process Important Data or Core Data?
    (Per 《数据安全法》data classification & grading system)
Q8: Does this system provide generative AI services to the public?
    (Per 《生成式人工智能服务管理暂行办法》— requires security assessment + algorithm filing)
Q9: Does the system involve 3+ autonomous agents?
    (Multi-agent threshold for cross-layer and confused-deputy risks)
Q10: Does this system involve cross-border data transfer or overseas deployment?
    (Per 《数据安全法》data export security assessment requirements)

China-Specific Override Logic (applies regardless of analysis_mode):

Scope Limitation Warning (for MVTM mode):

If in MVTM mode AND any Stage A MAESTRO question triggers Full/Standard OR any Stage B China criterion is YES, display:

⚠ Scope Limitation Warning:
Your system has characteristics that the MAESTRO MVTM standard recommends
against treating as "minimum viable." Specifically:
  - [List triggered criteria]
  - [List triggered China criteria]

Per MAESTRO + China regulatory guidance, this system requires at least
[Standard/Full] depth analysis. Performing only the MVTM checklist is a
scope limitation.

Do you want to:
  A) Continue with MVTM Checklist (scope limitation will be recorded in output)
  B) Switch to Full Assessment (recommended)
  C) Continue with MVTM + add explicit scope warning in report

If user chooses A or C → record in state.json "mvtm_scope_warning": true and add warning banner in all output files.

Step 2 — Project Setup

Please provide a short project name (e.g., "devops-agent", "trading-bot"):
→ [user provides name]

Each evaluation run creates an isolated timestamped output directory inside threat-models/. Use a -mvtm- infix for MVTM mode to distinguish from full assessments. Create the directory with explicit filesystem commands:

# Powershell — creates the per-run output directory
if ($analysisMode -eq "mvtm_checklist") {
  $runDir = "threat-models/$project-mvtm-$(Get-Date -Format 'yyyyMMdd-HHmm')"
} else {
  $runDir = "threat-models/$project-$(Get-Date -Format 'yyyyMMdd-HHmm')"
}
New-Item -ItemType Directory -Path $runDir -Force
# Initialize state.json with full schema (see Step 4 for field descriptions)
$stateJson = @"
{
  "project": "$project",
  "analysis_mode": "$analysisMode",
  "analysis_depth": "$depth",
  "mvtm_scope_warning": $scopeWarning,
  "created": "$(Get-Date -Format 'yyyy-MM-ddTHH:mm:ssZ')",
  "updated": "$(Get-Date -Format 'yyyy-MM-ddTHH:mm:ssZ')",
  "system_type": "unknown",
  "uses_mcp": false,
  "target_type": "agentic_ai_system",
  "phases": {
    "1": {"status":"pending","output_file":"01-business-context.md"},
    "2": {"status":"pending","output_file":"02-architecture.md"},
    "3": {"status":"pending","output_file":"03-threat-actors.md"},
    "4": {"status":"pending","output_file":"04-trust-boundaries.md"},
    "5": {"status":"pending","output_file":"05-asset-flows.md"},
    "6": {"status":"pending","output_file":"06-threat-register.md"},
    "7": {"status":"pending","output_file":"07-mitigations.md"},
    "8": {"status":"pending","output_file":"08-code-validation.md"},
    "9": {"status":"pending","output_file":"09-residual-risk.md"},
    "10": {"status":"pending","output_file":"10-output-summary.md"},
    "10j": {"status":"pending","output_file":"threat-model.json"}
  },
  "mvtm_checklist": null,
  "threat_count": 0,
  "mitigation_count": 0,
  "files_read": [],
  "version_metadata": {
    "playbook_version": "1.2.0",
    "analyst": "AI Agent (Claude Code)",
    "schema_version": "1.2.0",`n    "template_version": "1.0.0"
  }
}
"@
$stateJson | Set-Content -Path "$runDir/state.json"

# Bash equivalent — writes initial state.json with variable expansion via printf
if [ "$analysis_mode" = "mvtm_checklist" ]; then
  runDir="threat-models/${project}-mvtm-$(date +%Y%m%d-%H%M)"
else
  runDir="threat-models/${project}-$(date +%Y%m%d-%H%M)"
fi
mkdir -p "$runDir"
created="$(date -Iseconds)"
printf '{
  "project": "%s",
  "analysis_mode": "%s",
  "mvtm_scope_warning": false,
  "created": "%s",
  "updated": "%s",
  "system_type": "unknown",
  "uses_mcp": false,
  "target_type": "agentic_ai_system",
  "phases": {
    "1":{"status":"pending","output_file":"01-business-context.md"},
    "2":{"status":"pending","output_file":"02-architecture.md"},
    "3":{"status":"pending","output_file":"03-threat-actors.md"},
    "4":{"status":"pending","output_file":"04-trust-boundaries.md"},
    "5":{"status":"pending","output_file":"05-asset-flows.md"},
    "6":{"status":"pending","output_file":"06-threat-register.md"},
    "7":{"status":"pending","output_file":"07-mitigations.md"},
    "8":{"status":"pending","output_file":"08-code-validation.md"},
    "9":{"status":"pending","output_file":"09-residual-risk.md"},
    "10":{"status":"pending","output_file":"10-output-summary.md"},
    "10j":{"status":"pending","output_file":"threat-model.json"}
  },
  "mvtm_checklist": null,
  "threat_count": 0,
  "mitigation_count": 0,
  "files_read": [],
  "version_metadata": {
    "playbook_version": "1.2.0",
    "analyst": "AI Agent (Claude Code)",
    "schema_version": "1.2.0",`n    "template_version": "1.0.0"
  }
}' "$project" "$analysis_mode" "$created" "$created" > "$runDir/state.json"

This produces run-isolated directory trees:

threat-models/
│   Full Assessment runs:
├── <project>-20260701-1430/      ← Full assessment Run 1
│   ├── state.json
│   ├── 01-business-context.md
│   ├── 02-architecture.md
│   ├── 03-threat-actors.md
│   ├── 04-trust-boundaries.md
│   ├── 05-asset-flows.md
│   ├── 06-threat-register.md
│   ├── 07-mitigations.md
│   ├── 08-code-validation.md
│   ├── 09-residual-risk.md
│   ├── 10-output-summary.md
│   ├── threat-model.json
│   ├── 11-ai-risk-classification.md
│   ├── 11-ai-risk-classification.docx
│   ├── 11-ai-risk-classification.xlsx
│   └── 12-skill-risk-assessment.md      ← only when target_type=opencode_skill
│   MVTM Checklist runs:
├── <project>-mvtm-20260701-1500/  ← MVTM Run 1
│   ├── state.json
│   ├── 01-mvtm-checklist.md             ← Core MVTM output
│   ├── threat-model.json
│   ├── 11-ai-risk-classification.md
│   ├── 11-ai-risk-classification.docx
│   ├── 11-ai-risk-classification.xlsx
│   └── 12-skill-risk-assessment.md      ← only when target_type=opencode_skill
├── <project>-20260702-0900/      ← Full assessment Run 2
│   ├── state.json
│   └── ...
└── ...

Why timestamps? Threat models are living documents. Each iteration (re-assessment, periodic review, architecture change) gets its own directory, preserving the audit trail. Use the resumption protocol (line ~1618) to re-enter any specific run by reading its state.json.

Step 3 — Data Handling Consent

Present this exact notice:

Data Handling Notice: This threat modeling session uses the AI provider API. All content you provide — system descriptions, architecture details, and any source code reviewed during Phase 8 — will be transmitted for processing. Do you confirm this is acceptable under your organization's data handling policies?

If user declines → halt engagement. Recommend using the MAESTRO playbook as standalone documentation.

Step 4 — Verify state.json

{
  "project": "<project-name>",
  "analysis_mode": "mvtm_checklist|full_assessment",
  "analysis_depth": "full|standard|lightweight",
  "mvtm_scope_warning": false,
  "created": "<ISO-8601>",
  "updated": "<ISO-8601>",
  "system_type": "unknown",
  "uses_mcp": false,
  "target_type": "agentic_ai_system",
  "phases": {
    "1": {"status":"pending","output_file":"01-business-context.md"},
    "2": {"status":"pending","output_file":"02-architecture.md"},
    "3": {"status":"pending","output_file":"03-threat-actors.md"},
    "4": {"status":"pending","output_file":"04-trust-boundaries.md"},
    "5": {"status":"pending","output_file":"05-asset-flows.md"},
    "6": {"status":"pending","output_file":"06-threat-register.md"},
    "7": {"status":"pending","output_file":"07-mitigations.md"},
    "8": {"status":"pending","output_file":"08-code-validation.md"},
    "9": {"status":"pending","output_file":"09-residual-risk.md"},
    "10": {"status":"pending","output_file":"10-output-summary.md"},
    "10j": {"status":"pending","output_file":"threat-model.json"}
  },
  "mvtm_checklist": {
    "1_business_context":  {"status":"pending","passed":0,"total":5,"items":{}},
    "2_architecture":     {"status":"pending","passed":0,"total":7,"items":{}},
    "3_threat_actors":    {"status":"pending","passed":0,"total":5,"items":{}},
    "4_trust_boundaries": {"status":"pending","passed":0,"total":4,"items":{}},
    "5_asset_flows":      {"status":"pending","passed":0,"total":6,"items":{}},
    "6_layer_threats":   {"status":"pending","passed":0,"total":5,"items":{}},
    "7_cross_layer":      {"status":"pending","passed":0,"total":4,"items":{}},
    "8_mitigations":      {"status":"pending","passed":0,"total":6,"items":{}},
    "9_residual_risk":    {"status":"pending","passed":0,"total":8,"items":{}},
    "10_output":          {"status":"pending","passed":0,"total":4,"items":{}}
  },
  "threat_count": 0,
  "mitigation_count": 0,
  "files_read": [],
  "version_metadata": {
    "playbook_version": "1.0.0",
    "analyst": "AI Agent (OpenCode)",
    "schema_version": "1.2.0",`n    "template_version": "1.0.0"
  }
}

When analysis_mode == "mvtm_checklist": The phases object is not used for progress tracking. Instead, use mvtm_checklist to track per-sub-item status. Set each check item's status to pending, in_progress, complete, or skipped. Sub-items use passed, failed, or pending.

When analysis_mode == "full_assessment": The phases object tracks progress as before. The mvtm_checklist object is unused.

Important: The state.json was created in Step 2. If it does not exist (e.g., manual execution), write it now using the schema above.

Per-sub-item status example (for resumption):

"mvtm_checklist": {
  "1_business_context": {
    "status": "in_progress",
    "passed": 3,
    "total": 5,
    "items": {
      "1.1": {"status": "passed", "value": "Yes", "note": ""},
      "1.2": {"status": "passed", "value": "Yes", "note": ""},
      "1.3": {"status": "failed", "value": "No", "note": "等保定级未完成"},
      "1.4": {"status": "passed", "value": "Yes", "note": ""},
      "1.5": {"status": "pending"}
    }
  }
}

Conversation Rules

Follow these rules strictly throughout the engagement:

1. Phase/Check indicator: Start every response with the mode marker:
   • MVTM mode: [MVTM Check N/10]
   • Full mode: [Phase N/10] or [Pre-Engagement]
2. One question at a time in Full mode. In MVTM mode, batch related sub-items from the same check (e.g., present all 5 sub-items of Check 1 together for efficiency).
3. Closed questions only. Use "What LLM provider?" not "Tell me about your system."
4. Confirm after each check/phase: "Check X complete. Passed Y/Z. Ready for Check X+1?" or "Phase X complete. Summary: [key findings]. Ready for Phase X+1?"
5. Handle "I don't know": If user is unsure, offer defaults or simplified options.
6. Lightweight path (Full mode only): If depth=lightweight, tell the user: "Since your system is low-risk, we'll use the Lightweight path: brief Phases 1-2, then jump to Phase 6."
7. State persistence: Update state.json after every check/phase completion.
8. Disclaimer: Include AI-generated disclaimer in every output file.
9. ID validation: After Check 6-7 (MVTM) or Phases 6-7 (Full), cross-reference all IDs against source files.
10. Progressive summarization: Before each transition, show accumulated summary with pass/fail status for MVTM mode.

Mode Selection Gate

After completing the Pre-Engagement Protocol, read analysis_mode from state.json:

IF analysis_mode == "mvtm_checklist":
    → Follow the "MVTM Checklist Workflow" section below
    → Output directory: threat-models/<project>-mvtm-<timestamp>/
    → Primary output: 01-mvtm-checklist.md

IF analysis_mode == "full_assessment":
    → Follow the "Phase 1/10 — Business Context Analysis" section
    → Output directory: threat-models/<project>-<timestamp>/
    → Primary output: 10-output-summary.md

MVTM Checklist Workflow (10 Items)

Reference: MAESTRO Official MVTM Standard + Chinese regulatory extension (《网络安全法》《数据安全法》《个人信息保护法》《人工智能安全治理框架》2.0, GB/T 45654-2025, GB/T 45953-2025)

This workflow walks through 10 structured checklist items. Each item contains multiple sub-items. The agent MUST:

1. Display the sub-items as a batch (not one at a time)
2. Ask the user to confirm Yes/No per sub-item
3. Record each result in state.json.mvtm_checklist.<item>.items.<sub-id>.status
4. After completing each check item, update the pass count and status

Phase marker pattern: [MVTM Check N/10 — Name]

Scoring thresholds for each check item:

MVTM Check 1/10 — Business Context Documentation

Requirement: System function, users, criticality, data processing activities, and data classification documented.

Phase marker: [MVTM Check 1/10 — Business Context]

Conversation:

[MVTM Check 1/10 — Business Context]

I need to verify 5 items about your system's business context.
Please answer each:

  1.1 Is the system's business function and purpose clearly described?
      → Yes / No  (If No: what is missing?)
      
  1.2 Are system users/user groups identified?
      → Yes / No  (If No: who are the users?)
      
  1.3 Has the system's criticality/importance level been assigned?
      → Yes / No  (If No: what criticality would you assign?)
      [Prompt: Per 等保2.0 — Levels 1-4]
      
  1.4 Are data processing activities (collection, storage, use, 
      transmission, deletion) described?
      → Yes / No  (If No: what data activities exist?)
      [Prompt: 《数据安全法》Art.27 requires full lifecycle management]
      
  1.5 Does the system process Important Data or Core Data?
      → Yes / No
      [Prompt: If Yes, must include in Important Data catalog]

After user responds, update state.json and show summary:

Check 1 results: ✅ Passed 4/5 | ❌ 1.3 (No criticality assigned)
Status: ⚠ Partial
China compliance: 1.4 → 《数据安全法》Art.27, 1.5 → 《数据安全法》data classification

State update example:

"mvtm_checklist": {
  "1_business_context": {
    "status": "complete",
    "passed": 4,
    "total": 5,
    "items": {
      "1.1": {"status":"passed","value":"Yes","note":""},
      "1.2": {"status":"passed","value":"Yes","note":"Internal users"},
      "1.3": {"status":"failed","value":"No","note":"等保定级未完成"},
      "1.4": {"status":"passed","value":"Yes","note":""},
      "1.5": {"status":"passed","value":"Yes","note":"涉及重要数据"}
    }
  }
}

Confirmation:

Check 1 complete: ✅ 4/5 passed (⚡ Partial). Key gap: criticality not assigned (等保2.0 compliance risk). Ready for Check 2 (Architecture)?

MVTM Check 2/10 — Architecture Mapped to MAESTRO Layers

Requirement: System architecture mapped to all 7 MAESTRO layers.

Phase marker: [MVTM Check 2/10 — Architecture]

Conversation:

[MVTM Check 2/10 — Architecture]

I need to verify that your system's architecture maps to each
MAESTRO layer. Let me ask about each layer:

  L1 (Foundation Model):
  2.1 Is the model provider, model version, and prompt template identified?
      → Yes / No (If No: what LLM does the system use?)
      [China: Model provider data policy must comply with 《数据安全法》]

  L2 (Data Operations):
  2.2 Are data stores, vector databases, and RAG data sources identified?
      → Yes / No (If No: what data stores exist?)
      [China: Training data must be authentic, accurate, objective, diverse]

  L3 (Agent Frameworks):
  2.3 Are agent count, MCP servers, and message queues identified?
      → Yes / No (If No: what agent framework is used?)
      [China: Agent security is a key technology direction in 《人工智能安全标准体系》]

  L4 (Deployment Infrastructure):
  2.4 Are containers, image registries, key managers, and DNS identified?
      → Yes / No (If No: what infrastructure?)
      [China: 等保2.0 baseline config management and access control]

  L5 (Evaluation & Observability):
  2.5 Are logging, monitoring, and approval systems identified?
      → Yes / No (If No: how is the system monitored?)
      [China: 《网络安全法》Art.21 requires log retention ≥6 months]

  L6 (Security & Compliance):
  2.6 Are IAM, RBAC, key management, and code signing identified?
      → Yes / No (If No: what security controls exist?)
      [China: 网络安全等级保护 registration required]

  L7 (Agent Ecosystem):
  2.7 Are external systems (Git, cloud APIs, container registries) identified?
      → Yes / No (If No: what external integrations?)
      [China: Supply chain security per GB/T 45953-2025]

Confirmation:

Check 2 complete: ✅ 6/7 passed (⚡ Partial). Layers covered: L1-L7. Key gap: L5 observability not fully mapped — affects log retention compliance (《网络安全法》Art.21). Ready for Check 3?

MVTM Check 3/10 — Three Threat Actors

Requirement: At least three threat actor types identified with motivations and attack paths.

Phase marker: [MVTM Check 3/10 — Threat Actors]

Conversation:

[MVTM Check 3/10 — Threat Actors]

Let me check which threat actor types are covered for your system:

  3.1 External Attackers — e.g., prompt injection, data theft, DoS
      → Identified / Not relevant
      [China supplement: guard against organized cybercrime data poisoning]

  3.2 Malicious Insiders — e.g., backdoor insertion, data exfiltration
      → Identified / Not relevant
      [China: 《网络安全法》requires 主体责任 (primary responsibility)]

  3.3 Compromised Dependencies — e.g., third-party library → pipeline
      → Identified / Not relevant
      [China: Supply chain security is a 《人工智能安全标准体系》management direction]

  3.4 Compromised Agents — e.g., single agent compromised → message poisoning
      → Identified / Not relevant
      [China: Agent security is a new compliance focus]

  3.5 Nation-State APT — e.g., long-term CII penetration
      → Identified / Not relevant
      [China: CII operators must conduct annual security assessment]

MVTM minimum: At least 3 of 5 must be "Identified." Items 3.1, 3.2, 3.3 are the core three. Items 3.4 and 3.5 are optional but recommended.

Confirmation:

Check 3 complete: ✅ 3/5 identified. Core three: External, Insider, Dependency. Ready for Check 4?

MVTM Check 4/10 — Trust Boundaries

Requirement: Trust zones, boundary crossing points, risk levels, and controls identified.

Phase marker: [MVTM Check 4/10 — Trust Boundaries]

Conversation:

[MVTM Check 4/10 — Trust Boundaries]

Let me verify trust boundary coverage for your system:

  4.1 External → Agent Processing Layer boundary
      (PR submission, API calls)
      → Identified / Not identified
      Risk level: [Critical / High / Medium / Low]
      Controls: input validation, authentication
      [China: 多AI模型聚合平台 requires enhanced access control]

  4.2 Agent → Infrastructure Control Plane boundary
      (Review pass → triggers deployment)
      → Identified / Not identified
      Risk level: [Critical / High / Medium / Low]
      Controls: IAM policies, approval workflows
      [China: 最小权限原则 is 等保2.0 basic requirement]

  4.3 Agent → Production Environment boundary
      (Config changes, resource creation)
      → Identified / Not identified
      Risk level: [Critical / High / Medium / Low]
      Controls: deployment approval, rollback mechanisms
      [China: Must have capability to switch to manual/traditional systems]

  4.4 Agent ↔ Agent boundary
      (Message queue communication)
      → Identified / Not identified
      Risk level: [Critical / High / Medium / Low]
      Controls: message signing, access control
      [China: Must comply with 《数据安全法》transmission encryption]

Confirmation:

Check 4 complete: ✅ 3/4 passed. Boundary 4.4 (Agent↔Agent) not identified — this impacts inter-agent security compliance. Ready for Check 5?

MVTM Check 5/10 — Key Assets and Flows

Requirement: Critical assets identified with protection measures and data flow paths.

Phase marker: [MVTM Check 5/10 — Asset Flows]

Conversation:

[MVTM Check 5/10 — Asset Flows]

Let me verify critical asset coverage. For each asset type:

  5.1 Source Code
      → Identified / Not identified
      Protections: [branch protection / commit signing / access audit / encryption]
      [China: Source code audit is statutory (《网络安全法》Art.63)]

  5.2 Infrastructure Credentials
      → Identified / Not identified
      Protections: [key manager / auto rotation / access audit]
      [China: Credential management is 等保2.0 data encryption requirement]

  5.3 IaC State Files (e.g., Terraform state)
      → Identified / Not identified
      Protections: [encryption / version control / access logs]
      [China: State files are 重要数据 — must be classified and graded]

  5.4 Container Images
      → Identified / Not identified
      Protections: [signature verification / vulnerability scan / digest pinning]
      [China: Supply chain security per GB/T 45953-2025]

  5.5 Audit Logs
      → Identified / Not identified
      Protections: [immutable storage / retention ≥6 months / encryption]
      [China: 《网络安全法》Art.21 mandates ≥6 month retention]

  5.6 System Prompts
      → Identified / Not identified
      Protections: [version control / access control / no log leakage]
      [China: Prompt security is 《人工智能安全标准体系》"safety fence" direction]

Confirmation:

Check 5 complete: ✅ 5/6 passed. Asset 5.6 (System Prompts) not yet identified — affects 《人工智能安全标准体系》safety fence compliance. Ready for Check 6?

MVTM Check 6/10 — Per-Layer Threat Assessment (Agent-Driven)

AI Auto-Generation: This check is AGENT-DRIVEN. The AI analyzes architecture, actors, boundaries, and assets from Checks 1-5, then generates per-layer threat findings. The user confirms or modifies them.

Phase marker: [MVTM Check 6/10 — Per-Layer Threats]

Procedure:

1. The agent scans the accumulated data from Checks 1-5
2. The agent applies the 4 agentic risk factors (Non-Determinism, Autonomy, Identity Mgmt, A2A Communication)
3. The agent walks the per-layer checklist (L1, L2, L3, L4, L6) and suggests threats
4. The user confirms each layer's findings
5. Blindspot vectors BV-1 through BV-12 are also checked

Conversation:

[MVTM Check 6/10 — Per-Layer Threats]

Based on your architecture, actors, boundaries, and assets from Checks 1-5,
I've analyzed threats for each MVTM-required layer:

  L1 (Foundation Model):
  I found these potential threats:
    ✓ T6 Prompt Injection — likely (Critical)
      [Agent justification: system uses user-provided prompts → LLM → tool calls]
    ✓ T1 Memory Poisoning — possible (High)
      [Agent justification: shared memory between agents without auth]
    - BV-1 Context Window Poisoning — unlikely (Low)
  
  Do you agree with the L1 findings?
  → Yes (confirm all) / Modify / Add more

  L2 (Data Operations):
  I found:
    ✓ T18 RAG Input Manipulation — possible (High)
    ✓ T28 RAG Data Exfiltration — possible (Medium)
  
  Do you agree with the L2 findings?
  → Yes / Modify / Add more

  L3 (Agent Frameworks):
  I found:
    ✓ T2 Tool Misuse — likely (Critical)
    ✓ T20 Framework Code Injection — possible (High)
  
  Do you agree with the L3 findings?
  → Yes / Modify / Add more

  L4 (Deployment Infrastructure):
  I found:
    ✓ T3 Privilege Compromise — possible (High)
    ✓ BV-3 Dependency Confusion — possible (Medium)
  
  Do you agree with the L4 findings?
  → Yes / Modify / Add more

  L6 (Security & Compliance):
  I found:
    ✓ T45 Insufficient Permission Isolation — possible (High)
    ✓ T46 Data Residency Violation — possible (Medium)
  
  Do you agree with the L6 findings?
  → Yes / Modify / Add more

After all layers confirmed, update state.json:

"mvtm_checklist": {
  "6_layer_threats": {
    "status": "complete",
    "passed": 5,
    "total": 5,
    "items": {
      "6.1": {"status":"passed","value":"Confirmed","note":"L1: 2 threats (Critical+High)"},
      "6.2": {"status":"passed","value":"Confirmed","note":"L2: 2 threats (High+Medium)"},
      "6.3": {"status":"passed","value":"Confirmed","note":"L3: 2 threats (Critical+High)"},
      "6.4": {"status":"passed","value":"Confirmed","note":"L4: 2 threats (High+Medium)"},
      "6.5": {"status":"passed","value":"Confirmed","note":"L6: 2 threats (High+Medium)"}
    }
  }
}

Confirmation:

Check 6 complete: All 5 layers assessed. Total threats identified: [N]. Top risk: [top threat]. Ready for Check 7?

MVTM Check 7/10 — Cross-Layer Threat Patterns (Agent-Driven)

AI Auto-Generation: The agent analyzes whether each cross-layer pattern applies, using data from prior checks. The user confirms.

Phase marker: [MVTM Check 7/10 — Cross-Layer Threats]

Conversation:

[MVTM Check 7/10 — Cross-Layer Patterns]

Based on your architecture, I've evaluated the 4 cross-layer patterns:

  7.1 PR Injection → Production Deployment (L1→L3→L4→L5)
      → Threat exists / Not applicable
      [Defense: 体系对抗体系 — cross-layer defense required]

  7.2 Infrastructure Drift (L1→L4→L6)
      → Threat exists / Not applicable
      [China: LLM-hallucinated config changes require policy constraint validation]

  7.3 Compromised Dependency Propagation (L2→L3→L4→L7)
      → Threat exists / Not applicable
      [China: Supply chain security per GB/T 45953-2025]

  7.4 Confused Deputy / Agent Spoofing (L3→L4)
      → Threat exists / Not applicable
      [China: Agent permissions must follow 最小必要 principle]

Confirmation:

Check 7 complete: [X] patterns confirmed. Ready for Check 8?

MVTM Check 8/10 — Mitigation Planning

Requirement: At least 5 mitigations planned, with ≥1 Preventive AND ≥1 Detective for Critical threats.

Phase marker: [MVTM Check 8/10 — Mitigations]

Requirements by risk level:

Conversation:

[MVTM Check 8/10 — Mitigations]

Based on the threats identified in Checks 6-7, let me suggest mitigations.
Please confirm or modify for each:

  8.1 Input Sanitization + Injection Protection
      Addresses: T6 (Intent Breaking / Prompt Injection)
      Priority: 🚨 Immediate
      → Planned / Not planned
      [China: 《AI治理框架》2.0 requires input anomaly monitoring + circuit breaker]

  8.2 Sandbox Isolation
      Addresses: T11 (RCE / Code Execution)
      Priority: 🚨 Immediate
      → Planned / Not planned
      [China: Agent operation must be in 安全可控 environment]

  8.3 Message Signing + Verification
      Addresses: T12 (Agent Communication Poisoning)
      Priority: 🚨 Immediate
      → Planned / Not planned
      [China: Agent communication must comply with 《数据安全法》transmission encryption]

  8.4 OPA Policy-as-Code
      Addresses: T2 (Tool Misuse)
      Priority: ⚡ Short-term
      → Planned / Not planned
      [China: 等保2.0 requires baseline configuration management]

  8.5 Secret Scanning + Auto-Rotation
      Addresses: T3 (Privilege Compromise / Credential Leakage)
      Priority: ⚡ Short-term
      → Planned / Not planned
      [China: 《网络安全法》Art.21 requires data encryption]

  8.6 Human-in-the-Loop Approval Control
      Addresses: T14 (Human Attacks / Bypass HITL)
      Priority: 🚨 Immediate
      → Planned / Not planned
      [China: Must retain 人工复核与干预权限]

MVTM minimum: At least 5 of 6 must be "Planned." If fewer than 5 threats were identified, mark N/A on unused items but flag if total <5.

Mitigation gap check: After all items confirmed, check:

• Critical threats with NO Preventive → ⚠ Gap
• High threats with NO Detective → ⚠ Gap
• Any threat with only 1 mitigation → ⚠ Gap

Confirmation:

Check 8 complete: ✅ [N]/6 mitigations planned. [X] gaps flagged. Ready for Check 9?

MVTM Check 9/10 — Residual Risk

Requirement: Record accepted, mitigated, or transferred residual risks with Chinese compliance notes.

Phase marker: [MVTM Check 9/10 — Residual Risk]

Conversation:

[MVTM Check 9/10 — Residual Risk]

For each threat recorded in Check 6, let me calculate residual risk
and document the disposition:

  9.1 T6: Intent Breaking / Prompt Injection (固有风险: Critical)
      → Mitigation: 8.1 Input Sanitization
      → 残余风险: [Critical / High / Medium / Low]
      → 处置: [Mitigate / Accept / Transfer / Defer]
      [China: 《网络安全法》amendment 千万级罚款 — Critical residual must not be accepted]

  9.2 T2: Tool Misuse (固有风险: High)
      → 残余风险: [Critical / High / Medium / Low]
      → 处置: [Mitigate / Accept / Transfer / Defer]
      [China: 等保2.0 baseline violation may trigger 监管通报]

  9.3 T3: Privilege Compromise / Credential Leakage (固有风险: High)
      → 残余风险: [Critical / High / Medium / Low]
      → 处置: [Mitigate / Accept / Transfer / Defer]
      [China: 《数据安全法》Art.27 full lifecycle data security management]

  9.4 T14: Human Attacks / Bypass HITL (固有风险: Critical/High)
      → 残余风险: [Critical / High / Medium / Low]
      → 处置: [Mitigate / Accept / Transfer / Defer]
      [China: 《AI治理框架》2.0 "prevent loss of control" principle]

  9.5 T13: Rogue Agents / Supply Chain (固有风险: High)
      → 残余风险: [Critical / High / Medium / Low]
      → 处置: [Mitigate / Accept / Transfer / Defer]
      [China: GB/T 45953-2025 requires remediation within deadline]

  9.6 T11: RCE / Code Execution (固有风险: Critical)
      → 残余风险: [Critical / High / Medium / Low]
      → 处置: [Mitigate / Accept / Transfer / Defer]
      [China: This is a "不得投入生产" level defect — Critical must be remediated]

  9.7 T12: Agent Communication Poisoning (固有风险: High)
      → 残余风险: [Critical / High / Medium / Low]
      → 处置: [Mitigate / Accept / Transfer / Defer]
      [China: Agent security is 国家标准体系 key direction]

  9.8 T8: Repudiation / State Manipulation (固有风险: High)
      → 残余风险: [Critical / High / Medium / Low]
      → 处置: [Mitigate / Accept / Transfer / Defer]
      [China: State files are 重要数据 — must be encrypted]

Residual risk calculation:

Effective Risk = Inherent Risk Level × (1 - Implementation Status)
- Not Implemented: ×0.0 → Inherent Risk (unchanged)
- Partially Implemented: ×0.5 → e.g., Critical → Medium
- Implemented: ×1.0 → e.g., Critical → Eliminated (Effective Risk = 0)

Risk Level numeric mapping: Low=1, Medium=2, High=3, Critical=4
Example: Critical(4) × (1 - 0.5) = 2.0 → Medium

China-specific residual risk rules:

• CII threats at High residual: must not be "Accepted" — requires remediation plan
• Important Data threats at Medium residual: must remediate within quarter
• All risk acceptance decisions: require management written sign-off ("双罚制")

Aggregate assessment: After all items, check: "Is the aggregate residual risk within the risk appetite defined in Check 1?"

Confirmation:

Check 9 complete: [X] mitigated, [Y] accepted, [Z] deferred. Aggregate residual [is/is not] within risk appetite. China compliance: management sign-off [required / obtained]. Ready for Check 10?

MVTM Check 10/10 — Output Export

Requirement: Threat model outputs exported and available for audit/review.

Phase marker: [MVTM Check 10/10 — Output]

Conversation:

[MVTM Check 10/10 — Output Export]

Let me verify that all deliverables are in place:

  10.1 MVTM Checklist Report (01-mvtm-checklist.md) generated
       → Yes / Not yet
       [China: Can serve as supporting material for 安全评估 and 等保定级]

  10.2 Architecture + Data Flow documentation included
       → Yes / Not yet
       [China: CII operators must maintain complete architecture records]

  10.3 Mitigation Implementation Plan documented
       → Yes / Not yet
       [China: Can serve as 合规整改 action basis]

  10.4 Residual Risk approved by management (signed)
       → Yes / Not yet
       [China: 《网络安全法》"双罚制" requires management accountability]

Generate output files:

1. 01-mvtm-checklist.md — Complete checklist with per-item status, scoring summary, scope warning (if any), and China compliance reference appendix IMPORTANT — Must include a parseable Threat Register table with these columns: | Local ID | Threat Name | Layer | Severity | Risk Level | ASI ID | AI Risk Code | Also include a Mitigation Summary table with columns: | Mitigation ID | Catalog ID | Type | Cost | Effectiveness | Status | These tables are required for .docx/.xlsx generation by the Python scripts.
2. threat-model.json — Structured export with analysis_mode: "mvtm_checklist" marker
3. 11-ai-risk-classification.md — AI risk classification per 《人工智能安全治理框架》2.0
4. 11-ai-risk-classification.docx — via scripts/generate_docx.py (reads 01-mvtm-checklist.md instead of 10 phase files when analysis_mode == "mvtm_checklist")
5. 11-ai-risk-classification.xlsx — via scripts/generate_xlsx.py

If mvtm_scope_warning == true: All output files must include a prominent Scope Limitation Warning at the top:

⚠ SCOPE LIMITATION
This MVTM checklist was performed on a system that meets criteria for
[Full/Standard] analysis per MAESTRO + China regulatory guidance.
Specifically: [list criteria triggered].
The MVTM checklist is a MINIMUM baseline and does not replace a
comprehensive threat assessment. See the full decision tree analysis
for recommended next steps.

MVTM Scoring Summary Table (in output):

| Check Item | Total | Passed | Status |
|------------|-------|--------|--------|
| 1. Business Context | /5 | | [Complete/Partial/Missing] |
| 2. Architecture | /7 | | [Complete/Partial/Missing] |
| 3. Threat Actors | /5 | | [Complete/Partial/Missing] |
| 4. Trust Boundaries | /4 | | [Complete/Partial/Missing] |
| 5. Asset Flows | /6 | | [Complete/Partial/Missing] |
| 6. Per-Layer Threats | /5 | | [Complete/Partial/Missing] |
| 7. Cross-Layer Patterns | /4 | | [Complete/Partial/Missing] |
| 8. Mitigations | /6 | | [Complete/Partial/Missing] |
| 9. Residual Risk | /8 | | [Complete/Partial/Missing] |
| 10. Output Export | /4 | | [Complete/Partial/Missing] |
| **TOTAL** | **/54** | | |

MVTM Standard: [PASS / FAIL] — Must achieve ≥80% overall (≥43/54)

Decision Tree Recommendation (output section): Include the decision tree output as a section in the report:

• MAESTRO 5-question results
• China-specific 5-criteria results
• Recommended depth: MVTM / Standard / Full
• If user chose MVTM despite Full/Standard recommendation: note as conscious decision

Confirmation:

Check 10 complete: ✅ All outputs generated. MVTM Checklist assessment complete. Final score: [N]/54 ([PASS/FAIL]). See 01-mvtm-checklist.md and threat-model.json for full results.

End of MVTM Checklist Workflow

Risk Scoring Reference

Source: MAESTRO Official Risk Scoring Guide v1.0.0, integrated with GB/T 20984—2022, 《网络安全法》2026修订版, 《人工智能安全治理框架》2.0.

This reference is used by both MVTM Checks 6-9 and Full Assessment Phases 6-9. The agent MUST consult this section when scoring threats, planning mitigations, and calculating residual risk.

Severity Scale (Threat Severity)

Measures the potential impact if a threat is successfully exploited.

China Compliance Severity Extensions

Likelihood Scale (Threat Likelihood)

Measures the probability of exploitation under current controls and threat landscape.

Risk Matrix (Severity × Likelihood)

Usage: Find the severity row, then the likelihood column — the intersection is the Risk Level.

Risk Level Definitions

Attack Vector Modifier

Describes how an attacker reaches a vulnerable component. Wider vectors get higher priority.

Prioritization: When two threats have the same Risk Level, prioritize by vector breadth: Network > Adjacent > Local > Physical.

Attack Complexity Modifier

Describes the conditions outside the attacker's control required for successful exploitation.

Prioritization: When two threats have same Risk Level and Attack Vector, prioritize lower complexity: Low > High.

Implementation Status

Multiple mitigations: When multiple mitigations address the same threat, use the strongest status. If the strongest mitigation only covers part of the threat (e.g., handles one attack vector but not another), treat overall status as Partially Implemented (0.5).

No code access (Phase 8 skipped): All Phase 7 mitigations default to Not Implemented (0.0).

Effective Risk Formula

Effective Risk = Risk Level × (1 - Implementation Status)

Examples:

• Critical (4) × (1 - 0.0) = 4.0 → Critical (no mitigation)
• Critical (4) × (1 - 0.5) = 2.0 → Medium (partial mitigation)
• Critical (4) × (1 - 1.0) = 0.0 → Eliminated (fully implemented)
• High (3) × (1 - 0.5) = 1.5 → Low (partial mitigation)

Effective Risk vs. Residual Risk

Relationship: Effective Risk is an input to Residual Risk assessment, not a replacement. Even if Effective Risk is 0 (fully mitigated), residual risk may remain if mitigations rely on assumptions that could be overturned.

Mitigation Requirements by Risk Level

Mitigation Types

Defense-in-Depth Principle

For each threat, layer at least 2 mitigation types where possible. Relying on a single control is a single point of failure.

Cost-Effectiveness Matrix

Cost Levels

Effectiveness Levels

Cost-Effectiveness Prioritization Matrix

China-Specific Priority Adjustments

When scoring threats for systems operating in or serving the Chinese market, apply these overrides AFTER computing the base risk level:

China-Specific Risk Acceptance Criteria

China special rules:

• CII threats at High residual risk: must not be handled as "Accepted" — must have remediation plan and timeline
• Important Data threats at Medium residual risk: must remediate within the quarter — no indefinite acceptance
• All risk acceptance decisions: require management written sign-off ("双罚制" personal liability penetration)

Complete Prioritization Workflow (MAESTRO + China)

Step 1: SCORE
  ├─ Rate threat Severity (Low/Medium/High/Critical)
  ├─ Rate threat Likelihood (Unlikely/Possible/Likely/Very Likely)
  └─ Determine Risk Level from 4×4 matrix

Step 2: APPLY MODIFIERS
  ├─ Attack Vector: Network > Adjacent > Local > Physical
  └─ Attack Complexity: Low > High

Step 3: CHECK EXISTING CONTROLS
  ├─ Evaluate Implementation Status (0.0/0.5/1.0)
  └─ Compute Effective Risk = Risk Level × (1 - Implementation Status)

Step 4: SORT THREATS
  └─ By Effective Risk (desc) → Attack Vector breadth → Complexity (Low first)

Step 5: APPLY CHINA PRIORITY ADJUSTMENTS
  ├─ CII/Important Data/AI Autonomy → +1 grade
  ├─ Unfiled algorithm → Critical
  └─ Unassessed cross-border data → Critical

Step 6: IDENTIFY CANDIDATE MITIGATIONS
  ├─ For each unmitigated or partially mitigated threat
  └─ Score Cost (Low/Medium/High) and Effectiveness (Low/Medium/High)

Step 7: PRIORITIZE MITIGATIONS
  └─ Use Cost-Effectiveness Matrix: High-Effect/Low-Cost > High-Effect/Medium-Cost > Medium-Effect/Low-Cost

Step 8: RECORD RESIDUAL RISK
  ├─ Re-score after planned mitigations
  ├─ Record expected Residual Risk level
  └─ China: residual risk requires management sign-off ("双罚制")

Assessment Frequency Requirements (China)

Terminology Cross-Reference (MAESTRO ↔ GB/T 20984—2022)

Phase 1/10 — Business Context Analysis

File write: After completing this phase, write the output to 01-business-context.md in the run directory ($runDir/01-business-context.md).

User provides: System purpose, criticality, regulations, data sensitivity, stakeholders, risk appetite.

Conversation

[Phase 1/10 — Business Context]

Q1: What is the primary business function of this system? (One sentence)
→ [User: "Our customer support agent handles refund requests"] ✓

Q2: How critical is this system to business operations?
   → Low (internal tool, no revenue impact)
   → Medium (important but workarounds exist)
   → High (revenue-impacting if unavailable)
   → Critical (safety-critical or revenue-critical)
→ [User: High]

Q3: What regulatory frameworks apply to this system?
   → GDPR / HIPAA / SOX / PCI-DSS / EU AI Act / None / Other (specify)
→ [User: GDPR, SOX]

Q4: What is the highest data classification this system processes?
   → Public / Internal / Confidential / Restricted
→ [User: Confidential]

Q5: Who are the key stakeholders?
   → Business owner, data owner, technical lead
→ [User: CISO (risk owner), Head of Support (business owner), ML Eng Lead (technical)]

Q6: What is the risk appetite for this system?
   → Conservative (avoid risk, prefer manual approval)
   → Moderate (balance risk and speed)
   → Aggressive (optimize for speed, accept some risk)
→ [User: Moderate]

Q7: What are key business assumptions?
   (e.g., user base count, deployment environment, expected uptime)
→ [User: 5000 internal users, cloud-hosted, 99.9% uptime required]

Agentic Probe (after Q7)

Probe the user on agentic considerations:

• "Would non-deterministic LLM outputs be acceptable for refund decisions? If a customer gets different answers each time, is that OK?"
• "What level of autonomous decision-making is acceptable? Should the agent approve refunds automatically or only recommend?"

Output Template

# Phase 1: Business Context — <Project>

| Field | Value |
|-------|-------|
| Application Name | <name> |
| Business Domain | <domain> |
| Data Classification | Confidential |
| Regulatory Requirements | GDPR, SOX |
| Criticality | High |
| User Base | Internal (5,000) |
| Agent Type | TBD (Phase 2) |
| Autonomy Level | TBD (Phase 2) |
| Risk Appetite | Moderate |

## Assumptions

| ID | Description | Impact if Wrong | Status |
|----|-------------|----------------|--------|
| A1 | System processes only internal users | External exposure would increase threat actor pool | Unvalidated |
| A2 | 99.9% uptime target | Downtime above 0.1% would require re-architecture | Unvalidated |

Confirmation

"Phase 1 complete. I've captured: [system purpose], [criticality], [regulations]. Ready for Phase 2 (Architecture)?"

Phase 2/10 — Architecture Analysis

File write: After completing this phase, write the output to 02-architecture.md in the run directory ($runDir/02-architecture.md).

User provides: Component inventory, tech stack, data flows, trust boundaries.

Conversation

[Phase 2/10 — Architecture Analysis]

Q1: What LLM/foundation model does your system use?
   → GPT-4o / Claude 3.5 / Gemini / Llama / Custom / None
→ [User: GPT-4o via Azure OpenAI API]

Q2: Is the model API-hosted or self-hosted?
   → API-hosted (Azure / AWS Bedrock / GCP Vertex / OpenAI Direct)
   → Self-hosted (on-prem / VPC / Kubernetes)
→ [User: API-hosted — Azure OpenAI]

Q3: What data stores exist in your system?
   → Vector database? Which one?
   → Document store / object storage?
   → Relational database?
   → Cache layer?
→ [User: Pinecone vector DB, PostgreSQL, Redis cache]

Q4: What agent framework does your system use?
   → LangChain / CrewAI / AutoGen / Strands / Custom / None
→ [User: LangChain + custom agent logic]

Q5: What tools or APIs can agents access?
   → MCP servers? Function calling? External APIs?
→ [User: MCP server for refund processing, 3 external APIs (CRM, payment, ticketing)]

Q6: What is the deployment model?
   → Cloud (AWS/Azure/GCP) / On-prem / Hybrid / Serverless
→ [User: Cloud — Azure Kubernetes Service]

Q7: How do components communicate?
   → Direct API calls / Message queue / Shared memory / A2A protocol / MCP
→ [User: REST APIs + MCP protocol for agent-tool communication]

System Type Detection (after Q7)

Ask these two critical questions:

Q8: Is this a single-agent or multi-agent system?
   → Single-agent (one AI agent)
   → Multi-agent (multiple agents coordinating)
→ [User response]
   → If single-agent: adjust Phase 6 — skip multi-agent threats (T38, T21)
   → Update state.json "system_type"

Q9: Does your system use MCP (Model Context Protocol)?
   → Yes / No
→ [User response]
   → If yes: In Phase 6, include MCP-specific threats (T40,T42,T43,T47,T41,T44,T45,T46)
   → Update state.json "uses_mcp"

Q10: Is this assessment targeting an OpenCode Skill (code + prompt hybrid distributed via clawhub.ai)?
   → Yes (evaluate a skill) / No (evaluate a general agentic system)
→ [User response]
   → If yes:
     • Activate Layer **S0 (Skill Content)** in Phase 6 — examines the skill itself as a code+prompt hybrid threat vector
     • Add skill-specific mitigations (S0-P1, S0-P2, etc.) in Phase 7
     • Generate `12-skill-risk-assessment.md` in Phase 10 — a specialized report organized by the 6-step MAESTRO skill assessment method
     • Check for: runtime remote content loading, delayed payloads, multi-skill collusion, skill dependency chain attacks
   → Update state.json "target_type": "opencode_skill"

Layer Mapping (agent generates this from user input)

| Layer | Components | Notes |
|-------|------------|-------|
| L1: Foundation Model | GPT-4o via Azure OpenAI | API-hosted, no fine-tuning |
| L2: Data Operations | Pinecone vector DB, PostgreSQL | Customer data, refund policies |
| L3: Agent Frameworks | LangChain, MCP server for refund | Autonomy: human-in-loop |
| L4: Deployment Infrastructure | AKS, REST APIs, Redis | Service accounts, network policies |
| L5: Evaluation & Observability | Azure Monitor, Application Insights | Audit logging enabled |
| L6: Security & Compliance | Azure AD, RBAC, Key Vault | Secrets rotation: manual |
| L7: Agent Ecosystem | CRM, Payment API, Ticketing API | mTLS for MCP connections |

Confirmation

"Phase 2 complete. I've mapped 7 layers of your architecture and noted it's a [single/multi]-agent system [with/without] MCP. Ready for Phases 3-5. These can be done in any order — which would you like to start with: Threat Actors (3), Trust Boundaries (4), or Asset Flows (5)?"

Note: Phase 5 (Asset Flows) maps assets to trust zones defined in Phase 4 (Trust Boundaries). If you choose Phase 5 first, I'll need to revisit and update asset-to-zone mappings after Phase 4.

Phase 3/10 — Threat Actor Analysis

File write: After completing this phase, write the output to 03-threat-actors.md in the run directory ($runDir/03-threat-actors.md).

User provides: Relevant threat actor categories and their characteristics.

Conversation

[Phase 3/10 — Threat Actors]

For each category, I'll ask if it's relevant to your system:

Q1: External Attackers — Your system uses cloud APIs and is accessible over the network.
    Could external attackers target it?
   → Yes / No / Partially
→ [User: Yes — refund system is valuable target]

Q2: Malicious Insiders — Do employees or contractors have privileged access
    to the agent, its tools, or its data?
   → Yes / No / Partially
→ [User: Yes — support agents have access to refund tools]

Q3: Compromised Agents — Could an agent be subverted through
    prompt injection, poisoned memory, or plugin compromise?
   → Yes / No / Partially
→ [User: Yes — this is a key concern]

Q4: Nation-State Actors — Is this system in critical infrastructure,
    defense, or a politically sensitive domain?
   → Yes / No
→ [User: No]

Q5: Automated Threats — Could botnets or AI-powered attack
    tools target your system?
   → Yes / No / Partially
→ [User: Partially — rate limiting exists but not AI-specific]

For each relevant actor, document:

| Actor ID | TA1 |
|----------|-----|
| Category | External Attacker |
| Capability | Moderate (script kiddie to skilled) |
| Motivation | Financial gain (refund fraud) |
| Target Assets | Refund API, customer PII, credentials |
| Likely Vectors | Prompt injection, API abuse, credential theft |
| Target Layers | L3 (Agent Frameworks), L7 (Ecosystem) |
| Priority | High |

Confirmation

"Phase 3 complete. I've identified [N] relevant threat actors. The key concern is [top actor]. Ready for the next phase."

Phase 4/10 — Trust Boundary Analysis

File write: After completing this phase, write the output to 04-trust-boundaries.md in the run directory ($runDir/04-trust-boundaries.md).

User provides: Trust zone definitions, boundary crossings, security controls.

Conversation

[Phase 4/10 — Trust Boundaries]

Q1: What trust zones exist in your system?
   → Common zones: Public / DMZ / Application / Data / Privileged / External
→ [User: Public (users), Application (AKS), Data (DBs), External (CRM/Payment APIs)]

Q2: Where are the crossing points between these zones?
   → Which components connect across zones?
→ [User: MCP server in App zone connects to Payment API in External zone]

Q3: What security controls exist at each boundary?
   For each crossing: auth, authorization, input validation, encryption, rate limiting, logging
→ [User: OAuth + mTLS for External, RBAC for App→Data]

Q4: Where does the system implicitly trust data without verification?
   → Are there any unauthenticated channels or trusted relationships?
→ [User: Inter-agent memory channel — no auth between agents sharing context]

Q5: How do agents cross boundaries?
   → Do they carry user identity? Escalate privileges?
→ [User: Agent uses service account, doesn't pass user identity to payment API]

Q6: Rate each boundary: Strong / Moderate / Weak
→ [User: Public→App=Moderate, App→Data=Moderate, App→External=Strong]

Template

| ID | Source | Dest | Auth | Input Validation | Encryption | Logging | Strength |
|----|--------|------|------|-----------------|------------|---------|----------|
| TB1 | Public | App (AKS) | OAuth | Yes | TLS | Yes | Moderate |
| TB2 | App | Data (DBs) | RBAC | N/A | TLS | Partial | Moderate |
| TB3 | App (MCP) | Payment API | mTLS | Yes | mTLS | Yes | Strong |
| TB4 | Agent A | Agent B | None | No | None | No | **Weak** |

Agentic Probe

• "Could non-deterministic routing send data from the MCP server to an unintended tool?"
• "The agent uses a service account that doesn't carry user identity — this creates a confused deputy risk where the agent could perform actions the requesting user shouldn't be allowed to do."
• "The inter-agent memory channel (TB4) has no authentication. If Agent A is compromised, could it poison Agent B's memory?"

Confirmation

"Phase 4 complete. Key finding: the inter-agent memory channel (TB4) has no security controls — this is a significant gap. Ready for Phase 5 (Asset Flows) or back to [Phase 3/5]?"

Phase 5/10 — Asset Flow Analysis

File write: After completing this phase, write the output to 05-asset-flows.md in the run directory ($runDir/05-asset-flows.md).

User provides: Critical assets and their lifecycle.

Conversation

[Phase 5/10 — Asset Flow Analysis]

Q1: What critical assets exist in your system?
   → PII, credentials, API keys, system prompts, model weights, embeddings, audit logs
→ [User: Customer PII, refund API key, system prompt, audit logs]

Q2: Where is each asset created?
   → User input / API response / LLM generation / DB query
→ [User: PII from user input, API key from config, system prompt from code]

Q3: Where is each asset stored?
   → DB / vector store / memory / cache / file system
→ [User: PII in PostgreSQL, API key in env vars, system prompt in LangChain config]

Q4: How is each asset transmitted?
   → API call / message queue / shared memory / file transfer
→ [User: API key via HTTP header to Azure OpenAI, system prompt via LangChain runtime]

Q5: Where is each asset processed or transformed?
   → LLM inference / business logic / data pipeline
→ [User: Customer PII processed by GPT-4o during refund analysis]

Q6: How and when is each asset destroyed?
   → TTL / manual deletion / never
→ [User: Audit logs retained 7 years (SOX), API key rotated quarterly, PII deleted after 90 days]

Q7: What protections exist at each stage?
   → Encryption at rest / in transit / access controls / masking
→ [User: DB encrypted at rest, TLS in transit, no masking on PII in logs]

Template

| Asset ID | Name | Classification | Created | Stored | Transmitted | Processed | Destroyed | Protections |
|----------|------|---------------|---------|--------|-------------|-----------|-----------|-------------|
| AF1 | Customer PII | Restricted | User input | PostgreSQL | HTTPS→API | GPT-4o inference | 90 days | Encrypted at rest, TLS |
| AF2 | Refund API Key | Restricted | Config file | Env vars | HTTP header | Auth middleware | Quarterly rotation | Manual rotation only |
| AF3 | System Prompt | Confidential | Code | LangChain config | LangChain runtime | LLM context | Never | No access controls |
| AF4 | Audit Logs | Internal | System events | Azure Monitor | — | SOX compliance | 7 years | Immutable logging |

Agentic Probe

• "LLM-generated refund decisions may inadvertently include PII in logs — check Azure Monitor for PII leakage."
• "The refund API key is only rotated quarterly and transmitted in HTTP headers — any log that captures the header would expose the key."

Confirmation

"Phase 5 complete. Key finding: system prompt (AF3) has no access controls and is never destroyed. Also, PII may leak into GPT-4o context and appear in logs."

Phase 6/10 — Threat Identification (Agent-Driven)

File write: After completing this phase, write the output to 06-threat-register.md in the run directory ($runDir/06-threat-register.md).

AI Auto-Completion Available: Phases 6-10 can be automatically completed by the AI using information gathered in Phases 1-5. The AI will generate the threat register, mitigations, residual risk, and final outputs without further user input. You will have the opportunity to review and modify all outputs after generation.

Before proceeding, the agent MUST ask: "Phases 6-10 can be auto-completed by AI based on the information gathered so far. Would you like me to auto-complete the remaining phases, or would you prefer to go through each phase manually?"

• If Yes (auto-complete): AI generates Phases 6-10 sequentially using gathered data, then presents the full set for review at the end. Procedure:
  1. Generate Phase 6 (threat register) from existing data — scan all 7+1 layers and cross-layer patterns.
  2. Generate Phase 7 (mitigations) — map each threat to at least one mitigation from the catalog.
  3. Generate Phase 8 (code validation) — if source code access is available; otherwise note "Not applicable."
  4. Generate Phase 9 (residual risk) — calculate Effective Risk and classify each threat's disposition.
  5. Generate Phase 10 (output summary + .docx/.xlsx via scripts).
  6. Present a summary table: "Auto-generated Phases 6-10 complete. Review the 10-output-summary.md and script outputs above. Which sections would you like to modify?"
  • If the AI detects missing data, contradictions, or low-confidence scoring during auto-generation, flag it explicitly: "Note: Threat X scoring is uncertain because [reason]. Please review."
  • Auto-complete uses defaults for risk owners ("TBD — assign in Phase 9"), cost estimates ("Medium"), and implementation status ("Not Implemented").
• If No (manual): Proceed with the standard interactive Q&A for each phase as described below.

Goal: Agent derives threats from prior phase outputs. User reviews and confirms.

Inputs consumed: Phase 1 (business context), Phase 2 (architecture), Phase 3 (actors), Phase 4 (boundaries), Phase 5 (assets).

Instructions for Agent

1. For each applicable layer (determined by analysis depth), use the checklist below.
2. Apply all 4 agentic risk factors at every layer:
   • Non-Determinism: LLM outputs vary for identical inputs
   • Autonomy: Agent acts without human approval
   • Identity Management: Agent identity and permissions
   • Agent-to-Agent Communication: Inter-agent channels
3. Score each threat using the 4×4 Risk Matrix in the Risk Scoring Reference section.
   • Rate Severity (Low/Medium/High/Critical) using the Severity Scale
   • Rate Likelihood (Unlikely/Possible/Likely/Very Likely) using the Likelihood Scale
   • Look up Risk Level from the matrix intersection
   • Record Attack Vector (Network/Adjacent/Local/Physical) and Attack Complexity (Low/High)
4. Apply China-specific priority adjustments from the Risk Scoring Reference (CII/Important Data/AI Autonomy → +1 grade).
5. Assign local IDs: <PROJ>-T1, <PROJ>-T2, etc.
6. Map to ASI taxonomy IDs or extended threat IDs.
7. Check cross-layer patterns.
8. Walk blindspot vectors (BV-1 to BV-12).

Per-Layer Threat Checklists

Note: Layer S0 (Skill Content) is activated only when target_type=opencode_skill. It functions as a meta-layer that examines the skill artifact itself — both its prompt instructions and its executable code — for combined attack patterns that traditional single-layer analysis would miss.

Layer S0 — Skill Content (Code + Prompt Hybrid Meta-Layer)

Layer 1 — Foundation Model

Layer 2 — Data Operations

Layer 3 — Agent Frameworks

Layer 4 — Deployment Infrastructure

Layer 5 — Evaluation & Observability

Layer 6 — Security & Compliance

Layer 7 — Agent Ecosystem

Cross-Layer Attack Chains

Check each pattern for applicability:

Threat Card Template

| Field | Value |
|-------|-------|
| **Local ID** | `<PROJ>-T1` |
| **Threat Name** | Refund API Tool Misuse via Prompt Injection |
| **Layer** | L3 (Agent Frameworks), L7 (Ecosystem) |
| **ASI ID** | T2 (Tool Misuse), T6 (Intent Breaking) |
| **Severity** | Critical |
| **Likelihood** | Likely |
| **Risk Level** | Critical |
| **AI Risk Code** | E2 |
| --- | --- |
| STRIDE | Tampering, Elevation of Privilege |
| Description | Attacker crafts a prompt that causes GPT-4o to call the refund MCP tool with manipulated parameters |
| Attack Vector | Network |
| Attack Complexity | Low |
| Agentic Factors | Autonomy, Non-Determinism |
| Affected Components | GPT-4o, LangChain, MCP Refund Server, Payment API |
| Prerequisites | Knowledge of refund API parameters, access to chat interface |
| Impact | Financial loss from fraudulent refunds, SOX compliance violation |
| Mitigations | `<PROJ>-M1`, `<PROJ>-M2` |

Post-Phase Verification

After generating the threat register, the agent MUST:

1. Check every T-ID against the taxonomy. Any ID not in T1-T15, T16-T47, or BV-1-BV-12 is a hallucination — remove or replace.
2. Check every layer reference against actual component mappings from Phase 2.
3. Present the full register to the user for confirmation.

Case Study References

When explaining abstract threats, make them concrete with these examples:

• RPA Expense Agent (playbook/10-case-studies.md): An RPA agent with payment tool access was manipulated via prompt injection to approve fraudulent expense reports. Illustrates T2/T6 in a concrete business context.
• ElizaOS (playbook/10-case-studies.md): A plugin-based agent framework where a malicious plugin compromised the entire agent ecosystem. Illustrates T13/BV-3 supply chain risks.
• MCP Protocol (playbook/10-case-studies.md): Tool invocation protocol vulnerabilities including client impersonation and rogue servers. Illustrates T40/T47.
• OpenCode Skill Ecosystem (clawhub.ai): Skills are "code + prompt" hybrid artifacts. 2.9% of published skills have unverifiable runtime dependencies; 21% of confirmed malicious skills use prompt injection to override system instructions while code executes data exfiltration. Illustrates S0-layer threats (SK-P1 through SK-R4) and cross-layer patterns S1-S3.

Confirmation

"Phase 6 complete. I've identified [N] threats across [M] layers, including [X] Critical and [Y] High. The top risk is [top threat]. Review the threat register at 06-threat-register.md and confirm before I proceed to Phase 7 (Mitigation Planning)."

Phase 7/10 — Mitigation Planning (Agent-Driven)

File write: After completing this phase, write the output to 07-mitigations.md in the run directory ($runDir/07-mitigations.md).

Goal: For each threat, plan Preventive, Detective, Corrective, and Deterrent controls.

Mitigation Requirements

Mitigation Catalog Reference

User Interaction

After the agent generates mitigations:

[Phase 7/10 — I've drafted mitigations for each threat]
Q: For threat <PROJ>-T1 (Critical - Refund API Tool Misuse):
   I recommend: L3-P1 (Tool access control) + L3-D1 (Anomaly detection)
   Are these already implemented? (Yes / In Progress / No)
→ [User: No, but planned]

Q: What is the implementation cost estimate?
   → Low / Medium / High
→ [User: Medium]

Q: Who is the owner for implementing this?
→ [User: ML Engineering Team]

Mitigation Card Template

| Field | Value |
|-------|-------|
| Mitigation ID | <PROJ>-M1 |
| Name | MCP Tool Access Control |
| Type | Preventive |
| Catalog ID | L3-P1 |
| Addresses Threats | <PROJ>-T1, <PROJ>-T3 |
| Description | Validate every MCP tool call against an allowlist of permitted operations per user role |
| Cost | Medium |
| Effectiveness | High |
| Implementation Status | Not Implemented |
| Owner | ML Engineering |

Cost-Effectiveness Prioritization

After all mitigations are planned, use the Cost-Effectiveness Prioritization Matrix (see Risk Scoring Reference) to rank implementation order:

1. High Effect / Low Cost → Implement Now (best ROI)
2. High Effect / Medium Cost → Implement Soon
3. Medium Effect / Low Cost → Implement Soon (easy win)
4. Medium Effect / Medium Cost → Evaluate
5. High Effect / High Cost → Plan Carefully
6. All others → Defer or Do Not Implement

Apply China-specific urgency: if a threat involves CII, Important Data, or AI autonomous decisions, prefer faster implementation timelines regardless of cost.

Post-Phase Verification

1. Cross-reference every catalog ID (L3-P1, etc.) against the mitigation catalog source.
2. Verify every T-ID referenced exists in Phase 6 threat register.
3. Flag gaps: Critical threats with no Preventive, High threats with no Detective, any with single mitigation.

Confirmation

"Phase 7 complete. I've planned [N] mitigations for [M] threats. Flagged [X] gaps where threats lack sufficient controls. Review 07-mitigations.md and confirm before Phase 8."

Phase 8/10 — Code Validation

File write: After completing this phase, write the output to 08-code-validation.md in the run directory ($runDir/08-code-validation.md).

User provides: Source code access level. Agent validates mitigations against code.

Applicability Gate

[Phase 8/10 — Code Validation]
Q: What level of source code access do you have?
   A: Full access (app source + IaC) → Full analysis
   B: Partial access (config, IAM policies) → Config validation only
   C: No access (vendor/SaaS/closed-source) → Skip phase

If No access: Skip. Document "Code Validation: Not Applicable — no source code access." All Phase 7 mitigations default to Not Implemented (0.0) in Phase 9 per the Risk Scoring Reference.

Anti-Pattern Checklist (if access is granted)