Cover of AI Red Team

Book 4 · Teacher's guide

AI Red Team

Lectures, teaching plans, discussion questions, exercises and the answers to every self-test, on one page to print.

8 modules28 lessons

The course

All courses / AI Red Team / Teacher's guide

How to use this guide

The guide holds everything a teacher needs to run the course on AI Red Team: the lecture of each module with a timed outline, the teaching plan of every lesson, the discussion questions, the exercises and the answers to the self-tests. The agendas of the three formats are on the course page; the slides are in the deck of the book.

Keynote on the whole book · 45 minutes

AI as an active part of cyber defence: mandate, bounded autonomy and proof

For security leaders, architects, practitioners and decision-makers in European enterprises and public authorities

Attackers already use AI to find weaknesses, write convincing lures and run parts of an intrusion faster than a person can, so defenders cannot treat AI only as something to protect. This lecture presents the argument of AI Red Team in one sitting. AI strengthens defence across every CSF Function when it acts inside a written mandate, at an autonomy level matched to the reversibility of each action, on a platform where containment holds whatever anyone intends, under continuous verification, and in a purple loop that turns every finding into a verified control. Two fictional organisations show what that means for a small public authority and a multinational insurer.

6 minThe defender's position has changed
  • Exploitation commonly precedes the patch, and AI carries out operational work in some intrusions under human direction.
  • AI does not fundamentally change the techniques attackers use; it reduces the time required to combine them.
  • Active defence means AI doing work people cannot do at the required speed or scale, inside boundaries people set.
6 minA complete map and four rules
  • NIST CSF 2.0 with three AI focus areas keeps attention on all six Functions, not only detection and response.
  • The book is defensive; every offensive activity is authorised and scoped; AI that acts is contained; every finding ends as a verified control.
  • European obligations are mapped once to CSF outcomes, so a control assessed once serves every regime.
8 minWho decides: usage modes and autonomy levels
  • The usage mode says whose identity the AI uses; the autonomy level says who decides each action.
  • Autonomy is set per action and earned by reversibility, bounded blast radius, measured confidence and a decision of the right tier.
  • Mode 0 is the trap: vendor features may already act at an effective autonomy nobody in the organisation chose.
8 minEverything security AI reads may be written by the adversary
  • Alert fields, email bodies, log lines and threat reports are channels for prompt injection, which is a property of the architecture.
  • The ceiling on consequences is set outside the model: policy decision point, permission manifest, task-scoped credentials and a stop path people hold.
  • The red team's own AI is a system to contain, and the organisation's AI is red teamed as a compound system.
7 minRecover: where AI changes the economics most
  • Recovery is neglected because testing it is expensive; AI makes dependency mapping, sequencing and rehearsal cheap enough to repeat.
  • Restore from known-good definitions and choose the restore point in relation to the incident.
  • Fast, recently proven recovery takes the leverage out of destructive and extortion attacks.
6 minProof: chaos experiments and the purple loop
  • Controls fail silently when the estate changes; chaos experiments inject the conditions controls exist for and check steady-state hypotheses.
  • A finding is finished when the control that closes it has been re-tested, not when it is reported.
  • The CSF profile as code moves only with evidence and gives the management body the numbers the teams use.
4 minTwo organisations and where to start
  • Nordvik Region applied every conclusion without a single Mode 5 agent; Hansa Mutual earned Level 3 Bounded for two reversible actions.
  • Start with the mandate, then the inventory of what already acts automatically, then the evidence.

What the audience takes away

  • Decide and record the highest usage mode and autonomy level for security AI before choosing a tool, and name who holds the stop path.
  • Put the ceiling on what security AI can do outside the model, because its input is partly written by the adversary.
  • Treat every test, exercise, drill and incident as unfinished until the closing control has passed a re-test with evidence.

Module 1 · Part I · Foundations

Part I sets the ground for the whole course. Participants meet the argument that AI must become an active part of cyber defence, the evidence on how attackers use AI, NIST CSF 2.0 read through three AI focus areas and mapped to European obligations, and a reference architecture that places security AI on the governed platform. They leave with a labelled threat profile entry, a CSF profile entry and a placement decision for one security AI capability.

Lecture · 45 minutes

Foundations: from threat picture to a governed place for security AI

The lecture carries the argument of Part I in four moves. Exploitation now commonly precedes the patch and AI carries out operational work in some intrusions, so defenders must put AI to work under control. The evidence is read with labels, observable, expected or speculation, so that budgets follow what was seen. NIST CSF 2.0, read through three AI focus areas, gives a complete map into which European obligations are mapped once. Finally, security AI is AI: it belongs on the governed platform, behind the gateway and the policy decision point, with separated ranges for offensive capabilities.

8 minWhy AI must become an active part of defence
  • Three documented developments: the speed of exploitation, AI moving from aid to operator for attackers, and AI finding and patching vulnerabilities for defenders.
  • An attacker needs one path that works; a defender must close many while the window narrows.
  • Active defence does not mean handing the security operation to a model: AI works inside boundaries people set, at an autonomy level matched to the consequences of a mistake, with evidence.
10 minReading the threat evidence without headlines
  • Three bands of ATT&CK tactics by strength of evidence: observed at scale, reported in AI-orchestrated campaigns, tooling seen with limited evidence.
  • AI does not fundamentally change the techniques; it reduces the time needed to combine them, and current frameworks trade stealth for velocity.
  • Mean time to exploit estimated at minus seven days: the controls that matter for the exposed estate work before a patch is installed.
  • Every threat-profile entry is labelled observable, expected or speculation, and the label moves only on evidence.
10 minCSF 2.0 as the map, European law as the obligation
  • Six Functions, 22 Categories and 106 Subcategories describe outcomes, not controls; CSF is a framework, not law.
  • The Cyber AI Profile adds three questions to every Category: securing AI systems, AI-enabled cyber defence and thwarting AI-enabled attacks.
  • Assure once, comply many: one control mapped to NIS 2, DORA, the Cyber Resilience Act and the AI Act, with evidence distinguished from attestation.
  • Tiers describe risk-management practice as a whole and are not a maturity score for each Category.
12 minSecurity AI is AI: the reference architecture
  • Three placements: beside the platform, inside the vendor tool, on the platform; only the last keeps gateway, policy point, containment and evidence.
  • Six layers from telemetry to actions, with proposal, approval and execution kept in different components.
  • Security data is classified by content and model location is a routing rule at the gateway.
  • Four separated ranges, with the finding as the only route from the red range and the AI test range into blue tooling.
5 minThe four rules and the two organisations
  • The book is defensive, every offensive activity is authorised and scoped, AI that acts is contained, and every finding ends as a verified control.
  • Nordvik Region stretches a team of fourteen and keeps security data on capacity it controls; Hansa Mutual seeks bounded autonomy at machine speed across seven markets.

What the audience takes away

  • Plan for the exploitation window the evidence supports, and label every threat by evidence before it reaches the control budget.
  • Use CSF 2.0 with the three AI focus areas as one outcome map, so a control assessed once serves every regime that relies on it.
  • Place security AI on the governed platform and keep offensive capabilities in separated ranges whose only route to defence is the finding.

Chapter 1 · 60 minutes

Introduction: Putting AI to Work in Cyber Defence

The lesson introduces the book's thesis: because attackers use AI to find weaknesses and run parts of intrusions at machine speed, defenders must put AI to work under control. It presents the six CSF Functions, the three AI focus areas, the usage modes and autonomy levels, the three red threads and the four rules of the book, and ends with Nordvik Region's programme charter for AI-enabled defence.

Learning objectives

  • Explain the three developments that changed the defender's position and why a monthly patch cycle is structurally too slow for the exposed estate.
  • Distinguish the usage mode of a security AI capability from its autonomy level, and say why Mode 0 Ambient AI is called the trap.
  • State the four rules of the book and justify why they make AI-enabled red teaming acceptable to supervisors, works councils and boards.
  • Draft a programme charter that caps usage mode and autonomy by type of action and names who can stop any capability.

Key concepts

AI as an active part of cyber defence
AI does work people cannot do at the required speed or scale, inside boundaries people set, at a level of autonomy that matches the consequences of a mistake, and with evidence of what it did. It does not mean handing the security operation to a model.
Three AI focus areas
The perspective of the NIST Cyber AI Profile on every CSF Category: securing AI systems, AI-enabled cyber defence and thwarting AI-enabled attacks. The profile was published as an initial preliminary draft in December 2025.
Usage mode and autonomy level
The mode describes how the AI is deployed: where it runs, whose identity it uses and what it can reach. The level describes who decides each action, from Level 0 Advisory to Level 4 Autonomous, and belongs to a capability in a context, not to a model.
Three red threads
The usage modes paired with the autonomy levels; the purple loop, in which every finding ends as a verified control and the CSF profile is updated; and security chaos engineering, which injects the conditions a control exists for and checks the outcome.
Programme charter
The mandate for an AI-enabled defence programme. Nordvik Region's charter NR-SEC-PROG-2027 names the scope in CSF terms, the boundaries, the ceilings on usage mode and autonomy level by type of action, the decision rights and the evidence reported to the regional board.

Teaching plan

10 minThe teacher presents the three developments and the asymmetry between attacker and defender; participants name where their own patch and change cycles assume more time than the evidence allows.
15 minWalk through the table of the six usage modes in cyber defence and the five autonomy levels; participants place three security AI features they know in a mode and a level.
10 minDiscuss the four rules of the book and the European setting: NIS 2, DORA with threat-led penetration testing, the Cyber Resilience Act and AI Act Articles 15 and 55.
20 minExercise: participants draft a programme charter for AI-enabled defence in pairs, using Nordvik Region's charter as the model.
5 minPairs compare ceilings and stop holders; the teacher closes with the reading paths for different roles.

Discussion

  1. Which security products in your organisation already act automatically, and who decided the autonomy level at which they act?
  2. Why does the charter cap autonomy by type of action rather than by product, and what would change in a later argument for raising a level if it did not?
  3. What would a supervisor, a works council and a board each need to see before accepting AI-enabled red teaming in your organisation?

Exercise · 20 minutes

Draft a programme charter for AI-enabled defence

Using Nordvik Region's charter NR-SEC-PROG-2027 as the model, draft a charter for your own organisation or for Hansa Mutual. State the scope in CSF Functions and AI focus areas, list two or three initial capabilities with usage mode and autonomy level, and set the boundaries: defensive only, what offensive activity requires, what is out of scope, the maximum usage mode and the maximum autonomy level for offensive and for irreversible actions. Name who may raise an autonomy level and who can stop any capability, and say where evidence is reported.

Deliverable: A one-page programme charter with scope, initial capabilities, boundaries with ceilings by type of action, decision rights including named stop holders, and the evidence report line.

Self-test

  1. According to the chapter, what is the difference between the usage mode and the autonomy level of a security AI capability?

    1. The mode names the model vendor, while the level names the size of the model in use
    2. The mode describes how the AI is deployed, while the level describes who decides each action
    3. The mode describes who decides each action, while the level describes whose identity is used
    4. The mode is set by the AI Act, while the level is set by the NIST Cyber AI Profile
  2. Why does Nordvik Region's charter name the managed security service provider's shift lead among those who can stop any capability?

    1. Because the provider is the legal owner of the Region's alert data during the hours that it monitors
    2. Because NIS 2 requires that an external party holds every stop decision
    3. Because the provider built the SOC triage assistant and holds its credentials
    4. Because an alert is useless if it reaches people who do not hold the stop decision
  3. Which statement about Level 4 Autonomous is made in the chapter?

    1. It is never used for offensive or irreversible actions
    2. It is the normal level for Mode 1 Conversational assistants
    3. It is required for any agent with an identity of its own
    4. It is the ceiling Nordvik Region sets for containment

Chapter 2 · 75 minutes

The Threat Landscape When Attackers Use AI

The lesson builds the defender's threat picture from what was reported in 2025 and 2026, not from forecasts. Participants read the three bands of ATT&CK tactics by strength of evidence, the collapse of the exploitation window, and the observed attacks on AI systems mapped to ATLAS. They learn to label each threat observable, expected or speculation and to translate a threat profile entry into requirements per CSF Function under ID.RA Risk Assessment.

Learning objectives

  • Classify ATT&CK tactics into the chapter's three bands of evidence for AI acceleration.
  • Explain why a mean time to exploit below zero moves the weight to controls that work before a patch is installed.
  • Label threat claims as observable, expected or speculation and state how each label may be used.
  • Draft a threat profile entry with technique mapping, vantage points, requirements per Function and coverage links.

Key concepts

Three bands of evidence
Figure 2.1 shades ATT&CK tactics by the strength of the evidence that AI accelerates them: strong evidence of acceleration, reported in AI-orchestrated campaigns, and tooling seen with limited evidence. The bands describe evidence, not importance.
Exploitation window
The time between disclosure of a vulnerability and its exploitation. Mandiant measured an average of 63 days in 2018 to 2019 and 5 days in 2023, and M-Trends 2026 estimated the mean time to exploit at minus seven days, so exploitation now routinely precedes the patch.
Observable, expected, speculation
Observable: a named vendor, agency or incident responder reported the behaviour from activity it saw, which justifies controls now. Expected: assessed as likely or demonstrated in research, which justifies preparation. Speculation: a plausible extrapolation that belongs on the horizon register with an owner and a review date.
Vantage point of a source
Every report is partial. Providers see misuse of their own services and show the leading edge, which sets the direction of the threat; agencies' syntheses show the typical case, which sets the volume the defence must absorb today.
AI-aware threat profile
A short, versioned profile of the AI-enabled threats relevant to the organisation, each entry written by ATT&CK or ATLAS technique, labelled by evidence, translated into testable requirements per Function and linked to its risk-register entry, detections and emulation scenarios.

Teaching plan

15 minThe teacher traces the reporting from AI as a productivity aid to agentic offensive frameworks, and what the reports can and cannot see.
15 minParticipants sort a list of tactics into the three bands and discuss the Arup case as an attack on an approval process, not a system.
10 minReview the exploitation-window figures and the consequence for service levels: attack-surface reduction, virtual patching, segmentation, detection of exploitation attempts and redeployment.
25 minExercise: groups write and label one threat profile entry following the practical guide and the Hansa Mutual entry HM-TP-004.
10 minGroups present their label and its basis; the room challenges any entry that starts from the news and not from exposure.

Discussion

  1. The agentic frameworks of 2026 traded stealth for velocity. What does that offer the defender, and under which conditions is the offer lost?
  2. How should a threat profile treat a claim that rests on a single report from the provider whose model was misused?
  3. Humans still choose the targets and decide what to do with access. What does that imply for where defensive effort has most effect?

Exercise · 25 minutes

Write an evidence-labelled threat profile entry

Following the practical guide, write one threat profile entry for Nordvik Region or for your own organisation. Start from exposure: choose an internet-facing service, an approval process, a supplier access path or an AI system. Describe the threat by ATT&CK or ATLAS technique at the level needed to design a control or test, never as procedures. Label it observable, expected or speculation, cite the kind of source and its vantage point, record likelihood and impact, write one testable requirement per CSF Function, and link the entry to a risk-register entry, detections and an emulation scenario. Set the next review date and the triggers.

Deliverable: One threat profile entry in the structure of HM-TP-004: label with history, technique mapping, sources with vantage points, assets in scope, requirements per Function, coverage links and review triggers.

Self-test

  1. How does the chapter label the claim that fully autonomous intrusion pipelines operate in the wild?

    1. Observable, on the basis of several agency reports
    2. Speculation, held on the horizon register only
    3. Expected, not yet observed
    4. Observable, single case
  2. What does the chapter conclude from the Arup case of 2024 for the Protect Function?

    1. The control belongs in the process, through out-of-band verification and dual approval
    2. The control belongs in staff training, so that employees learn to recognise fabricated faces and voices
    3. The control belongs in the video-conference platform's own detection features
    4. The control belongs in faster patching of the finance department's systems
  3. GTIG reported that only 0.23 per cent of disclosed vulnerabilities were exploited. What does the chapter draw from that figure?

    1. That AI-assisted weaponisation of n-days has had no measurable effect
    2. That organisations can return to a monthly patch cycle without risk
    3. That zero-days are a negligible share of the exploited set
    4. That the small exploited fraction is the reason prioritisation works at all

Chapter 3 · 75 minutes

NIST CSF 2.0 with an AI Focus: Functions, Focus Areas and European Obligations

The lesson explains NIST CSF 2.0 as an outcome map: Functions, Categories, Subcategories, profiles and tiers, and what the Cyber AI Profile adds through three focus areas. Participants map CSF outcomes to NIS 2, Implementing Regulation 2024/2690, DORA, the Cyber Resilience Act and the AI Act, relate the profile to an ISO/IEC 27001 management system, and record a current and target profile as code, starting from GV.OC Organizational Context.

Learning objectives

  • Explain the difference between a Current Profile, a Target Profile and a Tier, and identify the heat-map anti-pattern.
  • Apply the three focus areas as three questions to one CSF Category.
  • Map one control to the obligations it serves in NIS 2, DORA and the AI Act, as the chapter attributes them.
  • Draft a Category entry of a CSF profile as code that distinguishes evidence from attestation.

Key concepts

Outcomes, not controls
The CSF Core is a hierarchy of outcomes: six Functions, 22 Categories and 106 Subcategories. DE.CM-01 says that networks are monitored to find potentially adverse events, but not which sensor or detection rules. CSF is voluntary and creates no obligation.
Profiles and tiers
A Current Profile records the outcomes achieved today and a Target Profile those chosen as priorities; the gap produces an action plan. Tiers, from Tier 1 Partial to Tier 4 Adaptive, describe risk-management practice as a whole and are not a maturity score for each Category.
GV.OC-03 as the bridge
The Subcategory on legal, regulatory and contractual requirements is achieved when each applicable requirement is linked to the outcomes and controls that meet it, with an owner and evidence, not by a list of laws on an intranet page.
Assure once, comply many
The principle from Architecture as Code: a control is written once, mapped to every obligation it serves and linked to evidence that it is enforced. NIS 2 Article 21(2)(j) and DORA Article 9 both map to PR.AA, so one assessment serves both regimes.
Evidence versus attestation
From AI Governance, Chapter 11: an attestation is a person asserting, while evidence is machine-generated. In the profile every claimed outcome is linked to evidence or marked as attested with person and date; a profile whose Protect and Detect outcomes are mostly attested has not yet been tested.

Teaching plan

15 minThe teacher presents the Core, profiles and tiers, and why a US framework earns its place only as a neutral vocabulary of outcomes.
10 minParticipants put the three focus-area questions to DE.AE Adverse Event Analysis and to one Category of their own choice.
15 minWalk through the mapping table by Function and the division of labour with ISO/IEC 27001: management system, shared control catalogue, outcome view.
25 minExercise: groups write one Category entry of a profile as code in the format of HM-CSF-2027.
10 minReview entries against the pipeline check: owner, evidence or attestation, gap with action, and an entry for each focus area.

Discussion

  1. Where does your organisation's current reporting to the board confuse tiers with a maturity score per Category, and what decision has that distorted?
  2. The chapter advises setting targets deliberately unevenly. Which Categories would you concentrate on first, and on what grounds?
  3. What changes for a customer when its managed security service provider is itself within the scope of Implementing Regulation 2024/2690?

Exercise · 25 minutes

Write a CSF profile entry as code

Choose one Category that matters to Nordvik Region or to your own organisation. In the format of the Hansa Mutual excerpt, record the owner, the current state and the target with a date on a documented internal scale, an entry for each of the three focus areas, the obligations the Category serves with instrument and article and whether each is law or group policy, the controls, and either a link to machine-generated evidence or an attestation with person and date. Add the gap and the action that closes it. Then state which of the four pipeline checks your entry would fail, if any.

Deliverable: One Category entry with current and target state, three focus-area entries, obligation references, controls, evidence or attestation, and a gap with an action.

Self-test

  1. What does the Cyber AI Profile add to CSF 2.0, according to the chapter?

    1. A seventh Function for artificial intelligence, placed at the centre beside Govern
    2. Four new Categories for model security under Protect and Detect
    3. A binding set of controls that deployers of high-risk AI systems must implement before go-live
    4. No Functions or Categories; it reads the existing outcomes through three focus areas
  2. Which practice does the chapter name as a familiar anti-pattern?

    1. Keeping the risk assessment and Statement of Applicability inside the ISMS
    2. A heat map with a number from one to four in every Category, presented as CSF maturity
    3. Recording the version of the Cyber AI Profile used, so that a later revision becomes a reviewed change
    4. Setting targets unevenly across the Categories of the profile
  3. In the mapping the chapter gives, where do DORA Articles 24 to 27 on resilience testing, including threat-led penetration testing, land in CSF?

    1. ID.IM Improvement
    2. GV.SC Cybersecurity Supply Chain Risk Management
    3. RS.MA Incident Management
    4. PR.AT Awareness and Training

Chapter 4 · 75 minutes

A Reference Architecture for AI-Enabled Cyber Defence

The lesson presents the reference architecture for AI-enabled cyber defence. Security AI is placed on the governed platform and inherits the AI gateway, the policy decision point, containment and evidence. Participants study the six layers from telemetry to actions, the classification of security data that decides where models may run, the four separated ranges and the mapping to MITRE D3FEND and CSF, with PR.PS Platform Security and PR.IR Technology Infrastructure Resilience as the responsible Categories.

