The AI Threat Register: Governing Scenarios as Code

Parts II to V returned a verdict on each trope, but a verdict in a book protects nobody. Organisations need somewhere to keep their conclusions, a way to notice when the evidence changes and a route to the people who can act. Every chapter so far has pointed at the same artefact: the AI threat register, in which each threat scenario carries its scale, trope, evidence rung, label, exposure, controls, owner and triggers, and is reviewed by the right decision tier and reported to the board.

This chapter defines that register, which answers open question Q10, how a board should treat risks that are low in estimated probability, extreme in consequence and contested among experts, in a form that can be operated. It is not a forecast and not a ranking of fears, but a versioned record of what the organisation believes about each threat, why, who acts and which observation would change its mind.

Figure 32.1: A threat register entry starts as a precisely stated claim, is graded, labelled and owned, returns for review when a trigger fires and is closed with a note.

Table 32.1: The four decision tiers at which an entry is reviewed.

Tier	Forum
T1	Pipeline gate
T2	Design authority
T3	AI governance board
T4	Management body

A fired trigger can go straight to the management body. A reviewed change to the rung, the label or the controls returns to the evidence record; a closed entry is recorded in the calibration log.

From horizon register to threat register

AI Governance, Chapter 22, ended with a horizon register: a version-controlled file in which each trend in AI regulation, supervision and markets carried a label, the artefacts it affected, their reversibility and a decision (178, Nordqvist, 2026). An observable trend justified commitment, an expected one preparation and a speculative one reversibility, and the register was valuable because it could be wrong in a reviewable way. This book builds on that conclusion (F31). A threat register keeps the labels and the discipline, but four things change when the subject is harm rather than trend.

First, a threat has a victim and a path that can be interrupted, so an entry names its controls, the points where the organisation breaks the path (Chapter 11).

Second, a threat needs an owner who will act, not only watch: a named role holding the budget and authority for its controls. Architecture as Code (Chapter 9C) established that risk is a versioned record with likelihood, impact, owner and expiring exceptions, and that a failing control metric fails the pipeline (F2) (177, Nordqvist, 2025); the threat register inherits the ownership and the pipeline, but replaces the single likelihood with the rung and label that Chapter 4 argued a contested risk needs.

Third, the evidence must be graded, not only cited. A register that cited a laboratory demonstration of shutdown interference (118, Schlatter et al., 2026) beside a pattern at scale of discriminatory outcomes (103, Obermeyer et al., 2019) without saying which was which would invite the confusion of capability, propensity and harm that Chapter 4 identified as the most common error on both sides of the debate.

Fourth, the register must hold threats the organisation cannot influence, because boards ask about them, without letting them crowd out those it can act on; the influence field and reverse stress tests serve this purpose.

What belongs in the register

An entry belongs when four conditions hold: there is a plausible path to harm for the organisation, its staff or the people it serves; AI materially changes the likelihood, speed, scale or character of that harm, since otherwise it belongs in the ordinary risk register; the claim can be stated precisely enough to be graded on the evidence ladder, which means splitting broad fears until each part can be graded alone; and a role can be named to own it.

Tropes do not belong as entries: T5 The intelligence explosion is metadata on the specific scenario through which the organisation would be affected. Vulnerabilities and evaluation findings live in their own processes and are linked through controls and triggers, and a threat already in the risk taxonomy is linked rather than copied, so that it does not gain a second owner. The test of a good entry is that a reader who disagrees with it can say where: in the rung, the label, the exposure or the controls. An entry that states a mood rather than a scenario is not ready.

The schema

The schema of an entry is published as 32_CODE_SCHEMA in Appendix A and is validated in the pipeline, so that no entry reaches a board without a scale, a trope, a rung, a label, an owner and at least one review trigger. Chapters 18, 22 and 27 showed complete entries for AI-accelerated exploitation at Nordvik Region (THR-NR-02), reward hacking in Hansa Mutual's IT-operations agent (THR-HM-03) and systemic loss of control among frontier AI systems (THR-HM-09). The fields fall into four groups.

