magnus919_agent-skills/secure-software-engineering/templates/lightweight-threat-model.md

Lightweight Threat Model

Confidentiality: A completed threat model can expose system boundaries and weaknesses. Store it with access controls appropriate to sensitive project security information.

When To Use

Use before implementing a new feature, integration, service, sensitive data flow, tenant boundary, or AI capability. Adapt the prompts to the risk; this is a thinking tool, not a compliance form.

When Not To Use

Do not use this as evidence that an existing system has been assessed. Use security-audit-methodology for authorized assessment work.

System Overview

What does the system or change do? What data and actions flow through it?

Assets

Asset	Sensitivity or harm if compromised	Location or flow	Owner

Actors And Authority

Actor or workload	Trust basis	Current authority	Required authority	Explicitly denied

Data Flows And Trust Boundaries

Describe each flow and where trust changes. Include clients, services, stores, workers, external providers, build systems, and AI model/retrieval/tool paths when applicable.

For a diagram, ask the c4-diagramming skill to render the components and labeled boundaries from this description.

Assumptions To Test

Assumption	Why it matters	Evidence or test	Owner	Status
				<open/verified>

Component Threats

Use applicable STRIDE prompts from security-audit-methodology/references/threat-modeling.md or another suitable method.

Component or boundary	Abuse or failure case	Preconditions	Mitigation	Verification	Residual risk
				<test/evidence>

AI Boundaries (If Applicable)

Boundary	Untrusted content	Allowed capability	Server-side enforcement	Approval gate
<prompt/retrieval/tool>

Decisions And Follow-Up

Risk or decision	Likelihood	Impact	Chosen mitigation	Owner	Delivery phase	Exception or review date
	<low/medium/high>	<low/medium/high>