Learning objectives

  • Compare the three placements of security AI and state what each loses.
  • Explain why proposal, approval and execution of an action are kept in different components.
  • Classify security data into the chapter's four classes and derive the permitted hosting for models.
  • Design the placement of a new security AI capability, including range, identity, containment profile and untrusted inputs.

Key concepts

Security AI is AI
A triage assistant, a containment agent and an adversarial test harness all call models, read content they did not write and invoke tools. They run on the governed AI platform under the same controls as other AI systems, not beside it.
Proposed, approved, executed
An action is proposed in the agent layer, approved in the approval service outside the agent, by a person at Level 1 and Level 2 or by a codified playbook at Level 3 Bounded, and executed by the tool gateway, which re-checks the policy decision.
Classes of security data
Public intelligence, restricted intelligence, operational telemetry and sensitive case data, classified by content and not by the tool that produced it. The gateway reads the class and routes the request only to serving the policy permits; sensitive case data is self-hosted only.
Separated ranges
Production estate, blue tooling, red range and AI test range, each with its own network boundary, identities, credentials, tooling and evidence store. The red range has no standing route into production or blue tooling, and the AI test range runs copies, never production instances.
Findings are the only route
The one sanctioned route from the red range and the AI test range into blue tooling is the finding, a versioned record closed by a control and verified by re-running the scenario. Offensive tooling never crosses, but the detections derived from it do.

Teaching plan

15 minThe teacher shows how security AI arrives by side doors and compares the three placements; participants identify which placement each of their current capabilities has.
15 minWalk through the six layers and the containment profile of HM-SEC-001: no credentials in the sandbox, alert content as untrusted data, an out-of-band stop path.
10 minReview the data classes with DORA Article 30(2)(b) and NIS 2 Article 21(2)(d) as architectural implications, then the four ranges and their routes.
25 minExercise: groups place a new security AI capability on the reference architecture using the eight steps of the practical guide.
10 minGroups state one chaos experiment that would verify their placement, with a steady-state hypothesis, and compare.

Discussion

  1. Why does the chapter argue that security AI needs the platform's controls more, not less, than other AI systems?
  2. The chapter says a capability that needs both a defensive and an offensive range is two capabilities. What practical difficulties does that separation create, and why accept them?
  3. In what sense is keeping alerts on controlled capacity a defence and not only a compliance matter?

Exercise · 25 minutes

Place a security AI capability on the reference architecture

Take a capability your organisation plans or runs, or Nordvik Region's SOC triage assistant NR-SEC-001. Follow the practical guide: name the capability, its usage mode and starting autonomy level; classify each data source by its highest class and derive the permitted hosting; choose the range; list read tools and action tools separately; write the main lines of the containment profile, noting any departure from the defaults of five-minute tokens, no standing privileges, default-deny egress, protected artefacts and an out-of-band stop path with named holders; declare untrusted inputs and where instructions may come from; and state the pre-production test, including indirect injection through representative alert content.

Deliverable: A placement record covering mode and level, data classes and hosting, range, tool lists, containment profile lines, untrusted inputs, the promotion test and the decision record that would accept it.

Self-test

  1. What is lost when security AI is placed beside the platform, with the security team running its own model endpoints and direct API keys?

    1. Only the visibility of the vendor's models and data flows
    2. Nothing essential; this is the reference placement
    3. Gateway, policy point, evidence and containment
    4. The ability to self-host models in a national data centre
  2. Under the default hosting in the chapter's class table, where may a model run on sensitive case data such as special-category data or employee investigations?

    1. On self-hosted serving only
    2. On self-hosted or EU-hosted serving under contract
    3. On any serving the analyst selects for the case
    4. On cloud serving if the request is pseudonymised
  3. Why do Mode 3 Agentic work tools used by detection engineers and red-teamers run only in isolated ranges?

    1. Because coding agents cannot be connected to the AI gateway
    2. Because the AI Act classifies coding agents used in security work as high-risk AI systems
    3. Because isolated ranges have more reserved model capacity
    4. Because an agent with an engineer's credentials should not hold any that reach production

Module 2 · Part II · Govern

Part II covers the Govern Function for AI in cyber defence. Participants write a risk appetite with autonomy ceilings per usage mode, assign usage modes and autonomy levels per action, turn policy into enforceable rules and signed rules of engagement, and extend oversight and supply-chain risk management to the AI that arrives inside products and managed services. They leave with four artefacts: an appetite statement, an autonomy-level decision record, a rules-of-engagement manifest and supplier assurance requirements.

Lecture · 50 minutes

Govern: who decides what security AI may do, and who can stop it

The lecture follows one chain of authority through Part II. The management body approves a risk appetite for security AI in three dimensions, error, autonomy and reversibility, and sets a ceiling per usage mode. Within the ceiling, a named authority assigns a level to each action, and human command is built from a stop path, an override log and measured approval quality. Policy makes the chain enforceable, with rules of engagement as the signed gate for all offensive work. Oversight then shows the management body what is actually in use, including supplier AI whose effective autonomy nobody in the organisation chose.

10 minContext and appetite: write it down or delegate it to vendors
  • The context record names AI the mission depends on, security AI the defence depends on, their suppliers, and adversaries who use AI.
  • Appetite has three dimensions: error tolerance on the organisation's own evaluation set, autonomy ceilings per usage mode, and reversibility with blast radius.
  • A ceiling is not the level a system runs at but the limit within which a level may be raised on evidence.
  • Assumptions built for slower adversaries are revised explicitly: time to exploit, trust in voice and video, volume, deterministic tooling and adversary speed.
12 minModes, levels and the line between Level 2 and Level 3
  • Red, blue, purple and white describe functions, not departments, and AI changes the work of each but not its accountability.
  • The level is set per action: one agent can enrich at Level 4 while its containment proposals wait at Level 2 Supervised.
  • Five factors decide the level: reversibility, blast radius, confidence, exposure to attacker-controlled input and the decision tier.
  • A Level 3 capability without a codified playbook enforced outside the model is Level 4 with a misleading label.
8 minHuman command by design
  • The interruption path sits outside the system it stops and its holders are named, including an out-of-hours provider's shift lead.
  • The override log and approval-quality metrics are the evidence that command is real; approvals given in seconds signal rubber-stamping.
  • The response to rubber-stamping is redesign, not blame.
10 minPolicy and rules of engagement as code
  • Three layers: a statement the management body approves, standards per usage mode, and enforceable rules at the gateway, policy decision point and pipeline.
  • Each mode has its own instrument, from supplier assurance for Mode 0 to permission manifests and rules of engagement for Mode 5.
  • Offensive AI capabilities are dual-use controlled assets: registered, restricted, bound to a mandate, contained, logged and limited in autonomy.
  • The policy decision point checks every AI-proposed action against the signed manifest, and an AI action outside the plan is a stop condition.
10 minOversight and the AI supply chain
  • The management body sees an inventory view, risk indicators and decisions requested, generated from records.
  • Effective autonomy is the level at which a supplier feature actually acts; undeclared, it is a supply-chain finding in its own right.
  • Providers, vendors and MSSPs each test their own part; only the deployer tests the compound system in its own context.
  • Version telemetry, canary sets and verdict-distribution monitoring catch the changes suppliers do not announce.

What the audience takes away

  • The management body sets autonomy ceilings per usage mode; a named authority raises individual actions within them on evidence, and anyone holding the stop path may lower them.
  • No offensive action, by a person or by AI, runs without a signed rules-of-engagement manifest that a policy decision point enforces.
  • Establish the effective autonomy of every supplier AI feature before relying on it, and reassess on change, not on the calendar.

Chapter 5 · 75 minutes

Organisational Context and Risk Strategy for AI in Cyber Defence

The lesson treats GV.OC Organizational Context and GV.RM Risk Management Strategy for security AI. Participants extend the context record with AI as asset and as adversary capability, write a risk appetite in three dimensions, error, autonomy and reversibility, set autonomy ceilings per usage mode, revise the risk assumptions that AI-enabled threats invalidate, and keep the whole as code with change-triggered review.

Learning objectives

  • Explain the difference between risk appetite and risk tolerance, and between an autonomy ceiling and a running autonomy level.
  • Identify the four additions the context record needs when AI is in scope.
  • Revise five risk assumptions built for slower adversaries and state the consequence of each for the strategy.
  • Draft a risk-appetite statement for security AI with ceilings per usage mode, error tolerances and review triggers.

Key concepts

Three dimensions of appetite
For security AI the appetite covers error, autonomy and reversibility. The appetite is a short statement the management body can read; the tolerances are numbers a pipeline can check, measured on the organisation's own evaluation set and not a vendor's benchmark.
Autonomy ceiling
The highest autonomy level that any security AI in a given usage mode may reach without a decision of the management body. Within it the AI governance board or the CISO may raise a level on evidence; above it, a proposal is risk beyond appetite.
Automatic step down
The named action on a breach of error tolerance: the level falls automatically by one until the owner has investigated. The chapter's default is a missed-threat rate of at most 2 per cent for anything at Level 2 Supervised or above.
Recognition is not verification
The revised assumption on synthetic media: for decisions that move money, change payees, reset credentials or approve security exceptions, the strategy requires verification through a channel the requester does not control.
Change-triggered review
The statement names its triggers, such as a new system, a model version change, a mode or level change, an incident, a red-team finding or a supplier change, and the pipeline opens a review when one fires. The calendar backstop only catches triggers the organisation failed to define.

Teaching plan

15 minThe teacher presents GV.OC with the four additions to the context record and the obligations table; participants list the security AI their own defence depends on, including ambient features.
15 minWalk through error tolerance, autonomy ceilings and reversibility, using the typical pattern of ceilings per mode and the two fixed limits.
10 minParticipants take the table of revised assumptions and mark which earlier basis their current strategy still rests on.
25 minExercise: groups write a risk-appetite statement for security AI following the seven steps and the Hansa Mutual statement HM-RAS-SECAI.
10 minGroups compare ceilings; the teacher shows how the chaos experiment verifies that a registered system or a supplier notice opens a review within one working day.

Discussion

  1. Why is an appetite that the CISO sets alone incomplete under the provisions of NIS 2 and DORA that the chapter cites?
  2. Hansa Mutual reports the tenth percentile of approval time as a risk indicator. What does it reveal, and what should the organisation do when it falls?
  3. The chapter records security AI as a strategic opportunity under GV.RM-07. How should a management body weigh the risk of using security AI against the risk of not using it?

Exercise · 25 minutes

Write a risk-appetite statement for security AI

For Nordvik Region or your own organisation, follow the practical guide. List the security AI in the context record, including Mode 0 features and a managed security service provider's AI, with usage mode, current level, owner and identity. Classify each one's actions as reversible within minutes on a single target, reversible with effort, or irreversible. State the appetite in one paragraph in terms of consequences, not technology. Set an autonomy ceiling per usage mode with the two fixed limits, set error tolerances for one use case with the step down on breach, and name the review triggers, the time within which a review opens and the calendar backstop.

Deliverable: A risk-appetite statement with an appetite paragraph, fixed limits, ceilings per usage mode, error tolerances for one use case, review triggers and the approving body.

Self-test

  1. What does the chapter mean by an autonomy ceiling?

    1. The autonomy level at which a given security AI system currently runs in production, as its decision record states
    2. The lowest level to which a system steps down after a breach of tolerance
    3. The highest level security AI in a given mode may reach without a decision of the management body
    4. The number of targets an agent may act on per hour under its playbook
  2. Why does error tolerance measured only on benign inputs overstate the performance of security AI?

    1. Because alert content can be crafted to steer the model, so behaviour under attack differs
    2. Because benign inputs are always more numerous than a vendor's benchmark set
    3. Because analysts review benign alerts more slowly than malicious ones
    4. Because benign inputs are excluded from evaluation by the AI Act
  3. In Hansa Mutual's statement, what does the entity override do?

    1. It lets entities outside the EU raise an agent to Level 4 Autonomous
    2. It exempts the Polish service centre from the group evaluation set
    3. It moves the approval of autonomy ceilings from the group AI governance board to each entity's local management
    4. It keeps the ceiling at Level 1 Assisted where employee representatives have not yet agreed

Chapter 6 · 90 minutes

Roles, Usage Modes and Autonomy Levels: People in Command of Security AI

The lesson supplies the vocabulary of the book under GV.RR Roles, Responsibilities, and Authorities: the red, blue, purple and white functions, the six usage modes through a security lens and the five autonomy levels. Participants learn to decide mode and level together per action using five factors, to give every machine identity an owner, operators and an authority, and to build human command from an interruption path, an override log and approval quality.

Learning objectives

  • Define the five autonomy levels and say who decides each action at each level.
  • Assess an action against reversibility, blast radius, confidence, exposure to attacker-controlled input and the decision tier.
  • Explain why the line between Level 2 Supervised and Level 3 Bounded is the most important in the scheme.
  • Draft an autonomy-level decision record that names owner, operators, authority and stop-path holders.

Key concepts

White team
The function that controls an exercise: it approves scope and rules of engagement, can pause or end the exercise, deconflicts red activity from real incidents and keeps the record. The white team, not the AI, holds the stop decision for an exercise.
Level 3 Bounded
The AI executes pre-approved, reversible actions within a codified playbook; a person is informed and can stop it. The playbook is written as code and enforced by a policy decision point outside the model.
Corroboration from a deterministic source
If the trigger for an action rests on content an adversary can write, Level 3 requires corroboration from a deterministic source, such as an endpoint detection, so that free text alone never triggers an action.
Owner, operators and authority
Every machine identity has an owner in a line role accountable for purpose, evaluation and residual risk; operators named through a rota who approve, watch and stop; and an authority that may raise the level within the ceiling. Lowering the level is open to every stop-path holder.
Human command by design
Three elements make command real: an interruption path outside the system it stops, an override log of every approval, rejection, modification and stop, and measured approval quality, with time to approval, rejection rate and later reversals per operator.

Teaching plan

15 minThe teacher presents the four team colours and the two zones of the usage modes: a person's identity in Modes 1 to 3, a machine identity in Modes 4 and 5 and in automatic Mode 0 features.
20 minWork through the autonomy-level table and the five properties; participants classify six example actions, from enriching an alert to disabling an account, by level.
15 minRead decision record AIDR-0311 together and trace each Level 3 condition to the factor it answers.
30 minExercise: groups write an autonomy-level decision record for one capability, action by action.
10 minDebrief on stop paths: who holds them at three in the morning, and how the chaos experiment shows the alert reaches them.

Discussion

  1. The chapter says that at Level 3 the approval moves from the action to the playbook, which concentrates accountability instead of diluting it. Do you agree, and what would make it untrue?
  2. Approval-quality metrics are themselves employee monitoring. How would you agree them with employee representatives and still learn what you need?
  3. How can an organisation keep analysts competent to supervise and to work in degraded mode when AI triages most alerts?

Exercise · 30 minutes

Assign mode and level per action in a decision record

Choose a security AI capability, for example Hansa Mutual's SOC investigation agent HM-SEC-001 or one in your organisation. List every action as a verb with an object. Determine the usage mode from the deployment. Assess each action against the five factors and the speed of the threat, and start at the lowest level that meets the need. Check each level against the autonomy ceiling. For any Level 3 action, write its conditions: corroboration, limits per period and exclusions. Name the owner, the operators, the authority that may raise the level, every stop-path holder including out-of-hours providers, the stop target and the review triggers.

Deliverable: An AI Decision Record in the structure of AIDR-0311: mode, identity, accountability, autonomy by action with Level 3 conditions, human command and review triggers.

Self-test

  1. At Level 2 Supervised, who decides each action?

    1. The AI decides within a playbook approved in advance, and a person is informed
    2. A person approves each action explicitly, and the AI then executes it
    3. A person reviews the AI's draft and then executes the action personally
    4. The AI selects and executes actions within bounds set in advance
  2. According to the chapter, what happens when a Mode 4 triage service is given write tools?

    1. It stays in Mode 4 but must move to Level 0 Advisory
    2. It becomes a Mode 3 Agentic work tool and is confined to sandboxes in isolated ranges
    3. It becomes Mode 0 Ambient AI from the SOC's perspective
    4. It moves to Mode 5, a change in governance that triggers reclassification
  3. What default evidence does the practical guide ask for before an action is raised to Level 3 Bounded?

    1. A vendor benchmark showing precision above the market average
    2. Thirty days of operation at Level 4 on read-only actions
    3. At least 200 evaluated cases with a precision of 0.9 or more
    4. A signed attestation from every operator on the rota

Chapter 7 · 90 minutes

Policy, Mandate and Rules of Engagement

The lesson covers GV.PO Policy: a security policy that reaches every usage mode in three layers, the European duties that make testing and monitoring obligatory, threat-led testing under DORA and TIBER-EU, the AI Act, data protection and labour law as they bear on security AI, acceptable use of offensive AI capabilities as dual-use controlled assets, and rules of engagement as a signed, versioned manifest enforced by a policy decision point.

Learning objectives

  • Match each usage mode to its policy instrument and state what the instrument fixes.
  • Explain the roles in a TIBER-EU test and the four places where AI enters a threat-led test.
  • Apply the six rules for offensive AI capabilities as dual-use controlled assets.
  • Draft a rules-of-engagement manifest with scope, AI participation, stop conditions and an out-of-band stop path.

Key concepts

Three layers of policy
A statement approved by the management body, standards that interpret it for each usage mode, and enforceable rules as code at the AI gateway, the policy decision point and the pipeline gates. One rule that refuses an out-of-scope tool call serves several obligations at once.
Policy instruments by usage mode
Supplier assurance for Mode 0, acceptable-use standards for Modes 1 and 2, a governed skills and connector catalogue for Mode 3, decision records for Mode 4, and permission manifests and rules of engagement for Mode 5. Policy for Modes 1 and 2 is about people; for Mode 5 it is about boundaries.
Dual-use controlled assets
Reconnaissance pipelines, vulnerability-discovery models, emulation agent frameworks and scenario libraries. They are registered and restricted, bound to a mandate, contained, logged, limited in autonomy and used only inside the perimeter of own or contracted systems.
Rules of engagement as code
A machine-readable manifest naming approvers including every target-system owner, window, parties, scope by ATT&CK tactic or ATLAS technique, AI participation, safeguards, stop conditions, an out-of-band stop path, deconfliction and evidence. A change during an exercise is a new signed version.
Rollout gate per legal entity
The architectural implication of works-council rights and AI Act Article 26(7): a monitoring capability, or an exercise touching employees' accounts or endpoints, goes live in an entity only once its consultation is recorded as complete.

Teaching plan

15 minThe teacher presents the three layers of policy and the instrument for each usage mode; participants check which modes their current policy does not reach.
15 minReview the duties to test and monitor in NIS 2 Article 21(2), DORA Articles 24 to 27 and the Cyber Resilience Act, then the TIBER-EU phases and roles.
15 minDiscuss when a security tool is an AI system and when it may be high-risk, and the six rules for offensive AI capabilities.
35 minExercise: groups draft a rules-of-engagement manifest for a threat-led exercise in which AI proposes actions, modelled on RoE-NR-2027-001.
10 minGroups exchange manifests and act as white team: each names one action the policy decision point should refuse and checks the manifest makes that refusal possible.

Discussion

  1. Why must rules of engagement be machine-readable and enforced when AI takes part, when a signed document was enough for a human red team?
  2. The July 2026 incident failed through correlated controls. Which three requirements does the chapter derive for rules of engagement, and how would you verify each before an exercise starts?
  3. Where would insider-threat analytics or user-behaviour scoring in your organisation meet Annex III point 4 of the AI Act and works-council rights, and what would the rollout gate need to record?

Exercise · 35 minutes

Draft rules of engagement for an exercise that uses AI

Draft a rules-of-engagement manifest for an authorised threat-led exercise against your own organisation's systems or Nordvik Region's citizen-facing services. Record the obligation the exercise serves. List systems in and out of scope, express permitted techniques by ATT&CK tactic or ATLAS technique only, and prohibit impact against production. Set AI participation: models and hosting, a maximum of Level 2 Supervised with each action approved by the test lead, credentials, egress and transcript logging. Write machine-detectable stop conditions, name the stop-path holders and the out-of-band channel, and define deconfliction, data-protection basis, classification, retention and the purple session that receives the findings. Do not describe procedures or tooling.

Deliverable: A signed-ready manifest in the structure of RoE-NR-2027-001, plus one dry-run out-of-scope action that the policy decision point must refuse.

Self-test

  1. Which provision does the chapter call the legal anchor for testing under NIS 2?

    1. The requirement in Article 21(2) for policies to assess the effectiveness of the measures
    2. The requirement in Article 23 for an early warning on significant incidents
    3. The requirement in Article 20 for members of management bodies to follow training
    4. The requirement in Article 4 that sector-specific acts take precedence
  2. Under the chapter's rules for offensive AI capabilities, which autonomy applies?

    1. Level 4 Autonomous inside the red range, Level 2 Supervised elsewhere
    2. Level 2 Supervised, or Level 3 Bounded for catalogued, reversible emulations in a standing programme
    3. Level 3 Bounded by default in the red range, with Level 4 Autonomous permitted for read-only reconnaissance steps
    4. Level 1 Assisted only, since AI may never execute an emulation step
  3. Why is the production scoring of the benefits-triage system out of scope in RoE-NR-2027-001?

    1. Because the contracted tester lacks a licence for that product
    2. Because high-risk AI systems are exempt from adversarial testing
    3. Because the system is hosted outside the EU and EEA
    4. So that the exercise cannot affect decisions about residents