Identity and classification. The id follows THR-NR-NN or THR-HM-NN; the title names the actor, behaviour and what is affected; scale is one of the four scales and tropes lists one or more of T1 to T10, so the board can see whether the register spans every scale.

Evidence and outlook. The rung is the highest rung the evidence reaches, with evidence listing the records behind it. The label is recorded separately, because the same rung can support different outlooks (Chapter 4), and it sets the kind of decision the entry justifies.

Exposure and influence. The exposure field (low, medium or high) records how badly the organisation would be affected, given controls in place; the influence field (none, indirect or direct) records how far it can change the likelihood of the scenario itself. They lead to different actions: Hansa Mutual's THR-HM-09, systemic loss of control, has high exposure and no influence, so the group reduces its exposure through stop paths, second sources and manual procedures, whereas THR-HM-03, reward hacking in its own agent, has direct influence. Neither field is a probability. The schema deliberately omits one, because for most of the entries in Part V a single figure would record a choice between camps of experts rather than a measurement (55, Grace et al., 2024) (63, Karger et al., 2023).

Ownership and review. The controls field names the measures that break the harm path, each traceable to a decision record or control identifier. The owner is a role, so that the entry survives staff changes; decisionTier names the reviewing forum; triggers list the observations that reopen the entry; nextReview is the backstop date; and status is open, monitoring or closed. The schema forbids additional properties, so a new field is added through a reviewed change.

The decision tiers come from AI Governance, Chapter 13: routine decisions at pipeline gates, exceptions at a design authority, high-risk go-live at the AI governance board and risk beyond appetite at the management body (F11) (178, Nordqvist, 2026). In the register, the pipeline gate records routine updates, the design authority reviews medium-exposure entries, the AI governance board reviews entries tied to high-risk systems or production agents, and the management body reviews entries that could exceed risk appetite, including every high-exposure speculative entry. The tier is chosen by the exposure, not by how frightening the trope sounds.

Triggers and review

AI Governance, Chapter 8, concluded that classification is triggered by change, not by the calendar (F10) (178, Nordqvist, 2026). A calendar review asks whether anything has changed, and the honest answer is usually that nobody has checked. A trigger instead names in advance the observation that would change the entry, assigns someone to watch for it and reopens the entry when it occurs.

Good triggers are observable from a named source without interpretation, such as a new edition of the International AI Safety Report (50, Bengio et al., 2026). They are tied to the entry's grading, so that each corresponds to a change in rung, label, exposure or control adequacy. And they run in both directions: Chapter 27's entry for systemic loss of control includes a lowering trigger, the replication finding that shutdown interference vanishes under realistic set-ups. A register whose triggers can only raise concern drifts upwards with every news cycle and stops being believed.

Triggers fall into four kinds. Evidence triggers move the rung; for example, the July 2026 incident, in which agents under evaluation at OpenAI left their sandbox and compromised parts of Hugging Face's production infrastructure, was such a trigger for every register that held a scenario about agents acting beyond their mandate (133, OpenAI, 2026) (134, Larcher et al., 2026). Internal triggers come from the organisation's own systems, such as a failed stop-path rehearsal. Change triggers come from its decisions: a new model, agent, autonomy level or market. External triggers come from supervisors and peers, such as the European Central Bank's letter on AI-enabled cybersecurity threats (23, ECB, 2026).

When a trigger fires, the owner opens a reviewed change, normally a pull request, records the new grading or the reason for keeping the old one, and flags every entry relying on the same evidence record. The nextReview date remains as a backstop, because silence may mean the triggers watch the wrong signals.

Board reporting

The board report compresses the register to one page under three principles. Every number is shown with its rung and label, and the page never sums exposures into a score or presents a heat map, because both hide the difference between an observable threat with a measured rate and a speculative one with none. The page separates what the organisation can influence from what it cannot. And it reports movement rather than state, since a board that sees the same entries in the same colours every quarter learns to ignore them.

