Threat Modelling and Adversary Frameworks

This chapter serves the activity of deciding what could go wrong with a system, who could make it go wrong and by what technique, and recording the answer so that a control and a test can be attached to it. It treats four kinds of tool: a small number of artefacts (the threat model as code, in three versions from three books, and the priority list of techniques); five methods for producing and reviewing threat models; the adversary frameworks and lists of AI security risks that give the models a shared vocabulary; and the software that supports the work. The tools come from Architecture as Code (1, Nordqvist, 2025), AI Platform and Security (3, Nordqvist, 2026), AI Red Team (4, Nordqvist, 2026), The Transformed Security Architect (6, Nordqvist, 2026), AI Blue (8, Nordqvist, 2026), AI Purple (9, Nordqvist, 2026) and AI Operations (10, Nordqvist, 2026), with entries inherited from AI Governance (2, Nordqvist, 2026).

The order of the chapter follows the order in which the tools are used, as Figure 10.1 shows. A framework supplies names. A method turns the architecture into candidate threats expressed in those names and puts a named reviewer in front of each. The artefact records the accepted threats with the controls that answer them, and a pipeline gate refuses a threat that has none. The tests that verify the threats, and the priority list that decides which techniques are tested first, close the loop. The chapter stays at the level the earlier volumes keep: threats are described as classes of behaviour and by technique identifier, never as operational recipes, and every red-team use named here is authorised, scoped by written rules of engagement and ends in a defensive improvement.

From framework to threat model to test

Figure 10.1: From framework to threat model to test. Frameworks name the threat, a method generates and reviews candidates, the threat model records them with controls, and tests give the model its evidence.

Adversary frameworks and vocabularies

A threat model is useful to the extent that other people can act on it, and that requires shared names. The Transformed Security Architect sets out five vocabularies and states the limit of each; the table is the compact form of that argument (6, Nordqvist, 2026).

Vocabulary What it contributes Limit
STRIDE Six categories of harm at a boundary Names the harm, not the route
Attack trees A goal decomposed into alternative and combined steps Costly; reserved for a few high-value goals
MITRE ATT&CK Adversary tactics and techniques against enterprise estates Not specific to AI
MITRE ATLAS Tactics, techniques and case studies for attacks on AI-enabled systems Young and still changing
MITRE D3FEND A knowledge graph of defensive countermeasures Families, not your configuration

The series' working rule is that STRIDE names the harm, ATT&CK and ATLAS name how an adversary produces it and D3FEND names what answers it. Two practices make the vocabularies work in a pipeline, and both are stated in The Transformed Security Architect, Chapter 6. The catalogue versions are pinned in the repository, and the build fails when a threat cites an identifier absent from the pinned version, because ATT&CK, ATLAS and the OWASP lists change between releases. The vector is recorded as a class of behaviour and never as a recipe: a threat entry says that instructions embedded in a claimant-supplied document could steer an agent and does not contain the instructions, which is enough to design a control, a detection and a test and keeps the model shareable with a supplier, an auditor and a works council.

MITRE ATT&CK
Kind Third-party tool (knowledge base of adversary tactics and techniques)
Origin Architecture as Code (Chapter 9B); AI Platform and Security, Chapter 16; AI Red Team (throughout); The Transformed Security Architect (throughout); AI Blue (throughout); AI Purple, Chapters 1, 2, 5, 9 and 17; AI Operations, Chapter 18
Purpose in the series Technique identifiers to describe adversary behaviour for threat models, to tag scenarios and detections, to map findings and to compute coverage.
Use when A threat names a vector against a conventional estate: a public endpoint (T1190), a valid account (T1078) crossing into production, unsecured credentials (T1552), impairing defences (T1562, which ATT&CK v19 revoked in favour of T1685 Disable or Modify Tools).
Limit of the series' claim ATT&CK is a vocabulary. It does not say whether a technique is relevant to a service, nor whether a detection exists.