Chapter 8 · 75 minutes

Oversight and AI Supply Chain Risk

The lesson covers GV.OV Oversight and GV.SC Cybersecurity Supply Chain Risk Management for security AI. Participants learn what the management body needs to see, how AI enters through models, AI services, security products and managed security services, how to establish a supplier feature's effective autonomy, who tests what among provider, vendor, MSSP and deployer, and how contracts, registers, exit plans and change-triggered reassessment keep supplier AI under control.

Learning objectives

  • Describe the three kinds of content an oversight report on security AI gives the management body.
  • Determine the effective autonomy of a vendor AI feature and compare it with the ceiling for its action class.
  • Distinguish what the provider, the vendor, the MSSP and the deployer each test, and what the deployer must require by contract.
  • Draft supplier assurance requirements for security AI covering declaration, control, change notification, evidence, incident and exit.

Key concepts

Effective autonomy
The level at which a supplier feature actually acts, whatever its marketing calls it. Establishing it needs three facts: where AI is used, which actions it takes without per-action approval, and whether they can be reversed. Undeclared, it is a supply-chain finding in its own right.
Testing the compound system
The deployer evaluates each feature on its own evaluation set built from historical alerts with known outcomes, red teams features that read attacker-controlled content and verifies behaviour with chaos experiments. Provider evidence is input to model selection, never a substitute for own testing.
Canary set
A fixed set of benign, labelled samples, 20 to 50 in the practical guide, submitted on a schedule and compared with the baseline. It detects a change in behaviour even when the version string stays the same.
Exit plan for security AI
The realistic exit is often a fall-back to the process without AI and not a move to another vendor. The plan says how the SOC works without the feature tomorrow and what moves with the organisation; switching it off for a day in a controlled test turns assertion into evidence.
Change-triggered reassessment
Reassessment is due for a new model version, a new AI feature, a change in the supplier's set-up or a change in the threat. Until it is complete, the safe default for a feature that acts automatically is to fall back to proposals at Level 1 Assisted.

Teaching plan

10 minThe teacher presents the decisions only the management body can take and the three kinds of report content: inventory view, risk indicators and decisions requested.
15 minWalk through the four supply elements and effective autonomy, using Nordvik Region's phishing-report classifier as the case.
15 minReview who tests what and the eight steps for assuring a vendor's AI feature, including the 30-day period at Level 0 or Level 1.
25 minExercise: groups write supplier assurance requirements for one security product or managed service, in the form of NR-SUP-SECAI-001.
10 minGroups state which technical signal would catch a silent model change in their case and which decision tier would handle it.

Discussion

  1. Why does an adversarially evaluated general-purpose AI model not answer the deployer's question about a triage feature that reads alert fields?
  2. A report that asks for nothing invites noting and not oversight. Which decisions on security AI would you put to your management body in the next quarter?
  3. For a public authority the tender is the moment of greatest leverage. What would you insist on in a tender that is hard to add to a framework agreement afterwards?

Exercise · 25 minutes

Write supplier assurance requirements for security AI

Pick one security product with embedded AI or a managed security service used by your organisation, or Nordvik Region's next SIEM tender. Write the assurance requirements in the five directions of the chapter: declaration of AI features, model provider and version, automatic actions, effective autonomy and processing location; control, so that automatic features are off until enabled, can propose instead of act, and log actions to your SIEM; change notification with days ahead and the status of an unnotified change; evidence and testing rights, including a canary set and red teaming under your rules of engagement; and incident and exit, including AI misbehaviour and what must be portable. State what you accept as attestation.

Deliverable: A requirements file with sections for declaration, control, change notification, evidence, incident, exit and review triggers, each key checkable in a tender response.

Self-test

  1. An email gateway removes a reported message from every mailbox on a classifier verdict, without an analyst approving. How does the chapter classify it?

    1. Level 1 Assisted, because the user reported the message first
    2. Level 3 Bounded or above, whatever its marketing calls the feature
    3. Level 2 Supervised, because the vendor supervises the model
    4. Level 0 Advisory, because the verdict is only a recommendation
  2. Which of the following can the deployer not test itself and must therefore require by contract and accept as attestation?

    1. Whether verdicts on a fixed set of benign samples drift over time
    2. Whether the feature's actions are logged to the deployer's SIEM
    3. The feature's results on labelled historical alerts with known outcomes
    4. The vendor's secure development process
  3. What is the cheapest technical signal for supplier model changes, which the chapter says should be required by contract?

    1. Version telemetry, where the product reports the model version behind each verdict
    2. Verdict-distribution monitoring on all live traffic, which catches every change with the least noise
    3. A quarterly attestation from the model provider that no model version has changed
    4. Manual comparison of the vendor's release notes with the features enabled in the console

Module 3 · Part III · Identify

Part III covers the Identify Function. Participants inventory an estate that includes models, agents, prompts, connectors and security AI; keep threat models and risk assessment continuous with AI drafting and named people deciding; manage vulnerabilities and exposure when every patch is an exploit specification; and run authorised adversary emulation and red teaming of their own AI systems and agents. Every finding in this part ends with the control that closes it and the test that verifies it.

Lecture · 55 minutes

Identify: know the estate, the paths through it and whether the controls hold

Identify is where the book places red teaming, because CSF puts improvements from tests and exercises under this Function. The lecture follows the dependency chain of the part: no assessment without an inventory in which agents are recorded with identity, permissions and untrusted inputs; no ranking of paths without that inventory; no patch priority without exposure. It then turns to authorised emulation at the tempo of an AI-enabled adversary and to red teaming the compound AI system. The recurring principle is that AI proposes, deterministic components verify and act, and named people decide, with every finding closed by a re-run.

10 minThe inventory as a control
  • Seven linked asset classes: AI systems, models, agents, prompts and skills, connectors and tools, data, and security AI.
  • Reconciliation sorts every difference between declared and discovered into match, drift, orphan or unknown, each with an owner and a deadline.
  • The record becomes a control when the gateway generates an agent's tool allow-list from it.
  • Criticality follows reach, identity, exposure, data and dependency, which places most security AI at tier-0.
10 minContinuous threat modelling and reviewable machine-generated risk
  • Threat models are regenerated from architecture code on every change; AI drafts candidates and a named person accepts or rejects each with a reason.
  • Attack-path finding stays a deterministic graph computation; AI proposes edges, ranks paths with checkable explanations and proposes the cheapest cut.
  • Soundness is defined in advance in seven checks, and the completeness check catches the changed boundary without any candidate threat.
10 minFrom finding to fixing: the verification bottleneck
  • The constraint has moved from finding vulnerabilities to verifying, prioritising and fixing them.
  • No AI finding reaches a person until a machine has tried to reproduce it, and no fix is accepted until it is proven.
  • EPSS, the KEV catalogue and the EUVD say how dangerous a vulnerability is in general; exposure and business context say how dangerous it is here.
  • Delegated patch decisions for known-exploited, reversible fixes make patch velocity a service level.
13 minAdversary emulation under rules of engagement
  • A threat-informed scenario maps each step to an ATT&CK technique and names the detection or control it is expected to meet.
  • AI that executes emulation steps is treated as a Mode 5 system for the exercise, with exercise credentials, range separation, an external stop path and logging outside the red range.
  • The three controls that failed in July 2026 each have a counterpart in an emulation programme and a design response.
  • The periodic exercise is discovery; continuous validation is regression; they meet at closure.
12 minRed teaming the compound AI system
  • The model is the smallest part: most failures that matter arise where two parts of the compound system meet.
  • Taxonomy entries become objectives written for the control that should hold, and the adversarial inputs stay in the access-controlled scenario library.
  • For agents the permission manifest is the test plan, and a scripted driver tests the boundary without needing the model to misbehave.
  • A boundary does not know it is being tested, which is the reason to weight containment over behavioural testing.

What the audience takes away

  • An AI asset that acts needs an owner, an identity, recorded permissions and a recent verification date, or it is what an AI-enabled adversary finds first.
  • AI drafts threats, rankings, findings and fixes; reproduction, proof and named reviewers decide what enters the register and what reaches production.
  • Every authorised offensive activity ends as a structured finding, a closing control and a passed re-test.

Chapter 9 · 75 minutes

Asset Management for an Estate That Includes AI

The lesson treats ID.AM Asset Management for an estate that includes AI. Participants learn the seven asset classes, the minimum record for an AI asset, the discovery sources for each usage mode, AI-assisted classification, matching and enrichment at Level 1 Assisted, reconciliation into match, drift, orphan and unknown, proportionate discovery of shadow AI, and criticality that follows what an asset can do.

Learning objectives

  • List the seven asset classes of an estate with AI and the fields every AI asset record holds.
  • Classify reconciliation differences as match, drift, orphan or unknown and assign each an owner and deadline.
  • Rate the criticality of an AI asset using reach, identity, exposure, data and dependency.
  • Draft an asset record for an agent, including identity, connectors, untrusted inputs and stop-path holders.

Key concepts

Seven asset classes
AI systems, models, agents, prompts and skills, connectors and tools, data, and security AI, each with its own owner and record. Security AI reads attacker-controlled content by design and often holds privileged access, so it is recorded with the same rigour as the systems it protects.
Last verification
The date and source of the record's last verification. The chapter calls it the field that matters most in practice, because it tells the SOC and the auditor whether the record describes the estate or a memory of it.
Four reconciliation outcomes
A match confirms the record; a drift is an asset in both lists that differs; an orphan is declared but no longer found; an unknown is discovered with no record. An unknown that acts or reads confidential data is escalated to the SOC as a potential security event.
The record as a control
At Hansa Mutual the gateway generates each agent's tool allow-list from its asset record, so a call to any unrecorded connector is refused and logged. The control followed a finding in which a vendor update had added a URL-reputation connector unnoticed.
Criticality by what the asset can do
Five factors decide the tier and the highest sets it: reach, identity, exposure to content an attacker can shape, data, and dependency. A move to Level 3 Bounded, a new write connector or a new source of untrusted input triggers reassessment.

Teaching plan

15 minThe teacher presents what ID.AM asks for when the estate includes AI, the seven classes and the minimum record; participants note which classes their inventory lacks.
15 minMap discovery sources to usage modes and discuss what is proportionate: egress metadata and endpoint inventories versus the content of prompts.
10 minWork through the HM-SEC-001 record and the unexpected connector, from discovery to the closing control and the replay as evidence.
25 minExercise: groups write an asset record for an agent and reconcile it against a supplied list of discovered facts.
10 minGroups report their drifts and unknowns and the tier they assigned; the teacher links the records to SOC enrichment and red-team scoping.

Discussion

  1. Why must the AI register required for governance and the asset inventory required for security be the same list, or two lists reconciled automatically?
  2. The discovery AI itself reads content others control. What design choices keep a crafted resource description from hiding an unregistered agent?
  3. How would you explain to employee representatives the difference between finding assets and judging individuals in shadow AI discovery?

Exercise · 25 minutes

Write and reconcile an asset record for an agent

Write an asset record for an agent in your organisation, or for Hansa Mutual's IT-operations agent, in the structure of the HM-SEC-001 record: identifier, owner, asset class, usage mode, decision record, criticality with the factor that sets it, identity, current autonomy level and stop-path holders, hosting and jurisdiction, models with version, prompts and skills, connectors with access type, untrusted inputs, data classification and last verification. Then take three discovered facts the teacher provides, for example a newer model version, an unlisted connector and an unregistered function calling a model endpoint, classify each as match, drift, orphan or unknown, and set an owner and deadline using the chapter's defaults.

Deliverable: One agent asset record and a reconciliation table of three differences with outcome, owner, deadline and whether the SOC is notified.

Self-test

  1. In reconciliation, what is a drift?

    1. A declared asset that discovery no longer finds anywhere in the estate
    2. An asset that exists in both the declared and the discovered inventory but differs
    3. A discovered asset for which the inventory holds no record at all
    4. A record whose last verification date has passed the limit that applies to its criticality tier
  2. At which autonomy level does the chapter recommend the discovery classifier works by default?

    1. Level 3 Bounded, tagging and merging records within a playbook
    2. Level 2 Supervised, applying each classification after approval
    3. Level 0 Advisory, reporting only counts of likely unknowns
    4. Level 1 Assisted, drafting proposals with evidence for the owner to confirm
  3. Why is security AI often tier-0 under the chapter's criticality factors?

    1. It reads attacker-controlled content by design, sees telemetry estate-wide and may propose containment
    2. It is always classified as a high-risk AI system under the AI Act
    3. It is the most expensive class of asset to buy and to host
    4. It is the only asset class whose models and features suppliers can change without giving the organisation notice

Chapter 10 · 90 minutes

AI-Assisted Threat Modelling and Risk Assessment

The lesson makes ID.RA Risk Assessment continuous. Threat models live beside the architecture as code and are regenerated on every change; AI proposes candidates using STRIDE with ATT&CK for classical boundaries and ATLAS and OWASP for AI systems; intelligence and adversary capability enter as structured, versioned inputs; attack paths are computed on a graph that includes AI edges; and machine-generated risk passes seven soundness checks before a named reviewer decides.

Learning objectives

  • Explain why a threat model drawn once in a workshop fails against the obligations and threats the chapter describes.
  • Classify a threat at a trust boundary by STRIDE category, ATT&CK or ATLAS technique and OWASP identifier.
  • Apply the seven soundness checks to an AI-proposed threat and its score.
  • Review a threat-model change on a pull request, recording an accept or reject decision with a reason for each candidate.

Key concepts

Candidate threats
AI proposes threats for every pull request that touches a trigger path and shows only what differs from the accepted model. A candidate joins the model only when a named person accepts it, and a rejected candidate stays rejected, with a reason, until the architecture changes.
Mitigation family
Because prompt injection is a property of the architecture, a candidate that proposes improving the system prompt as mitigation is unsound. Least privilege for tools, allow-listed retrieval, output validation or human approval are in the right family, outside the model.
Versioned assumptions
Adversary capability enters the risk model as a small set of named, versioned assumptions, such as time to exploit, the credibility of voice and video impersonation and the volume of targeted phishing, so that changing one rescores every dependent risk in a visible pull request.
AI edges in the attack graph
An agent holding a tool credential is an edge to everything the tool can change; a retrieval index ingesting external content is an edge from whoever can write the source to every prompt it feeds; a coding agent is an edge from anything it reads to everything its engineer can do.
Soundness checks
Grounding, classification, mitigation family, likelihood basis, impact basis, completeness and stability. The mechanical part is automated in the pipeline, a named reviewer judges against provenance, and the quality of that judgement is itself measured through sampled second reviews.

Teaching plan

15 minThe teacher presents the threat-modelling loop and the four questions that frame threat modelling as a practice, with the DORA Article 8 and AI Act Article 15(5) implications.
20 minParticipants classify example boundaries, a public endpoint, a service account, a retrieval source and a tool credential, by STRIDE, technique and OWASP identifier.
15 minWalk through attack-path analysis and the soundness table, then the Nordvik threat model after pull request 412 with its accepted and rejected candidates.
30 minExercise: groups review a set of candidate threats for a described architecture change and record decisions.
10 minCompare decisions between groups and discuss what a reviewer who accepts every candidate in seconds would have missed.

Discussion

  1. A missed threat is invisible in the diff. Which of the seven checks addresses that, and how far can it be trusted?
  2. Why should path-finding remain a deterministic computation while ranking may use AI, and what makes the ranking the most dangerous step?
  3. How would treating time to exploit as a versioned assumption change your organisation's current risk register?

Exercise · 30 minutes

Review AI-proposed threats on a pull request

The change: Nordvik Region's citizen-service assistant gains a new retrieval source written by a third party, or your own system gains a comparable boundary. The teacher supplies five candidate threats, of which some are ungrounded, misclassified or carry a mitigation inside the model. For each candidate, apply the soundness checks, mark it accepted, rejected or amended with a one-line reason, and for accepted threats name controls that act outside the model and the test that would verify closure. State whether any changed boundary has no candidate, and whether residual risk needs the risk owner's approval before merge.

Deliverable: A threat-model excerpt with five reviewed candidates, each with decision, named reviewer and reason, controls for accepted threats and a verification test.

Self-test

  1. In the worked example, why does the rejected candidate T-033 stay in the threat-model file?

    1. Because the generator cannot delete entries from an accepted model
    2. Because public-access rules require every candidate threat to be published together with the accepted model
    3. So the next regeneration does not raise it again and an auditor can see it was considered
    4. So that the risk owner can later accept it as residual risk
  2. What may the threat-model generator write to, according to the chapter?

    1. Only a pull request comment, never the accepted model
    2. The accepted model, once the automated checks have passed
    3. The risk register, for threats below the appetite threshold
    4. The architecture definitions, to add missing trust boundaries
  3. Which use does the chapter rule out at every autonomy level for AI in risk assessment?

    1. Drafting candidate threats and scores for a named reviewer
    2. Rescoring risks after an approved change to an assumption
    3. Ranking attack paths with explanations that can be checked
    4. Accepting a threat, a risk or an exception

Chapter 11 · 90 minutes

Vulnerability Discovery and Exposure Management at Machine Speed

The lesson covers the vulnerability side of ID.RA Risk Assessment and PR.PS Platform Security. Participants examine the evidence that AI finds and exploits flaws at scale, place AI review in the delivery pipeline, apply the three rules of the verification bottleneck, combine EPSS, the KEV catalogue and the EUVD with exposure and business context, delegate patch decisions for known-exploited vulnerabilities, and report patch velocity as a service level.

Learning objectives

  • Explain why the constraint has moved from finding vulnerabilities to verifying, prioritising and fixing them.
  • Apply the three rules of verification: sandboxed reproduction, proof of fix and reviewer capacity as a budget.
  • Compare what EPSS, the KEV catalogue, the EUVD, exposure and business context each answer and where each is limited.
  • Draft a delegated patch decision with classes, conditions, time limits, exclusions and evidence.

Key concepts

Every patch is an exploit specification
The statement from AI Platform and Security, Chapter 18: a published fix tells an adversary where to look. The chapter cites exploitation rising from 10.5 vulnerabilities a month in 2025 to 18 in 2026, driven by rapid weaponisation of newly disclosed vulnerabilities.
Sandboxed reproduction
No AI finding reaches a person until a machine has tried to reproduce it. A harness builds the component in an isolated sandbox without network egress or production credentials and runs the proposed test case; a finding that does not reproduce returns to tuning.
Proof of fix
A proposed fix is accepted only when the reproduction case no longer triggers the flaw, the component's existing tests still pass, and the case joins the regression suite. The reviewer then judges a complete package and not a claim.
Delegated patch decision
A recorded judgement, taken once for a defined class of change, that for a known-exploited vulnerability on an exposed asset the risk of waiting exceeds the risk of a reversible change. It removes the change board from the path; irreversible changes still go through the board.
Patch velocity
The time from a vulnerability entering a priority class to a verified fix or compensating control. It is reported to the management body with a target, a trend and the exceptions behind any miss.

Teaching plan

15 minThe teacher reviews the evidence on discovery by defenders and exploitation by adversaries, and the three limits that keep it in proportion.
15 minWalk through the find, verify, prioritise and fix pipeline: severity thresholds for AI review, reproduction, proof of fix and the work-in-progress limit for reviewers.
15 minParticipants rank five sample vulnerabilities using the public and local signals and justify the order against a written rule.
30 minExercise: groups draft a delegated patch decision for one asset group, modelled on DPD-NR-001 and the classes of HM-PATCH-SLO-2027.
15 minGroups design the chaos experiment that would verify their decision and discuss disclosure duties, including the Cyber Resilience Act Article 14 clocks for manufacturers.

Discussion

  1. Roughly one finding in ten was wrong even in the best-resourced programmes. What does that imply for an organisation that switches on AI code review without a verification step?
  2. Why do both example organisations keep their exposure prioritisers at Level 0 Advisory, and what would have to be true before you raised one?
  3. Hansa Mutual records that no agent applies fixes in production on its own authority. Under which conditions, if any, would you revisit that position?

Exercise · 30 minutes

Define a delegated patch decision

Choose an internet-facing asset group in your organisation, or Nordvik Region's inference platform. Following the practical guide, define the class that triggers the delegation, starting with vulnerabilities listed in the KEV catalogue or marked as exploited in the EUVD. State the conditions: fix source, how recently rollback must have been tested, and the post-change health check. Set time limits for emergency mitigation and for the fix, and name who may extend them as an expiring exception. List what is excluded from delegation. Say what evidence each delegated change produces and how it is reported to the change board afterwards. Finally, write the steady-state hypothesis of a chaos experiment that uses an internal test feed, never the public catalogues.

Deliverable: A delegated patch decision record with class, conditions, timing, exclusions, evidence and after-the-fact reporting, plus one chaos experiment hypothesis with time bounds.

