Threat Modeling MCP Server

A Model Context Protocol (MCP) server for comprehensive threat modeling with guided code validation.

Table of Contents

• Overview

• Quick Start Prompts

• Key Features

• Prerequisites

• Installation

• Running with Kiro CLI

• Output File Management

• Quick Reference

• Tools Overview

• Threat Modeling Methodology

• Assumptions in Threat Modeling

• Development

Related MCP server: threatmodel-mcp

Overview

This server provides tools for threat modeling, including business context analysis, architecture analysis, threat actor analysis, trust boundary analysis, asset flow analysis, code security validation and comprehensive report generation.

Architecture and Approach

This MCP Server calls the existing agent's LLM instead of making an external API or network call to a different service. It relies on existing client's LLM which could be Amazon-Q, Kiro or Cline.

This Threat Modeling MCP Server has three main functionalities:

1. Threat modeling phase or state management and prompt controlling.

2. Prompts steering, which controls the agent to go through a methodic approach to threat modeling using built in definitions of business risks, exposures, threat actors and use STRIDE in sequential order.

3. Structured input validation and phase-completion checks that support an actionable threat model report.

It also has tools to generate a final report in both Markdown and JSON exportable formats.

Key Advantages of this approach

• This threat model follows the standard STRIDE approach to threat modeling in phases rather than quick conclusion of assets, boundaries and threats which can lead to hallucination or low quality output.

• There is an effort by LLM to understand the business context of the project and make valid assumptions which can be controlled by the user.

• This local server relies on the MCP client's configured LLM (Cline, Amazon Q, Kiro) rather than calling a separate model API. Data exposure depends on the client and any other MCP servers the client invokes.

• The server keeps the working threat model in memory for the current process. Export tools can write JSON and Markdown snapshots to a .threatmodel directory, but those snapshots are not automatically loaded in a later session.

• The code-validation tool records evidence supplied by the client after it inspects the implementation, applies status transitions atomically, and fails the phase closed until every current threat and mitigation is covered.

Quick Start Prompts and Examples on how to threat model with this MCP server

Note: Before using these prompts, you must first complete the Installation process to set up the MCP server.

Start a threat model

"Threat model this project using the threat modeling MCP Server"

Being specific in the prompt to use the threat modeling MCP Server will make sure the client (Cline/Kiro/etc) will follow the exact phases and methodology rather than taking short cut path and introduce hallucination in results.

Threat model a subproject or reduce the scope to a sub folder

"Threat model this subfolder using the threat modeling MCP Server"

Running it on a subfolder limits the intended analysis scope. To save exports there, request an output path inside that subfolder; the export location is not inferred automatically from the analysis scope.

Save the result of threat model

"Save the threat model report"

Validate the completeness of the threat modeling process

"Please complete all the phases in the threat model plan and then generate the final report."

Feed an architecture diagram image as input

"Threat model this project using the threat model MCP server and consider this architecture_image.png attached for this review"

Attempt remediating the threats

"Can you see if you can implement mitigation controls in the code based on the threats reported in the threat model"

Regenerate threat model based on code fixes

"Can you updated the threat model based on the code fixes which mitigated the reported threats"

More examples

# Set up context
"Set business context for an e-commerce payment system"

# Add architecture
"Add a web server component using AWS EC2"
"Add a database component using AWS RDS"

# Identify threats
"Add a threat where an attacker with network access performs SQL injection"

# Add mitigations
"Add a mitigation for input validation"

# Export results
"Export the threat model to my_model.tc.json"

Key Features

• Comprehensive Threat Modeling: Structured approach to identifying, evaluating, and addressing security risks

• Evidence-Based Code Validation: Records implementation evidence, updates statuses, and produces a deterministic report

• Business Context Analysis: Understand the business value and criticality of the system

• Architecture Analysis: Document the system's technical architecture and data flows

• Threat Actor Analysis: Identify potential adversaries and assess their capabilities

• Trust Boundary Analysis: Identify trust zones and validate security controls at boundaries

• Asset Flow Analysis: Track critical assets through the system

• Threat Identification: Systematically identify potential threats using STRIDE methodology