ATT&CK is a publicly maintained knowledge base of adversary tactics and techniques (67, MITRE, n.d.). AI Red Team has the generator propose, for each applicable STRIDE category at each trust boundary, a threat expressed as an ATT&CK technique, so that detection engineers can check coverage and the red team can choose scenarios (4, Nordqvist, 2026). AI Operations uses it for the operator's own agents and estate: T1078 and T1552 for the access path to agent and pipeline identities, T1195.002 for the route into skills and tool servers, T1562 and T1070 for what follows (10, Nordqvist, 2026). AI Purple adds the discipline that a list is written against a stated release, recording the ATT&CK version in the priority list (attack_version) (9, Nordqvist, 2026).

MITRE ATLAS
Kind Third-party tool (knowledge base of adversarial techniques against AI-enabled systems)
Origin AI Governance, Chapter 21; AI Platform and Security, Chapters 3, 9, 16 and 17; AI Red Team (throughout); The Transformed Security Architect, Chapters 1, 6, 7, 10, 13, 15, 21 and 22; AI Blue, Chapters 1, 5, 15, 25 and 26; AI Purple, Chapters 5, 12 and 13; AI Operations, Chapter 18
Purpose in the series Technique identifiers against AI systems, used in threat models, red-team plans and scenario tags.
Use when A threat concerns a model, a retrieval index, an agent's tools or an AI supply chain.
Limit of the series' claim Described by the originating book as young and still changing; identifiers must be pinned and checked against a named data release.

ATLAS describes adversary techniques against machine-learning systems, with case studies (68, MITRE, n.d.). The identifiers that the series uses most are AML.T0051.001 for indirect prompt injection, AML.T0053 for AI agent tool invocation, AML.T0070 for RAG poisoning and AML.T0010.005 for AI agent tool compromise in the supply chain; AI Operations records that its identifiers were checked against data release 5.6.0, which is the model for how to record a pin (10, Nordqvist, 2026). AI Platform and Security observes that because Article 15(5) of the AI Act names the attack classes a high-risk system must resist (195, European Union, 2024), a threat model built on ATLAS and OWASP identifiers can show, entry by entry, that each class was considered (3, Nordqvist, 2026).

MITRE D3FEND
Kind Third-party tool (knowledge graph of cybersecurity countermeasures)
Origin AI Red Team, Chapters 4, 10, 19 and 21; The Transformed Security Architect, Chapters 6 and 10; AI Purple, Chapter 5
Purpose in the series Map building blocks to defensive techniques, state which countermeasure a scenario is expected to exercise, and support deception.
Use when A threat has been named by technique and the reader needs the matching class of countermeasure.

D3FEND is the countermeasure vocabulary (69, MITRE, n.d.). It names families of defence and not the organisation's configuration, which is the limit The Transformed Security Architect states, so a control in a threat model still resolves to deployed configuration in addition to a D3FEND label.

Top ATT&CK Techniques, the Center for Threat-Informed Defense and ATT&CK Navigator

Tool Kind Origin What the series uses it for
Top ATT&CK Techniques Third-party method and ranked list, published by the Center for Threat-Informed Defense, a research and development consortium operated by MITRE AI Purple, Chapter 5 A ranked list built on prevalence, common choke points and actionability, used as one of four sources for a priority list (74, Center for Threat-Informed Defense, 2024).
Center for Threat-Informed Defense (CTID) Third-party programme AI Purple, Chapters 5 and 17 The centre that publishes Top ATT&CK Techniques and Summiting the Pyramid. Entry for the centre only; the projects are described in Chapter 12.
ATT&CK Navigator Third-party open-source web application AI Purple, Chapter 17 Annotates ATT&CK matrices with layers, colours, scores and comments (205, MITRE, n.d.).

AI Purple is plain about the limit of the Navigator: it is a sensible tool for planning and a poor tool for asserting. A cell has room for a colour, and a colour does not say whether a rule exists, fired in a test or is current; the series' answer is a coverage record with evidence age, which belongs with the verification loop in Chapter 14 (9, Nordqvist, 2026).

Lists of AI security risks