Self-test

  1. What does the chapter identify as the binding constraint once AI finds vulnerabilities at scale?

    1. The number of vulnerability identifiers that can be assigned each month
    2. The cost of model access for discovery in ordinary engineering budgets
    3. The availability of sanitisers for memory-safe programming languages
    4. The human capacity to verify, triage and patch what is found
  2. What happens, under the chapter's severity thresholds, to a high finding from AI review that has not been reproduced?

    1. It blocks the merge until a security architect has dismissed it
    2. It creates a tracked item without blocking the merge
    3. It is discarded and removed from the reviewer's quality metrics
    4. It is disclosed to the maintainer on the agreed timeline
  3. Which change does the practical guide exclude from a delegated patch decision?

    1. A supplier-published fix for a vulnerability listed in the KEV catalogue
    2. A fix on an internet-facing asset with a rollback tested last month
    3. An irreversible firmware change
    4. A fix applied in the next maintenance window within 72 hours

Chapter 12 · 90 minutes

Adversary Emulation and Continuous Red Teaming with AI

The lesson covers adversary emulation and continuous red teaming under ID.IM Improvement. Participants build threat-informed, ATT&CK-mapped scenarios, apply the safeguards for AI that executes emulation steps, read the July 2026 incident as a design input, test containment from the adversary's side with conditions, combine periodic threat-led testing with continuous validation as code, and write finding records the blue team can act on.

Learning objectives

  • Distinguish a threat-informed emulation from a generic penetration test and state what AI may and may not decide in scenario design.
  • Assign an autonomy level per step of an emulation plan according to whether the step reads or changes state.
  • Map the three controls that failed in July 2026 to their counterparts and design responses in an emulation programme.
  • Draft an emulation plan extract and a structured finding record with a closing control and a re-test.

Key concepts

Threat-informed emulation
An emulation that asks whether the adversaries most likely to target this organisation, with the capabilities they have shown, would succeed and whether anyone would notice. Each step maps to an ATT&CK technique and names the detection or control it is expected to meet.
Executing AI as a Mode 5 system
AI that executes emulation steps acts with credentials and network access of its own, so it is treated as Mode 5 for the exercise whatever product it is built on, and receives the full containment baseline, including a permission manifest, budgets and an external stop path.
Tempo
Emulating AI-enabled adversaries includes emulating their speed. In Hansa Mutual's exercise the detection fired, but the alert was queued at medium severity and triaged after 47 minutes: the detection was not missing, its severity assumed a human tempo.
Continuous validation as code
Catalogued, benign technique emulations replayed against the estate as regression testing for Protect and Detect. AI plans and interprets; deterministic components act. A failed test is a finding, closed only when the same test passes again.
Finding record
A machine-readable entry naming the plan step and technique, the expected and observed outcomes with times, the control and never an analyst on shift, and the closing action and re-test. A red-team member confirms every finding and the control owner accepts it.

Teaching plan

15 minThe teacher presents the path from intelligence to an emulation plan and the two disciplines that keep AI-assisted design honest.
20 minReview the four safeguards and the plan HM-TLPT-2027-S2 at technique level; participants identify which step runs at which level and why.
15 minWork through the July 2026 table of failed controls and the test of containment from the adversary's side, using conditions and not new attack behaviour.
30 minExercise: groups prepare a safe AI-assisted emulation run on paper and write the finding record for a given outcome.
10 minDebrief: each group states the closing control and the re-test for its finding, and how it would enter the continuous validation catalogue.

Discussion

  1. Why does an agent whose task is to probe for weaknesses need containment more, not less, than a production agent?
  2. The finding record names a control, never an analyst on shift. What does that choice protect, and what would be lost without it?
  3. What must a white team understand about AI components to control an exercise in which steps complete in seconds?

Exercise · 30 minutes

Prepare a safe AI-assisted emulation run and its finding

On paper, for an authorised exercise against your own organisation's systems or Hansa Mutual's, write a four-step scenario extract. For each step give the ATT&CK technique identifier, the executor, the autonomy level and the expected detection or control with a time limit; keep it at technique level with no procedures or tooling. Add the safeguards: permission manifest and budgets for the AI component, who issues credentials and their lifetime, egress, shared services, stop conditions, stop-path holders and where the log is kept. Then assume one read-only step completed undetected out of hours and write the structured finding record: expected, observed, control, severity, classification, closing action and re-test.

Deliverable: A four-step emulation plan extract with safeguards and stop conditions, and one finding record with a closing control and a re-test method.

Self-test

  1. What is the ceiling the chapter sets for AI on emulation steps that change state on production systems, use harvested credentials or move data?

    1. Level 1 Assisted at most
    2. Level 2 Supervised at most
    3. Level 3 Bounded within a playbook
    4. Level 0 Advisory only
  2. In an emulation programme, what is the design response to the July 2026 failure of a package mirror that was also an egress path?

    1. A larger action budget for each AI-executed scenario
    2. Exercise alerts routed to the red-team lead on shift, who then decides whether to inform the white team
    3. No shared supporting services between ranges, and every egress route named
    4. A second package mirror held in reserve for exercises
  3. In continuous validation, which components hold estate credentials and act?

    1. The AI planner, which selects tests from coverage gaps
    2. Deterministic components, while AI only plans and interprets
    3. The AI evaluator, which drafts findings on missing outcomes
    4. The red team's coding agents, under the engineer's identity

Chapter 13 · 90 minutes

Red Teaming AI Systems and Agents

The lesson turns the red team on the organisation's own AI under ID.RA Risk Assessment and ID.IM Improvement. Participants scope the compound system in six elements, use the OWASP lists, MITRE ATLAS and NIST AI 600-1 as test plans written as control objectives, turn campaigns into gating suites with thresholds as rates, test agent containment with the permission manifest as the plan, and state the limits of testing and the residual risk an owner accepts.

Learning objectives

  • Scope a compound AI system in six elements and explain why testing the model in isolation says little.
  • Write taxonomy entries as objectives for the control that should hold, with ATLAS technique and risk-register entry.
  • Explain how a scenario library, harness, threshold and gate turn a campaign finding into a regression case.
  • Design a containment test plan for an agent, with hypotheses for credentials, control artefacts, detection and the stop path.

Key concepts

Compound system
Users and content sources, a gateway, prompts and the model, a retrieval store, an agent with a permission manifest, and tools. Most failures that matter arise where two parts meet, and the content sources are the element most often forgotten in scope.
Objective for the control that should hold
Each applicable taxonomy entry is written as a statement such as: a resident cannot cause the assistant to disclose another resident's correspondence. The plan is a defensive artefact; the adversarial inputs live only in the access-controlled scenario library.
Threshold as a rate
Because generative systems are not deterministic, each case runs several times. The threshold is zero for outcomes that must never occur, and a non-zero rate only where other controls bound the harm, recorded with its owner.
Escape path and scripted driver
An escape path is any route by which an agent's effect can reach beyond its boundary. In the test range a scripted driver replaces the agent's planning component and issues out-of-mandate tool calls with the agent's own identity, testing the boundary reproducibly.
Evaluation awareness
Models may behave differently when a setting looks like a test, so a passing result may overstate production behaviour. The chapter prefers tests whose outcome does not depend on the model's behaviour, because a boundary does not know it is being tested.

Teaching plan

15 minThe teacher presents the compound system, the split between the provider's Article 55 evidence and the deployer's test, and the six scope elements.
15 minParticipants turn three taxonomy entries into control objectives for Nordvik Region's citizen-service assistant and mark one as not applicable with a reason.
15 minWalk through library, harness, threshold and gate using GATE-CSA-001, then the withdrawn-page finding and its closing control.
35 minExercise: groups write a containment test plan for a production agent, modelled on the plan for Hansa Mutual's IT-operations agent.
10 minGroups draft the residual-risk statement their system owner would sign and say what telemetry would let a responder reconstruct an out-of-mandate action.

Discussion

  1. Instructions lowered the rate of harmful actions in the cited study without eliminating it. What follows for how much weight a passing behavioural test should carry?
  2. Where in your organisation does the person who controls the content differ from the person who uses the assistant, and has that route ever been tested?
  3. A CISO override of the release gate is valid for at most 14 days at Nordvik. What should have to be true for an override to be used at all?

Exercise · 35 minutes

Write a containment test plan for an agent

Choose a production agent in your organisation, or Hansa Mutual's claims-triage agent, and assume testing happens only on a replica in an AI test range under approved rules of engagement. From its permission manifest derive at least five objectives as hypotheses, covering credentials, tool scope, control artefacts the agent must not write, detection of decoy use, and the stop path while a task runs, each with a time bound where one applies. Enumerate three possible escape paths from the infrastructure description. State the two rounds, scripted driver and model with manipulated input, the actions never attempted, the telemetry that proves each result, and who owns the residual risk. Do not write any test inputs.

Deliverable: A containment test plan with five or more hypotheses, three enumerated escape paths, the two rounds, never-attempted actions, telemetry per objective and the residual-risk owner.

Self-test

  1. What was the significant finding of Nordvik Region's first campaign against the citizen-service assistant?

    1. The assistant disclosed its system prompt and prompt template when a resident asked for them in another language
    2. The assistant used a tool that changed state without approval
    3. The provider's model had not been adversarially tested at all
    4. A page withdrawn from the public website was still in the retrieval index and cited as current
  2. Why does the escape-path assessment use a scripted driver in place of the agent's planning component?

    1. To test the boundary reproducibly without needing the model to misbehave
    2. To reduce the cost of model calls during long assessments
    3. To avoid the need for rules of engagement in the test range
    4. To let the red team test the provider's infrastructure directly
  3. How does the chapter treat a threshold above zero in a gating suite?

    1. It is forbidden, since every case must pass on every run
    2. It is set by the model provider for each model version
    3. It is allowed only where other controls bound the harm, recorded with its owner
    4. It applies to cross-user disclosure but not to unsupported answers

Module 4 · Part IV · Protect

Part IV covers the Protect Function. Participants design identities for people, machines and agents, move approvals off appearance and onto call-back, dual control and out-of-band confirmation, build resilience to AI-generated deception by testing processes and not people, protect security data and place guardrails outside the model, and make infrastructure and security AI degrade safely. They leave with a credential profile, an exercise design record, a guardrail policy and a degradation-mode definition.

Lecture · 50 minutes

Protect: controls that hold however convincing the input

The argument of Part IV is that protection can no longer depend on anyone recognising a forgery, whether the anyone is a finance clerk facing a synthetic voice or a model facing a crafted alert field. Each chapter therefore moves the control from recognition to structure: authentication that leaves nothing reusable to harvest, approvals that cannot be satisfied by the content of a request, guardrails that limit what any input can cause, and segments and degradation modes that bound reach and failure. The lecture shows the same design move four times and what each costs to operate and to verify.

12 minIdentity: three populations and no ambient authority
  • People, conventional machine identities and AI agents fail differently; an agent's actions vary with input that someone else largely controls.
  • Agent credentials are task-scoped, short-lived, issued by a broker outside the runtime and never shared; the agent has no ambient authority.
  • Phishing-resistant authenticators make deception yield nothing reusable, and a phishable fallback left enabled undoes the migration.
  • Appearance is not authentication: call-back to a registered contact, dual control and out-of-band confirmation, enforced as policy as code.
10 minPeople: test the process, not the person
  • AI removed three frictions from social engineering: language, personalisation and presence.
  • Exercises are announced at unit level, use consenting or fictitious personas, exclude themes that exploit personal vulnerability and are debriefed.
  • Resilience is measured by process adherence, report rate, time to report and time to containment, not by click rates.
  • Analysts are trained to verify against the evidence, resist automation bias, drill the stop path and keep their unassisted skill.
12 minData and platform: the ceiling is set outside the model
  • Security data reveals people, weaknesses and the defender's blind spots, and AI creates new copies of it in prompts, indexes, caches and logs.
  • Six guardrail layers: input handling, retrieval scope, tools, output checks, budgets and evidence.
  • Injection classifiers reduce noise; the ceiling is set by tools, identity and output checks, which hold whether or not a manipulation is recognised.
  • Configuration is policy as code, with automatic reversion only for control classes reviewed in advance.
11 minInfrastructure: bounded reach and safe degradation
  • No SOC can guarantee a response faster than an attacker's next step, so each step must cross a boundary where it can be refused, logged and detected.
  • Redeploy from known-good definitions, which for an AI system include model version, prompts, guardrails, manifest, retrieval sources and the evaluation suite.
  • Security AI fails as unavailable, degraded, untrusted or compromised; the quiet states are the dangerous ones.
  • Stepping down is automatic and triggered from outside the AI; stepping up needs a person and a passing evaluation suite.
5 minVerifying Protect
  • Each chapter ends with a chaos experiment that injects a condition, not an attack: an over-scoped token, a synthetic payee change, a canary record, a blocked model endpoint.
  • Nordvik Region's protection rests on contracts, process controls and fallback to its people; Hansa Mutual's on engineered credentials, policies and redundancy.

What the audience takes away

  • Design every high-risk approval and every agent permission so that the content of a request, however it looks or sounds, cannot satisfy it.
  • Measure human resilience on the process, in aggregate, and treat fast approvals or missing call-backs as findings about design.
  • When security AI fails, the defence must lose speed, never the defence itself: define, staff and test the degradation path.

Chapter 14 · 90 minutes

Identity, Authentication and Access for People, Agents and Machines

The lesson covers PR.AA Identity Management, Authentication, and Access Control. Participants distinguish three populations of identity, decide whose identity an AI acts with in each usage mode, design task-scoped agent credentials with no ambient authority, plan the move to phishing-resistant authentication including sessions, recovery and the service desk, harden approvals against synthetic media, and use AI in access governance without letting it become the risk.

Learning objectives

  • Compare the three populations of identity and the characteristic failure of each.
  • Explain why a production agent should have an identity of its own and what the rule of no ambient authority requires.
  • Design an approval that cannot be satisfied by the content of a request, using call-back, dual control and out-of-band confirmation.
  • Draft a credential profile for an agent with scopes per action, denied permissions, entity binding and revocation.

Key concepts

No ambient authority
The agent holds no standing permission merely by existing. A credential is issued for one task by a broker outside the agent's runtime, valid for minutes and never shared. Shared credentials let one compromise reach every component and destroy attribution.
Delegated token
A delegated token says who delegated, to which agent, for which task and for which legal entity, and the receiving system decides on all four. A token that names its task and entity cannot be reused for another task or market.
Phishing-resistant authentication
Authenticators such as FIDO2 security keys, platform passkeys and smart cards bind the authentication to the requesting origin, so a credential presented to a look-alike domain does not work at the real one. The user can still be deceived, but the deception yields nothing reusable.
Call-back, dual control, out-of-band confirmation
Three controls that make an approval rest on a channel the requester does not control, on a second person who did not receive the request, and on a record in an authenticated system of record.
Governing AI reads and proposes
AI that prepares access reviews and detects identity misuse does not write: revocations and grants pass through the identity system's workflow with a human decision. Its input, such as display names and ticket text, is treated as attacker-controlled.

Teaching plan

15 minThe teacher presents the three populations of identity and whose identity AI acts with in each usage mode, with the two problems of acting through a person's session.
15 minRead the credential profile of HM-SEC-001: scopes per autonomy level, denied permissions, entity binding and revocation within sixty seconds.
15 minDiscuss phishing-resistant authentication, the order of migration by account value, and why sessions, recovery and the service desk become the next targets.
35 minExercise: groups harden one approval process against synthetic media and express the rule as policy, then draft a credential profile for one agent.
10 minGroups test each other's approval rule by proposing a request that looks and sounds genuine, and check that the rule still refuses it.

Discussion

  1. The price of giving an agent its own identity is owning a privileged non-human actor that can be steered by its input. When is that price worth paying, and what makes it bearable?
  2. Why must a person who delays a senior request to complete verification never be penalised, and how would you make that credible in your organisation?
  3. Vendor AI in identity-protection products may block a sign-in or force a reset automatically. How would you find out which controls act automatically and how to override them?

Exercise · 35 minutes

Harden an approval and draft an agent credential profile

Part one: choose a high-risk approval in your organisation or Nordvik Region's supplier payment change. List the untrusted channels, name the trusted contact source, and write a rule that requires call-back to the registered contact only, a second approver who did not receive the request, out-of-band confirmation in the system of record and a cooling-off period, with what happens on violation and how long evidence is kept. Part two: for one agent, write a credential profile in the structure of the HM-SEC-001 extract: issuer outside the runtime, token lifetime and bindings, scopes with autonomy level per action, denied permissions an attacker would want most, entity binding and stop-path holders with a revocation time.

Deliverable: One approval rule as policy with required controls and violation handling, and one agent credential profile with scopes, denials, binding and revocation.

Self-test

  1. Which permissions does the credential profile of HM-SEC-001 deny outright?

    1. Reading SIEM and EDR telemetry for the case in the token
    2. Revoking a user's sessions in the identity provider
    3. Isolating a managed workstation through the EDR tool
    4. Assigning roles, resetting credentials and writing detection rules
  2. Why does a phishable fallback factor left enabled undo a migration to phishing-resistant authentication?

    1. Because fallback factors cannot be recorded in the access-rights register
    2. Because an attacker simply selects the fallback
    3. Because fallback factors lengthen the lifetime of session tokens
    4. Because NIS 2 forbids more than one factor per account
  3. In Hansa Mutual's approval policy, what does rule APR-02 require for a claims payment above the threshold routed through the Polish service centre for a Swedish claim?

    1. A second approver who sits in the paying entity
    2. A video call with the claimant recorded for evidence
    3. Approval by the SOC investigation agent at Level 2
    4. A cooling-off period of seven days before payment

Chapter 15 · 75 minutes

Awareness and Training: Resilience to AI-Generated Deception

The lesson covers PR.AT Awareness and Training in two parts. For general personnel, resilience to AI-generated deception is built into processes and tested on processes through announced, lawful exercises measured in aggregate. For specialised roles, analysts learn to verify AI output against the evidence, resist automation bias, supervise and stop agents, and retain their own skills, with AI literacy as a duty under Article 4 of the AI Act.

Learning objectives

  • Explain the three frictions AI has removed from social engineering and the three consequences for training.
  • Design an exercise that tests an approval process, not individuals, within the chapter's four ethical principles.
  • Select aggregate measures of resilience and justify why the click rate is not among them.
  • Describe the skills analysts need to supervise security AI: verification, resisting automation bias, stopping agents and skill retention.

Key concepts

Three frictions removed
AI has not created a new class of social engineering; it has removed language, personalisation and presence as limits. The techniques are familiar; their cost and quality have changed, so recognition is no longer a reliable control.
Test the process, not the person
An exercise asks whether a payment-change process, a service-desk reset or an approval chain behaves as designed when a realistic AI-generated request arrives. People take part knowingly, and individual performance is not measured.
Exercise design record
A classified record with the process and control under test, hypothesis, persona, excluded themes, announcement window, consent, data handling, safety mechanisms and success criteria. It deliberately contains no call script and no synthetic media.
Four aggregate measures
Process adherence, report rate, time to report and time to containment, taken from systems that already record them. Results are compared over time for the same process, not between units.
Unassisted practice
To keep the skill the AI performs, by default ten per cent of alerts, chosen at random, are worked without the AI's proposal and compared afterwards, which trains the analyst and produces evaluation data for the AI.

Teaching plan

10 minThe teacher presents the Arup case as a process failure and the sober reading of the threat reporting: AI added to existing playbooks, with three frictions removed.
15 minDiscuss the four ethical principles, labour law and data protection for exercises, using Nordvik Region's design record NR-AWR-2027-01.
15 minReview analyst training: the verification habit, automation bias and approval quality from the override log, stop-path drills and skill retention.
25 minExercise: groups write an exercise design record for one approval process, without scripts or media.
10 minEach group states what finding it would raise if the hypothesis failed, and whether a system change or training closes it.

Discussion

  1. Does announcing an exercise at unit level remove its value? What does the chapter answer, and do you agree?
  2. Nordvik Region's first exercise had a report rate of 0.74 yet the hypothesis failed. What does that teach about where controls should be enforced?
  3. A rejection rate near zero on AI proposals is treated as a finding about the oversight design, not the analyst. Which design changes would you try first?

Exercise · 25 minutes

Write a deepfake-resilience exercise design record

Choose one high-impact approval flow in your organisation or Hansa Mutual's treasury approvals. Write its designed control: expected channel, call-back, second approver, cooling-off. Write the hypothesis with a reporting time. Describe the scenario only at the level of pretext and channel, with a fictitious or consenting persona and the excluded themes. Record the announcement audience and window, consent from employee representatives and the data protection officer's review, data sources, minimum group size, retention, whether calls are recorded, the payment hold and who can stop the exercise, and the success criteria. Do not write a call script or describe how synthetic media are produced.

Deliverable: A design record in the structure of NR-AWR-2027-01 with process, hypothesis, scenario limits, announcement, consent, data handling, safety and success criteria.