• Mitigation Planning: Develop strategies to address identified threats

• Compact Domain Managers: Action-based tools for assumptions, architecture, actors, boundaries, assets, threats, and mitigations

• Threat Model Guide: Step-by-step guidance through the threat modeling process

• Data Model Inspection: One tool for listing enum models and inspecting accepted values

Prerequisites

Before installing the Threat Modeling MCP Server, ensure you have the following requirements:

Installation Requirements

1. Install uvx from Astral or the GitHub README

   • uvx is part of the uv package manager

   • Verify installation: uvx --version

Installation

Once you have uvx installed and verified to be working, add the below configuation to your mcp.json config file. Depending on the what type of client your are using (kiro/cline/amazon-q) the location of this mcp.json will be different. Once you add the config and restart your IDE, the Threat Modeling MCP Server will be automatically be installed directly from this GitHub repository using uvx.

Note: The tools used by this mcp server for threat modeling are already added to the autoApprove for ease of user experience which enables seamless operation without manual approval prompts for each tool call. All tools are internal to the server and do not make external API calls. If you want to review each of the tools and approve it per invocation, then you need to replace the autoApprove array with this: "autoApprove": []

Configuration

Add the following to your MCP client configuration:

For Amazon Q (~/.aws/amazonq/mcp.json):

{
  "mcpServers": {
    "threat-modeling-mcp-server": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/awslabs/threat-modeling-mcp-server.git",
        "threat-modeling-mcp-server"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": ["manage_workflow","export_threat_model","manage_system_context","manage_assumptions","manage_architecture","manage_threat_actors","manage_trust_boundaries","manage_asset_flows","manage_threats","inspect_data_models","manage_code_validation"]
    }
  }
}

For VSCode Cline:

{
  "mcpServers": {
    "threat-modeling-mcp-server": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/awslabs/threat-modeling-mcp-server.git",
        "threat-modeling-mcp-server"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": ["manage_workflow","export_threat_model","manage_system_context","manage_assumptions","manage_architecture","manage_threat_actors","manage_trust_boundaries","manage_asset_flows","manage_threats","inspect_data_models","manage_code_validation"],
      "timeout": 60,
      "type": "stdio"
    }
  }
}

For Kiro (~/.kiro/settings/mcp.json):

{
  "mcpServers": {
    "threat-modeling-mcp-server": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/awslabs/threat-modeling-mcp-server.git",
        "threat-modeling-mcp-server"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": ["manage_workflow","export_threat_model","manage_system_context","manage_assumptions","manage_architecture","manage_threat_actors","manage_trust_boundaries","manage_asset_flows","manage_threats","inspect_data_models","manage_code_validation"]
    }
  }
}

Running with Kiro CLI

To run the MCP server via kiro-cli with all tools auto-approved:

kiro-cli chat --trust-tools="@threat-modeling-mcp-server/*"

This trusts all tools from the threat-modeling-mcp-server MCP server, so you won't be prompted to approve each tool call individually.

Running with the Custom Kiro CLI Agent

This repository includes a pre-configured Kiro CLI agent that covers nine numbered phases plus the optional Phase 7.5 code-validation step. The agent configuration is in .kiro/agents/threat-modeler.json.

Global install (available from any directory):

./install-kiro-agent.sh

To uninstall: ./install-kiro-agent.sh --remove

Local install (project-specific):

cp -r /path/to/threat-modeling-mcp-server/.kiro /path/to/your-project/.kiro

Usage:

# Non-interactive: run full threat model and exit
kiro-cli chat --agent threat-modeler --no-interactive "Threat model this project"

# Interactive: start a session with the agent
kiro-cli chat --agent threat-modeler

What the agent includes:

• System prompt (.kiro/prompts/threat-modeler.md): Detailed instructions for the phased STRIDE methodology

• Skills (.kiro/skills/): Per-phase reference materials, including optional Phase 7.5

• Auto-approved MCP tools: All threat modeling tools run without manual approval prompts

Output File Management

Before exporting, select the directory being threat modeled with manage_workflow(action="set_project", directory=...). The export tool always creates <selected-project>/.threatmodel/ and writes these artifacts there:

