Prompting for Threat Modeling: STRIDE Analysis With an LLM Co-Pilot

Most teams skip threat modeling. They know they should do it. They've read the frameworks. But the process feels like it belongs to enterprises with dedicated security architects and week-long design reviews.

It doesn't. STRIDE analysis is structured enough that a well-prompted LLM can do 80% of the heavy lifting. You describe your system, the model walks each component through six threat categories, and you get a threat model you can actually act on. The whole thing takes about 15 minutes.

Here's the exact workflow.

Why STRIDE Works So Well With LLMs

STRIDE breaks threats into six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Each category asks a specific question about a specific component. That structure is exactly what LLMs need to produce useful output instead of vague security advice.

The 2024-2025 State of Threat Modeling report found that 88% of surveyed organizations use STRIDE or align to it. It's the shared vocabulary of threat modeling. When you prompt an LLM with STRIDE categories, you get output that maps directly to how security teams already think and communicate.

Research from Carleton University (May 2025) tested five different LLMs on STRIDE classification tasks. Performance was comparable across all models. The differentiator wasn't which model you used. It was how you prompted it. A separate study on the ThreatModeling-LLM framework showed that combining structured prompting with fine-tuning nearly doubled accuracy at identifying mitigation codes, from 36% to 69% on Llama-3.1-8B.

The prompt matters at least as much as the model.

Step 1: Describe Your Architecture

Before you touch STRIDE, you need to give the LLM enough context about your system. Vague descriptions produce vague threat models. Be specific about components, data flows, trust boundaries, and authentication mechanisms.

Here's a prompt template for the architecture description:

You are a senior security architect performing a threat model review.

I will describe a system architecture. Your job is to:
1. Confirm your understanding of the system by listing all components, data flows, and trust boundaries
2. Identify any gaps in the description that would affect threat analysis
3. Ask clarifying questions before proceeding

System description:
[Paste your architecture description here]

List the components, their interactions, and where trust boundaries exist. Do not begin threat analysis yet.

This two-step approach (describe first, analyze second) prevents the LLM from rushing into generic threat lists. You want it to build a mental model of YOUR system before applying STRIDE.

Expected output: A structured list of components (e.g., "Web application (React SPA), API gateway (Kong), authentication service (OAuth2/OIDC), PostgreSQL database, S3 file storage"), data flows between them, and identified trust boundaries (e.g., "Trust boundary between public internet and API gateway, between API gateway and internal services").

Step 2: Run STRIDE Per Component

Once the LLM confirms it understands your architecture, hit each component with STRIDE. The key is prompting for one component at a time. Asking for "all threats to the entire system" produces shallow results. Asking for "all STRIDE threats to the authentication service" produces specifics.

Now analyze the [authentication service] using the STRIDE framework.

For each STRIDE category (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege):

1. Identify specific threats relevant to THIS component in THIS architecture
2. Rate each threat: HIGH / MEDIUM / LOW based on likelihood and impact
3. Propose one concrete mitigation for each threat
4. Note which data flows or trust boundaries are involved

Skip generic threats that don't apply to this specific system. I want threats that are specific to my architecture, not a textbook list.

Format as a markdown table with columns: STRIDE Category | Threat | Rating | Mitigation | Affected Flow

That last instruction ("skip generic threats") is critical. Without it, you'll get the same boilerplate STRIDE output for every system. LLMs default to comprehensive coverage. You want targeted analysis.

Expected output: A table with 8-15 specific threats. For an auth service, you'd see things like "Spoofing | Stolen OAuth tokens reused from compromised client app | HIGH | Implement token binding and short-lived access tokens (5 min expiry) | Client -> Auth Service flow" rather than generic entries like "Spoofing | Someone pretends to be a user | MEDIUM | Use authentication."

Step 3: Map Cross-Component Threats

Individual component analysis misses threats that emerge from how components interact. After you've run STRIDE on each component, prompt for the gaps between them.

You've now analyzed each component individually. Review the complete set of
component-level threats and identify:

1. Cross-component attack chains: Where compromising Component A enables
   attacks on Component B
2. Trust boundary violations: Where data crosses a trust boundary without
   adequate validation
3. Gaps in the individual analyses: Threats that only become visible when
   you look at the full system

For each finding, specify the attack path (which components, in what order)
and a mitigation that addresses the chain, not just individual links.

This is where LLM-assisted threat modeling earns its keep. A human analyst doing this manually would need to hold the entire system in their head and mentally trace every interaction. The LLM already has all the component analyses in context.

Expected output: 3-5 cross-component findings. Example: "Attack chain: Attacker exploits Information Disclosure in the API gateway (verbose error messages expose internal service names) to target a specific internal service with a known Tampering vulnerability (unvalidated JSON payload to the order processing service). Mitigation: Sanitize API gateway error responses AND add schema validation at the service layer."

Step 4: Generate the Deliverable

A threat model sitting in a chat window isn't useful. Prompt the LLM to structure everything into a format your team can review and track.

Compile all identified threats into a threat model document with these sections:

1. System Overview (2-3 sentences)
2. Component Inventory (bulleted list)
3. Trust Boundary Map (describe each boundary and what crosses it)
4. Threat Register (master table: ID | Component | STRIDE Category | Threat | Rating | Mitigation | Status)
5. Top 5 Priority Items (highest-rated threats that should be addressed first)
6. Assumptions and Limitations (what this analysis doesn't cover)

Set all Status fields to "Open". Number threat IDs as TM-001, TM-002, etc.
Output as markdown.

You now have a document you can paste into your wiki, convert to Jira tickets, or hand to a security reviewer. The numbered IDs make it easy to reference specific threats in code reviews and architecture discussions.

What This Misses (And What to Do About It)

LLM-generated threat models have real limitations. Google's Threat Intelligence Group reported in February 2026 that the biggest security gaps they see aren't exotic AI-generated attack vectors. They're basic hygiene: unpatched systems, misconfigured access controls, missing logging. An LLM won't catch that your staging database has the same credentials as production, or that nobody rotates the API keys.

Use the LLM output as a starting point, not a finished product. The 15-minute workflow gives you a structured draft that would take days to produce manually. But you still need a human to validate the ratings, check for threats the model missed because they depend on institutional knowledge, and prioritize based on your actual risk tolerance.

STRIDE GPT, an open-source tool built by Matthew Adams, a security leader at Citi, takes this workflow further with a dedicated interface. It accepts architecture descriptions, generates full STRIDE analyses, builds attack trees, and exports to CSV or JSON for ticketing systems. If you're doing this regularly, it's worth checking out on GitHub.

The field is also moving toward continuous threat modeling integrated into CI/CD rather than one-shot analysis. The Cloud Security Alliance published guidance on this in late 2025. As your architecture changes, re-run the prompts against the updated description. Keep the threat register as a living document.

Try It on Your Own System

Pick one system you're responsible for. Spend five minutes writing a plain-English architecture description. Run it through the four prompts above. You'll have a threat model draft before lunch.

The prompts work across Claude, GPT, Gemini, and Llama models. You may need to adjust the level of detail in your architecture description depending on the model's context window, but the STRIDE structure translates cleanly everywhere.

If your team wants to build threat modeling into your regular workflow, or you want hands-on training on security-focused prompt engineering, connect with Kief Studio on Discord (https://discord.gg/JfjyUdjJgP) or schedule a session at kief.studio/contact. We run live workshops where teams practice these exact techniques against their own architectures.