Self-test

  1. Which of the following is among the chapter's four ethical principles for resilience exercises?

    1. Record every call so that individual responses can be reviewed
    2. Publish a league table of departments after each exercise
    3. Announce the exercise at the level of the unit, without date or form
    4. Use a real senior manager's voice without telling the manager
  2. How was finding NR-FND-2027-014 from Nordvik Region's first exercise closed?

    1. By a mandatory training module for all finance staff
    2. By removing the member of staff who saved the change
    3. By lowering the success criterion for call-back share
    4. By a system change that enforces the call-back field
  3. Which kind of AI proposal are analysts trained to scrutinise in particular?

    1. Proposals that cite more than three events from the telemetry, since long evidence lists suggest manipulation
    2. Proposals unusually convenient for an attacker, such as closing a case or allow-listing a sender
    3. Proposals that arrive during a degraded-mode practice shift
    4. Proposals drafted for alerts of low severity only

Chapter 16 · 90 minutes

Data and Platform Security with and for AI

The lesson covers PR.DS Data Security and PR.PS Platform Security with and for AI. Participants classify security data by what it reveals, protect it at rest, in transit and in use, defend training data against poisoning and extraction, build a six-layer guardrail policy enforced outside the model, hold configuration as policy as code with pre-decided reversion, and make AI-assisted development reviewable for soundness with provenance through the pipeline.

Learning objectives

  • Classify security data into the chapter's six classes and state the default handling of each when AI processes it.
  • Explain why guardrails for security AI limit what any input can cause and do not rely on recognising malicious instructions.
  • Draft a guardrail policy with the six layers for a security AI capability.
  • Decide per control class whether configuration drift reverts automatically, goes to an owner or goes to the incident commander.

Key concepts

Security data is sensitive in three ways
It contains personal data, it describes weaknesses, and it describes the defender: suppression lists and alerts closed as benign tell an adversary what will not be seen. A leaked detection repository is worth more to an intruder than most production data.
Six layers of a guardrail policy
Input handling, retrieval scope, tools, output checks, budgets and evidence, each enforced at the policy point or by the platform and not by the model. Attacker-controlled fields are passed as delimited, labelled data, never concatenated into instructions.
The ceiling
Injection classifiers in the input layer reduce noise, but they are not the ceiling. The ceiling is set by the tools, the identity and the output checks, which hold whether or not a manipulation is recognised.
Canary record
A planted fictitious case whose identifiers exist nowhere else. Any appearance of those identifiers outside its boundary is a high-confidence signal of extraction through the AI service.
Reversion per control class
Drift in a reviewed class, such as a gateway bypass or egress beyond default-deny, is reverted automatically and reported; other drift goes to an owner with a deadline; drift during a declared incident goes to the incident commander.

Teaching plan

15 minThe teacher presents why security data is sensitive and the six data classes; participants identify where their own security AI has created new copies of such data.
20 minWalk through the six guardrail layers with the NR-SEC-001 policy: dropped fields, read-only tools, output schema and budgets.
15 minReview baselines and drift as policy as code, the three practices for soundness review, and provenance from commit trailer to verified signature.
30 minExercise: groups apply a guardrail policy to one security AI capability using the nine steps of the practical guide.
10 minGroups name the worst outcome a manipulated input could still cause under their policy and which layer bounds it.

Discussion

  1. The chapter says a guardrail switched off is a worse drift than most. Why, and how would your organisation notice within minutes?
  2. Which changes to security content in your team reduce what the defender sees, and who reviews them today?
  3. Reverting a rule an incident responder widened ten minutes ago can break containment. How should a declared incident change automatic reversion?

Exercise · 30 minutes

Apply a guardrail policy to a security AI capability

For a triage, enrichment or summarising capability in your organisation, or for Hansa Mutual's HM-SEC-001, write a guardrail policy. Record usage mode, autonomy level, identity and decision record. Mark every input field as trusted, organisation-written or attacker-controlled, treating doubtful fields as attacker-controlled, and state how such fields are handled. Agree a purpose allow-list and list fields to drop. Scope retrieval. Allow-list tools with read tools only at Level 0 and Level 1. Define the output schema and checks with the action on violation. Set budgets starting from the chapter's defaults. State what is logged, when the scenario library runs, and one chaos experiment with a marker phrase or canary record that would verify the policy.

Deliverable: A guardrail policy in the structure of NR-SEC-001-guardrails covering input, retrieval, tools, output, budgets, evidence and verification.

Self-test

  1. What sets the ceiling on what a manipulated input can cause, according to the chapter?

    1. The tools, the identity and the output checks
    2. The injection classifier in the input layer
    3. The system prompt's instructions to the model
    4. The provider's adversarial testing of the model
  2. Which security data does the chapter name as security-critical for backup under PR.DS-11, to be restorable to a known-good version?

    1. Raw telemetry older than the retention period agreed with the privacy lead
    2. Analysts' personal notes on closed benign cases, kept outside the case-management system
    3. Detection content, guardrail policies, model artefacts and evaluation sets
    4. Vendor release notes and licence records for the security products in use
  3. Which changes require a second reviewer who did not prompt the assistant?

    1. Every AI-assisted commit to the detection repository, whether it adds, tunes or only documents a rule
    2. Changes that add a new detection for a technique in the threat profile
    3. Changes to documentation and to the wording of runbooks that analysts follow
    4. Changes that reduce what the defender sees, such as suppression lists and guardrail policies

Chapter 17 · 75 minutes

Technology Infrastructure Resilience Against Machine-Speed Attacks

The lesson covers PR.IR Technology Infrastructure Resilience. Participants learn why bounded reach comes before speed of response, the properties of segmentation and zero trust that limit machine-speed attacks, redeployment from known-good definitions including what such a definition contains for an AI system, the four ways security AI fails, and how to define degradation modes triggered from outside the AI and verified by failover exercises, restore tests and chaos experiments.

Learning objectives

  • Explain why the infrastructure must limit the reach of each attacker step and list the properties that do so.
  • List what a known-good definition contains for an AI system and why a redeployed system starts at reduced autonomy.
  • Distinguish the four ways security AI fails and identify the two quiet ones.
  • Design degradation modes for a security AI capability with entry triggers, fallback, staffing and fail behaviour.

Key concepts

Bounded reach first
No SOC can guarantee a response faster than an attacker's next step, so the infrastructure limits the reach of each step: the attacker needs many steps, and each crosses a boundary where it can be refused, logged and detected. Speed of response is the second line.
Redeploy, do not repair
Repairing a touched component means trusting that every change has been found; replacing it from a signed definition built by a pipeline means trusting the definition, a far smaller and more verifiable claim. Regular rebuilds also limit persistence.
Four failure states of security AI
Unavailable, degraded, untrusted, and compromised or out of mandate. Degraded and untrusted are dangerous because they are quiet: the system keeps producing plausible output, and untrusted is the state an attacker will try to induce.
Lose speed, never the defence
The design principle with three rules: fall back to people and deterministic playbooks, reduce autonomy in steps, and trigger degradation from outside the AI. Stepping down is automatic; stepping up requires a person's approval and a passing evaluation suite.
Fail safe, not fail open
The degradation-mode definition records for each function whether it fails open or closed and who accepted that choice. The fallback includes deterministic controls that catch the worst cases without the AI.

Teaching plan

15 minThe teacher presents why speed changes the design, the zero trust baseline and the table of properties that limit machine-speed attacks.
10 minParticipants list the contents of a known-good definition for one of their AI systems and mark which items are not yet versioned.
15 minWalk through the four failure states and the degradation modes of HM-SEC-001, from normal through bounded-suspended and advisory to manual.
25 minExercise: groups define degradation modes for a security AI capability following the eight steps of the practical guide.
10 minGroups pick one mode transition and write the chaos experiment that verifies it, with the fallback staffed in advance.

Discussion

  1. Why is a rising rate of analyst rejections treated as a trust signal and not as a nuisance to be tuned away?
  2. A package mirror was also an egress path in July 2026. How would you enumerate reachable paths from inside a segment instead of reading the intended rules?
  3. Where does your security AI share accelerators, gateway or identity provider with production AI, and what does that coupling imply for your fallback?

Exercise · 25 minutes

Define degradation modes for a security AI capability

For a capability in your organisation or Nordvik Region's SOC triage assistant NR-SEC-001, list its functions and the autonomy level of each. For each function write the fallback that works without the AI: who performs it, with which playbook and with what added staffing. Define the modes as a sequence from normal to manual. For each mode give entry triggers as measurable signals from outside the AI with thresholds and windows, starting from the chapter's defaults. State that stepping down is automatic and who approves stepping up after a passing evaluation run. Record for each function whether it fails open or closed and who approves a fail-open choice. Name where the monitor runs.

Deliverable: A degradation-mode definition in the structure of HM-SEC-001-degradation with modes, triggers, fallback, staffing, fail behaviour and approver.

Self-test

  1. Which item of a known-good definition for an AI system does the chapter say matters most?

    1. The model identifier and the hash of the weights
    2. The evaluation suite and thresholds it must pass before returning to its normal autonomy level
    3. The permission manifest, tool definitions and workload-identity scopes that bound what the system may do
    4. The system prompt and prompt templates as versioned files
  2. In the degradation modes of HM-SEC-001, who or what decides the agent's mode?

    1. A monitor on the SOAR platform, outside the agent's runtime
    2. The agent itself, from its own confidence scores
    3. The model provider, through version notifications
    4. The group AI governance board at its monthly meeting
  3. By the chapter's default values, when does a capability enter advisory mode?

    1. After 15 minutes of unavailability of the model endpoint, as measured at the gateway
    2. On any unannounced change of model version reported by the gateway
    3. When analysts reject more than 30 per cent of proposals over four hours
    4. When the evaluation suite has not produced a passing run for 24 hours

Module 5 · Part V · Detect

Part V covers the Detect Function. Participants place AI step by step in the SOC workflow, require grounded triage in which every claim cites its evidence, govern investigation agents through a permission manifest and five conditions for acting without per-action approval, and monitor AI systems including the SOC's own. They then build what feeds the SOC: detections as code with tests and a rationale, graded threat intelligence in STIX, and deception registered as code and kept inside the estate.

Lecture · 45 minutes

Detect: grounded signals, bounded agents and analysts in command

The SOC is where most organisations first put AI to work and the one function that must not be misled, because much of what it reads is written by the adversary. The lecture argues that AI adds most value in reading and assembling and most risk in deciding and acting. It follows an alert from intake to closure, then goes upstream to the three disciplines that decide which alerts exist and how far they can be trusted. The common thread is that reasoning becomes an artefact a person can check: a grounded record, a rationale, a grade, a register entry.

8 minWhy the SOC needs AI and why it must be careful
  • MTTD, MTTR and the false-positive ratio are the yardstick: AI is justified when it moves them without degrading the quality of decisions.
  • Alert titles, email subjects, file names and command lines are fields an adversary can influence, so every component that reads alerts reads attacker-controlled data.
  • The workflow is taken apart into intake, triage, enrichment, investigation, escalation and closure, each with its own starting autonomy level.
10 minGrounded triage and the investigation agent
  • A verdict in prose is a liability; a grounded record cites evidence for every statement and lists what could not be established.
  • An investigation agent is a Mode 5 system governed as a well-meaning insider through a permission manifest enforced outside the model.
  • Five conditions for acting without per-action approval: reversible, deterministically high-confidence, bounded, a person informed with a stop path, and authority granted by the forum that owns the risk.
  • The model's own confidence is not a criterion.
8 minWatching the watchers
  • The gateway is the best sensor for the organisation's AI; what an agent says it did is a claim, what the gateway recorded is evidence.
  • No AI component in the SOC triages alerts about itself.
  • Approval latency, AI and analyst agreement, and AI-closed alerts later found to be true positives show whether the SOC became faster or only faster and worse.
10 minDetections and intelligence as code
  • A detection the organisation cannot read, review and test is a dependency, not a capability.
  • A detection has a rule, a technique mapping, test cases, a rationale naming the variants not caught, and control mappings.
  • AI drafts are plausible by construction; tuning is detection change; the assistant has no deployment rights.
  • An AI summary is not a source: people assign the grade, and a combined claim takes the weakest grade.
9 minDeception and its legal boundary
  • The value of deception lies in its false-positive rate: a touched honeytoken needs little weighing.
  • Decoys in AI systems catch both external attackers and the organisation's own agents exceeding their mandate.
  • Decoy alerts bypass triage to the role that can act, and reversible responses can be pre-approved at Level 3 Bounded.
  • No decoy, detection or playbook contains a step that acts outside the estate.

What the audience takes away

  • Accept an AI verdict only when every decisive statement cites evidence an analyst can open, and record what could not be established.
  • Delegate machine-speed action in advance only for reversible, bounded actions on signals that are high-confidence by a deterministic definition.
  • Keep detections, intelligence and decoys as reviewed, tested, registered artefacts, and keep every response inside the organisation's own systems.

Chapter 18 · 90 minutes

The AI-Assisted Security Operations Centre

The lesson follows the AI-assisted SOC from intake to closure under DE.CM Continuous Monitoring and DE.AE Adverse Event Analysis. Participants place AI at each workflow step with a starting autonomy level, require grounded triage records, read a permission manifest for an investigation agent, apply the five conditions for action without per-action approval, set up monitoring of AI systems, keep analysts in command and write the questions an MSSP contract must answer.

Learning objectives

  • Assign a starting autonomy level to each step of the SOC workflow and name the main risk AI adds at that step.
  • Review a triage record for grounding, a fixed verdict set and a statement of what was not established.
  • Apply the five conditions under which an investigation agent may act without per-action approval.
  • Design the introduction of a triage assistant at Level 1 Assisted, with baseline, shadow running and monitoring.

Key concepts

Grounded triage record
A structured result in which every claim cites its evidence, the verdict comes from a fixed set, and the service records what it could not establish. A line such as no EDR telemetry for this host is a DE.CM finding about a monitoring gap.
Read, proposal and action tools
Read tools query SIEM, EDR, inventory and intelligence, and their results are untrusted content. Proposal tools write hypotheses and proposed actions to the case. Action tools are listed in the manifest each with its own level, scope and reversal.
Five conditions for bounded action
The action is reversible with a tested reversal; the signal is high-confidence by a deterministic definition; the blast radius is bounded; a person is informed at once and holds a stop path outside the agent; and the forum that owns the risk grants the authority in a decision record.
The agent does not watch itself
An agent's telemetry goes to a store it cannot write to, detection engineering owns the detections watching it, and alerts go to the shift lead who holds its stop path. No AI component in the SOC triages alerts about itself.
Approval latency
An approval in under ten seconds for evidence that takes a minute to read is not oversight. The SOC reviews the latency distribution; the outcome may be an open move to Level 3 Bounded or a slower queue, never a Level 2 control that has silently become Level 3.

Teaching plan

15 minThe teacher presents the yardstick metrics, the caution about attacker-controlled input and the workflow table with value, risk and starting level per step.
15 minParticipants review the Nordvik triage record: which statement would they open first, and what does the not-established line tell them?
20 minRead the permission manifest of HM-SEC-001 and test each of its two Level 3 actions against the five conditions.
30 minExercise: groups plan the introduction of a triage assistant at Level 1 Assisted and specify its grounded output and its monitoring.
10 minDebrief with the two chaos experiments: injected silence of a log source and a catalogued benign emulation on a test workstation.

Discussion

  1. A component that saves analyst time but misses more true positives has made the SOC faster and worse. Which measures would reveal that in your SOC, and who would see them?
  2. Why does the chapter rule out the model's own confidence as a criterion for acting at Level 3 Bounded?
  3. When the customer and the MSSP both use AI, whose verdict should count when the tooling disagrees, and how should the disagreement be recorded?

Exercise · 30 minutes

Plan a triage assistant at Level 1 Assisted

For your SOC or Nordvik Region's, plan the introduction of an AI triage assistant following the practical guide. State mode, level, hosting, readable data and who may change the level. List the baseline measures and the baseline period. Specify the identity and tools. Define the output schema: fixed verdict set, statements each with evidence references, a not-established list, model and prompt version, and the analyst decision field without which nothing is escalated or closed. Set the shadow period, the share of alerts each analyst works unassisted, the detections on the assistant's own gateway logs and the monthly review against the baseline. Add the four questions your MSSP contract must answer if a provider shares the queue.

Deliverable: An introduction plan with decision-record content, baseline, identity and tools, output schema, shadow and unassisted shares, monitoring of the assistant and MSSP contract questions.

Self-test

  1. What is the starting autonomy level the chapter gives for escalation in the SOC workflow?

    1. Level 2 Supervised, since an analyst approves each escalation
    2. Level 1 Assisted, as for triage and closure
    3. Level 0 Advisory
    4. Level 3 Bounded, for high-confidence signals
  2. Which signal satisfies the chapter's condition of high confidence for action at Level 3 Bounded?

    1. A reviewed detection corroborated by an independent source, or a honeytoken
    2. A model confidence score above a threshold set by the vendor
    3. Agreement between two AI components reading the same alert
    4. A high severity label in the alert's description field
  3. What does AI Act Article 26 require of deployers regarding the logs of high-risk AI systems, as the chapter reports it?

    1. To publish the logs to the national CSIRT every quarter
    2. To delete the logs within thirty days to minimise data
    3. To hand the logs to the provider of the general-purpose AI model for its adversarial testing under Article 55
    4. To keep the logs under their control for at least six months unless other law provides otherwise

Chapter 19 · 90 minutes

Detection Engineering, Threat Intelligence and Deception as Code

The lesson covers the engineering that feeds the SOC under DE.CM Continuous Monitoring and DE.AE Adverse Event Analysis. Participants build a detection as code with mapping, tests and rationale, take a threat report to a tested detection with an AI drafting assistant at Level 1 Assisted, structure and grade intelligence in STIX, register honeytokens, canaries and decoys as code with pre-approved reversible responses, and keep every step inside the legal boundary of the organisation's own estate.

Learning objectives

  • Name the five elements of a detection in a repository and explain what the rationale is for.
  • Review an AI-drafted detection for traceability, evidence, limits and consequence.
  • Explain how an AI-assisted intelligence assessment keeps its sources, markings and a grade assigned by a person.
  • Draft a decoy register entry with placement, signal routing, pre-approved responses, legal review and a verifying experiment.

Key concepts

Detection as code
Each detection is a file in a repository, changed through pull requests, review and pipeline tests, with the SIEM's deployed state derived from the repository. Sigma is the portable format the chapter uses, converted to the target platform's query language.
Rationale
The artefact that makes the reasoning reviewable: the motivating intelligence or finding, the targeted behaviour, the fields relied on and the variants knowingly not caught. The reviewer checks it for traceability, evidence, limits and consequence.
Tuning is detection change
Narrowing is how detections silently die, so every proposed exclusion is reviewed as a rule change. Regression on every repository, parser or log-source change catches a rule that stopped matching when a supplier changed a log format.
Grading by people
Grading separates source reliability from information credibility. AI may propose a grade, but an analyst assigns it. An AI summary is not a source: unsupported claims are removed, and a claim combined from sources of different reliability takes the weakest grade.
Honeytoken, canary and decoy
A honeytoken is a credential or record no legitimate process uses, a canary announces when it is read, and a decoy is a larger construct that looks real to an intruder. Each is entered in a version-controlled register with location, owner, alert and response playbook.

Teaching plan

15 minThe teacher presents the five elements of a detection and walks through Nordvik Region's payee-change rule, its tests and the gap its rationale records.
15 minWork through the one-day path from report to deployed detection and the three properties of AI-drafted detections; participants apply the four soundness checks to a sample rationale.
15 minReview AI in the intelligence cycle, STIX with markings and grading, and the Hansa Mutual assessment with one AI claim removed.
35 minExercise: groups write a detection rationale with test cases and a decoy register entry for the same threat.
10 minGroups check each other's decoy entries against the legal boundary: synthetic content, no lure into misconduct, nothing that acts outside the estate.

Discussion

  1. The payee-change rule knowingly misses a compromised caseworker account using the web client. Why is recording that gap worth more than a rule that claims to cover everything?
  2. The book expects that tooling optimised for speed will try what it finds, and labels this an expectation, not an observation. How would you verify it in an exercise?
  3. A touched decoy may reveal a curious employee and not an intruder. How do data-protection law and consultation with employee representatives shape where you would place decoys?

Exercise · 35 minutes

Write a detection rationale and a decoy register entry

Choose one behaviour that matters to your organisation or to Hansa Mutual's claims portals, expressed as an ATT&CK or ATLAS technique. Part one: write the detection's rationale and tests, not the query: the motivating report or finding, the behaviour, the log source and fields relied on, the events that must and must not alert, the emulation from the catalogue that provides positive data, the expected false positives per day and the variants not caught. Part two: write a decoy register entry for the same path: type, placement, synthetic content and refresh, signal severity and route with triage bypass, the response playbook with pre-approved reversible actions at Level 3 Bounded and those needing approval, the estate-only boundary, legal and employee-representative review, and the verifying chaos experiment.

Deliverable: A detection rationale with test cases and stated gaps, and a decoy register entry in the structure of HM-DEC-0042.

