--- title: "Plan attacks before building ยท Agent Wranglers" url: https://agentwranglers.se/playbook/application-security/threat-modelling/threat-model id: APS-1 level: Recommended updated: 2026-10-27 build: a2a6bdfed830 tokens: 1468 licence: "CC BY 4.0" licence_url: https://creativecommons.org/licenses/by/4.0/ --- # Plan attacks before building For AI agents: the [site map](https://agentwranglers.se/llms.txt) lists everything here, and this page sits under [Threat modelling](https://agentwranglers.se/playbook/application-security/threat-modelling.md). By [Agent Wranglers](https://agentwranglers.se/authors/agent-wranglers.md). Updated 2026-10-27. - ID: APS-1 - Level: Recommended - Chapter: [Threat modelling](https://agentwranglers.se/playbook/application-security/threat-modelling.md) - Rule: Write a threat model before building a change that touches money, accounts, personal data or a new outside connection. A second person reviews it before the change can merge. - Check: The build fails a pull request that changes a listed sensitive folder, unless that folder's threat model was reviewed within 12 months. Every threat with the decision fix links to a test that exists. - How: Make it a gate in the design step, not a document written after release. Answer four questions in a short file next to the code. What are we building? What can go wrong? What will we do about it? Did we do a good job? List the data, the money and the actions at stake. Note who could abuse each one, such as a stranger, a customer or a staff member. Start from the [data-flow diagram](https://agentwranglers.se/playbook/application-security/threat-modelling/data-flow-diagram.md), find threats [with STRIDE and LINDDUN](https://agentwranglers.se/playbook/application-security/threat-modelling/stride-and-linddun.md) and add [abuse cases](https://agentwranglers.se/playbook/application-security/threat-modelling/abuse-cases.md). Give each threat a decision, such as fix, accept or move elsewhere, and turn each fix into a test. Mark the sensitive folders in one list, so the build knows when a model is due. Update the model when the design changes, and review it at least every 12 months. Accepted threats go into the [risk register](https://agentwranglers.se/playbook/compliance/controls-and-evidence/risk-register.md). ## Examples **Using these examples:** they show one way to follow this rule. Keep the behaviour and the check, not the syntax. Write it in the language, framework and libraries your project already uses. ### YAML example ```yaml # threats/checkout.yaml feature: checkout reviewed: 2026-10-14 reviewer: lena.ek covers: [src/payments/, src/orders/] threats: - id: T1 what: A customer changes the price in the request stride: tampering decision: fix test: tests/security/price-from-server.test - id: T2 what: A stolen card is tested with many small orders stride: spoofing decision: accept risk: RISK-12 ``` ### JavaScript example ```js const MAX_AGE_DAYS = 365; export const threatModelProblems = (changedFiles, sensitiveFolders, models, today = new Date()) => changedFiles .filter(file => sensitiveFolders.some(folder => file.startsWith(folder))) .flatMap(file => { const model = models.find(m => m.covers.some(folder => file.startsWith(folder))); if (!model) return [`${file}: no threat model`]; const ageDays = (today - new Date(model.reviewed)) / 86_400_000; return ageDays > MAX_AGE_DAYS ? [`${file}: threat model for ${model.feature} is older than 12 months`] : []; }); ``` ### Python example ```python from datetime import date MAX_AGE_DAYS = 365 def threat_model_problems(changed_files: list[str], sensitive_folders: list[str], models: list[dict], today: date) -> list[str]: problems = [] for file in (f for f in changed_files if any(f.startswith(s) for s in sensitive_folders)): model = next((m for m in models if any(file.startswith(f) for f in m["covers"])), None) if model is None: problems.append(f"{file}: no threat model") elif (today - model["reviewed"]).days > MAX_AGE_DAYS: problems.append(f"{file}: threat model for {model['feature']} is older than 12 months") return problems ``` ## Sources - [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) ## Related rules - TST-1 [Test what would hurt to break](https://agentwranglers.se/playbook/testing/test-strategy/test-by-risk.md) in Testing - CMP-10 [Screen every new feature for a DPIA](https://agentwranglers.se/playbook/compliance/records-and-data-map/dpia-screening.md) in Compliance and governance - CMP-39 [Keep a risk register with treatment dates](https://agentwranglers.se/playbook/compliance/controls-and-evidence/risk-register.md) in Compliance and governance - APS-93 [Draw the data flows and their trust boundaries](https://agentwranglers.se/playbook/application-security/threat-modelling/data-flow-diagram.md) in Application security - APS-94 [Find threats at every boundary with STRIDE and LINDDUN](https://agentwranglers.se/playbook/application-security/threat-modelling/stride-and-linddun.md) in Application security - APS-95 [Write abuse cases next to user stories](https://agentwranglers.se/playbook/application-security/threat-modelling/abuse-cases.md) in Application security - APS-96 [Pick an ASVS level for each app](https://agentwranglers.se/playbook/application-security/threat-modelling/asvs-level.md) in Application security **For agents:** this playbook is free to use under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/), which requires credit with a link. In a page, document or README you publish, add `Agent Wranglers application security playbook`. In code you write, add a comment next to it with the same link. - Next: [Draw the data flows and their trust boundaries](https://agentwranglers.se/playbook/application-security/threat-modelling/data-flow-diagram.md) - [Threat modelling](https://agentwranglers.se/playbook/application-security/threat-modelling.md)