The page has five rows: one per scale and a fifth for the tail of speculative, high-exposure entries, shown separately so that they neither vanish nor dominate.

Row	What it shows	Example content for Hansa Mutual
Human mind	Entries, labels, triggers fired, overdue controls	2 expected; oversight metric within tolerance; no decision
Society and truth	As above	2 observable, 1 expected; disparity threshold breached at one release, release stopped
Humans wielding machines	As above	2 observable, 1 expected; ECB letter received, patch-velocity target confirmed
Machines beyond control	As above	2 observable, 1 expected; one fallback test failed, retest scheduled
Tail	Speculative entries, decision rule, leading indicators	2 speculation; no indicator moved; reverse stress test unchanged
Decisions asked for	At most three, each with cost and reversibility	Approve funding for second-source capacity under EXIT-004

The last row matters most, because a report that asks for no decisions is a briefing. For speculative entries the decision is usually to confirm the rule that only reversible measures are taken on the strength of the entry alone, as Hansa Mutual recorded in AIDR-0412 for THR-HM-09.

This is how the register answers Q10. A board treats such risks by declining to price them, testing whether the organisation would survive them through a reverse stress test, taking the measures worth taking anyway, naming the leading indicators that would change the label and recording dissent. The NIST AI Risk Management Framework makes the underlying point that the inability to measure a risk does not imply that it is either high or low (72, NIST, 2023), and its generative AI profile acknowledges that some risks are unknown, that the potential scale of generative AI is uncertain and that other risks are difficult to estimate (73, NIST, 2024).

Connecting to existing risk processes

A register that runs beside the other risk processes rather than inside them will be ignored, so it feeds three of them.

The own risk and solvency assessment

An insurer in the European Union assesses its risks and solvency needs in the ORSA required by Article 45 of the Solvency II Directive (182, European Union, 2009). Following Chapter 4, Hansa Mutual uses a pattern at scale for quantified modelling, an incident in the wild or a strong laboratory demonstration for scenario analysis, and argument alone for a reverse stress test. The register supplies the scenarios and the ORSA the financial consequences, linked through the group risk taxonomy. The speculative entries, THR-HM-09 and THR-HM-13, appear in the ORSA as reverse stress tests, not as priced risks.

For the group's EU entities, DORA requires an ICT risk management framework (Article 6) that manages ICT third-party risk as an integral part (Article 28) (11, European Union, 2022). The entries for AI-enabled intrusion, correlated provider failure and agents acting beyond their mandate are ICT risks in DORA's sense, so their controls, such as the stop-path rehearsals of Chapter 24 and the exit plan EXIT-004, belong in that framework too, with the same evidence serving both.

The NIS 2 risk analysis

NIS 2 requires essential and important entities to take all-hazards cybersecurity risk-management measures, including risk analysis, incident handling, business continuity and supply-chain security (Article 21), and makes their management bodies approve and oversee them (Article 20) (10, European Union, 2022). For Nordvik Region, within the national transposition, the entries on AI-accelerated exploitation (THR-NR-02), synthetic-media impersonation (THR-NR-03) and provider dependence (THR-NR-05) are inputs to the Article 21 analysis, which cites them rather than restating them; a trigger in the register reopens the corresponding section.

The AI risk classification

The AI Act requires providers of high-risk AI systems to operate a life-cycle risk management system (Article 9), deployers to use and monitor such systems according to their instructions (Article 26), and certain deployers, including bodies governed by public law and deployers of the insurance systems in Annex III point 5(c), to assess the impact on fundamental rights before first use (Article 27) (1, European Union, 2024). An entry tied to a specific system, such as THR-NR-04 on the benefits-triage system, lists the system's classification record (AI Governance, Chapter 8) among its controls, and a reclassification is also a trigger for the entry (178, Nordqvist, 2026). The register does not replace the Article 9 system or the Article 27 assessment; it holds the scenarios that cross systems, such as correlated provider failure.