• <base>.tc.json: strict AWS Threat Composer JSON. This is the only file to import into Threat Composer. It holds only the standard schema keys, uses deterministic UUID ids, and applies Threat Composer's field length limits.

• <base>.md: the human-readable Markdown report with full text.

• <base>.extended.json: a separate server-state snapshot (architecture, taxonomy profiles, residual risk, phase progress) with internal ids and full text. It is not importable into Threat Composer. Pass include_extended_data=False to skip it.

The stored model keeps full text. When a field exceeds a Threat Composer limit, only the .tc.json copy is shortened, and the tool response lists each shortened field (by entity, field, and length) under "Export Warnings".

Omitting output_path uses a timestamped base filename. Supplying output_path selects only the base filename; absolute paths, parent traversal, and other directory components cannot redirect any artifact outside the selected project's .threatmodel directory.

Validation and analysis tools generally return text through MCP rather than writing report files. The exported files are snapshots; the server does not automatically reload them when a new process starts.

Quick Reference

Essential Tools for Getting Started

🚀 Step-by-Step Guidance

Recommended Approach: Use the consolidated guidance tool for one phase at a time:

Tools Overview

The Threat Modeling MCP Server provides 11 tools organized into the following categories:

Threat Modeling Methodology

STRIDE Framework

The server uses the STRIDE methodology for systematic threat identification:

Threat Modeling Process

The comprehensive threat modeling process includes these phases:

• Phase 1 - Business Context Analysis: Understanding the business value and criticality of the system

• Phase 2 - Architecture Analysis: Connecting every component and data-store node

• Phase 3 - Threat Actor Analysis: Identifying potential adversaries and their capabilities

• Phase 4 - Trust Boundary Analysis: Assigning every node to a zone and mapping inter-zone connections

• Phase 5 - Asset Flow Analysis: Tracking every critical asset through at least one flow

• Phase 6 - Threat Identification: Systematically identifying potential threats using STRIDE

• Phase 7 - Mitigation Planning: Linking at least one mitigation to every threat

• Phase 7.5 - Code Validation Analysis (optional): Recording implementation evidence for every threat and mitigation

• Phase 8 - Residual Risk Analysis: Recording a current decision, residual ratings, and rationale for every threat

• Phase 9 - Output Generation and Documentation: Exporting current JSON and Markdown snapshots

Each phase includes specific objectives, activities, and outputs to guide the threat modeling process.

Threat Severity Levels

• Critical: Immediate action required, system compromise likely

• High: Significant risk, should be addressed quickly

• Medium: Moderate risk, address in normal development cycle

• Low: Minor risk, address when convenient

Threat Likelihood Levels

• Very Likely: Expected to occur

• Likely: More likely than not

• Possible: Plausible given the right conditions

• Unlikely: Would require unusual circumstances

Mitigation Types

• Preventive: Controls that prevent threats from occurring

• Detective: Controls that detect when threats occur

• Corrective: Controls that respond to and correct threats

• Deterrent: Controls that discourage an attacker from attempting the threat

Assumptions in Threat Modeling

Assumptions are statements that we accept as true without requiring further validation. They help scope the threat model by establishing boundaries and constraints. Common examples include:

• "All network connections in the VPC are encrypted in transit"

• "AWS KMS keys cannot be discovered by brute force"

• "Nation-state threat actors are not a concern for this system"

By documenting assumptions, we can:

• Prevent generating pointless threats

• Avoid recommending unnecessary mitigations

• Focus on relevant security concerns

• Clearly document the scope and limitations of the threat model

Development

Contributing

To contribute to this project:

1. Clone the repository

2. Create a virtual environment with uv venv

3. Activate it with source .venv/bin/activate (Windows PowerShell: .venv\Scripts\Activate.ps1)

4. Install the package and test dependencies with uv pip install -e '.[test]'

5. Run the server locally with python run_server.py

6. Run tests with python -m pytest

Security

See CONTRIBUTING for more information.

License

This project is licensed under the Apache-2.0 License. See the LICENSE file for details.