The OWASP lists give the weaknesses seen in deployed applications and complement ATLAS, which gives the techniques. They are used to start a threat model and as a test plan.

Tool Kind Origin Purpose in the series
OWASP Top 10 for Large Language Model Applications (2025 edition) Third-party risk list AI Governance, Chapters 2, 10, 16A and 21; AI Platform and Security, Chapters 16 and 17; AI Red Team (throughout); The Transformed Security Architect, Chapters 6, 12 and 21; AI Blue, Chapters 8 and 15; AI Purple, Chapters 12 and 16; AI Operations, Chapters 15 and 18 A risk taxonomy from LLM01 prompt injection to LLM10 unbounded consumption, used to start a threat model and as a test plan (70, OWASP, 2025).
OWASP Top 10 for Agentic Applications for 2026 Third-party risk list AI Governance, Chapter 16A; AI Platform and Security, Chapters 16 and 17; AI Red Team, Chapters 10, 13 and 14; The Transformed Security Architect, Chapters 6, 7, 8, 13 and 21; AI Blue, Chapters 9, 10 and 15; AI Purple, Chapters 12 and 16; AI Operations, Chapters 15, 16 and 18 Risks of tools, delegated identity and multi-step autonomy; names loop amplification; a checklist against which an agent's tool set is reviewed (71, OWASP, 2025).
OWASP Non-Human Identities Top 10 (2025) Third-party risk list The Transformed Security Architect, Chapter 8 Failures shared by non-human identities, among them improper offboarding, secret leakage, overprivileged identities, long-lived secrets and the reuse of one identity across many workloads (72, OWASP, 2025). Mentioned in passing; the agent and identity chapters of Part VI return to it.
CWE-117 Improper Output Neutralization for Logs Third-party weakness class AI Operations, Chapter 18 Describes a product that builds a log message from external input without neutralising special elements. AI Operations uses it to state why a log line written in part by whoever controls the inputs is unsafe to read as an instruction, whether the reader is a person, a parser or a model (75, MITRE, 2026).

AI Red Team adds two cautions that apply to all of the lists. They are lists of observed weaknesses and so describe the past; and AI Platform and Security concluded that prompt injection is a property of the architecture and not a patchable defect, so a candidate whose mitigation is "improve the system prompt" is unsound, whereas least privilege for tools, allow-listed retrieval, output validation or human approval are in the right family (4, Nordqvist, 2026) (3, Nordqvist, 2026).

Threat modelling methods

Five methods from four books describe how a threat model is produced. They are listed first in the table and then the principal ones are described.

Method Origin Purpose Treatment
Threat modelling from code Architecture as Code (Chapters 9 and 9C) Regenerate models and attack trees from architecture code whenever it changes Below
STRIDE extended with ATLAS threat modelling AI Platform and Security, Chapter 17 Combine STRIDE categories with ATLAS techniques and OWASP identifiers per threat Below
AI-assisted STRIDE and ATLAS analysis AI Red Team, Chapter 10 Classify generated threats and review them for soundness Below
AI-assisted threat-modelling review on a pull request AI Red Team, Chapter 10 (practical guide) Run the review in the pull request with soundness checks and reviewer accountability Below
Generated threat models in eight weeks The Transformed Security Architect, Chapter 6 Introduce generated, reviewed and pipeline-enforced threat models for one system Below

Threat modelling from code

Architecture as Code (Chapter 9C) states the premise that the other methods build on: model systems according to principles such as those in the Threat Modeling Manifesto, with tools such as the Microsoft Threat Modeling Tool, but generate the models from the codebase. Diagrams and attack trees stored as Mermaid or Structurizr files are regenerated whenever the architecture code changes, and automated validation checks for missing trust boundaries, unclassified data stores or unmitigated threats (1, Nordqvist, 2025). The book's pull request templates require authors to link risk identifiers and threat model references for each change. The later volumes keep this premise and add the vocabulary and the review.

STRIDE extended with ATLAS