The connections share one design rule: the register owns the scenario, the existing process owns its obligation, and each references the other by identifier, so that an auditor can follow a board decision to its evidence through the evidence manifest (F12) (178, Nordqvist, 2026).

Keeping the register honest

A register decays predictably: it only grows, its labels drift with the news, its owners stop reading their triggers and only its authors review it. Three practices counter the decay.

Closing entries. An entry is closed, with a note recording the reason and evidence, when its harm path no longer exists; Nordvik Region's removal of postcode features from its claims ranker (AIDR-0018) is the reference case. An entry with no trigger or control failure for two review cycles moves to monitoring.

Recording errors. At each review, the owner records whether the previous grading was borne out, for example a trigger that fired without changing anything or an event that should have been a trigger. These notes form a calibration log that the board sees yearly, showing whether the register is systematically too alarmed or too calm. In the long-run tournament reported by Karger and colleagues, disagreement between groups narrowed little after months of structured discussion (63, Karger et al., 2023); because argument alone rarely settles whose judgement deserves weight, a record of the organisation's own track record is valuable.

External challenge. Each organisation assigns a challenger who did not write the register and reports to someone other than its owner, such as internal audit, the second-line risk function or the actuarial function. The challenger tests whether each grading follows Chapter 4, whether any scale is neglected and whether the triggers would fire. Unresolved disagreements are recorded as dissent, as Hansa Mutual recorded the argument for labelling THR-HM-09 expected rather than speculation. The challenger also applies Perrow's lesson that failures often arise from interactions between components that each looked safe (165, Perrow, 1984), and Kasirzadeh's account of many smaller disruptions eroding resilience until a threshold is crossed (57, Kasirzadeh, 2025). Once a year the challenger therefore reads across entries for shared controls and correlated failures, the kind of reading that found, in Chapter 26, a fallback evaluation at Hansa that depended on the primary provider.

Practical guide: Setting up an AI threat register in a quarter

Purpose. Establish a working AI threat register, validated, owned, connected and reported once to the board, within thirteen weeks. Roles. A sponsor on the management body; a register owner (the CISO in a public authority, the chief risk officer in a financial group); entry owners; a challenger from internal audit or the second line; and a platform engineer.

1. Weeks 1 and 2: mandate. Record a decision record naming the sponsor, the register owner, the scope and the reporting line, and adopt the evidence ladder, labels and schema 32_CODE_SCHEMA unchanged for the first quarter.
2. Week 3: repository and pipeline. Create one file per entry in the governance repository, validate each against the schema on every change and block the merge on failure. Check that every trigger has a signal owner and no nextReview date has passed.
3. Weeks 3 to 5: harvest candidates from the risk register, incident records, evaluation findings, supplier assessments and the verdicts of Parts II to V. Expect to keep about a third, and run a workshop at each scale so that slower threats are not crowded out.
4. Weeks 5 to 7: state and grade. Apply the four inclusion conditions, split broad candidates, and grade and label each with an evidence record, recording the reasoning for the label separately from the rung.
5. Weeks 7 to 9: owners, controls and exposure. Assign owners by role, list existing controls by identifier, and record exposure and influence. Record gaps as findings rather than inventing controls.
6. Weeks 9 and 10: triggers and tiers. Give each entry at least two triggers, one internal where the organisation operates the system, and a lowering trigger for every speculative entry. Assign the tier by exposure and influence, with nextReview at six or twelve months.
7. Week 11: connect each entry to the risk taxonomy and, where they apply, the ORSA, the DORA framework, the NIS 2 analysis and system classification records.
8. Weeks 11 and 12: challenge. Give the challenger two weeks; resolve what can be resolved and record the rest as dissent.
9. Week 13: report the one-page summary to the management body with no more than three decisions, and record the quarter's lessons as the first calibration-log entry.

Definition of done. Every entry validates and has an owner, two triggers and a tier; every scale has been considered; speculative entries have a decision rule and a lowering trigger; and the management body has recorded its decisions. A public authority also publishes the register, with security details in a classified annex, under its public-access rules.

Worked example: The full threat register of Hansa Mutual

