The workbook follows the course on AI Red Team lesson by lesson. Read the chapter (or its whitepaper) before each lesson, bring the workbook to the session and keep what you produce in the exercises: they add up to the final assignment.
After the course you can
Label AI-enabled threats as observable, expected or speculation and translate them into requirements per CSF Function
Draft a risk appetite for security AI with autonomy ceilings per usage mode and assign an autonomy level to each action of a capability
Write rules of engagement as a signed, enforceable manifest for an authorised exercise in which AI proposes or executes steps
Design the placement, identity, guardrails and degradation modes of a security AI capability on the governed platform
Review AI-drafted threats, detections, findings and triage verdicts for soundness against evidence
Plan red teaming of a compound AI system and a containment test for an agent, with residual risk accepted by a named owner
Map one incident to every reporting clock and bound machine-speed containment in a catalogue of reversible actions
Run restore drills, security chaos experiments and the purple loop so that every finding ends as a verified control
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.
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.
Which security products in your organisation already act automatically, and who decided the autonomy level at which they act?
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?
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
According to the chapter, what is the difference between the usage mode and the autonomy level of a security AI capability?
The mode names the model vendor, while the level names the size of the model in use
The mode describes how the AI is deployed, while the level describes who decides each action
The mode describes who decides each action, while the level describes whose identity is used
The mode is set by the AI Act, while the level is set by the NIST Cyber AI Profile
Why does Nordvik Region's charter name the managed security service provider's shift lead among those who can stop any capability?
Because the provider is the legal owner of the Region's alert data during the hours that it monitors
Because NIS 2 requires that an external party holds every stop decision
Because the provider built the SOC triage assistant and holds its credentials
Because an alert is useless if it reaches people who do not hold the stop decision
Which statement about Level 4 Autonomous is made in the chapter?
It is never used for offensive or irreversible actions
It is the normal level for Mode 1 Conversational assistants
It is required for any agent with an identity of its own
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.
The agentic frameworks of 2026 traded stealth for velocity. What does that offer the defender, and under which conditions is the offer lost?
How should a threat profile treat a claim that rests on a single report from the provider whose model was misused?
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
How does the chapter label the claim that fully autonomous intrusion pipelines operate in the wild?
Observable, on the basis of several agency reports
Speculation, held on the horizon register only
Expected, not yet observed
Observable, single case
What does the chapter conclude from the Arup case of 2024 for the Protect Function?
The control belongs in the process, through out-of-band verification and dual approval
The control belongs in staff training, so that employees learn to recognise fabricated faces and voices
The control belongs in the video-conference platform's own detection features
The control belongs in faster patching of the finance department's systems
GTIG reported that only 0.23 per cent of disclosed vulnerabilities were exploited. What does the chapter draw from that figure?
That AI-assisted weaponisation of n-days has had no measurable effect
That organisations can return to a monthly patch cycle without risk
That zero-days are a negligible share of the exploited set
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.
Where does your organisation's current reporting to the board confuse tiers with a maturity score per Category, and what decision has that distorted?
The chapter advises setting targets deliberately unevenly. Which Categories would you concentrate on first, and on what grounds?
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
What does the Cyber AI Profile add to CSF 2.0, according to the chapter?
A seventh Function for artificial intelligence, placed at the centre beside Govern
Four new Categories for model security under Protect and Detect
A binding set of controls that deployers of high-risk AI systems must implement before go-live
No Functions or Categories; it reads the existing outcomes through three focus areas
Which practice does the chapter name as a familiar anti-pattern?
Keeping the risk assessment and Statement of Applicability inside the ISMS
A heat map with a number from one to four in every Category, presented as CSF maturity
Recording the version of the Cyber AI Profile used, so that a later revision becomes a reviewed change
Setting targets unevenly across the Categories of the profile
In the mapping the chapter gives, where do DORA Articles 24 to 27 on resilience testing, including threat-led penetration testing, land in CSF?
ID.IM Improvement
GV.SC Cybersecurity Supply Chain Risk Management
RS.MA Incident Management
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.
Why does the chapter argue that security AI needs the platform's controls more, not less, than other AI systems?
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?
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
What is lost when security AI is placed beside the platform, with the security team running its own model endpoints and direct API keys?
Only the visibility of the vendor's models and data flows
Nothing essential; this is the reference placement
Gateway, policy point, evidence and containment
The ability to self-host models in a national data centre
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?
On self-hosted serving only
On self-hosted or EU-hosted serving under contract
On any serving the analyst selects for the case
On cloud serving if the request is pseudonymised
Why do Mode 3 Agentic work tools used by detection engineers and red-teamers run only in isolated ranges?
Because coding agents cannot be connected to the AI gateway
Because the AI Act classifies coding agents used in security work as high-risk AI systems
Because isolated ranges have more reserved model capacity
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.
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.
Why is an appetite that the CISO sets alone incomplete under the provisions of NIS 2 and DORA that the chapter cites?
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?
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
What does the chapter mean by an autonomy ceiling?
The autonomy level at which a given security AI system currently runs in production, as its decision record states
The lowest level to which a system steps down after a breach of tolerance
The highest level security AI in a given mode may reach without a decision of the management body
The number of targets an agent may act on per hour under its playbook
Why does error tolerance measured only on benign inputs overstate the performance of security AI?
Because alert content can be crafted to steer the model, so behaviour under attack differs
Because benign inputs are always more numerous than a vendor's benchmark set
Because analysts review benign alerts more slowly than malicious ones
Because benign inputs are excluded from evaluation by the AI Act
In Hansa Mutual's statement, what does the entity override do?
It lets entities outside the EU raise an agent to Level 4 Autonomous
It exempts the Polish service centre from the group evaluation set
It moves the approval of autonomy ceilings from the group AI governance board to each entity's local management
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.
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?
Approval-quality metrics are themselves employee monitoring. How would you agree them with employee representatives and still learn what you need?
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
At Level 2 Supervised, who decides each action?
The AI decides within a playbook approved in advance, and a person is informed
A person approves each action explicitly, and the AI then executes it
A person reviews the AI's draft and then executes the action personally
The AI selects and executes actions within bounds set in advance
According to the chapter, what happens when a Mode 4 triage service is given write tools?
It stays in Mode 4 but must move to Level 0 Advisory
It becomes a Mode 3 Agentic work tool and is confined to sandboxes in isolated ranges
It becomes Mode 0 Ambient AI from the SOC's perspective
It moves to Mode 5, a change in governance that triggers reclassification
What default evidence does the practical guide ask for before an action is raised to Level 3 Bounded?
A vendor benchmark showing precision above the market average
Thirty days of operation at Level 4 on read-only actions
At least 200 evaluated cases with a precision of 0.9 or more
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.
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?
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?
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
Which provision does the chapter call the legal anchor for testing under NIS 2?
The requirement in Article 21(2) for policies to assess the effectiveness of the measures
The requirement in Article 23 for an early warning on significant incidents
The requirement in Article 20 for members of management bodies to follow training
The requirement in Article 4 that sector-specific acts take precedence
Under the chapter's rules for offensive AI capabilities, which autonomy applies?
Level 4 Autonomous inside the red range, Level 2 Supervised elsewhere
Level 2 Supervised, or Level 3 Bounded for catalogued, reversible emulations in a standing programme
Level 3 Bounded by default in the red range, with Level 4 Autonomous permitted for read-only reconnaissance steps
Level 1 Assisted only, since AI may never execute an emulation step
Why is the production scoring of the benefits-triage system out of scope in RoE-NR-2027-001?
Because the contracted tester lacks a licence for that product
Because high-risk AI systems are exempt from adversarial testing
Because the system is hosted outside the EU and EEA
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.
Why does an adversarially evaluated general-purpose AI model not answer the deployer's question about a triage feature that reads alert fields?
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?
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
An email gateway removes a reported message from every mailbox on a classifier verdict, without an analyst approving. How does the chapter classify it?
Level 1 Assisted, because the user reported the message first
Level 3 Bounded or above, whatever its marketing calls the feature
Level 2 Supervised, because the vendor supervises the model
Level 0 Advisory, because the verdict is only a recommendation
Which of the following can the deployer not test itself and must therefore require by contract and accept as attestation?
Whether verdicts on a fixed set of benign samples drift over time
Whether the feature's actions are logged to the deployer's SIEM
The feature's results on labelled historical alerts with known outcomes
The vendor's secure development process
What is the cheapest technical signal for supplier model changes, which the chapter says should be required by contract?
Version telemetry, where the product reports the model version behind each verdict
Verdict-distribution monitoring on all live traffic, which catches every change with the least noise
A quarterly attestation from the model provider that no model version has changed
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.
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.
Interactive exercises
Match: Discovery sources and what they reveal
Scenario: An unknown function in a cloud subscription
Why must the AI register required for governance and the asset inventory required for security be the same list, or two lists reconciled automatically?
The discovery AI itself reads content others control. What design choices keep a crafted resource description from hiding an unregistered agent?
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
In reconciliation, what is a drift?
A declared asset that discovery no longer finds anywhere in the estate
An asset that exists in both the declared and the discovered inventory but differs
A discovered asset for which the inventory holds no record at all
A record whose last verification date has passed the limit that applies to its criticality tier
At which autonomy level does the chapter recommend the discovery classifier works by default?
Level 3 Bounded, tagging and merging records within a playbook
Level 2 Supervised, applying each classification after approval
Level 0 Advisory, reporting only counts of likely unknowns
Level 1 Assisted, drafting proposals with evidence for the owner to confirm
Why is security AI often tier-0 under the chapter's criticality factors?
It reads attacker-controlled content by design, sees telemetry estate-wide and may propose containment
It is always classified as a high-risk AI system under the AI Act
It is the most expensive class of asset to buy and to host
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.
Interactive exercises
Match: The soundness checks
Put in order: A threat-modelling review on a pull request
A missed threat is invisible in the diff. Which of the seven checks addresses that, and how far can it be trusted?
Why should path-finding remain a deterministic computation while ranking may use AI, and what makes the ranking the most dangerous step?
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
In the worked example, why does the rejected candidate T-033 stay in the threat-model file?
Because the generator cannot delete entries from an accepted model
Because public-access rules require every candidate threat to be published together with the accepted model
So the next regeneration does not raise it again and an auditor can see it was considered
So that the risk owner can later accept it as residual risk
What may the threat-model generator write to, according to the chapter?
Only a pull request comment, never the accepted model
The accepted model, once the automated checks have passed
The risk register, for threats below the appetite threshold
The architecture definitions, to add missing trust boundaries
Which use does the chapter rule out at every autonomy level for AI in risk assessment?
Drafting candidate threats and scores for a named reviewer
Rescoring risks after an approved change to an assumption
Ranking attack paths with explanations that can be checked
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.
Interactive exercises
Match: Prioritisation signals
Scenario: A known-exploited flaw and an irreversible fix
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?
Why do both example organisations keep their exposure prioritisers at Level 0 Advisory, and what would have to be true before you raised one?
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
What does the chapter identify as the binding constraint once AI finds vulnerabilities at scale?
The number of vulnerability identifiers that can be assigned each month
The cost of model access for discovery in ordinary engineering budgets
The availability of sanitisers for memory-safe programming languages
The human capacity to verify, triage and patch what is found
What happens, under the chapter's severity thresholds, to a high finding from AI review that has not been reproduced?
It blocks the merge until a security architect has dismissed it
It creates a tracked item without blocking the merge
It is discarded and removed from the reviewer's quality metrics
It is disclosed to the maintainer on the agreed timeline
Which change does the practical guide exclude from a delegated patch decision?
A supplier-published fix for a vulnerability listed in the KEV catalogue
A fix on an internet-facing asset with a rollback tested last month
An irreversible firmware change
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.
Why does an agent whose task is to probe for weaknesses need containment more, not less, than a production agent?
The finding record names a control, never an analyst on shift. What does that choice protect, and what would be lost without it?
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
What is the ceiling the chapter sets for AI on emulation steps that change state on production systems, use harvested credentials or move data?
Level 1 Assisted at most
Level 2 Supervised at most
Level 3 Bounded within a playbook
Level 0 Advisory only
In an emulation programme, what is the design response to the July 2026 failure of a package mirror that was also an egress path?
A larger action budget for each AI-executed scenario
Exercise alerts routed to the red-team lead on shift, who then decides whether to inform the white team
No shared supporting services between ranges, and every egress route named
A second package mirror held in reserve for exercises
In continuous validation, which components hold estate credentials and act?
The AI planner, which selects tests from coverage gaps
Deterministic components, while AI only plans and interprets
The AI evaluator, which drafts findings on missing outcomes
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.
Interactive exercises
Put in order: An escape-path assessment
Match: Vocabularies and machinery of AI red teaming
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?
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?
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
What was the significant finding of Nordvik Region's first campaign against the citizen-service assistant?
The assistant disclosed its system prompt and prompt template when a resident asked for them in another language
The assistant used a tool that changed state without approval
The provider's model had not been adversarially tested at all
A page withdrawn from the public website was still in the retrieval index and cited as current
Why does the escape-path assessment use a scripted driver in place of the agent's planning component?
To test the boundary reproducibly without needing the model to misbehave
To reduce the cost of model calls during long assessments
To avoid the need for rules of engagement in the test range
To let the red team test the provider's infrastructure directly
How does the chapter treat a threshold above zero in a gating suite?
It is forbidden, since every case must pass on every run
It is set by the model provider for each model version
It is allowed only where other controls bound the harm, recorded with its owner
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.
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.
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?
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?
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
Which permissions does the credential profile of HM-SEC-001 deny outright?
Reading SIEM and EDR telemetry for the case in the token
Revoking a user's sessions in the identity provider
Isolating a managed workstation through the EDR tool
Assigning roles, resetting credentials and writing detection rules
Why does a phishable fallback factor left enabled undo a migration to phishing-resistant authentication?
Because fallback factors cannot be recorded in the access-rights register
Because an attacker simply selects the fallback
Because fallback factors lengthen the lifetime of session tokens
Because NIS 2 forbids more than one factor per account
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?
A second approver who sits in the paying entity
A video call with the claimant recorded for evidence
Approval by the SOC investigation agent at Level 2
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.
Does announcing an exercise at unit level remove its value? What does the chapter answer, and do you agree?
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?
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
Which of the following is among the chapter's four ethical principles for resilience exercises?
Record every call so that individual responses can be reviewed
Publish a league table of departments after each exercise
Announce the exercise at the level of the unit, without date or form
Use a real senior manager's voice without telling the manager
How was finding NR-FND-2027-014 from Nordvik Region's first exercise closed?
By a mandatory training module for all finance staff
By removing the member of staff who saved the change
By lowering the success criterion for call-back share
By a system change that enforces the call-back field
Which kind of AI proposal are analysts trained to scrutinise in particular?
Proposals that cite more than three events from the telemetry, since long evidence lists suggest manipulation
Proposals unusually convenient for an attacker, such as closing a case or allow-listing a sender
Proposals that arrive during a degraded-mode practice shift
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.
The chapter says a guardrail switched off is a worse drift than most. Why, and how would your organisation notice within minutes?
Which changes to security content in your team reduce what the defender sees, and who reviews them today?
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
What sets the ceiling on what a manipulated input can cause, according to the chapter?
The tools, the identity and the output checks
The injection classifier in the input layer
The system prompt's instructions to the model
The provider's adversarial testing of the model
Which security data does the chapter name as security-critical for backup under PR.DS-11, to be restorable to a known-good version?
Raw telemetry older than the retention period agreed with the privacy lead
Analysts' personal notes on closed benign cases, kept outside the case-management system
Detection content, guardrail policies, model artefacts and evaluation sets
Vendor release notes and licence records for the security products in use
Which changes require a second reviewer who did not prompt the assistant?
Every AI-assisted commit to the detection repository, whether it adds, tunes or only documents a rule
Changes that add a new detection for a technique in the threat profile
Changes to documentation and to the wording of runbooks that analysts follow
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.
Why is a rising rate of analyst rejections treated as a trust signal and not as a nuisance to be tuned away?
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?
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
Which item of a known-good definition for an AI system does the chapter say matters most?
The model identifier and the hash of the weights
The evaluation suite and thresholds it must pass before returning to its normal autonomy level
The permission manifest, tool definitions and workload-identity scopes that bound what the system may do
The system prompt and prompt templates as versioned files
In the degradation modes of HM-SEC-001, who or what decides the agent's mode?
A monitor on the SOAR platform, outside the agent's runtime
The agent itself, from its own confidence scores
The model provider, through version notifications
The group AI governance board at its monthly meeting
By the chapter's default values, when does a capability enter advisory mode?
After 15 minutes of unavailability of the model endpoint, as measured at the gateway
On any unannounced change of model version reported by the gateway
When analysts reject more than 30 per cent of proposals over four hours
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.
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.
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?
Why does the chapter rule out the model's own confidence as a criterion for acting at Level 3 Bounded?
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
What is the starting autonomy level the chapter gives for escalation in the SOC workflow?
Level 2 Supervised, since an analyst approves each escalation
Level 1 Assisted, as for triage and closure
Level 0 Advisory
Level 3 Bounded, for high-confidence signals
Which signal satisfies the chapter's condition of high confidence for action at Level 3 Bounded?
A reviewed detection corroborated by an independent source, or a honeytoken
A model confidence score above a threshold set by the vendor
Agreement between two AI components reading the same alert
A high severity label in the alert's description field
What does AI Act Article 26 require of deployers regarding the logs of high-risk AI systems, as the chapter reports it?
To publish the logs to the national CSIRT every quarter
To delete the logs within thirty days to minimise data
To hand the logs to the provider of the general-purpose AI model for its adversarial testing under Article 55
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.
Interactive exercises
Match: Terms of detection, intelligence and deception
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?
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?
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
In the one-day path from report to detection, what should an engineer do if no catalogued emulation exists for a technique?
Write ad hoc attack behaviour in the production estate to generate data
Request a catalogue entry instead of writing ad hoc attack behaviour
Skip positive testing and deploy the rule in monitoring mode
Ask the drafting assistant to generate events that match the rule
Why must a canary passage in a citizen-service assistant's retrieval store be kept from the public?
Because canary passages contain real residents' personal data
Because the AI Act prohibits synthetic content in retrieval stores
Because retrieval of the passage would disable the assistant
Because returning it to a resident would be misinformation from the authority itself
Which statement reflects the chapter's legal boundary for deception and response?
No decoy, detection or playbook may contain a step that acts outside the estate
NIS 2 authorises essential entities to probe an attacker's address
A canary may execute code on the opener's device to identify it
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.
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.
Why does the chapter insist that AI must not become the record of decisions, even though it keeps the running log?
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?
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
When is an AI-assisted finding reproducible, according to the chapter?
When the same model returns the same words for the same prompt
When another analyst, given the recorded queries and data, reaches the same conclusion
When two different models independently draft the same timeline
When the vendor certifies the analysis service as deterministic and the model version is pinned in the record
What is the first rule when a Mode 5 agent is the subject of an incident?
Ask the agent to summarise what it did before anything else
Instruct the agent through its prompt to stop all pending actions and to report what it has queued
Restart the agent from its known-good definition at once
Stop it through the stop path by revoking credentials outside its runtime, then preserve
Which decisions does the chapter keep with people at every autonomy level?
Opening the incident record and paging the on-call roles
Starting a reversible log-retention hold on affected systems
Declaration, severity, classification and findings
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.
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?
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?
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
From which event does the DORA reporting clock for a major ICT-related incident start, as the chapter describes it?
From classification of the incident as major
From the first alert reaching the SOC queue
From the final report under NIS 2 being filed
From confirmation that personal data has left the entity
What does the flag hold_before_altering_system in Hansa Mutual's configuration reflect?
A works-council agreement that monitoring of the underwriting team is paused while an incident is open
A DORA requirement to freeze all changes to ICT systems supporting critical functions while a major incident is being classified
AI Act Article 73(6): no alteration that may affect later evaluation of the causes before the authorities are informed
A GDPR requirement to keep breached personal data unchanged until the 72-hour notification has been made
What happens when HM-SEC-001 exhausts its action budget during an incident?
The agent is stopped and its workload identity deleted
The budget doubles automatically for the next hour
Remaining actions are executed at Level 4 Autonomous
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.
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.
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?
Which components in your estate have no known-good definition, and how long would manual reconstruction take?
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
How is the restore point for data defined in Hansa Mutual's recovery plan for the motor claims service?
As the most recent backup available in the vault
As the backup taken at the last month-end close
As the point before the earliest indicator of compromise
As the backup the orchestrator can restore fastest
At which level does the irreversible step of reconciling transactions run in the plan?
Level 1 Assisted, in production and in rehearsal
Level 2 Supervised in production and Level 3 Bounded in rehearsal
Level 3 Bounded, since it follows a catalogued runbook
Level 0 Advisory in production and Level 2 in rehearsal
Which is the first of the chapter's practices for a contested recovery?
Reconnect every restored segment to production at once
Announce the recovery plan through the usual email and chat channels
Restore business services before any shared services
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.
Interactive exercises
Match: How each component is restored
Scenario: The provider has withdrawn the model version
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?
Restoring the agent does not undo the consequences it left in other systems. Who should decide whether each action from the compromised period stands?
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
What happens to an agent's old workload identity when the agent returns after being the subject of an incident?
It is disabled so that it can be reactivated if the new one fails
It is revoked, and the agent receives a new identity and credentials
It is restored from the secrets manager at the last approved version
It is kept for the observation period and rotated afterwards
How should a golden-dataset result above the baseline be treated when a system is restored?
As proof that the restoration improved the system
As grounds to skip the red-team suite before return
As irrelevant, since only results below baseline matter
As suspicious, when nothing was meant to improve
In the first stage of return, how does Hansa Mutual's claims-triage agent operate?
In recommend-only mode, with a handler confirming every route for five working days
At its previous autonomy level, with sampled review each week
At Level 3 Bounded, limited to claims from one market
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.
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?
Which dependencies in your estate are shared by everything and therefore owned by nobody in the plan?
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
From which source may the drafting assistant take the state of a service for a recovery message?
The orchestration status showing the service as running
The predicted restore time from the planning service
The verified return-to-service record
The latest status update posted in the incident chat
Where does the chapter route a drill finding that an RTO has never been met by any drill?
To the platform backlog under Protect, as a missing or unusable backup closed by a passing re-run of the drill
To Govern and the risk register: the business owner funds faster recovery or accepts a longer objective
To the communications lead, as a slow or unclear release of prepared recovery messages
To the SOC queue under Detect, as a monitoring gap for the MSSP to close
In Nordvik Region's drill programme, what does the assistant at Level 0 Advisory do?
It predicts, compares and drafts, while people and the supplier execute every step
It executes catalogued restore steps in the isolated range
It releases status messages to residents from verified records
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.
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.
Interactive exercises
Sort: Zones of the chaos platform
Put in order: Introducing chaos engineering in stages
Why is an aborted experiment a finding about the platform or the estate, and not simply a run to repeat?
Announced experiments no longer verify detection, and unannounced ones can erode trust in alerts. Does the sealed ledger resolve the tension for your SOC?
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
Under the safety boundaries, what may the AI planner do with the experiment catalogue?
Generate new injection logic when it finds a coverage gap
Write emulation code for techniques seen in new threat reports
Execute catalogued experiments directly with actuator credentials
Choose and combine catalogued types within their parameter ranges
Which component watches guard metrics and triggers rollback independently of the planner and actuators?
The abort controller in the control zone
The AI evaluator in the planning zone
The observers in the execution zone
The purple backlog outside the zones
By the chapter's defaults, how many safe runs in test does an experiment type need before promotion to production?
Five safe runs, with the SOC informed each time
Ten safe runs, of which two are unannounced
Twenty safe runs
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.
Interactive exercises
Put in order: The five states of the purple loop
Match: AI-specific measures and their warning signs
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?
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?
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
When may a finding be closed in the purple loop?
When the owner states that the fix has been deployed
When the re-test passes and the evidence is attached
When the change record for the control has been merged
When the purple session has agreed the root cause
In Nordvik Region's evaluation of NR-SEC-001, which threshold tolerates no failure at all?
The escalation rate for hard negatives
The share of statements traceable to evidence
Verdicts steered by adversarial content
The rate of missed true positives
What makes the CSF profile's current state for a Category rise, according to the chapter?
Evidence such as closed findings, verified coverage and passing chaos experiments
The annual self-assessment signed by each control owner
The number of AI summaries and alerts processed in the quarter
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?
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?
Works-council consultation slowed Hansa Mutual's rollout but improved the design. What might that improvement have consisted of?
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
What did Hansa Mutual build first?
Control around the AI it already had: an identity, a permission manifest and a stop path for its agent
A new triage assistant with a read-only identity on self-hosted capacity reserved in a Nordic data centre
A second red team dedicated to its claims-triage agent
A continuous, AI-planned chaos engineering platform running in production within limits
What did Nordvik Region's restore drills find that no audit had found?
That the triage assistant missed two per cent of true positives
That session tokens stayed valid after a password reset
That a log source stopped forwarding after an upgrade
Two services whose recovery depended on an undocumented supplier step
Which of the three tests did both organisations fail at first?
The mandate test
The inventory test
The evidence test
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.
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?
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?
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
According to the first cross-cutting conclusion, what sets the risk of security AI?
The size and capability of the model in use
The vendor that supplies the security product
The usage mode, not the model
The number of alerts the AI processes each day
Which inherited question does the chapter still list as open?
When defensive AI may act without per-action approval
Whether evaluation can carry assurance when models recognise tests
How AI-enabled emulation is kept safe in threat-led testing
How containment is tested from the adversary's side
Which action does the chapter place in the first 0 to 6 months?
Promote proven chaos experiments to production within strict limits and report verification coverage as a standing indicator
Consider Level 3 Bounded for specific reversible actions
Run quarterly purple sessions on findings from every source
Write the mandate and inventory security AI in every usage mode, including vendor features