AI Platform and Security, Chapter 17, extends STRIDE because it names the harm but not the technique by which an adversary reaches a model or extracts what it holds. Each threat therefore carries a STRIDE category, an OWASP identifier and an ATLAS identifier. The book's rule is that every threat names a control, every control names a configuration, and a pipeline stage fails when a threat has no control or a control is absent from the deployed configuration; a code-ownership rule routes changes to the model's review_trigger paths to the security architect, so that the model is reviewed as often as the system changes (3, Nordqvist, 2026).

AI-assisted STRIDE and ATLAS analysis, and the review on a pull request

AI Red Team, Chapter 10, observes that the quality of AI-generated threats depends less on the model than on its vocabulary: free prose is plausible but hard to compare between versions, whereas entries classified by STRIDE, ATLAS or ATT&CK technique and OWASP identifier are searchable, stable and shared with the defenders who will test and detect them. The generator reads only architecture definitions, the accepted model and the catalogues, runs on trusted infrastructure, writes only to a pull request comment, and treats external threat reports as untrusted input, because a report crafted to make a path look harmless is an attack on the risk assessment itself (4, Nordqvist, 2026).

The review is where the method earns its place. The book's soundness checks give the reviewer seven questions, each answerable in about a minute, and an automated part for each.

Check Question the reviewer answers Automated part
Grounding Does the threat refer to a component, boundary, identity or flow that exists in this version? Every reference resolves in the architecture definition
Classification Are the STRIDE category, technique and OWASP identifier right for the vector? Identifiers exist in the pinned catalogue versions
Mitigation family Does the control act outside the model where the threat concerns model behaviour? Controls resolve to deployed configuration
Likelihood basis Which assumption or intelligence drives the likelihood, and is it current? Every likelihood cites a named assumption or dated object
Impact basis Is the impact tied to the inventory's criticality and classification? Impact matches or explains its deviation
Completeness Does every boundary changed in this pull request have threats considered? Changed boundaries without candidates are flagged
Stability Why did the score change since the last version? Diff against the previous accepted model

The completeness check catches the failure that a reviewer reading only the candidates would never see: a boundary that changed without any candidate threat. The practical guide fixes the roles (change author, named security reviewer, risk owner for residual-risk acceptance, the platform team running the generator) and the default values: a reviewer decision on every candidate within two working days, no merge with an unreviewed candidate, a ten per cent quarterly re-review sample, and a change of generator model treated as a change to the generator's own threat model. The reviewer is named, not a group alias, and the reviewer's workload is watched, because a reviewer who accepts every candidate in seconds is not reviewing. The defaults are the book's and are meant to be adapted to the organisation's capacity and risk appetite (4, Nordqvist, 2026).

Generated threat models in eight weeks

This method from The Transformed Security Architect, Chapter 6, introduces the practice for one system with high consequence, an existing architecture model and a nameable owner. Week 1 chooses the system; week 2 runs a half-day workshop whose output is the baseline for comparison; weeks 3 and 4 add security properties to the workspace, write down review triggers, fix the schema and pin the catalogue versions; week 5 adds the gate in report-only mode; week 6 adds the AI generator at Level 1 Assisted and runs it on the last ten merged pull requests to compare with the baseline; week 7 names reviewers and switches the gate to blocking; week 8 links each accepted threat to an attack case, runs the first purple loop and records the decision to extend or stop as an AI Decision Record. Its definition of done requires that the gate has blocked at least once for a real gap (6, Nordqvist, 2026).

Threat model as code
Kind Artefact
Origin AI Platform and Security, Chapters 16 and 17; AI Red Team, Chapter 10; The Transformed Security Architect, Chapter 6
Purpose Declare assets, trust boundaries, threats and linked controls for a system as a versioned file.
Use when For every system whose architecture is in code, regenerated or reviewed on every change that touches a trigger path.
Inputs Architecture definitions (for example a Structurizr workspace commit), the accepted model, pinned ATT&CK, ATLAS and OWASP catalogues, and structured threat intelligence as dated assumptions.
Outputs A versioned model with threats, reviewer decisions, controls with owners, and a pointer to the test that verifies each threat.
Identifier family kind: ThreatModel; threats T-nnn; boundaries TB-nn; controls CTRL-*
Full template The three books give different schemas of the same kind; see below