Illustrative. The register below is the compact view that Hansa Mutual's emerging-risk team generates for the risk committee from the thirteen entry files in the group governance repository. Each entry file carries the controls, evidence and triggers omitted here, as the full entries THR-HM-03 and THR-HM-09 in Chapters 22 and 27 show. The register owner is the chief risk officer, and the ORSA treatment of its speculative entries is recorded in AIDR-0412.

# threat-register/hansa-mutual.yaml - illustrative compact view; controls, evidence and triggers in entry files
apiVersion: ai-threat.example.org/v1
kind: ThreatRegister
metadata: {organisation: Hansa Mutual, owner: chief-risk-officer, assessment: ATA-HM-2026-01,
           decisionRecord: AIDR-0412, schema: 32_CODE_SCHEMA, reviewed: "2026-10-30"}
entries:
  - {id: THR-HM-01, title: Claims-triage agent acting beyond its approval rules, scale: machines-beyond-control,
     tropes: [T2, T4], rung: laboratory-demonstration, label: expected, exposure: high, decisionTier: ai-governance-board}
  - {id: THR-HM-02, title: AI-enabled intrusion into the group estate, scale: humans-wielding-machines,
     tropes: [T6], rung: incident-in-the-wild, label: observable, exposure: high, decisionTier: management-body}
  - {id: THR-HM-03, title: Reward hacking in the IT-operations agent on EU production, scale: machines-beyond-control,
     tropes: [T2], rung: laboratory-demonstration, label: observable, exposure: high, decisionTier: ai-governance-board}
  - {id: THR-HM-04, title: Deepfake-supported claims fraud and executive impersonation, scale: humans-wielding-machines,
     tropes: [T6, T10], rung: incident-in-the-wild, label: observable, exposure: medium, decisionTier: design-authority}
  - {id: THR-HM-05, title: Unfair outcomes from the underwriting-support model, scale: society-and-truth,
     tropes: [T7], rung: pattern-at-scale, label: observable, exposure: medium, decisionTier: ai-governance-board}
  - {id: THR-HM-06, title: Correlated failure of a shared model provider, scale: machines-beyond-control,
     tropes: [T8], rung: incident-in-the-wild, label: observable, exposure: high, decisionTier: management-body}
  - {id: THR-HM-07, title: Accumulation of AI-related losses across cyber and liability portfolios, scale: humans-wielding-machines,
     tropes: [T6], rung: argument, label: expected, exposure: high, decisionTier: management-body}
  - {id: THR-HM-08, title: Erosion of claims-handling skills, scale: human-mind,
     tropes: [T8], rung: laboratory-demonstration, label: expected, exposure: medium, decisionTier: design-authority}
  - {id: THR-HM-09, title: Systemic loss of control among frontier AI systems, scale: machines-beyond-control,
     tropes: [T5, T1, T3], rung: argument, label: speculation, exposure: high, decisionTier: management-body}
  - {id: THR-HM-10, title: Graduates who never learn underwriting and claims judgement, scale: human-mind,
     tropes: [T8], rung: laboratory-demonstration, label: expected, exposure: medium, decisionTier: design-authority}
  - {id: THR-HM-11, title: Synthetic photographs and documents in claims evidence, scale: society-and-truth,
     tropes: [T10], rung: incident-in-the-wild, label: observable, exposure: medium, decisionTier: design-authority}
  - {id: THR-HM-12, title: Unlawful discrimination by the underwriting-support model in a market, scale: society-and-truth,
     tropes: [T7], rung: pattern-at-scale, label: expected, exposure: medium, decisionTier: ai-governance-board}
  - {id: THR-HM-13, title: Pandemic losses aggravated by AI-enabled biological misuse, scale: humans-wielding-machines,
     tropes: [T6], rung: laboratory-demonstration, label: speculation, exposure: high, decisionTier: management-body}

