threat-modeling

Threat Modeling

Rules (for AI agents)

ALWAYS

• Produce a written list, not an impression. One row per finding, in the design doc, the RFC, or the PR description: (asset, boundary, threat, control, owner) — what is worth taking, where it crosses, what could go wrong there, what stops it, and which component enforces it. A model that exists only in the reasoning that produced the code cannot be reviewed, disagreed with, or checked later.
• Name the assets and the actors first: data, funds, credentials, keys and compute on one side; users, tenants, services, admins and the attacker on the other. Every later row references one of each, which is what makes the list finite.
• Locate the trust boundaries — internet to application, tenant to shared store, service to service, user input to an interpreter, model output to anything that acts on it. A boundary is where data arrives from a party you do not control, and it is the unit the rest of the model is organised around.
• At each boundary, ask the six STRIDE questions and write down only the answers that matter: can the caller be spoofed (is there authentication), can the data be tampered with in flight, will there be a record if someone repudiates the action, what is disclosed if this crossing leaks, what happens under denial of service, and does anything here allow elevation of privilege. A category with no answer is not a gap; a category nobody asked about is.
• Write down the assumptions the design depends on: this gateway is the only ingress, this queue's producers are authenticated, this field is already validated upstream, this CDN strips that header. Assumptions are the part of a threat model that later becomes false without anyone noticing, and an unwritten one cannot be rechecked.
• Rank the rows and say which ones block the design. A model that treats every threat as equally urgent gets implemented in whatever order the work happens to arrive, which means the ranking gets made anyway, by accident.
• Design controls to fail closed: on error, missing configuration, a timeout, or an unhandled case, the secure outcome is denial. This is a design property because the alternative is usually invisible in the code — an exception that skips a check reads exactly like an exception that skips a log line.
• Put each control at the component that owns the asset, behind any gateway rather than instead of it. The owning service authenticates and authorizes even when a perimeter also does, because perimeters get bypassed, reconfigured, and eventually routed around by the next service that needs direct access.
• Re-run the model when its inputs change — a new actor, a new boundary, a new data flow for an existing asset, a component moving between trust zones, or an assumption you wrote down turning out to be false. A model is a statement about a design, so it expires when the design moves.
• Route each control to the skill that owns it, and record that in the row's owner. auth-security owns who the caller is and what they may touch, api-security the endpoint's own controls, database-security how tenant isolation is actually enforced, iam-best-practices the privileges a workload runs with, and llm-app-security what a model's output is allowed to reach. This skill decides which controls the design requires; those skills say what the control is.