What is a threat model diagram?

A threat model diagram is a data-flow diagram with trust boundaries drawn on it: the processes, stores and external entities, the flows between them, and dashed boxes marking where trust changes — the internet, the DMZ, the internal network. Threats are then listed per element, usually with STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.

How does Chiltepin draw a threat model?

The threatmodel block takes boundaries, nodes, edges and a threats table. The renderer draws the dfd shapes inside the dashed boundaries, marks every channel: plain hop, and lays the threats out as a table keyed to the node or edge each one targets, with the STRIDE letter, the mitigation, the severity and the status. chiltepin check validates every target and every enum.

Can an AI agent write the threat model?

Yes, and it is a good fit: the agent can read the actual request path and the actual stores, so the data flow is real rather than remembered. After npx skills add jdiejim/chiltepin -g the agent knows the block, runs chiltepin block threatmodel for the contract, and writes the boundaries, flows and threats. You review the threats; the schema has already checked the shape.

Is there a threat model template?

Yes — threat-model is one of the document templates that ship with Chiltepin: a finished threat model about a plausible system, with the diagram, the threats table and the mitigations, that you edit rather than fill in. Open it in the browser Studio at chiltepin.dev/studio?template=threat-model, or scaffold it locally with chiltepin new threat-model.

Why keep the threat model in the repository?

Because the system it describes changes in the repository. A threat model in a slide deck is right on the day of the review; one in docs/ changes in the same pull request as the new endpoint, and chiltepin check fails when a threat targets a node that no longer exists. That is the docs-as-code argument applied to security.

Guide

Threat model diagrams, STRIDE on the flow

A threat model diagram puts the security review where the attacker works: on the data flow, at the trust boundaries. Chiltepin draws it from a typed block — the shapes, the boundaries and the STRIDE table from one YAML body — so the model changes with the system instead of with the slide deck.

The block and its render

This is the threatmodel starter template. Boundaries are dashed regions on a grid, nodes take the data-flow kinds (external, process, store), and every edge names its channel. The threats table is keyed to a node or an edge by id.

```threatmodel
title: Login — STRIDE
boundaries:
  - { id: inet, col: 1, row: 1, cols: 1, rows: 1, label: Internet }
  - { id: dmz, col: 2, row: 1, cols: 2, rows: 1, label: Trusted network }
nodes:
  - { id: browser, col: 1, row: 1, name: Browser, kind: external }
  - { id: auth, col: 2, row: 1, name: Auth service }
  - { id: users, col: 3, row: 1, name: Users DB, kind: store }
edges:
  - { from: browser, to: auth, label: "POST /login", channel: tls }
  - { from: auth, to: users, label: SELECT by email, channel: internal }
threats:
  - { id: T1, target: browser, category: S, threat: Credential stuffing, mitigation: Rate limit + breached-password check, severity: high, status: mitigated }
  - { id: T2, target: auth, category: I, threat: Verbose error reveals whether the email exists, mitigation: One generic message, severity: medium, status: open }
  - { id: T3, target: users, category: T, threat: Password hash column altered by an admin, mitigation: Audit log + Argon2id, severity: high, status: accepted }
```

SECTION 01 · Threat model

Login — STRIDE

THREAT MODEL

Legendprocessexternal entitydata storetrust boundarytls (lock)internal

ID	STRIDE	Target	Threat	Mitigation	Severity	Status
T1	S	Browser	Credential stuffing	Rate limit + breached-password check	high	mitigated
T2	I	Auth service	Verbose error reveals whether the email exists	One generic message	medium	open
T3	T	Users DB	Password hash column altered by an admin	Audit log + Argon2id	high	accepted

Two trust boundaries, one TLS hop across them, and three STRIDE threats with a mitigation, a severity and a status each. chiltepin check rejects a threat whose target does not exist.

How to write one

Install the skill. Run npx skills add jdiejim/chiltepin -g once; the authoring skill lands in Claude Code, Cursor, Codex, Copilot and 70+ other agents.
Ask for the threat model. "Threat-model the login flow in docs/security/login.md: browser, auth service, users database, STRIDE per element." The agent runs chiltepin block threatmodel and writes the boundaries, the flows and the threats table.
Check it. npx chiltepin check reports an unknown target, a bad STRIDE letter or an unknown field with a stable code and the fix. The agent repairs it before handing off.
Render and review. npx chiltepin html docs/security/login.md -p opens the page. You review the threats and the mitigations; the diagram is drawn by the renderer, never the model.

One boundary per block, mitigations in the table

The skill teaches the two rules that keep a threat model readable: one trust boundary question per block (split a large system into one model per boundary) and mitigations in the table, not in prose, so the status column can say open, mitigated or accepted and a reviewer can scan it. When the question is the data flow rather than the threats, the skill picks a plain dfd; when it is what a review found, an audit.

Part of the security doc

A threat model rarely stands alone: the same document carries the sequence diagram of the login flow, the architecture it runs in and a checklist of the controls. Chiltepin renders all of it — a growing set of typed blocks, one grammar — from one Markdown source. See the threatmodel in the catalog, the quality & audits reference, or open the threat-model template.

Frequently asked questions

What is a threat model diagram?: A threat model diagram is a data-flow diagram with trust boundaries drawn on it: the processes, stores and external entities, the flows between them, and dashed boxes marking where trust changes — the internet, the DMZ, the internal network. Threats are then listed per element, usually with STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.
How does Chiltepin draw a threat model?: The threatmodel block takes boundaries, nodes, edges and a threats table. The renderer draws the dfd shapes inside the dashed boundaries, marks every channel: plain hop, and lays the threats out as a table keyed to the node or edge each one targets, with the STRIDE letter, the mitigation, the severity and the status. chiltepin check validates every target and every enum.
Can an AI agent write the threat model?: Yes, and it is a good fit: the agent can read the actual request path and the actual stores, so the data flow is real rather than remembered. After npx skills add jdiejim/chiltepin -g the agent knows the block, runs chiltepin block threatmodel for the contract, and writes the boundaries, flows and threats. You review the threats; the schema has already checked the shape.
Is there a threat model template?: Yes — threat-model is one of the document templates that ship with Chiltepin: a finished threat model about a plausible system, with the diagram, the threats table and the mitigations, that you edit rather than fill in. Open it in the browser Studio at chiltepin.dev/studio?template=threat-model, or scaffold it locally with chiltepin new threat-model.
Why keep the threat model in the repository?: Because the system it describes changes in the repository. A threat model in a slide deck is right on the day of the review; one in docs/ changes in the same pull request as the new endpoint, and chiltepin check fails when a threat targets a node that no longer exists. That is the docs-as-code argument applied to security.

Open the threat-model template Set up your agentnpx skills add jdiejim/chiltepin -g