Three books define an artefact of kind: ThreatModel, and they differ in structure. AI Platform and Security wraps the model in apiVersion and metadata and lists review_trigger paths and a residual rating per threat. AI Red Team uses a flat file with decisionRecord, architectureCommit, proposedBy provenance, the reviewer's decision and reason, and a closure block naming the test. The Transformed Security Architect adds reviewTrigger, changedBoundaries, the legs line for the three conditions of an agent that holds private data, reads untrusted content and can communicate externally, a reclassified review decision, and verifiedBy on each threat. The Transformed Security Architect names the same artefact "Threat-model manifest" in its Appendix B. The volume that first defines the kind is AI Platform and Security, and the extensions of the later books are compatible with it; Chapter 25 records the differences.

The original form. Quoted from AI Platform and Security, Chapter 17, excerpt of the dispute assistant's model.

apiVersion: ai-architecture.example.org/v1
kind: ThreatModel
metadata:
  system: ai-system/dispute-assistant
  version: 2.3.0
  owner: cards-platform-team
  decision_record: AIDR-0087
  review_trigger: [retrieval_sources, tools, model_version, prompt_template]
trust_boundaries:
  - {id: TB-01, from: customer-channel, to: ai-gateway}
  - {id: TB-02, from: document-ingest, to: vector-index}
  - {id: TB-03, from: agent-runtime, to: dispute-api}
threats:
  - id: T-014
    boundary: TB-02
    stride: tampering
    owasp: LLM01
    atlas: AML.T0051.001
    vector: Instructions hidden in a merchant receipt uploaded to a case
    impact: Agent requests a refund the customer never asked for
    controls: [CTRL-RAG-003, CTRL-AGT-002, CTRL-GW-007]
    residual: low
controls:
  CTRL-RAG-003: Uploaded attachments indexed as untrusted with instruction stripping
  CTRL-GW-007: Output validated against the refund request schema
  CTRL-AGT-002: Refunds above threshold require case handler approval

Worked example: a threat model for a retrieval-augmented assistant

The example comes from AI Red Team, Chapter 10, and is marked illustrative there. It belongs to Nordvik Region's citizen-service assistant, the Mode 4 system that answers residents' questions from published information (AIDR-0014). The pull request that triggers the review adds a retrieval source, the disruption feed of a contracted public-transport operator. That creates a new trust boundary, because third-party content now enters the index that steers the assistant's answers. The generator ran on the Region's self-hosted capacity. The file below is quoted from the book, and its vector is a class of behaviour with no instruction text in it.

# Illustrative: Nordvik Region, threat model excerpt after PR 412
kind: ThreatModel
system: citizen-service-assistant
decisionRecord: AIDR-0014
version: 3.4.0
architectureCommit: 9f3c2e1
classification: classified-security    # public-access rules
trustBoundaries:
  - {id: TB-05, from: transport-operator-feed, to: retrieval-index}   # new
threats:
  - id: T-031
    boundary: TB-05
    stride: tampering
    owasp: LLM01
    atlas: AML.T0051.001               # indirect prompt injection
    vector: Instructions placed in disruption notices by whoever can write the feed
    impact: Residents receive misleading answers about services and contacts
    proposedBy: {generator: tm-generator@3.2, inputs: [9f3c2e1, atlas-pinned, owasp-2025]}
    review: {decision: accepted, by: nr-analyst-04, reason: feed is third-party writable}
    controls: [CTRL-CSA-021, CTRL-CSA-022, CTRL-CSA-007]
    residual: low
  - id: T-033
    boundary: TB-05
    stride: information_disclosure
    owasp: LLM02
    vector: Personal data of residents leaks into the operator feed
    review: {decision: rejected, by: nr-analyst-04, reason: feed flows inbound only}
controls:
  CTRL-CSA-007: Answers cite their source page; no actions on residents' behalf
  CTRL-CSA-021: Feed content indexed as untrusted data, never as instructions
  CTRL-CSA-022: Feed limited to schema fields; free text length-capped
