Building Threat Models with MCP and AI Agents
A practitioner's guide to using AI agents and MCP to analyze your environment, map threats to attack paths, and identify detection coverage gaps
Welcome to Detection at Scale, a weekly newsletter on AI-first security operations, detection engineering, and the infrastructure that makes modern SOCs work. I’m Jack, founder & CTO at Panther. If you find this valuable, please share it with your team.
We hope you had a great start to 2026!
Threat modeling is the process of analyzing systems from an attacker’s perspective to prioritize defenses, monitoring, and countermeasures. It ensures that detection efforts are high-leverage and focused on preventing the next potential incident rather than reacting to whatever threat is trending this week.
In 2025, security leaders sent a resounding message: focus on the fundamentals, and that starts with understanding your highest-priority threats to the business. But what does modern threat modeling look like with AI at your disposal?
Security teams have historically been siloed and relied on peer expertise to understand how the business’s core systems work and where potential security flaws exist. With AI agents, security teams can gain direct access to context previously locked within engineering, product, and infrastructure teams. This is especially powerful in understanding what you’re protecting.
This post kicks off a series on using AI agents and Model Context Protocol (MCP) servers to build and operationalize threat models for security operations. We’ll use Claude Code and MCP servers to research, analyze, and gather data from your SIEM and organizational context to answer three critical questions: Where should we focus our detection efforts? What are our current blind spots? What should we do about them?
In this post, we’ll walk through generating a comprehensive threat model using AI agents. The subsequent post will show you how to hunt for active threats using that model and immediately formalize findings into detection-as-code rules. These workflows are generally repeatable across different AI agent tools, so you can adapt them to whatever’s in your stack.
Why Threat Modeling Matters for Detection Programs
Threat modeling defines your priorities as a security team. It answers the question: What’s most important to be monitoring for right now? Without this foundation, detection programs drift toward either alert fatigue (monitoring everything, prioritizing nothing) or reactive mode (chasing whatever threat made headlines this week). Both approaches waste the scarcest resources security teams have: time and attention.
Strong threat modeling creates a through line from detection to response. Each alert should be treated as a line item in your team’s time-and-attention budget. If you’re not confident that an alert maps to a real threat against a critical asset, you’re wasting that budget on noise. Slava Klimov from CoreWeave described this problem on the Detection at Scale podcast #71:
Security teams often build detection coverage based on what’s easy to instrument rather than what’s actually important to protect. The result is high-fidelity alerts on low-value assets and blind spots on crown jewels.
The traditional barrier to good threat modeling has been coordination.
Building a useful model requires input from engineering (what are we running?), product (what’s business-critical?), infrastructure (where are trust boundaries?), and security (what are the active threats?). AI agents with access to organizational context via MCP servers can now synthesize this information directly, removing the weeks of meetings and documentation review that made threat modeling a once-a-year exercise rather than a continuous practice.
The Five Contexts AI Agents Need for Threat Modeling
AI agents can only be as good as the context they’re provided, and threat modeling requires five distinct layers of intelligence that most organizations keep in separate systems. In a previous post on context engineering, we outlined four foundational layers for security operations. For threat modeling specifically, we need to expand this model to distinguish between detection posture (what we can see) and operational history (what we have seen).
Each of the following layers answers a critical question that informs where detection efforts should focus:
Identities and Assets tell you what exists and who has access to it. This layer includes user directories, service accounts, cloud resources, SaaS applications, databases, and APIs. For threat modeling, this context answers “What are we protecting?” and “What are the attack paths between assets?” An AI agent querying your identity provider and cloud environment can map trust relationships, identify privileged accounts, and surface shadow IT that traditional asset inventories miss.
Threat Intelligence provides the adversary perspective tailored to your industry and technology stack. This includes threat actor profiles actively targeting your sector (financial services faces different adversaries than healthcare) or MITRE ATT&CK techniques commonly used in your vertical. This context answers “Who attacks organizations like ours?” and “What techniques are they using against our sector right now?”
Logs and Detection Coverage reveal what you can currently see in your environment. This layer includes which log sources are instrumented (Windows Event Logs, CloudTrail, Kubernetes audit logs), data sources collected but not actively monitored, detection rules currently deployed and their MITRE ATT&CK mappings, and coverage gaps where you have no visibility. This context answers “What can we detect?” and “Where are our blind spots?” that map your theoretical detection capabilities against threat scenarios.
Alerts and Case History reveal prior security events in your environment. This layer includes SIEM alerts from the past N days, closed incident tickets and their root causes, false-positive patterns, and mean time to detect across different attack types. For threat modeling, this context answers “What have we seen before?” and “What’s generating noise versus signal?” This historical perspective prevents threat models from treating all scenarios equally, as your operational reality shows that specific attack paths recur while others remain more hypothetical.
Organizational Context connects technical assets to business criticality. This includes architecture documentation, data classification policies, revenue-impacting systems, compliance requirements, and deployment patterns (on-prem, cloud, hybrid). This context answers “What matters most to the business?” and “What’s the impact if this system is compromised?” Understanding which applications handle customer PII or which infrastructure supports your core product can prioritize threats based on business impact rather than technical severity scores.
Model Context Protocol makes these five layers accessible to AI agents through standardized interfaces. Instead of manually gathering context from a dozen different browser tabs or documents and synthesizing it, you can connect MCP servers to your agent and let it query across all five layers simultaneously. Security teams can choose from official integrations that either run locally or remotely.
Building the Threat Model with AI
Connecting your MCPs
Before you can generate a useful threat model, your AI agent needs access to the five context layers. At minimum, you’ll want to connect:
SIEM data (e.g., Panther) for log sources, detection rules, alert history, and query capabilities across your security data lake. This MCP server provides both read access to existing detections and the ability to run ad-hoc queries for threat hunting.
Ticketing and case management systems (Jira, Linear) to surface historical incident patterns and understand what your team has responded to before.
Documentation (Notion, Confluence) where application architecture, runbooks, and data classification policies live. This organizational context prevents the AI from treating all assets equally when some are clearly more critical than others.
Operational monitoring (Sentry, New Relic, CloudWatch) to understand which systems are customer-facing, which handle sensitive data, and where trust boundaries exist in your infrastructure.
The specific MCPs you’ll need depend on your stack, but the point is to give the agent read access to systems that hold context about your environment, threats, and detection posture. Claude Code supports MCP natively, and other AI agent frameworks are rapidly adding support.
Analyzing Your Internal Software
Most companies maintain internal software and services that serve as their revenue source. This context is crucial for threat modeling as it helps map specific components to attack techniques, identify necessary telemetry, and focus detection logic where it matters most.
The sample prompt below dissects these applications and pinpoints the most critical context for AI/SOC consumption, focusing on detection and response rather than application security.
Generate a security threat model for this codebase as a YAML file optimized for AI/SOC consumption. Focus on detection and response, not application security.
Structure it with:
metadata
architecture_components (with IDs, data sources, log verbosity)
data_flows (what’s visible to defenders, detection points)
trust_boundaries
authentication (what gets logged, session indicators)
sensitive_assets (crown jewels, business impact)
external_integrations (third-party attack surface, credential exposure)
log_sources (what telemetry exists, gaps, retention)
attack_paths (MITRE ATT&CK mapped: initial_access → persistence → lateral_movement → exfiltration, with TTPs and detection opportunities)
threat_scenarios (attacker objectives, kill chain stages, IOCs, forensic artifacts)
detection_coverage (which ATT&CK techniques are detectable, blind spots)
response_playbooks (containment actions, evidence preservation, escalation triggers)
monitoring_recommendations (alerts to build, threat hunting queries, dashboards).
Use explicit IDs, map to MITRE ATT&CK technique IDs where applicable, and identify visibility gaps.
Point the agent at your application repository and let it analyze the code, infrastructure definitions, and documentation. What you’ll get back is a structured system architecture that identifies potential areas of interest for an attacker, which will serve as a reference point for the next prompt to produce a prioritized threat model that considers broader organizational data sources.
Generating Organizational Threat Models
The organizational-level threat model takes a broader view, synthesizing business context, historical incidents, and threat intelligence to produce prioritized recommendations. This is where connecting to your SIEM becomes necessary. The agent needs to query your alert history, detection rules, and log sources to ground the model in operational reality.
This prompt positions the agent as a senior security architect conducting a comprehensive threat modeling exercise:
You are a senior security architect conducting a threat modeling exercise for [COMPANY_NAME]. Your goal is to produce a prioritized threat model covering current risks, controls, monitoring gaps, and historical activity.
Discovery
Business Context: Research the company’s industry, geography, technology stack, and what makes it a valuable target.
Assets & Identities: Query log sources, cloud environments, identity providers, and critical data stores.
Detection Coverage: Review active detection rules, MITRE ATT&CK coverage, alert volumes, and log sources without rules.
Historical Activity: Analyze the last 90 days of alerts for patterns, recurring issues, and unresolved items.
Interview
Interview me for additional context. I’m the [TITLE].
If available, request any internal application threat models or architecture documentation to incorporate org-level security findings (authentication flows, sensitive data inventory, third-party integrations, CI/CD pipelines).
Output
Produce a markdown threat model document that includes:
Executive summary with overall risk level
Critical assets ranked by business impact
Relevant threat actors based on industry/geography
Threat register with unique IDs (e.g., T-001, T-002), likelihood, impact, and mitigation status
Current security controls and monitoring coverage
Detection gaps mapped to ATT&CK where applicable
Prioritized recommendations (immediate, short-term, long-term)
Assign each identified threat a unique ID for tracking and reference.
The agent will conduct a back-and-forth interview to clarify organizational specifics. The resulting threat model included sections like this:
Business Context that identifies the company profile, industry positioning, and what makes it a high-value target.
Crown Jewels ranked by existential risk versus operational impact.
Threat Actor Analysis prioritizes relevant threat actors based on your industry and customer base.
Historical Incident Analysis based on the past 90 days of alerts from your SIEM.
Threat Register with unique tracking IDs for each identified threat. For example:
T-INSIDER-002: External contractor abuse of admin privileges
Likelihood: Medium | Impact: High | Risk: HIGH
Mapped to: T1078 (Valid Accounts)
Mitigation: [context-specific recommendations]
This structured output becomes a living document you can reference when prioritizing detection engineering work, conducting quarterly security reviews, or explaining risk to executives. The unique threat IDs enable tracking over time—you can note when T-INSIDER-002 gets addressed with new monitoring controls and update its status accordingly.
What to Look For in Your Threat Model
A useful threat model should tell you three things immediately:
Which assets matter most (crown jewels)
Which adversaries are relevant to your organization
Where detection gaps are mapped to actual attack techniques
If your threat model lists generic threats without tying them to your specific environment, the agent didn’t have enough context. Go back and ensure you’ve connected MCP servers or provide business context manually by typing it out in a stream of consciousness.
The most valuable output is the detection gap analysis—where the model explicitly identifies attack paths you can’t currently detect because you lack the necessary log sources or detection rules. These gaps become your prioritized backlog for threat hunting and detection engineering.
From Threat Model to Detection Priorities
The threat model you’ve just generated is the foundation for your detection engineering roadmap, monthly security reporting, and immediate threat hunting activities. With access to your SIEM, web search, ticketing systems, and internal documentation through MCP servers, AI agents can synthesize context that would typically require weeks of meetings across engineering, infrastructure, and security teams. The result is a living threat model with unique threat IDs and explicit detection gaps, aligning with what matters most rather than a static document that becomes stale the moment it’s published.
The natural next question is: are there signs of historical activity we missed? In the next post, we’ll use Claude Code and mcp-panther to hunt for evidence of these prioritized threats across your security data lake and immediately formalize successful hunts into detection-as-code rules. This workflow, from threat model to hunting queries to production detections, shows how AI agents compress what used to be month-long cycles into actionable security improvements you can deploy the same day.
Cover Photo by A Chosen Soul on Unsplash
What’s powerful here isn’t just MCP or agents — it’s the unification of business context with detection logic. Security has always failed when it optimizes for what’s easy to see instead of what’s actually costly to lose. This architecture finally makes that visible.