Threat Modeling

Pathrule1 Rule • 1 Memory • 2 Skills

Threat modeling is a repeatable design activity that asks what is being built, what can go wrong, what will be done, and whether the response is sufficient. This bundle maps data flows and trust boundaries, ranks concrete attacker paths, records decisions, and converts mitigations into owned tests. Unlike Web Security, it chooses and validates controls for a specific system before implementation instead of supplying request-layer defenses.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

run-threat-model

docs/

security/

Every material threat receives a recorded response

The model is a map of trust, not a diagram of components

review-threat-model

Rules

Every material threat receives a recorded response/docs/securityhighstrictThreats are mitigated, eliminated, transferred, or explicitly accepted with evidence and ownership.

1	Threats are mitigated, eliminated, transferred, or explicitly accepted with evidence and ownership. An unranked threat list creates the appearance of review while leaving the team unable to tell which risks block delivery. Enforce this boundary in /docs/security so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Describe the attacker capability, targeted asset, trust boundary crossed, preconditions, and plausible impact in system-specific terms.
4	- Choose a response and connect mitigation responses to a concrete requirement, implementation owner, and verification method.
5	- Require a named risk owner and review date for acceptance or transfer; developers cannot accept business risk by omission.
6	- Reopen the decision when data sensitivity, exposure, identity, dependency, or architecture assumptions change.
7
8	Verification: Sample every high-impact path and trace it from model to code or test evidence; fail review for orphan threats, orphan controls, and expired acceptances.

Memories

The model is a map of trust, not a diagram of components/docs/securityComponent boxes alone do not reveal where data changes authority, validation, ownership, or confidentiality.

1	Component boxes alone do not reveal where data changes authority, validation, ownership, or confidentiality. Show actors, assets, processes, stores, external systems, data flows, and trust boundaries, then annotate identity and protection on each crossing.
2
3	Split broad diagrams until reviewers can reason about one sensitive flow without guessing hidden hops. Include control-plane, support, recovery, CI, and third-party paths because attackers do not stay on the happy-path architecture. Record assumptions such as private-network reachability or upstream validation as testable dependencies, not facts. Keep the decision explicit at /docs/security; moving it into an incidental caller makes behavior depend on which route happened to execute first.
4
5	See /src/api for enforcement points and /infra for workload and network trust boundaries. That related boundary consumes this decision and carries the evidence that proves it still holds.

Skills

run-threat-model/rootRun a structured threat-model workshop and turn findings into owned, testable security work.

1	---
2	name: run-threat-model
3	description: Run a structured threat-model workshop and turn findings into owned, testable security work.
4	---
5
6	# Run Threat Model
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Define scope, assets, security objectives, attacker capabilities, and out-of-scope assumptions before discussing controls.
11	2. Draw data flows with identities, stores, external systems, protocols, and trust boundaries; walk one real scenario end to end.
12	3. Use STRIDE or another prompt set at each boundary, then write concrete abuse paths and rank them with product and operations input.
13	4. Choose responses, create mitigation requirements and verification tasks, assign risk owners, and schedule the next review trigger.
14
15	Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.

review-threat-model/docs/securityReview an existing threat model for architecture drift, unresolved risks, and ineffective mitigations.

1	---
2	name: review-threat-model
3	description: Review an existing threat model for architecture drift, unresolved risks, and ineffective mitigations.
4	---
5
6	# Review Threat Model
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Compare the model with current deployment manifests, routes, identities, stores, third parties, and privileged support or recovery paths.
11	2. Re-run abuse-path prompts for changed boundaries and identify assumptions that no longer have evidence.
12	3. Trace each open and high-impact threat to a current response, owner, test, monitoring signal, and acceptance expiry where relevant.
13	4. Publish the delta, create follow-up work with measurable outcomes, and record the event that will trigger the next review.
14
15	Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.

Why this pattern

Agents jump from a feature description to familiar controls without mapping assets, data flows, trust changes, attacker goals, or untested assumptions.

Built for Teams designing new services, sensitive flows, integrations, privilege changes, or major architecture revisions.

Keeps your assistant from:

Security reviews that list generic threats unrelated to the design
Mitigations with no owner, requirement, or verification method
Threat models that become stale after architecture and trust boundaries change

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25