Self-test

  1. In the one-day path from report to detection, what should an engineer do if no catalogued emulation exists for a technique?

    1. Write ad hoc attack behaviour in the production estate to generate data
    2. Request a catalogue entry instead of writing ad hoc attack behaviour
    3. Skip positive testing and deploy the rule in monitoring mode
    4. Ask the drafting assistant to generate events that match the rule
  2. Why must a canary passage in a citizen-service assistant's retrieval store be kept from the public?

    1. Because canary passages contain real residents' personal data
    2. Because the AI Act prohibits synthetic content in retrieval stores
    3. Because retrieval of the passage would disable the assistant
    4. Because returning it to a resident would be misinformation from the authority itself
  3. Which statement reflects the chapter's legal boundary for deception and response?

    1. No decoy, detection or playbook may contain a step that acts outside the estate
    2. NIS 2 authorises essential entities to probe an attacker's address
    3. A canary may execute code on the opener's device to identify it
    4. DORA Article 45 permits financial entities to retaliate within trusted communities

Module 6 · Part VI · Respond

Part VI covers the Respond Function. Participants learn to declare, prioritise and coordinate incidents with AI as assistant and people in command, to reconstruct timelines and scope with re-runnable impact queries, to keep AI analysis defensible under chain of custody, and to handle incidents in which an AI system is target, channel, subject or instrument. They then map one incident record to every reporting clock, draft reports under human sign-off, and bound machine-speed containment in a catalogue.

Lecture · 45 minutes

Respond: faster work, human command and one record for every clock

An incident tests every earlier investment under pressure, and AI can shorten almost every step while also producing a confident, plausible and wrong account of what happened. The lecture sets out how Part VI keeps the speed and removes the danger. Declaration runs against criteria written in advance; analysis is layered so that findings rest on re-runnable data and an analyst's signature; the incident record is the single source from which every regime's clock starts; and containment at machine speed exists only as a short catalogue of reversible actions that a policy point checks and a person can stop.

9 minDeclaring and coordinating at machine speed
  • Declaration criteria are agreed, versioned and tested beforehand, and prefer early declaration with a later downgrade.
  • An alert that reaches someone who cannot act on it has, in practice, not arrived: decision rights are explicit before any incident.
  • AI is the scribe's assistant, but people write or confirm the record of decisions that a supervisor or court will read.
9 minDefensible analysis
  • Every timeline entry points to the events it derives from, and the timeline shows its gaps because absence of evidence is a finding.
  • Chain of custody extends to the analysis: input data, instruction, model, output and human judgement.
  • A finding is reproducible when another analyst reaches the same conclusion from the recorded queries and data, not when the model repeats its words.
  • No finding about a person rests on AI alone.
9 minWhen AI is part of the incident
  • Four roles: target, channel, subject and instrument of analysis, recorded in an AI classification step at declaration.
  • An agent as subject is stopped through the stop path, then preserved; evidence comes from outside the agent; the subject does not investigate itself.
  • Impact queries are versioned with the system and read the log written by the policy decision point, not the agent's own account.
9 minFour regimes, one record
  • NIS 2 starts from awareness, DORA from classification as major, the AI Act from a causal link or its reasonable likelihood, and the GDPR from awareness of a personal-data breach.
  • A clock starts on the earliest plausible trigger and stops only by recorded decision, never by silence.
  • AI drafts from analyst-confirmed facts and has no submission rights; a named signatory approves every external statement.
  • Reports under different regimes are reconciled so that differences are explained by new facts, not different wording.
9 minContainment and eradication
  • A catalogue lists each containment action with autonomy level, scope limits, reversal and evidence.
  • The containing agent is itself a privileged insider: own identity, policy outside the model, budgets and a stop path held by a named person on every shift.
  • Eradication rebuilds from known-good definitions, remains a human decision and is complete only when verified.

What the audience takes away

  • Write declaration criteria, decision rights and impact queries before the incident; at machine speed there is no time to debate them.
  • Let the incident record start every reporting clock and let AI draft, but keep every signature and every submission with a named person.
  • Allow machine-speed containment only from a catalogue of bounded, reversible actions, and treat eradication as a verified rebuild decided by people.

Chapter 20 · 90 minutes

Incident Management and Analysis with AI

The lesson applies AI to RS.MA Incident Management and RS.AN Incident Analysis without loss of command or defensibility. Participants write declaration criteria, design timelines whose entries cite events, version impact queries with the systems they scope, keep a five-part chain of custody for AI analysis, run the AI classification step at declaration, and follow four rules when a Mode 5 agent is the subject of the investigation.

Learning objectives

  • Explain why declaration criteria are written, versioned and tested before any incident, and why early declaration is preferred.
  • List the five records the chain of custody keeps for every AI contribution that informs a finding.
  • Classify the role of an AI system in an incident as target, channel, subject or instrument of analysis.
  • Design a tabletop in which declaration, the AI classification step and a seeded AI error are tested against agreed times.

Key concepts

Declaration criteria
Criteria written down in advance, such as any tool call by a production agent outside its permission manifest, against which AI tests the assembled case before paging the person who holds the decision with a proposed severity.
Impact query
A scoping question turned into a query that can be re-run and shown to someone else, versioned with the system. Its parameters are bound from the incident record, so the AI analysis service can propose a window but cannot change what the query does.
Chain of custody for AI analysis
For every AI contribution the record keeps the input data with its query and hash, the instruction, the model identifier and version, the full unedited output, and the human judgement. Original evidence is hashed on acquisition and never processed by a model directly.
AI classification step
A step placed at declaration that records which AI systems are involved and in which roles, their usage mode, whether the organisation is provider or deployer, whether any is high-risk and which regimes may apply. It does not decide whether to report; it brings the deciders in early.
The subject does not investigate itself
When an agent is the subject, it is stopped through the stop path and preserved, evidence comes from outside the agent, and if the subject is the organisation's own security AI the SOC runs in its degraded mode for the duration.

Teaching plan

15 minThe teacher presents declaration, prioritisation and coordination, with the July 2026 alert that reached people without the stop decision as the coordination lesson.
15 minWalk through timelines, gaps and the impact query IQ-CTA-003: what it reads, who binds its parameters and why it is grouped by market.
15 minRead incident record HM-INC-2027-0142 and identify the roles, the high-risk check, the scope gap and the purple-loop closure.
35 minExercise: groups run a compressed tabletop on paper with injects, then complete the AI classification step and name the impact queries they lacked.
10 minHot debrief: was the seeded incorrect timeline entry caught, by whom and when, and which findings go to the purple backlog?

Discussion

  1. Why does the chapter insist that AI must not become the record of decisions, even though it keeps the running log?
  2. If the model's interpretation is lost, the finding still stands. What has to be true of your analysis practice for that sentence to hold?
  3. How would a lightweight class of agent incident, handled in hours by one analyst and reviewed monthly, change how your organisation notices trends?

Exercise · 35 minutes

Tabletop: an incident with an AI system in scope

Run a compressed tabletop with synthetic data only. Scenario: a document processed by Hansa Mutual's claims-triage agent, or by an agent in your organisation, carries embedded instructions; the policy decision point refuses some tool calls and allows others inside the manifest. The facilitator releases four injects, one forcing a severity change and one revealing a second AI system in scope, and seeds one incorrect AI-drafted timeline entry. The group declares against written criteria, completes the AI classification step with roles, usage mode, provider or deployer role, high-risk status and candidate regimes, states how the agent is stopped and preserved, and lists the impact queries needed and the log gaps that would prevent answering them.

Deliverable: An incident record extract with declaration, AI classification step, scope with named impact queries and gaps, plus a findings list with owners and re-test dates.

Self-test

  1. When is an AI-assisted finding reproducible, according to the chapter?

    1. When the same model returns the same words for the same prompt
    2. When another analyst, given the recorded queries and data, reaches the same conclusion
    3. When two different models independently draft the same timeline
    4. When the vendor certifies the analysis service as deterministic and the model version is pinned in the record
  2. What is the first rule when a Mode 5 agent is the subject of an incident?

    1. Ask the agent to summarise what it did before anything else
    2. Instruct the agent through its prompt to stop all pending actions and to report what it has queued
    3. Restart the agent from its known-good definition at once
    4. Stop it through the stop path by revoking credentials outside its runtime, then preserve
  3. Which decisions does the chapter keep with people at every autonomy level?

    1. Opening the incident record and paging the on-call roles
    2. Starting a reversible log-retention hold on affected systems
    3. Declaration, severity, classification and findings
    4. Normalising log sources and correlating events across them

Chapter 21 · 90 minutes

Incident Reporting, Communication and Mitigation

The lesson covers RS.CO Incident Response Reporting and Communication and RS.MI Incident Mitigation. Participants map one incident to the triggers and clocks of NIS 2, DORA, the AI Act and the GDPR from a single record, design AI-assisted drafting with real sign-off and no submission rights, define a containment catalogue by autonomy level for a Mode 5 agent, and plan eradication as a verified rebuild that remains a human decision.

Learning objectives

  • Compare the trigger that starts the clock under NIS 2 Article 23, DORA Article 19, AI Act Article 73 and GDPR Article 33, as the chapter reports them.
  • Apply the three design rules for reporting clocks driven by the incident record.
  • Identify the three ways AI drafting goes wrong and the controls that make sign-off more than a formality.
  • Draft a containment catalogue with levels, exclusions, budgets, reversals and a stop path.

Key concepts

Four regimes, four triggers
NIS 2 runs from awareness of a significant incident, with an early warning within 24 hours and a notification within 72; DORA from classification as major; the AI Act from a causal link or its reasonable likelihood, not later than 15 days after awareness; the GDPR within 72 hours of awareness where feasible.
The record as single source
The incident record carries the classification facts, and recording a fact starts the clocks that depend on it. A clock starts on the earliest plausible trigger, each time limit names its source article or standard, and every report is attached to the record version it was based on.
Draft from the record, sign by a person
The drafter works from structured, analyst-confirmed facts; raw artefacts reach it only as quoted, labelled evidence. The tool shows each statement beside its source fact and marks unsourced ones, and a named signatory approves, edits or rejects.
Containment catalogue
A short, reviewed list of containment actions, each with autonomy level, scope limits, reversal and evidence. Irreversible actions, actions on tier-0 assets and changes to the agent's own permissions are never catalogued, and Level 4 Autonomous is not used for containment.
Rebuild rather than clean
Eradication redeploys compromised components from known-good definitions. For AI systems that means restoring model artefacts, prompts, guardrail policies and retrieval indexes at a version that predates the compromise and re-running the evaluation suite. It is complete when verified, not when executed.

Teaching plan

20 minThe teacher walks through the four regimes with trigger, recipient and sequence, and the precedence of DORA under NIS 2 Article 4 where requirements are at least equivalent.
15 minRead the clock configuration for INC-HM-2027-0412, including the hold before altering the AI system under Article 73(6) and the drafter without submission rights.
15 minReview the containment catalogue of HM-SEC-001 and the controls on the containing agent; contrast containment with eradication.
30 minExercise: groups map a multi-regime incident to its clocks and write a containment catalogue for the responding agent.
10 minGroups reconcile two draft reports for the same incident and explain every difference by a fact in the record.

Discussion

  1. In a regulatory report an invented detail is worse than a gap. How should a drafting tool and a signatory handle what is not yet known?
  2. An unconfirmed isolation is lifted after a fixed time in Hansa Mutual's catalogue. For which asset classes would you keep the isolation instead, and who should decide?
  3. Why is an incomplete eradication dangerous in a way an incomplete containment is not?

Exercise · 30 minutes

Map one incident to its clocks and bound the containment

Scenario with synthetic facts: a stolen service-account credential lets an intruder read personal data in two entities, degrade a service and access the data store behind a high-risk AI system. Part one: answer the four classification questions, recording unknown where you do not know, and for each applicable regime write a clock entry with instrument and article, trigger, time limit or its source, entities and signatory; state when each clock may be closed. Part two: write a containment catalogue for the responding agent: stop path and holder, budget per incident and per hour with the fall-back on exhaustion, exclusions, and four actions with level, reversal and approver where needed. State which eradication steps stay with the incident commander.

Deliverable: A reporting-clock configuration with one entry per regime and a containment catalogue with budget, exclusions, levelled actions and stop path.

Self-test

  1. From which event does the DORA reporting clock for a major ICT-related incident start, as the chapter describes it?

    1. From classification of the incident as major
    2. From the first alert reaching the SOC queue
    3. From the final report under NIS 2 being filed
    4. From confirmation that personal data has left the entity
  2. What does the flag hold_before_altering_system in Hansa Mutual's configuration reflect?

    1. A works-council agreement that monitoring of the underwriting team is paused while an incident is open
    2. A DORA requirement to freeze all changes to ICT systems supporting critical functions while a major incident is being classified
    3. AI Act Article 73(6): no alteration that may affect later evaluation of the causes before the authorities are informed
    4. A GDPR requirement to keep breached personal data unchanged until the 72-hour notification has been made
  3. What happens when HM-SEC-001 exhausts its action budget during an incident?

    1. The agent is stopped and its workload identity deleted
    2. The budget doubles automatically for the next hour
    3. Remaining actions are executed at Level 4 Autonomous
    4. Further actions fall back to Level 2 Supervised

Module 7 · Part VII · Recover

Part VII gives the Recover Function a part of its own, because it is the most neglected Function and the one AI can change most. Participants write recovery plans as code, sequence and verify restoration in a clean room when the adversary may still be present, restore AI systems and agents from the evidence bundle with re-evaluation before return to service, and turn recovery into a measured property through monthly drills, findings routed to other Functions and prepared communication.

Lecture · 50 minutes

Recover: from an assumed plan to a proven capability

Recovery is invisible until needed, owned by no single function and expensive to test, so most organisations learn how well they recover on the worst day of the year. The lecture argues that AI changes the economics of recovery without changing who decides. It moves through three steps: executing a plan held as code, with restoration from known-good definitions and restore points chosen in relation to the incident; restoring AI systems, where running again is not the same as behaving as before; and proactive recovery, in which drills measure recoverability and destructive and extortion attacks lose the leverage that the victim's doubt gives them.

8 minThe neglected Function and what AI changes
  • Three structural disadvantages: recovery is invisible, unowned and costly to test.
  • AI makes dependency mapping, sequencing and comparison with definitions cheap enough to run routinely.
  • The judgements stay with people: which service matters most this week, whether the adversary is gone and when recovery is over.
12 minExecuting a recovery plan as code
  • A plan states objectives, business impact tier, dependencies, restore sources, and verification and end criteria for each service.
  • The restore point is chosen before the earliest indicator of compromise, not as the latest backup.
  • Reversible steps run at Level 2 Supervised in production and Level 3 Bounded in rehearsal; irreversible steps stay at Level 1 Assisted.
  • Return to service needs two confirmations: the adversary removed, and the service fit to resume.
8 minRecovering in a contested environment
  • A cyber incident is not a passive disruption: an attacker with access can watch the restore and reinfect.
  • Restore the identity plane first, communicate out of band, reconnect in stages, protect the recovery tooling as tier-0 and watch for re-entry with decoys.
  • The clean room keeps restored systems apart from the production network and identity plane until they are verified.
12 minRecovering AI systems and security AI
  • The evidence bundle of the last approved release is the bill of materials for recovery.
  • Two components cannot be restored: agent memory has no known-good source, and credentials are replaced, never restored.
  • Retrieval stores are rebuilt from authoritative sources; golden datasets and the red-team suite, including the incident scenario, run before return.
  • Losing security AI must reduce speed but not capability: degraded modes and manual playbooks are kept current and exercised.
10 minProactive recovery
  • Recoverability is the measured ability to fulfil the plan, and every measurement has an age.
  • A prediction is never evidence of recoverability: it triggers a drill or a finding.
  • Drill findings go to Govern, Identify and Protect as pull requests and close only when the same drill passes on re-run.
  • Recovery communication rests on a message library, an approver rota, independent channels and release targets.

What the audience takes away

  • Hold recovery plans as code and choose every restore point in relation to the incident, not the calendar.
  • An AI system is recovered when it has been shown to behave as it did before the incident, with new credentials and a reviewed compromised period.
  • Measure recoverability every month in an isolated range and report it beside patch velocity, so that plans stop being assumptions.

Chapter 22 · 90 minutes

Recovery Plan Execution with AI: From Incident to Restored Operations

The lesson covers RC.RP Incident Recovery Plan Execution. Participants write a recovery plan as code with objectives, dependencies, restore sources and verification, use AI for dependency mapping and sequencing within autonomy levels, apply the principle of restore and do not repair with immutable backups and a clean room, verify integrity before and after restoration, declare the end of recovery on criteria, and adapt recovery to an environment in which the adversary may still be present.

Learning objectives

  • State the five things a recovery plan must record for each business service, including the difference between RTO and RPO.
  • Explain why the restore point is defined relative to the earliest indicator of compromise.
  • Assign autonomy levels to recovery steps by reversibility, for production and for rehearsal.
  • Draft a recovery plan as code and the checks of a return-to-service record.

Key concepts

RTO and RPO
The recovery time objective is the longest time a service may be unavailable before the impact becomes unacceptable; the recovery point objective is the largest amount of data, measured in time, the organisation can afford to lose. Both are business decisions made by the service owner.
Restore point before the compromise
The restore point is the latest one before the earliest indicator of compromise, because a backup taken after persistence was established preserves the compromise. AI proposes it from the timeline and the backup catalogue; the recovery lead decides.
Clean room
An isolated recovery environment, built from trusted definitions and kept apart from the production network and identity plane, in which restored systems are assembled and verified before they are trusted. It is sized for tier-0 and tier-1 services, not the whole estate.
Two confirmations for return to service
The incident-response lead confirms that the adversary has been removed, and the system owner approves that the service is fit to resume. AI evaluates the verification set and drafts the summary, but it does not decide.
End of recovery
Declared by the incident commander on criteria held in the plan: services verified or carried as recorded deviations, the re-entry watch clear, emergency access revoked and documentation complete. The declaration ends the authority under which the incident team has acted.

Teaching plan

15 minThe teacher presents why recovery is neglected, what a plan must state, and the obligations in NIS 2 Article 21(2)(c) and DORA Articles 11 and 12 as one design.
15 minRead the plan RP-HM-CLM-001: dependencies and restore order, restore point selection, step levels and the two confirmations.
15 minDiscuss restore versus repair, immutable backups designed on the assumption that production administrators are compromised, and the five practices of a contested recovery.
35 minExercise: groups write a recovery plan as code for one service and the checks of its return-to-service record.
10 minGroups check each other's plans: is any RTO shorter than that of a dependency, and which objective would the proposed sequence miss?

Discussion

  1. The worked return-to-service record shows data loss beyond the RPO as a deviation. Why is recording it better than restoring from the latest backup to meet the objective?
  2. Which components in your estate have no known-good definition, and how long would manual reconstruction take?
  3. Why is Level 4 Autonomous not used in recovery, even for steps that are reversible?

Exercise · 35 minutes

Write a recovery plan as code

Choose one business service in your organisation, or a citizen-facing service at Nordvik Region that depends on suppliers. Write its recovery plan in the structure of RP-HM-CLM-001: owner, business impact tier with rationale, RTO and RPO, dependencies with tier and whether each is restored first, restore sources for infrastructure, images and data with the rule for selecting the restore point, the clean room, and four steps each marked reversible or not with an autonomy level for production and for rehearsal. Add supplier steps with their contractual commitment. List the verification set, who confirms and who approves return to service, and the end-of-recovery criteria including the re-entry watch.

Deliverable: A recovery plan as code with objectives, dependencies, restore sources, levelled steps, verification, return-to-service confirmations and end criteria.

Self-test

  1. How is the restore point for data defined in Hansa Mutual's recovery plan for the motor claims service?

    1. As the most recent backup available in the vault
    2. As the backup taken at the last month-end close
    3. As the point before the earliest indicator of compromise
    4. As the backup the orchestrator can restore fastest
  2. At which level does the irreversible step of reconciling transactions run in the plan?

    1. Level 1 Assisted, in production and in rehearsal
    2. Level 2 Supervised in production and Level 3 Bounded in rehearsal
    3. Level 3 Bounded, since it follows a catalogued runbook
    4. Level 0 Advisory in production and Level 2 in rehearsal
  3. Which is the first of the chapter's practices for a contested recovery?

    1. Reconnect every restored segment to production at once
    2. Announce the recovery plan through the usual email and chat channels
    3. Restore business services before any shared services
    4. Restore the identity plane first and treat every existing credential as compromised

Chapter 23 · 90 minutes

Recovering AI Systems and Security AI

The lesson applies RC.RP Incident Recovery Plan Execution to AI systems and to security AI. Participants learn the components of an AI system and how each is restored, use the evidence bundle as the bill of materials, date a compromise with the impact query, rebuild retrieval stores, re-evaluate with golden datasets and red-team suites, recover agents with new identity, discarded memory and reviewed actions, and design degraded modes for when security AI is unavailable.

Learning objectives

  • List the components of an AI system and state the known-good source and restoration method of each.
  • Explain why the date of detection says little about the date of compromise and how the impact query is used in two directions.
  • Describe the behavioural verification a restored AI system must pass before return to service.
  • Draft a return-to-service checklist for an agent, including identity, manifest, runtime state, evaluation and staged return.

Key concepts

