Skip to main content
Glama
awslabs

Threat Modeling MCP Server

Official
by awslabs

Threat Modeling MCP Server

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

Table of Contents

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

The export tool writes JSON and Markdown files to a .threatmodel directory next to the requested output path. The directory is created when an export runs. export_threat_model() uses the server's current working directory because it supplies a relative output filename.

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

Tool

Purpose

Example

manage_workflow(action="plan")

Get comprehensive plan

Start here for overview

manage_workflow(action="guidance", phase="1")

Get focused Phase 1 guidance

Recommended starting point

manage_workflow(action="status")

Check progress

Track completion status

manage_system_context(action, section, ...)

Define business context and taxonomy profiles

action="set", section="all"

manage_assumptions(action, ...)

Document and maintain assumptions

Start with action="describe"

manage_architecture(action, section, ...)

Manage components, data-store nodes, and connections

Start with action="describe"

manage_threat_actors(action, ...)

Assess and analyze threat actors

Use action="update" for relevance and priority

manage_trust_boundaries(action, section, ...)

Manage zones, crossings, and boundaries

Use action="detection_plan" for guidance

manage_asset_flows(action, section, ...)

Manage assets and flows

Sections are assets and flows

manage_threats(action, section, ...)

Manage threats, mitigations, links, and residual-risk decisions

Use action="assess" in Phase 8

manage_code_validation(action, values)

Record and report code-validation evidence

Start with action="describe"

export_threat_model()

Execute Phase 9 export

Generates JSON and Markdown snapshots

🚀 Step-by-Step Guidance

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

Phase

Tool

Purpose

1

manage_workflow(action="guidance", phase="1")

Business Context Analysis

2

manage_workflow(action="guidance", phase="2")

Architecture Analysis

3

manage_workflow(action="guidance", phase="3")

Threat Actor Analysis

4

manage_workflow(action="guidance", phase="4")

Trust Boundary Analysis

5

manage_workflow(action="guidance", phase="5")

Asset Flow Analysis

6

manage_workflow(action="guidance", phase="6")

Threat Identification

7

manage_workflow(action="guidance", phase="7")

Mitigation Planning

7.5

manage_workflow(action="guidance", phase="7.5")

Guided Code Validation (Optional)

8

manage_workflow(action="guidance", phase="8")

Residual Risk Analysis

9

manage_workflow(action="guidance", phase="9")

Output Generation and Documentation

Tools Overview

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

Category

Tools

Description

Workflow

2 tools

Plan and guide the workflow, track or advance phases, and export the result

System Context

1 tool

Manage business context plus software, data, user, and NFR taxonomy profiles

Domain Managers

6 tools

Manage assumptions, architecture, actors, boundaries, asset flows, threats, and mitigations

Data Model Types

1 tool

Explore available enum models and accepted values

Code Validation

1 tool

Record evidence, apply statuses, validate coverage, and render reports

Threat Modeling Methodology

STRIDE Framework

The server uses the STRIDE methodology for systematic threat identification:

Category

Description

Example Threats

Spoofing

Impersonating someone or something else

Authentication bypass, identity theft

Tampering

Modifying data or code

Data corruption, code injection

Repudiation

Claiming to have not performed an action

Log tampering, non-repudiation failures

Information Disclosure

Exposing information to unauthorized users

Data leaks, privacy breaches

Denial of Service

Denying or degrading service

Resource exhaustion, availability attacks

Elevation of Privilege

Gaining capabilities without authorization

Privilege escalation, unauthorized access

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.