closure:
  finding: T-031
  verifiedBy: NR-SEC-002 suite case csa-ind-017   # re-run passes

The rejected candidate stays in the file with its reason, so that the next regeneration does not raise it again and an auditor can see that it was considered. The accepted threat ends with the control that closes it and the test that verifies it: the red-teaming suite NR-SEC-002 gains a case that plants benign marker instructions in a test copy of the feed and checks that the answers are unaffected (4, Nordqvist, 2026).

The agent form. The Transformed Security Architect, Chapter 6, applies the artefact to Hansa Mutual's claims-triage agent, a Mode 5 system, and shows two things the earlier form lacks. The legs line records that the agent holds private data and reads untrusted content and that the architecture cuts the third condition by denying egress (control CTRL-NET-004); this is why threat T-103 (claim data leaves through an outbound channel) is rejected, and why its revisitWhen: tools field brings it back the day an outbound tool is added. And threat T-102 shows a reviewer correcting the generator: the agent proposed spoofing, and the reviewer reclassified it as elevation of privilege because the question is what the call may reach and not who the caller is. The model is version 6.2.0 and records the workspace commit it was generated from; each threat carries verifiedBy pointing to a case in the red-teaming suite HM-SEC-003 (6, Nordqvist, 2026).

The gate. The Transformed Security Architect also gives the pipeline rule that makes the artefact binding. Written in Rego, the policy language of Open Policy Agent, it takes the parsed model, adds the boundaries changed in the pull request, and denies the merge when an accepted threat has neither a control nor a risk acceptance, when a threat names a control that is not defined, or when a control has no owner. A threat without verifiedBy is classed as declared and not verified. Policy tools of this kind belong to Chapter 5, and the rule is cited here only because a threat model nobody enforces is, in the book's phrase, a document with better formatting.

Priority list
Kind Artefact
Origin AI Purple, Chapters 5 and 17, and Appendix A
Purpose List the 20 to 40 ATT&CK or ATLAS techniques that matter most for a service, with the reason for each, so that the loop verifies them first.
Use when Planning which scenarios to run; re-ranked when evidence changes.
Inputs The harm paths of the threat-register entries touching the service; technique tags of the last four quarters of intelligence; the organisation's own incidents and findings; public prevalence sources such as Top ATT&CK Techniques; the technique list of each service's threat model.
Outputs A signed list with tiers (impact, relevance, uncertainty, each 1 to 3), an emulation route, and the scenarios that test each technique.
Identifier family PRI-* (for example PRI-NR-2028-01)
Full template AI Purple, Appendix A, "Priority list for the benefits-triage service"

The list closes the gap between a threat model and a test plan. A technique in a threat model that is never selected for a scenario remains a belief. AI Purple makes the ranking a sum of three coarse ordinal tiers and not a score to the second decimal, sets review at six months and on triggers (a new threat-register entry, a major incident, a change in the estate), and keeps the detection owner from vetoing a technique, because the party being tested must not remove a test. It also asks for a check on selection bias: a quarter of the list should sit in the categories that need the red team or a mirror, because AI drafts tend to favour techniques that are well documented in public sources. The excerpt is quoted from the book, where it is marked illustrative (9, Nordqvist, 2026).

# priority/benefits-triage.yaml  (illustrative excerpt)
list: PRI-NR-2028-01
service: benefits-triage
attack_version: "v16"            # record the release the list was written against
review: { cadence_months: 6, next: 2028-07-31, triggers: [new-register-entry, major-incident, estate-change] }
accepted_by: ciso-nordvik
techniques:
  - id: T1110.003
    name: Password Spraying
    tiers: { impact: 3, relevance: 3, uncertainty: 1 }
    why: "Exposed staff portal; DET-NR-0001 passed last test"
    emulation_route: mirror
    scenarios: [SCN-NR-0001]
  - id: T1486
    name: Data Encrypted for Impact
    tiers: { impact: 3, relevance: 2, uncertainty: 3 }
    why: "Mirror only, irreversible if real; last run 2027-03-30, evidence expired"
    emulation_route: mirror
    hard_to_emulate: true
    scenarios: [SCN-NR-0009]     # expired evidence is shown as untested