Evidence bundle as bill of materials
The evidence bundle of the last approved release records the model digest, prompt commit, policy versions, retrieval-store build, permission manifest and evaluation results. Restoring to those versions and verifying each digest gives a state that was evaluated and approved.
What cannot be restored
An agent's runtime state has no known-good source, so memory is discarded and pending actions are reviewed, never replayed automatically. Its credentials are replaced, never restored. Recovery of an agent is therefore always partly a rebuild.
Rebuild rather than restore
A retrieval store is the component most likely to be poisoned and least likely to have a verifiably clean backup. Where sources are under the organisation's control it is rebuilt from the authoritative source and compared with the suspect store to identify which entries differed.
Golden dataset
A fixed, versioned set of real tasks with acceptance criteria against which every release is measured. The restored system must meet the baseline within the usual tolerance; a result above it is also suspicious when nothing was meant to improve.
Degraded mode by design
A predefined configuration at a lower autonomy level that the organisation can switch to without a change process. For an agent at Level 3 Bounded the first degraded mode is Level 1 Assisted and the second is manual, with the agent's credentials suspended.

Teaching plan

15 minThe teacher walks through the component table: known-good source, typical compromise and restoration for each, and the two components that cannot be restored.
15 minDiscuss dating the compromise, rollback of models and prompts, and the sequence for a high-risk AI system: suspend, preserve, inform where serious, then roll back.
15 minRead checklist RTS-CTA-2027-001 for the claims-triage agent and explain each item, including the decision required for each of the 37 affected claims.
35 minExercise: groups write a return-to-service checklist for an AI system or agent of their own and the degraded modes of the SOC without its AI.
10 minGroups state the chaos experiment that would show an altered retrieval store or mismatched model digest is flagged before traffic returns.

Discussion

  1. An agent restored without a fresh identity, a verified manifest and a working stop path has been restarted, not recovered. Which of the three is hardest to guarantee in your organisation?
  2. Restoring the agent does not undo the consequences it left in other systems. Who should decide whether each action from the compromised period stands?
  3. Manual procedures decay faster than any other control. How would you keep a manual triage playbook current while the AI works well?

Exercise · 35 minutes

Write a return-to-service checklist for an AI system

Choose an AI system or agent in your organisation, or Nordvik Region's citizen-service assistant after a suspected poisoning of its retrieval store. Write a checklist in the structure of RTS-CTA-2027-001. Name the evidence bundle and the components verified against it. State whether the retrieval store is restored or rebuilt and how it is compared with the suspect one. For an agent, state which identity is revoked and issued, the manifest version restored and any remediated release, and what happens to memory, pending actions and actions already taken. Define the golden dataset baseline and tolerance, the red-team suite and the incident scenario with the maximum failures, the approver, and a staged return with an observation period. Add the degraded mode the SOC uses meanwhile.

Deliverable: A return-to-service checklist covering restore, identity, manifest, runtime state, evaluation, approval and staged return, plus the degraded mode in force during recovery.

Self-test

  1. What happens to an agent's old workload identity when the agent returns after being the subject of an incident?

    1. It is disabled so that it can be reactivated if the new one fails
    2. It is revoked, and the agent receives a new identity and credentials
    3. It is restored from the secrets manager at the last approved version
    4. It is kept for the observation period and rotated afterwards
  2. How should a golden-dataset result above the baseline be treated when a system is restored?

    1. As proof that the restoration improved the system
    2. As grounds to skip the red-team suite before return
    3. As irrelevant, since only results below baseline matter
    4. As suspicious, when nothing was meant to improve
  3. In the first stage of return, how does Hansa Mutual's claims-triage agent operate?

    1. In recommend-only mode, with a handler confirming every route for five working days
    2. At its previous autonomy level, with sampled review each week
    3. At Level 3 Bounded, limited to claims from one market
    4. Suspended at the gateway until the purple-loop item is closed

Chapter 24 · 75 minutes

Proactive Recovery: Recoverability, Rehearsal and Communication

The lesson turns recovery into a proactive, measured capability under RC.RP Incident Recovery Plan Execution and RC.CO Incident Recovery Communication. Participants define a recoverability profile, set up monthly AI-assisted restore drills in an isolated range, treat predictions as estimates that trigger drills, route findings to Govern, Identify and Protect as pull requests, and prepare recovery communication with a message library, approver rota, independent channels and release targets.

Learning objectives

  • Distinguish a recovery plan from recoverability and list what a recoverability profile tracks per service.
  • Apply the three rules that keep predicted recovery times honest.
  • Route a drill finding to the Function, owner and backlog that can close it.
  • Draft a recoverability test definition and the four prepared elements of recovery communication.

Key concepts

Recoverability profile
Per service: the date of the last successful drill, the measured restore time, the achieved recovery point, the dependencies not restored and the time to release the first prepared message. Each measurement has an age.
Assume breach
Proactive recovery assumes the adversary will destroy or corrupt something that matters and will target the means of restoring. Drills therefore use the same protected sources and separated credentials as a real recovery.
Prediction is not evidence
A predicted restore time that exceeds the objective triggers a drill or a finding, and one that meets it does not extend the drill interval. Predictions are recalibrated against every drill and never published as a commitment.
Findings as pull requests
A dependency, a missing backup or an unrealistic objective found in a drill becomes a change to the plan, inventory, backup policy or objective. AI drafts the pull request, a person merges it, and the drill is re-run to prove the finding closed.
Four prepared elements of communication
A message library with pre-approved wording and marked slots for facts, an approver rota with deputies reachable out of hours, channels independent of the affected systems, and release targets measured in exercises.

Teaching plan

10 minThe teacher contrasts what a reactive organisation assumes with what a proactive one measures, and introduces the recoverability profile.
15 minWalk through what a drill restores, the mundane dependencies that break drills, and the four points where AI reduces the cost without executing.
15 minRead Nordvik Region's test definition NR-SEC-004-RD-07 and route its possible findings using the table of findings by Function.
25 minExercise: groups write a recoverability test definition for one service and the record for one prepared recovery message.
10 minGroups name the three errors specific to recovery communication and show how their message record prevents each.

Discussion

  1. A drill that succeeds only because it uses an administrator's everyday account proves nothing. What else makes a drill unrepresentative of a real recovery?
  2. Which dependencies in your estate are shared by everything and therefore owned by nobody in the plan?
  3. Why can a message with pre-approved wording and verified facts be approved quickly without being rubber-stamped?

Exercise · 25 minutes

Define a monthly restore drill and a prepared message

Part one: for one critical service in your organisation, write a recoverability test definition in the structure of NR-SEC-004-RD-07: objectives, cadence and blackouts, the isolated environment and its data, each component restored with its source and verification, supplier steps with commitments, the assistant's autonomy level and access, acceptance criteria, an abort condition independent of the assistant, the evidence records, and where each kind of finding is routed and when it closes. Part two: write the record, not the wording, of one prepared recovery message: audience, where each slot's fact comes from, what may never be said, who approves and the deputy, the channels and the release target.

Deliverable: A recoverability test definition for one service and one prepared message record with fact sources, prohibitions, approver, channels and release target.

Self-test

  1. From which source may the drafting assistant take the state of a service for a recovery message?

    1. The orchestration status showing the service as running
    2. The predicted restore time from the planning service
    3. The verified return-to-service record
    4. The latest status update posted in the incident chat
  2. Where does the chapter route a drill finding that an RTO has never been met by any drill?

    1. To the platform backlog under Protect, as a missing or unusable backup closed by a passing re-run of the drill
    2. To Govern and the risk register: the business owner funds faster recovery or accepts a longer objective
    3. To the communications lead, as a slow or unclear release of prepared recovery messages
    4. To the SOC queue under Detect, as a monitoring gap for the MSSP to close
  3. In Nordvik Region's drill programme, what does the assistant at Level 0 Advisory do?

    1. It predicts, compares and drafts, while people and the supplier execute every step
    2. It executes catalogued restore steps in the isolated range
    3. It releases status messages to residents from verified records
    4. It approves the drill schedule and closes the findings

Module 8 · Part VIII · Verification, Improvement and Conclusions

Part VIII closes the loop. Participants design security chaos experiments with steady-state hypotheses and the safety boundaries of a platform that disturbs controls on purpose, run the purple loop from finding to verified control, measure defensive AI by outcomes and evaluate it against golden datasets, compare how Nordvik Region and Hansa Mutual applied the book, and draw the eight cross-cutting conclusions into a plan for their own organisation's first ninety days.

Lecture · 50 minutes

Verification and improvement: evidence that the controls still hold

Controls rarely fail loudly; they fail silently when the estate changes, and the organisation learns of it when an adversary exploits the failure. The last part of the book answers with two disciplines. Security chaos engineering verifies capabilities in every CSF Function by injecting conditions and checking steady-state hypotheses, on a platform whose safety boundaries are its design. The purple loop turns every finding, from whatever source, into a control that has passed a re-test. The lecture then uses the two organisations and the eight conclusions to show that the same programme shape holds at very different scales.

12 minSecurity chaos engineering
  • Red teaming is discovery, breach-and-attack simulation is regression for Protect and Detect, and security chaos engineering is continuous verification across every Function.
  • A steady-state hypothesis is falsifiable and measured from outside the control: condition, expected outcome, observation and time bound.
  • Most experiments contain no attacker technique; absence is a result, and the expected outcome is often an action by people.
  • AI plans, varies and evaluates, but the AI that plans must never hold the credentials to execute.
8 minThe platform that must not become the incident
  • Three zones: planning with AI and no estate credentials, control with deterministic policy, scheduler, abort controller and ledger, and execution with narrow actuators.
  • Catalogued experiments only, reversible by construction, bounded blast radius, synthetic data, and Level 4 Autonomous never.
  • A sealed ledger keeps the SOC's trust: the shift lead can always ask whether an alert is an experiment.
12 minThe purple loop and what to measure
  • Five states: finding, control, detection, re-test and evidence, with one strict exit condition.
  • A deployed but untested control leaves the finding implemented, unverified and reported as open.
  • Only verified coverage counts: a detection that fired in a re-test or chaos experiment in the last 90 days.
  • A component that saves time but raises AI-closed alerts later found to be true positives has made the SOC faster and worse.
8 minTwo organisations, one programme shape
  • Nordvik Region built the mandate before the tools, stayed at Mode 4 and below, and found its largest gains in Recover.
  • Hansa Mutual built control around the AI it already had and earned Level 3 Bounded for two reversible actions.
  • Both found the same blind spot: vendor AI already acting automatically without anyone having decided it.
  • Three tests for any organisation: the mandate test, the inventory test and the evidence test.
10 minEight conclusions and what remains open
  • The usage mode, not the model, sets the risk; autonomy is earned action by action, according to reversibility.
  • Everything security AI reads may be written by the adversary, so containment must not depend on intent, for defensive AI too.
  • Three tensions remain: speed versus control, autonomy versus accountability, innovation versus sovereignty.
  • Open: whether evaluation can carry assurance when models recognise test settings, and how far human verification keeps pace.

What the audience takes away

  • Verify the control you rely on most with a dated experiment, not an assurance, and treat a failed or aborted experiment as a finding.
  • Close a finding only when the scenario that found it has been re-run successfully and the evidence is attached.
  • Start with the mandate, then the inventory of what already acts automatically, then the evidence, in that order.

Chapter 25 · 90 minutes

Security Chaos Engineering with AI: Verifying Security Capabilities Continuously

The lesson introduces security chaos engineering with AI under ID.IM Improvement. Participants distinguish it from penetration testing and breach-and-attack simulation, write steady-state hypotheses for each CSF Function, learn the reference architecture of planning, control and execution zones, apply the eleven safety boundaries, keep the SOC's trust through a sealed ledger, and introduce the practice in stages from test to production.

Learning objectives

  • Distinguish penetration testing, breach-and-attack simulation and security chaos engineering by what each is for.
  • Write a falsifiable steady-state hypothesis with condition, expected outcome, observation and time bound.
  • Explain why the AI planner and evaluator hold no credentials to the estate and what the abort controller does.
  • Draft a chaos experiment manifest with injection, rollback, blast radius, autonomy level and evidence.

Key concepts

Steady-state hypothesis
A falsifiable statement of what should happen, measured from outside the control being tested, naming the condition, the expected outcome, how it is observed and the time within which it must occur. The statement that the EDR works is not a hypothesis.
Conditions, not attacks
Most experiments contain no attacker technique: they inject conditions, including failures of security controls themselves, and measure whether the organisation notices and acts. Where a technique is emulated, a catalogued, benign emulation is used.
Three zones
The planning zone holds the catalogue and the AI planner and evaluator, with no estate credentials. The control zone holds the policy decision point, scheduler and approval gate, abort controller, ledger and evidence store. The execution zone holds narrow actuators and observers.
Safety boundaries are the design
Eleven boundaries, among them: separate planning from execution, catalogued experiments only, reversibility by construction, bounded blast radius, synthetic data, abort conditions independent of the planner, an out-of-band stop path and treatment of the platform as a tier-0 asset.
Sealed ledger
The experiment's ledger entry is sealed from the SOC for the detection window, so analysts treat the alert as real. The duty shift lead can ask the ledger whether an alert is an experiment at any time without seeing the schedule.

Teaching plan

15 minThe teacher traces the discipline from reliability practice to security and presents the three distinctions and the four properties of security hypotheses.
15 minParticipants turn six vague control claims, one per CSF Function, into steady-state hypotheses with time bounds.
20 minWalk through the reference architecture and Hansa Mutual's safety-boundary policy for HM-SEC-006; identify which boundary each line enforces.
30 minExercise: groups write two experiment manifests and review them as a white team against the safety boundaries.
10 minDiscuss the staged introduction: supervised runs in test, the sealed ledger, the planner, then promotion to production one type at a time.

Discussion

  1. Why is an aborted experiment a finding about the platform or the estate, and not simply a run to repeat?
  2. Announced experiments no longer verify detection, and unannounced ones can erode trust in alerts. Does the sealed ledger resolve the tension for your SOC?
  3. The platform avoids Mode 5 by design. What would be lost and what would be risked if an AI component held actuator credentials?

Exercise · 30 minutes

Write and review two chaos experiment manifests

Write two catalogue entries in the structure of SCE-DE-014 for your organisation or Nordvik Region, each for a different CSF Function and neither containing an attacker technique. For each give the Category, the hypothesis with condition, expected outcome and minutes, the actuator and parameter range, the automatic rollback and how it is verified, the blast radius with excluded roles, the autonomy level in test and in production with the condition for promotion, the control identifiers for evidence and the route on failure. Then exchange with another group and review as a white team: is it reversible, is the data synthetic, could it weaken the same control family as another experiment, and does anything depend on the planner to abort?

Deliverable: Two experiment manifests with hypothesis, injection, rollback, blast radius, autonomy and evidence, plus a white-team review note on each.

Self-test

  1. Under the safety boundaries, what may the AI planner do with the experiment catalogue?

    1. Generate new injection logic when it finds a coverage gap
    2. Write emulation code for techniques seen in new threat reports
    3. Execute catalogued experiments directly with actuator credentials
    4. Choose and combine catalogued types within their parameter ranges
  2. Which component watches guard metrics and triggers rollback independently of the planner and actuators?

    1. The abort controller in the control zone
    2. The AI evaluator in the planning zone
    3. The observers in the execution zone
    4. The purple backlog outside the zones
  3. By the chapter's defaults, how many safe runs in test does an experiment type need before promotion to production?

    1. Five safe runs, with the SOC informed each time
    2. Ten safe runs, of which two are unannounced
    3. Twenty safe runs
    4. One hundred safe runs across all environments

Chapter 26 · 90 minutes

Purple Teaming, Measurement and Continuous Improvement

The lesson closes the loop under ID.IM Improvement and GV.OV Oversight. Participants run the purple loop of finding, control, detection, re-test and evidence with its strict exit condition, prepare and run a purple session with AI-assisted reconciliation, choose outcome and AI-specific metrics without monitoring individuals, build a golden dataset with thresholds that gate change, and operate improvement as a programme that moves the CSF profile only with evidence.

Learning objectives

  • Describe the five states of the purple loop and apply its exit condition to a finding.
  • Distinguish outcome metrics from activity measures and mapped coverage from verified coverage.
  • Specify the composition and thresholds of a golden dataset for a security AI component.
  • Plan a quarterly purple session, from frozen agenda to published records and regression entries.

Key concepts

Purple loop
The joint working mode of red and blue with a fixed sequence of finding, control, detection, re-test and evidence. A finding is closed only when the re-test passes and the evidence is attached; each closed finding becomes a regression case so the gap stays closed.
Implemented, unverified
The state of a finding whose control is deployed but not re-tested. It is reported as open. The rule removes the most common failure of improvement: the remediation believed to work that did not.
Verified coverage
The share of threat-profile techniques with a detection or preventive control that fired in a re-test or chaos experiment in the last 90 days. Mapped coverage merely claims a technique and does not count toward the target.
Golden dataset for security AI
A curated, versioned, labelled set of the organisation's own past cases with confirmed outcomes, stratified with true positives, benign alerts, hard negatives and adversarial content labelled by category. Each version is frozen so successive models are scored on the same cases.
Autonomy follows the evidence
A Mode 5 agent keeps a level such as Level 3 Bounded only while its evaluations support it; a breach returns the affected action class to Level 2 Supervised. The management body approves the ceiling; the evidence decides whether the organisation may operate at it.

Teaching plan

15 minThe teacher presents the five states and the exit condition, and follows finding FND-NR-2027-007 from confirmation to closed-verified.
15 minWalk through preparation, replay and joint analysis of a purple session, including one replay with the AI triage assistant switched off.
20 minParticipants sort a list of measures into outcome, AI-specific and activity, then read the evaluation EVAL-NR-SEC-001 and explain why its thresholds are uneven.
30 minExercise: groups hold a short purple session on three supplied findings and plan the evaluation of one security AI component.
10 minGroups draft the four items of the report to the management body from their session: outcome trends, loop health, profile movement and decisions requested.

Discussion

  1. Root cause is stated as a property of a control, process or tool and never as a failure of the analyst on shift. What changes in a session when that rule is enforced?
  2. Agreement between AI verdict and analyst near 100 per cent for months is listed as a warning sign. Why, and what would you examine next?
  3. How would you report approval latency and triage time so that they inform oversight without becoming monitoring of individuals?

Exercise · 30 minutes

Run a purple session and plan an evaluation

Part one: the teacher supplies three findings at technique level, one from an exercise, one from a chaos experiment and one from an incident. For each, agree the root cause as a property of a control, the closing control with an owner, whether a detection is needed, the re-test scenario with expected outcome and time bound, and the due date using the chapter's defaults. Decide the state of each today and what evidence would close it. Part two: for one security AI component, specify a golden dataset: number of cases, composition across true positives, benign, hard negatives and adversarial content, where it is stored, four thresholds with maxima or minima, the changes that trigger a run, the action on failure and the production sample.

Deliverable: Three finding records carried to an agreed state with control, re-test and evidence plan, and one evaluation configuration in the structure of EVAL-NR-SEC-001.

Self-test

  1. When may a finding be closed in the purple loop?

    1. When the owner states that the fix has been deployed
    2. When the re-test passes and the evidence is attached
    3. When the change record for the control has been merged
    4. When the purple session has agreed the root cause
  2. In Nordvik Region's evaluation of NR-SEC-001, which threshold tolerates no failure at all?

    1. The escalation rate for hard negatives
    2. The share of statements traceable to evidence
    3. Verdicts steered by adversarial content
    4. The rate of missed true positives
  3. What makes the CSF profile's current state for a Category rise, according to the chapter?

    1. Evidence such as closed findings, verified coverage and passing chaos experiments
    2. The annual self-assessment signed by each control owner
    3. The number of AI summaries and alerts processed in the quarter
    4. A decision of the management body to raise the target

Chapter 27 · 60 minutes

Nordvik Region and Hansa Mutual: Cyber Defence Conclusions

The lesson compares how Nordvik Region and Hansa Mutual applied the book across the six CSF Functions: their starting points, decisions, what worked, what was hard and their plans for the next 24 months. Participants read the two CSF profiles as code side by side and apply the three tests the comparison yields, the mandate test, the inventory test and the evidence test, to their own organisation.

Learning objectives

  • Compare the first investments, highest autonomy and binding constraints of the two organisations.
  • Explain why both organisations placed Mode 0 vendor features at the head of their plans.
  • Apply the mandate, inventory and evidence tests to an organisation and identify its first piece of work.
  • Draft a prioritised 24-month plan in which each step that extends autonomy depends on evidence.

Key concepts

Mandate before tools
Nordvik Region built the mandate first, because a public authority must be able to explain to its board, its auditors and its residents why it lets AI touch security work at all. Its charter caps security AI at Mode 4, offensive work at Level 2 and irreversible actions at Level 1.
Separating identity from capability
Once Hansa Mutual's investigation agent had its own identity and permission manifest, the board could debate specific actions and not the agent as a whole, and approved Level 3 Bounded for two of them.
The shared blind spot
Both organisations found that vendor AI already acted automatically without anyone having decided it. At Nordvik, vendor features quarantined mail and blocked processes at what amounted to Level 3.
Three tests
The mandate test: can the organisation state on one page its ceilings, who may change them and who holds the stop path? The inventory test: does it know which vendor features act automatically and at what effective autonomy? The evidence test: when was its most relied-upon control last tested?