The register spans all four scales, showing the risk committee that the group has not looked only at threats that make headlines. The rung and the label diverge where Chapter 4 said they would: THR-HM-12 rests on a pattern at scale of discrimination in automated judgement, yet is labelled expected because no unlawful outcome has been found in Hansa's own model, while THR-HM-13 rests on a laboratory demonstration and stays speculation, because the step from capability to harm is untested. Furthermore, the two speculative entries ask the board to confirm a decision rule rather than fund a control.

Nordvik Region and Hansa Mutual

Nordvik Region keeps nine entries, THR-NR-01 to THR-NR-09, owned by the chief information security officer and reported to the audit committee, which asked for the register in response to the council's motion. Its weight lies at the scales of the mind and of society, such as caseworkers' judgement, pupils' learning and residents' rights in the benefits-triage system, while its exposure to machines beyond control comes through suppliers (THR-NR-01 and THR-NR-05). The register is published under the Region's public-access rules, with the security controls for THR-NR-02 and THR-NR-03 in a classified annex, and regional internal audit acts as challenger.

Hansa Mutual integrates its thirteen entries into the group risk taxonomy and the ORSA; the chief risk officer owns the register and the actuarial function challenges it. It alone reaches financial modelling, because THR-HM-07 and THR-HM-13 are underwriting risks before they are operational ones, and its triggers include rulings in each of its seven legal regimes. The two registers differ in size, owner and audience but follow the same schema, which is why Chapter 33 can compare them entry by entry.

Summary

The AI threat register extends the horizon register of AI Governance from trends to harm: each entry is a scenario with a path to harm, an owner who will act and a grading on the evidence ladder. The schema omits a probability on purpose, separates exposure from influence and sends each entry to the tier its exposure demands, and review is triggered by change in both directions.

The board sees one page with five rows and at most three decisions, the operational answer to Q10: decline to price what cannot be priced, test survival through reverse stress tests, take the measures worth taking anyway, watch the indicators and record dissent. The register feeds the ORSA, DORA, NIS 2 and the AI risk classification by reference, and stays honest through closed entries, a calibration log and external challenge.

Chapter 33 draws the threads of the book together for Nordvik Region and Hansa Mutual, comparing their registers and stating what the answer to each governing body's question turned out to be.

Sources

1. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (178, Nordqvist, 2026)
2. Nordqvist, G. (2025). Architecture as Code. (177, Nordqvist, 2025)
3. Schlatter, J., Weinstein-Raun, B. & Ladish, J. (2026). Incomplete Tasks Induce Shutdown Resistance in Some Frontier LLMs. (118, Schlatter et al., 2026)
4. Obermeyer, Z., Powers, B., Vogeli, C. & Mullainathan, S. (2019). Dissecting racial bias in an algorithm used to manage the health of populations. (103, Obermeyer et al., 2019)
5. Grace, K. et al. (2024). Thousands of AI Authors on the Future of AI. (55, Grace et al., 2024)
6. Karger, E. et al. (2023). Forecasting Existential Risks: Evidence from a Long-Run Forecasting Tournament. (63, Karger et al., 2023)
7. Bengio, Y. et al. (2026). International AI Safety Report 2026. (50, Bengio et al., 2026)
8. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. (133, OpenAI, 2026)
9. Larcher, H., Carreira, A. et al. (2026). Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. (134, Larcher et al., 2026)
10. European Central Bank (2026). Addressing AI-enabled cybersecurity threats. (23, ECB, 2026)
11. National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). (72, NIST, 2023)
12. National Institute of Standards and Technology (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. (73, NIST, 2024)
13. European Parliament and Council of the European Union (2009). Directive 2009/138/EC on the taking-up and pursuit of the business of Insurance and Reinsurance (Solvency II) (recast). (182, European Union, 2009)
14. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (11, European Union, 2022)
15. European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (10, European Union, 2022)
16. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
17. Perrow, C. (1984). Normal Accidents: Living with High-Risk Technologies. (165, Perrow, 1984)
18. Kasirzadeh, A. (2025). Two types of AI existential risk: decisive and accumulative. (57, Kasirzadeh, 2025)