Software that supports threat modelling

The inventory also contains software and principles that the series names in passing. None is developed by the originating books as a procedure; each is entered with its purpose and with what the originating book says of it.

Tool Kind Origin Purpose in the series Note
STRIDE Third-party classification scheme AI Red Team, Chapter 10; The Transformed Security Architect, Chapters 6 and 22 Six categories of harm at a boundary (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) Names the harm and not the route; used with a technique identifier (202, Microsoft, 2017)
Microsoft Threat Modeling Tool Third-party software Architecture as Code (Chapters 9 and 9C) STRIDE-based threat modelling tool Named as an example of a tool; the book generates models from code instead
Attack trees Third-party method The Transformed Security Architect, Chapter 6 Decompose a goal into alternative and combined steps Costly; reserved for a few high-value goals (206, Schneier, 1999)
Threat Modeling Manifesto Third-party principles AI Red Team, Chapter 10; The Transformed Security Architect, Chapter 6; cited in Architecture as Code Principles for continuous threat modelling A statement of principles and not a procedure (73, Threat Modeling Manifesto Working Group, 2020)
Threagile Third-party open-source toolkit The Transformed Security Architect, Chapter 6 Agile threat modelling toolkit Mentioned in passing (204, Schneider, n.d.)
OWASP pytm Third-party open-source framework The Transformed Security Architect, Chapter 6 Threat modelling as code in Python Mentioned in passing (203, OWASP, n.d.)

The Transformed Security Architect says that a team with a schema and deterministic rules can adopt an existing tool in week 4 (the book names Threagile and pytm) of the eight-week method instead of writing its own; the series does not rank them, and the choice depends on whether the tool can read the architecture workspace the organisation already keeps.

Across the usage modes

The usage mode decides who judges, with whose identity the AI acts, and therefore the dominant threat to model. The table is the one in AI Red Team, Chapter 10 (4, Nordqvist, 2026).

Mode Opportunity in risk assessment Characteristic vulnerability to model Who judges, with whose identity
Mode 0 Ambient AI Vendor AI scores risk without effort Automatic actions and scores the organisation cannot inspect The vendor's model, the product's identity
Mode 1 Conversational assistants Faster threat drafting and reading A misled person acting on a plausible wrong answer A person, own session
Mode 2 Embedded workplace assistants Risk summaries in everyday tools A summary that hides a critical path; injected content A person, delegated access
Mode 3 Agentic work tools Quick updates to architecture and threat models An agent acting with an engineer's credentials before review A person after the fact, engineer's identity
Mode 4 Built AI applications Generator and path ranker at estate scale Poisoned inputs steering scores Named reviewers, read-only service identity
Mode 5 Autonomous production agents Machine-speed risk models for machine-speed operations A manipulated or compromised machine insider Policy outside the agent and its operators, own identity

Mode 5 agents are modelled as well-meaning insiders that can be manipulated or compromised, so their permissions are scored as if an adversary held them. On the degrees of delegation, the generator and the ranker are kept low because their output is an organisational statement of risk: Level 1 Assisted is the default (the generator drafts and a named reviewer decides each candidate), Level 3 Bounded is limited to reversible housekeeping such as rescoring after an approved assumption change, and Level 4 Autonomous is not used, because no AI accepts a threat, a risk or an exception. The catalogues themselves do not differ by mode, but, in this chapter's reading, the entry that matters changes: the OWASP Top 10 for Agentic Applications and the Non-Human Identities Top 10 move to the front in Modes 3 to 5, where tools and delegated identity are the attack surface.

Nordvik Region and Hansa Mutual