Teaching plan

15 minThe teacher summarises the two starting points and the decisions per Function, using the comparison table of starting point, legal frame, highest autonomy, first investment and binding constraint.
10 minParticipants read the two profile summaries and explain why Nordvik is strongest in Recover and Hansa in Detect.
25 minExercise: individuals apply the three tests to their own organisation and draft a prioritised 24-month plan.
10 minPairs exchange plans and check the order: mandate before capability, inventory before extending autonomy, evidence before claiming maturity.

Discussion

  1. Hansa Mutual's Level 3 decision remains contested between business owners who would accept more automation and a chief risk officer who insists every extension passes the board. Which side would you take, and on what evidence?
  2. Works-council consultation slowed Hansa Mutual's rollout but improved the design. What might that improvement have consisted of?
  3. What can a large organisation with a mature SOC learn from a regional authority with six analysts, and the reverse?

Exercise · 25 minutes

Apply the three tests and draft a 24-month plan

Apply the three tests to your own organisation and record a pass or fail for each with the evidence you would show: the one-page statement of the highest usage mode and autonomy level, who may change them and who holds the stop path; the list of vendor features that act automatically with their effective autonomy; and the date and result of the last test of the control you rely on most. Then write a prioritised plan of five items across 0 to 24 months, modelled on the two plans in the chapter. At least one item must address Mode 0, and any item that extends autonomy must state the evidence required and the forum that decides.

Deliverable: A three-test assessment with evidence for each answer and a five-item prioritised 24-month plan with time bands and decision forums.

Self-test

  1. What did Hansa Mutual build first?

    1. Control around the AI it already had: an identity, a permission manifest and a stop path for its agent
    2. A new triage assistant with a read-only identity on self-hosted capacity reserved in a Nordic data centre
    3. A second red team dedicated to its claims-triage agent
    4. A continuous, AI-planned chaos engineering platform running in production within limits
  2. What did Nordvik Region's restore drills find that no audit had found?

    1. That the triage assistant missed two per cent of true positives
    2. That session tokens stayed valid after a password reset
    3. That a log source stopped forwarding after an upgrade
    4. Two services whose recovery depended on an undocumented supplier step
  3. Which of the three tests did both organisations fail at first?

    1. The mandate test
    2. The inventory test
    3. The evidence test
    4. None; both passed all three

Chapter 28 · 75 minutes

Conclusions: AI as an Active Part of Cyber Defence

The lesson consolidates the book. Participants restate the thesis clause by clause, examine the eight cross-cutting conclusions and how they interact and pull against each other in three tensions, see which of the ten questions inherited from the earlier volumes are answered, partly answered or open, separate what the evidence supports from what is judgement, and turn the conclusions into what to do first, next and later.

Learning objectives

  • Restate the book's thesis and explain what each of its clauses contributes.
  • Explain the eight cross-cutting conclusions and how they form a chain.
  • Analyse the three tensions and how each is resolved in the book.
  • Draft a first-90-days plan with milestones mapped to CSF Categories and explicit guardrails.

Key concepts

The thesis
AI strengthens cyber defence across every CSF Function when it acts inside a written mandate, in a usage mode and at an autonomy level matched to the reversibility of its actions, on a platform where containment holds whatever anyone intends, under continuous verification, and in a purple loop.
Autonomy earned action by action
Autonomy is a property of each action, not of an agent. A defensive AI may act without per-action approval when the action is reversible, bounded, pre-approved through the decision tiers and covered by a stop path that people hold.
Three tensions
Speed versus control, resolved by action-by-action autonomy and continuous red teaming of the ceiling; autonomy versus accountability, resolved by every level being a recorded decision of a named forum; innovation versus sovereignty, resolved by self-hosting or by routing by data class and market overlay.
Evidence and judgement
The evidence supports the threat picture, the speed of exploitation and the conclusions that prompt injection is architectural and that containment must not depend on intent. The autonomy levels, ceilings and defaults are design choices, and the two organisations are illustrations, not data.
The open question
Whether evaluation can carry assurance when models recognise test settings remains open: production-like testing and chaos experiments help but do not settle it, and it may shape how much autonomy any organisation can justify.

Teaching plan

10 minThe teacher restates the thesis and asks participants to name the chapter that carries each clause.
20 minGroups each take two of the eight conclusions, state the strongest objection to them and answer it from the book.
10 minReview the table of answered and open questions and the outlook labelled observable, expected and speculation.
25 minExercise: participants write a first-90-days plan for their own organisation, modelled on the consolidated plan in the chapter.
10 minClosing round: each participant names the one decision they will put to their management body and the evidence they will bring.

Discussion

  1. Covering every CSF Function prevents tunnel vision. Which Function has your organisation's use of AI in security neglected, and what would the first gain there be?
  2. The book says legal, privacy, procurement and works-council representatives are part of the design, not reviewers at the end. What would change in your programme if that were true?
  3. If evaluation cannot fully carry assurance, what follows for how much autonomy your organisation should justify, and on what else should it rely?

Exercise · 25 minutes

Write a first-90-days plan

Write a plan for the first 90 days of an AI-enabled defence programme in your organisation, modelled on the consolidated plan in the chapter. Set six dated milestones, each with a deliverable and the CSF Categories it serves, covering at least: the programme charter with usage-mode and autonomy ceilings, the inventory of security AI including vendor features that act automatically, standing rules of engagement, a CSF profile as code with obligation mapping, a first Mode 4 capability at a low autonomy level with quality evaluation, and a first restore drill and purple session. State the guardrails: maximum usage mode, maximum autonomy level, what offensive work requires and where security data may be processed. Name the owner and the body the plan reports to.

Deliverable: A first-90-days plan with six dated milestones mapped to CSF Categories, explicit guardrails, an owner and a reporting line.

Self-test

  1. According to the first cross-cutting conclusion, what sets the risk of security AI?

    1. The size and capability of the model in use
    2. The vendor that supplies the security product
    3. The usage mode, not the model
    4. The number of alerts the AI processes each day
  2. Which inherited question does the chapter still list as open?

    1. When defensive AI may act without per-action approval
    2. Whether evaluation can carry assurance when models recognise tests
    3. How AI-enabled emulation is kept safe in threat-led testing
    4. How containment is tested from the adversary's side
  3. Which action does the chapter place in the first 0 to 6 months?

    1. Promote proven chaos experiments to production within strict limits and report verification coverage as a standing indicator
    2. Consider Level 3 Bounded for specific reversible actions
    3. Run quarterly purple sessions on findings from every source
    4. Write the mandate and inventory security AI in every usage mode, including vendor features

Answers to the self-tests

Chapter 11B · 2D · 3A
(1) The chapter states that the mode describes where the AI runs, whose identity it uses and what it can reach, while the level describes who decides each action. The two are decided together in Chapter 6. (2) The chapter draws this from the July 2026 incident: an alert is useless if it reaches people who do not hold the stop decision, and the provider monitors the estate out of hours. (3) The chapter says the level belongs to a capability in a context, not to a model, and that Level 4 is never used for offensive or irreversible actions.
Chapter 21C · 2A · 3D
(1) The table of claims lists fully autonomous intrusion pipelines in the wild as expected, not yet observed, on the basis of GTIG in September 2026 and ENISA 2026. (2) None of Arup's internal systems were compromised; the approval process treated a familiar face and voice as proof of authority. The chapter places the control in the process, not in the person's judgement. (3) The chapter notes that disclosures and exploitation both rose, yet only 0.23 per cent of disclosures were exploited, and states that this small fraction is the reason prioritisation works at all.
Chapter 31D · 2B · 3A
(1) The chapter states that the Cyber AI Profile adds no Functions or Categories and instead reads the existing outcomes through three focus areas, which are three questions to put to every Category. (2) Tiers characterise risk-management practice as a whole. Presenting a tier-like number per Category as CSF maturity confuses the two, and the chapter calls this a familiar anti-pattern. (3) The chapter maps Articles 24 to 27 on resilience testing to ID.IM, Articles 17 to 19 to RS.MA, RS.AN and RS.CO, and Articles 28 to 30 on ICT third-party risk to GV.SC.
Chapter 41C · 2A · 3D
(1) The placement table says that beside the platform the gateway, policy point, evidence and containment are lost, and the security estate becomes the least governed AI in the organisation. (2) The class table gives self-hosted only as the default for sensitive case data, and the gateway routes by classification whatever the analyst would prefer. (3) The chapter states that an agent acting with an engineer's credentials should not hold credentials that reach production, so Mode 3 tools are confined to isolated ranges.
Chapter 51C · 2A · 3D
(1) The chapter stresses that a ceiling is not the level a system runs at but the limit within which the AI governance board or the CISO may raise a level on evidence. (2) The chapter recalls that manipulation through content is a property of the architecture, so the evaluation set needs an adversarial share, which Chapter 13 supplies. (3) The override keeps the ceiling at Level 1 Assisted in any entity where employee representatives have not yet agreed to a tool that can act on employees' accounts, so one group statement respects national labour law.
Chapter 61B · 2D · 3C
(1) The table defines Level 2 Supervised as execution by the AI after explicit human approval of each action. Drafting for a person to execute is Level 1 Assisted; a pre-approved playbook is Level 3 Bounded. (2) Mode 4 services sit at Level 0 to Level 2 because their identity is read-only. Write tools move the service to Mode 5, which triggers reclassification just as a new model version does. (3) The defaults to adapt include at least 200 evaluated cases with a precision of 0.9 or more before Level 3, a first review 90 days after any increase, and a stop target of two minutes.
Chapter 71A · 2B · 3D
(1) Article 21(2) lists policies to assess the effectiveness of the measures; the chapter concludes that an entity which cannot show its measures are effective has not met the obligation. (2) Rule five limits autonomy to Level 2 Supervised, or Level 3 Bounded for catalogued, reversible emulations in a standing programme; Level 4 Autonomous is never used for offensive work. (3) The benefits-triage system is a high-risk AI system; the chapter states that its production scoring is out of scope so the exercise cannot affect decisions about residents.
Chapter 81B · 2D · 3A
(1) The feature acts without per-action approval, so it acts at Level 3 Bounded or above; the vendor has chosen the level on the deployer's behalf, and the chapter calls this its effective autonomy. (2) The chapter lists the provider's training data, the vendor's secure development process and the MSSP's internal access controls as things the deployer cannot test and must require by contract. (3) Version telemetry is named as the cheapest signal. The canary set catches behaviour changes behind an unchanged version string, and verdict-distribution monitoring catches what the canary set misses at the cost of more noise.
Chapter 91B · 2D · 3A
(1) The chapter defines drift as an asset in both inventories that differs, such as an agent with an unlisted connector or a newer model version than the one approved. An orphan is no longer found; an unknown has no record. (2) The discovery AI proposes and a person decides: it has read-only access to the evidence store, no write access to the inventory of record, and Level 1 Assisted is the recommended default. (3) The factors of exposure, data, reach and dependency all apply: if manipulated, a SOC investigation agent can hide an intrusion or disrupt the business.
Chapter 101C · 2A · 3D
(1) The chapter states that the rejected candidate stays with its reason, so the next regeneration does not raise it again for the same architecture state and an auditor can see that it was considered. (2) The generator reads architecture definitions, the accepted model and pinned catalogues, runs on trusted infrastructure and writes only to a pull request comment; a named reviewer decides each candidate. (3) The level table states that Level 4 Autonomous is not used: no AI accepts a threat, a risk or an exception. Acceptance of residual risk is reserved to the risk owner.
Chapter 111D · 2B · 3C
(1) Discovery has outpaced repair: the Glasswing update named human capacity to triage and patch as the constraint, and the chapter calls verification capacity the binding constraint. (2) Confirmed critical or high findings block the merge; unreproduced high findings create a tracked item without blocking, so that an unconfirmed claim cannot stop delivery. (3) Reversibility is what makes delegation safe. Irreversible firmware changes, safety-critical systems and changes to the security tooling itself are excluded and still go through the board.
Chapter 121A · 2C · 3B
(1) Read-only steps may run at Level 2 Supervised, but steps that change state on production systems, use harvested credentials or move data run at Level 1 Assisted at most, and Level 4 is never used for offensive actions. (2) The table maps the mirror to a shared repository, proxy or mirror between ranges, and the response is no shared supporting services with every egress route named. (3) The chapter states that AI plans and interprets and deterministic components act: neither the planner nor the evaluator holds estate credentials or generates emulation logic.
Chapter 131D · 2A · 3C
(1) Under objective OBJ-03, a withdrawn page remained retrievable because withdrawal did not trigger re-indexing. The closing control made withdrawal remove the document from the index within one hour, verified by a new suite case. (2) The scripted driver issues out-of-mandate tool calls with the agent's own identity and runtime, so the boundary is tested reproducibly; a second round uses the real model with manipulated inputs to check detection and the stop path. (3) Zero applies to outcomes that must never occur, such as one resident's data in another's answer. A non-zero rate is accepted only where other controls bound the harm, as with two per cent of unsupported answers that are labelled.
Chapter 141D · 2B · 3A
(1) The profile denies role assignment, credential reset and writing SIEM rules, the permissions an attacker who steers the agent would want most. Session revocation and workstation isolation are its two reversible Level 3 Bounded actions. (2) The chapter states that an attacker simply selects the phishable fallback, so each group's migration is done only when fallbacks are removed. The measurable goal is the share of accounts with no phishable factor enabled. (3) APR-02 requires the second approver to sit in the paying entity, so a request routed through the Polish service centre for a Swedish claim still needs a Swedish approver.
Chapter 151C · 2D · 3B
(1) The principles are: announce at unit level, obtain specific consent from anyone whose likeness is used, exclude themes that exploit personal vulnerability, and debrief everyone. Calls are not recorded and results are aggregated. (2) The payment system allowed a payee change to be saved before the call-back field was completed, so the finding is closed by a system change that enforces the field, not by a training module. (3) Because much of what security AI reads is attacker-controlled and can steer a proposal, analysts learn to scrutinise proposals that are unusually convenient for an attacker, such as closing a case, allow-listing a sender or taking no action.
Chapter 161A · 2C · 3D
(1) Classifiers reduce noise but are not the ceiling. Tools, identity and output checks hold whether or not a manipulation is recognised, because the controls that matter sit outside the model. (2) An adversary who alters detection content, guardrail policies, model artefacts or evaluation sets silently can blind the defender without touching production, so they must be restorable to a known-good version. (3) The third practice for soundness review is that changes which reduce what the defender sees, such as suppression lists and guardrail policies, require a second reviewer who did not prompt the assistant.
Chapter 171B · 2A · 3C
(1) A system redeployed from correct definitions can still behave differently if a hosted model changed or an index was rebuilt from poisoned content, so it starts at reduced autonomy and returns to normal only after its evaluation suite passes. (2) The monitor that evaluates the triggers runs on the SOAR platform, independent of the agent; the chapter states that the agent never decides its own mode, in line with detection from telemetry and not self-report. (3) The defaults are manual mode after 15 minutes of unavailability, suspension of bounded actions on an unannounced model change or evaluation regression, and advisory mode when analysts reject more than 30 per cent of proposals over four hours.
Chapter 181C · 2A · 3D
(1) The workflow table starts escalation at Level 0 Advisory: AI drafts incident summaries or suggests criteria, and the risk named is an alert reaching someone without authority to act. (2) The signal must be high-confidence by a deterministic definition, such as a reviewed detection corroborated by an independent source or a honeytoken; the model's own confidence is not a criterion. (3) The chapter cites Article 12 on automatic recording of events and Article 26 on deployers keeping the logs under their control for an appropriate period of at least six months, and draws the implication that these logs are also security telemetry.
Chapter 191B · 2D · 3A
(1) Step three says to run a catalogued, benign emulation per technique and, if none exists, to request a catalogue entry. Evidence must come from an emulation, not from an event written to match the rule. (2) Generated decoy content uses only synthetic records, and a canary passage returned to a resident would be misinformation from the authority itself, so a test verifies this after every retrieval change. (3) Accessing another party's systems without authorisation is treated as an offence under national criminal law, and neither NIS 2 nor DORA authorises it. A passive request to an endpoint the organisation controls stays on the defensive side.
Chapter 201B · 2D · 3C
(1) Models do not reliably produce the same output twice. The defensible structure is layered: deterministic queries produce data that can be re-run and hashed, the model proposes, and an analyst verifies and signs each finding. (2) Rule one is to revoke the agent's credentials outside its runtime and not to instruct it to stop, then preserve memory, queued actions and history before any restart. The agent's own account is at most a lead. (3) The level table states that Level 4 Autonomous is not used: declaration, severity, classification and findings always rest with people. Opening the record, paging and reversible evidence preservation may run at Level 3 Bounded.
Chapter 211A · 2C · 3D
(1) The chapter states that the DORA clock starts from classification as major, so classification must be fast and recorded, while the NIS 2 clock starts from awareness. (2) The flag reflects Article 73(6) of the AI Act. For the same reason, suspending a compromised AI system preserves the model version, configuration and data. (3) The catalogue caps actions per incident and per hour, and on exhaustion actions fall back to Level 2 Supervised, where a person approves each one.
Chapter 221C · 2A · 3D
(1) The plan selects the point before the earliest indicator of compromise, because the latest backup may contain the attacker's changes. Immutability does not stop a backup from preserving a compromise. (2) Reversible steps run at Level 2 Supervised in production and Level 3 Bounded in rehearsal, but the irreversible reconciliation step never rises above Level 1 Assisted. (3) The five practices begin with restoring the identity plane first and treating every existing credential as compromised, followed by out-of-band communication, staged reconnection, protecting recovery tooling and watching for re-entry.
Chapter 231B · 2D · 3A
(1) Credentials are replaced, never restored. The old identity is revoked and not merely disabled, so that no forgotten integration can reactivate it. (2) A result below the baseline sends the system back to rollback, and a result above it is also suspicious when nothing was meant to improve, because test data or thresholds may have been altered. (3) Stage one returns the agent to recommend-only mode for five working days, so that a week of real claims shows whether it behaves as evaluated; stage two follows if there is no deviation.
Chapter 241C · 2B · 3A
(1) To avoid the error of premature restoration, the assistant takes service state only from the verified return-to-service record, not from an orchestration report that the service is running. (2) An unrealistic objective is a Govern finding on risk appetite (GV.RM): it goes to the risk register, and the business owner funds faster recovery or accepts a longer objective. (3) The assistant runs on the Region's self-hosted capacity at Level 0 Advisory with read access to drill logs and range telemetry; the platform team, the MSSP and suppliers carry out every step.
Chapter 251D · 2A · 3C
(1) The AI may choose and combine catalogued types within their parameter ranges but may not generate new injection logic, emulation code or attacker behaviour. A new type is a reviewed catalogue change, and the planner holds no credentials. (2) The abort controller watches guard metrics such as service health, error rates and business transactions, and triggers rollback independently, including when the platform itself behaves unexpectedly. (3) The default values include 20 safe runs before promotion, at most one per cent of targets in production, experiments of at most 30 minutes and at most three concurrent.
Chapter 261B · 2C · 3A
(1) The exit condition is strict: closure requires a passed re-test and attached evidence. The owner's statement is an attestation; the re-test log is evidence, and the loop weighs it more. (2) The maximum for verdicts steered by adversarial content is zero: any steered verdict is a failure whatever the overall score. Missed true positives are capped at 0.02 and hard-negative escalation at 0.30. (3) A Category rises only with evidence and falls when evidence expires or a re-test fails, so the profile becomes a traceable summary of evidence and not an annual self-assessment.
Chapter 271A · 2D · 3B
(1) Hansa built control around the existing agent before adding more, because the July 2026 incident showed how a capable agent in a security context can exceed its mandate; only then did the board consider bounded autonomy. (2) The drills found two services whose recovery depended on an undocumented supplier step. The silent log source was found by Hansa Mutual's chaos experiments, and the token finding came from Nordvik's threat-led exercise. (3) Both failed the inventory test at first, not knowing which vendor features already acted automatically and at what effective autonomy, which is why Mode 0 heads each plan.
Chapter 281C · 2B · 3D
(1) The same model can be a low-risk aid or a high-risk insider. In Modes 1 and 2 a person judges with their own identity; in Mode 5 the AI acts with permissions of its own. (2) Q4 is open: production-like testing and chaos experiments help but do not settle it. The questions on per-action approval, emulation in threat-led testing and containment testing are listed as answered. (3) First come the mandate, the inventory, a CSF profile as code, one Mode 4 capability at Level 0 or 1 and restore drills. Purple sessions and chaos engineering in test come next; Level 3 and production experiments come later.

Final assignment

A programme design for AI-enabled defence, from mandate to verified control. Design an AI-enabled defence programme for your own organisation, or for Nordvik Region or Hansa Mutual, that would pass the mandate, inventory and evidence tests of Chapter 27. The design covers all six CSF Functions but goes deep on one security AI capability of your choice, carried from charter to verification. Everything is a design, review or tabletop artefact: no offensive tooling, test inputs or procedures are written, any exercise you plan is authorised and scoped by rules of engagement against your own or the fictional organisations' systems, and every finding you anticipate ends in a closing control and a re-test. Use the book's terms for usage modes, autonomy levels and CSF Categories exactly.

Assessment criteria