Use this when you need to systematically identify threats to a system -- when designing a new architecture, onboarding onto a client's system, preparing for a security review, or responding to a risk assessment request. Goes beyond feature-level security review to model threats across an entire system.

Related skills: Use /system-diagram for architecture input. Use /security-review for per-feature deep dives on high-risk components. Use /adr-generate for security architecture decisions. Use /architecture-discovery for domain boundary analysis.

Process

Step 1: Gather system context

Ask the user for:

• Architecture diagram or description (or run /system-diagram to generate one)
• Data flows -- what data moves where, in what format, over what protocols
• Trust boundaries -- where do privilege levels change?
• Authentication and authorization mechanisms
• External integrations (third-party APIs, SaaS dependencies, payment processors)
• Data sensitivity classification (PII, PHI, financial, public, internal)
• LLM and agent surface: any model calls, RAG pipelines, tool-calling agents, system prompts, vector stores, or multi-model routing. Note what reaches the model (user input, retrieved documents, tool outputs) and what the model can do (which tools, which scopes, which side effects).

If the user provides a description rather than a diagram, sketch a component list with data flows before proceeding.

Step 2: Identify trust boundaries

Map every point where data crosses a trust boundary:

• Client to server -- browser/mobile app to backend API
• Service to service -- internal microservice communication
• Internal to external -- calls to third-party APIs, webhooks
• User to admin -- privilege escalation boundaries
• Encrypted to unencrypted -- TLS termination points, decryption for processing
• Network zones -- public internet, DMZ, private subnet, database tier

Document each boundary with: source, destination, protocol, authentication method, data sensitivity.

Step 3: Apply STRIDE per component

For each component that sits on or crosses a trust boundary, analyze six threat categories:

Be specific about attack vectors. Not "the API could be attacked" but "an unauthenticated user could enumerate valid user IDs via timing differences in the login response."

Step 3b: Add the LLM and agent trust-boundary layer

If the system calls an LLM, runs a RAG pipeline, or hosts a tool-calling agent, STRIDE on the web app is not enough. An LLM cannot architecturally separate instructions from data: everything arrives as one token stream, so any untrusted text that reaches the model can act as an instruction. Model this layer explicitly using the 2026 OWASP Top 10 for LLM Applications and the parallel OWASP Top 10 for Agentic Systems.

For each model or agent on a trust boundary, work through these threat classes:

Treat every input that reaches the model as untrusted instruction surface, not just the obvious user prompt. Retrieved documents, tool outputs, fetched web pages, and prior-turn content all qualify. Roll the threats you find here into the same matrix in Step 4, tagged with their OWASP class in the description so reviewers can trace the lineage.

Step 4: Generate the threat matrix

Produce a table covering every identified threat:

| Threat ID | STRIDE Category | Affected Component | Threat Description | Likelihood (1-5) | Impact (1-5) | Risk Score (L x I) | Existing Controls | Residual Risk |
|---|---|---|---|---|---|---|---|---|
| T-001 | {{category}} | {{component}} | {{specific_attack_vector}} | {{1-5}} | {{1-5}} | {{score}} | {{current_controls}} | {{low/medium/high/critical}} |

Scoring guidance:

• Likelihood: 1 = requires nation-state capability, 5 = script kiddie with public tools
• Impact: 1 = minor inconvenience, 5 = regulatory action, mass data breach, business shutdown
• Risk score: multiply likelihood by impact. Critical >= 20, High >= 12, Medium >= 6, Low < 6

Step 5: Produce prioritized mitigations

For each threat rated high or critical, recommend a mitigation:

| Threat ID | Recommended Control | Control Type | Implementation Effort | Priority |
|---|---|---|---|---|
| T-001 | {{specific_control}} | Preventive / Detective / Corrective | S / M / L | {{P1-P4}} |

Every mitigation must be actionable -- include enough detail that an engineer could estimate and plan the work. "Implement rate limiting" is too vague. "Add per-IP rate limiting at the API gateway (100 req/min for unauthenticated, 1000 req/min for authenticated) with 429 responses and alerting at 80% threshold" is actionable.

Step 6: Annotate the data flow diagram

Mark the system diagram (or component list) with:

• Trust boundary lines (dashed borders around zones)
• Threat entry points (numbered, referencing threat IDs)
• Highest-risk components (highlighted)
• Data sensitivity labels at each flow

If starting from a text description, produce a labeled component diagram in Mermaid or ASCII.

Step 7: Review

Ask the user:

• Are there components or integrations we missed?
• Does the team have threat intelligence -- known attack patterns against similar systems?
• Are there compliance requirements that mandate specific controls (PCI-DSS, HIPAA, SOC 2)?
• What's the team's current security posture -- mature security practice or greenfield?
• Which threats feel most realistic given the organization's exposure?
• If the system uses an LLM or agent: are all instruction-bearing inputs (retrieval sources, tool outputs, fetched pages) accounted for, and is every tool the agent can call scoped to least privilege?

Output location

Deliver the threat model as a markdown document. Suggested filename: threat-model-{{system-name}}-{{date}}.md. Store in the project's security documentation directory or deliver directly to the requesting team.