Nordvik Region starts with the benefits-triage service and the citizen-service assistant, which carry the most personal data and consequence for residents. Their threat models live as code, candidates are generated on self-hosted capacity because the architecture's weaknesses are themselves sensitive, and one of the six analysts reviews each. Its first priority list for the benefits-triage service, PRI-NR-2028-01, holds nine ATT&CK techniques, among them valid accounts (T1078), password spraying (T1110.003), spearphishing link (T1566.002), exploitation of a public-facing application (T1190), account manipulation (T1098), data encrypted for impact (T1486) and impairing defences (T1562.001).

Hansa Mutual runs attack-path analysis across all seven markets, with a three-person threat-intelligence cell supplying the capability of AI-enabled adversaries as explicit inputs. The paths that matter most run through agents: its IT-operations agent, a Mode 5 system with write access to production, is modelled as a possible machine insider, and its claims-triage agent has the model of version 6.2.0 shown above. Its red-teaming suites are HM-SEC-003 and, for continuous automated red teaming of the estate, HM-SEC-004 (4, Nordqvist, 2026) (6, Nordqvist, 2026).

How many entries are treated

The inventory assigns 53 entries to this chapter: 4 artefacts, 5 methods and 44 third-party entries. The 44 third-party entries are largely repeats: MITRE ATT&CK, MITRE ATLAS and the two OWASP lists are each inventoried once per book that uses them, and this chapter treats each as one tool with the books that use it listed in its entry. The three ThreatModel entries are treated as one artefact with three forms. All entries are accounted for in the entries and tables above, and Appendix A holds every inventory line with its book and location.

Summary

This chapter's own conclusions follow. Frameworks and models do different jobs, and the series keeps them apart: ATT&CK, ATLAS, D3FEND and the OWASP lists name, STRIDE classifies the harm, the threat model as code records the accepted threats with owned controls, and only a test, named in verifiedBy, turns a threat from a belief into evidence. The threat model is useful when it is regenerated from architecture code on every relevant change, reviewed by a named person against defined soundness checks, and enforced by a gate that fails when a threat has no control; it is not useful as a workshop document. The priority list is the tool that connects the model to the test plan, and its main discipline is that expired evidence shows as untested. Three books define the same artefact with different schemas, which the reader should know when sharing a model between teams that follow different volumes. The catalogues change between releases, so every use of them is pinned to a version, and none of the tools in this chapter replaces the judgement of the reviewer who accepts, rejects or reclassifies a candidate.

Sources

  1. Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
  2. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
  3. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
  4. Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (4, Nordqvist, 2026)
  5. Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (6, Nordqvist, 2026)
  6. Nordqvist, G. AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (8, Nordqvist, 2026)
  7. Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
  8. Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
  9. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (67, MITRE, n.d.)
  10. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. (68, MITRE, n.d.)
  11. MITRE Corporation. MITRE D3FEND: A knowledge graph of cybersecurity countermeasures. (69, MITRE, n.d.)
  12. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (70, OWASP, 2025)
  13. OWASP Foundation. OWASP Top 10 for Agentic Applications for 2026. (71, OWASP, 2025)
  14. OWASP Foundation. OWASP Non-Human Identities Top 10, 2025. (72, OWASP, 2025)
  15. Threat Modeling Manifesto Working Group. Threat Modeling Manifesto. (73, Threat Modeling Manifesto Working Group, 2020)
  16. Center for Threat-Informed Defense. Top ATT&CK Techniques. (74, Center for Threat-Informed Defense, 2024)
  17. MITRE Corporation. CWE-117: Improper Output Neutralization for Logs. (75, MITRE, 2026)
  18. Microsoft. Threats – Microsoft Threat Modeling Tool (STRIDE model). (202, Microsoft, 2017)
  19. OWASP Foundation. OWASP pytm: A Pythonic framework for threat modeling. (203, OWASP, n.d.)
  20. Schneider, C. Threagile: Agile Threat Modeling Toolkit. (204, Schneider, n.d.)
  21. MITRE Corporation. ATT&CK Navigator. (205, MITRE, n.d.)
  22. Schneier, B. Attack Trees: Modeling Security Threats. (206, Schneier, 1999)
  23. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (195, European Union, 2024)