Book Blueprint and Chapter Briefs

This blueprint records the editorial intent of AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities, Book 4 of The Transformed Architecture. It is the brief every chapter is written against. The chapter briefs below are generated from scripts/outline_data.py by python3 scripts/generate_outlines.py; edit the data file, not the generated section.

Premise

The first three volumes of the series made architecture, governance and the AI platform executable, and concluded that AI is now both a target and a source of threat. Attackers already use AI to find vulnerabilities, scale social engineering and run parts of intrusions at machine speed, and the time between disclosure and exploitation has collapsed. Defenders who treat AI only as something to protect will lose the race on time alone.

This book argues that AI must become an active, governed part of cyber defence, and shows how large European enterprises and public authorities can make it so in practice. To make sure that no part of cybersecurity is left out, it is organised by the NIST Cybersecurity Framework (CSF) 2.0 and covers all six Functions and all 22 Categories (CSF_COVERAGE.md):

Govern (Part II): context and risk strategy, roles and autonomy levels, policy and rules of engagement, oversight and supply chain.
Identify (Part III): asset management, threat modelling and risk assessment, vulnerability and exposure management, adversary emulation and continuous red teaming, and red teaming of AI systems.
Protect (Part IV): identity and access, awareness and training, data and platform security, infrastructure resilience.
Detect (Part V): the AI-assisted SOC, detection engineering, threat intelligence and deception.
Respond (Part VI): incident management and analysis, reporting, communication and mitigation.
Recover (Part VII): recovery plan execution with AI, recovering AI systems and security AI, and proactive recovery with rehearsal and communication. Recover has a part of its own because it is the most neglected Function in many organisations, and because AI can make recovery fast, verified and proactive rather than an untested promise.

The AI focus comes from the three focus areas of the NIST Cyber AI Profile (NIST IR 8596, initial preliminary draft, December 2025). Every chapter in Parts II to VI treats its Categories through all three: securing AI systems (the organisation's AI, including its security AI, as something to protect), AI-enabled cyber defence (AI as a tool for achieving the Category's outcomes) and thwarting AI-enabled attacks (how the Category must change when attackers use AI).

Red teaming runs through the book rather than sitting in one part. CSF places the improvements identified from security tests and exercises under Identify (ID.IM), so Part III holds adversary emulation and AI red teaming; every other Function is tested by the red team and improved through the purple loop of Chapter 26, and verified continuously by the security chaos engineering of Chapter 25. Part I lays the foundations (threat picture, CSF with an AI focus, reference architecture) and Part VIII verifies, closes the loop and draws the conclusions.

Thesis

AI strengthens cyber defence across every CSF Function when it acts inside a written mandate, at an autonomy level matched to the reversibility of its actions, on a platform where containment holds whatever anyone intends, and in a purple loop that turns every finding into a verified control with evidence.

Audience

Chief information security officers and heads of security operations
Red-, blue- and purple-team leads and practitioners; detection and threat-intelligence engineers
Security and AI architects
Risk, compliance and internal-audit functions that assure security AI
Technology leaders in large enterprises and public authorities, particularly in sectors covered by NIS 2 and DORA

Boundaries

Defensive only. The book describes adversary behaviour at the level needed to design controls, detections, tests and exercises. It contains no exploit code, malware, payloads, jailbreak or prompt-injection strings, phishing templates, evasion techniques or intrusion walkthroughs. Every offensive activity it describes is authorised, scoped by rules of engagement, run against the organisation's own or contracted systems, logged, and closed with a defensive improvement.
No offensive cyber operations. Hacking back and operations against third-party systems are out of scope, and Chapter 19 explains the legal boundary.
Not a repeat of the earlier volumes. Platform construction, AI governance and AI platform security are summarised where needed and referenced by chapter (see SERIES_FOUNDATIONS.md).
Legal content is attributed to the instrument and article and framed as architectural implications, not legal advice.

Red threads

NIST CSF 2.0 and the three AI focus areas (Chapter 3): every Category has a responsible chapter, and every Function chapter treats securing AI systems, AI-enabled cyber defence and thwarting AI-enabled attacks.
Usage modes and autonomy levels (Chapters 1 and 6): the six usage modes of the series, from Mode 0 Ambient AI to Mode 5 Autonomous production agents, read through a security lens, because each offers distinct opportunities and has distinct vulnerabilities: in the lower modes a person judges and the AI acts with the person's identity, in Mode 5 the AI acts with an identity and permissions of its own. Paired with the autonomy levels, Level 0 Advisory to Level 4 Autonomous, which say who decides each action. Level 4 is never used for offensive or irreversible actions. Every Function chapter has an Across the usage modes subsection.
Security chaos engineering (Chapter 25): every Function chapter names a security chaos experiment that verifies its capabilities continuously; Chapter 25 gives the platform architecture and its safety boundaries.
The purple loop (Chapter 26): finding, control, detection, re-test, evidence, and an updated CSF profile.
Rules of engagement as code (Chapter 7): no exercise without a signed, versioned manifest.
The two organisations: Nordvik Region, which stretches a small security team with AI without giving up sovereignty over security data, and Hansa Mutual, which gives AI bounded autonomy at machine speed while proving to supervisors that people remain in command (EXAMPLE_ORGANISATIONS.md).

Status

The book was started on 2026-11-02 and restructured the same day around NIST CSF 2.0 with an AI focus. The engine, the table of contents, these briefs, CSF_COVERAGE.md, SERIES_FOUNDATIONS.md, the security operations profiles of the two organisations, the part introductions and a first draft of Chapter 1 exist. Chapters 2 to 25 are outlines generated from the briefs. The status of each chapter is recorded in its brief below (outline, draft, complete).

Length and weighting

Numbered narrative chapters are 3,600 to 5,500 words of prose, as in the other volumes. Chapters 3, 7, 18, 25 and 26 are expected to be the longest, because they carry the CSF frame, the mandate, the SOC and the purple loop on which the rest of the book depends. Chapters that hold two CSF Categories (5, 8, 16, 18, 19, 20, 21, 24, 25, 26) may use the companion range of up to 6,500 words. Any weighting decision taken during drafting is recorded in the brief. Refactoring (2026-11): the manuscript was cut by about 30 % in a series-wide refactoring; the length ranges given in this blueprint and in the individual briefs below are superseded by rule 2 of CHAPTER_AUTHORING_GUIDE.md (numbered narrative chapters 2,500 to 4,000 words of prose, companion chapters up to 4,500).

Chapter briefs

Part I: Foundations

Chapter 1: Introduction: Putting AI to Work in Cyber Defence

File: 01_introduction.md
Status: complete
Purpose: Introduce the book on its own terms: why AI must now be an active part of cyber defence, how the book builds on the three earlier volumes, why it is organised by the six Functions of NIST CSF 2.0 and the three AI focus areas, the rules that keep it defensive, the European setting and the two organisations.
Builds on: F18, F19, F21, F13, Q9
Sections: Why this book, and why now; What the series has already established; NIST CSF 2.0 with an AI focus; Red, blue and purple across the Functions; Rules of the book; The European setting; Two organisations; How to read this book
Worked examples: A one-page charter for an AI-enabled defence programme
Nordvik Region and Hansa Mutual: Introduces both security functions: Nordvik's small team with an MSSP and no red team, Hansa's 24/7 SOC with a red team and DORA TLPT.
Figure: The six CSF Functions with the three AI focus areas, resting on the foundations of Books 1 to 3

Chapter 2: The Threat Landscape When Attackers Use AI

File: 02_threat_landscape.md
Status: complete
Purpose: Give the defender's picture of what AI changes for attackers, based on observed evidence rather than forecasts, and translate it into requirements for each CSF Function. This is the threat picture behind the 'thwart' focus area throughout the book.
CSF 2.0 Categories: ID.RA Risk Assessment
AI focus: Securing AI systems: How attackers target AI systems themselves, mapped to ATLAS. AI-enabled cyber defence: Which defensive AI capabilities the threat picture calls for, by Function. Thwarting AI-enabled attacks: The observed AI-enabled techniques, mapped to ATT&CK, that the rest of the book must counter.
Builds on: F18, F19, F5, Q3, Q9
Sections: From misuse reports to agentic offensive frameworks; The kill chain under acceleration; The exploitation window; Attacks on AI systems; Separating evidence from forecast; From threat picture to requirements per Function
Practical guides: Building an AI-aware threat profile for your organisation
Worked examples: Threat profile entry for AI-enabled initial access, labelled by evidence level
Nordvik Region and Hansa Mutual: Nordvik's exposure is citizen-facing services and supplier access; Hansa's is fraud, extortion and the scale of its group estate.
Figure: ATT&CK tactics shaded by the observed degree of AI acceleration

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

File: 03_csf_with_ai_focus.md
Status: complete
Purpose: Present NIST CSF 2.0 as the organising frame of the book: its six Functions and 22 Categories, profiles and tiers, the three focus areas of the NIST Cyber AI Profile, and how CSF outcomes map to the European obligations (NIS 2 and Implementing Regulation 2024/2690, DORA, the CRA, the AI Act) and to ISO/IEC 27001, so that a European organisation can use CSF without importing a US compliance regime.
CSF 2.0 Categories: GV.OC Organizational Context
AI focus: Securing AI systems: How the Cyber AI Profile extends each Category to AI systems in the estate. AI-enabled cyber defence: How AI can help achieve each Category's outcomes. Thwarting AI-enabled attacks: How each Category must change when attackers use AI.
Builds on: F3, F9, F12, F17
Sections: CSF 2.0 in brief; The AI focus: three focus areas; Mapping CSF to European obligations; CSF and ISO/IEC 27001; Profiles as code; How the book follows the Functions
Practical guides: Building a current and target CSF profile with an AI focus
Worked examples: CSF profile as code with Category targets, AI focus areas and links to European obligations
Nordvik Region and Hansa Mutual: Nordvik maps CSF to NIS 2 and its national transposition; Hansa maps CSF to DORA, NIS 2 and the UK and Swiss regimes through one control catalogue.
Figure: CSF Functions and Categories mapped to the three AI focus areas and to European obligations

Chapter 4: A Reference Architecture for AI-Enabled Cyber Defence

File: 04_reference_architecture.md
Status: complete
Purpose: Present a reference architecture for AI-enabled cyber defence that places security AI on the governed platform of the earlier volumes, so that every later chapter has a common picture of where data, models, agents, tools, policy points, evidence and the separated ranges sit.
CSF 2.0 Categories: PR.PS Platform Security, PR.IR Technology Infrastructure Resilience
AI focus: Securing AI systems: Security AI is AI: gateway, policy point, containment and evidence applied to it. AI-enabled cyber defence: The layers of an AI-enabled security operation from telemetry to action. Thwarting AI-enabled attacks: Separation of ranges and sovereignty of security data as defences in their own right.
Builds on: F17, F23, F6, F20
Sections: Security AI is AI: inheriting the platform; Layers of the AI-enabled security operation; Sovereignty of security data; Separation of ranges; Mapping to D3FEND and CSF
Practical guides: Placing a new security AI capability on the reference architecture
Worked examples: Containment profile for the SOC investigation agent
Nordvik Region and Hansa Mutual: Nordvik self-hosts security AI on its reserved Nordic capacity; Hansa runs it on the Frankfurt group platform with market overlays.
Figure: Layered reference architecture for AI-enabled defence with separated ranges

Part II: Govern

Chapter 5: Organisational Context and Risk Strategy for AI in Cyber Defence

File: 05_context_and_risk_strategy.md
Status: complete
Purpose: Establish the organisational context and risk strategy for AI in cyber defence: mission and stakeholders, legal and regulatory requirements, dependencies, risk appetite for security AI and for AI-enabled threats, and how the strategy is expressed as code.
CSF 2.0 Categories: GV.OC Organizational Context, GV.RM Risk Management Strategy
AI focus: Securing AI systems: Which AI systems the organisation depends on and how their risk enters the cybersecurity risk strategy. AI-enabled cyber defence: The risk appetite for using AI in defence, including tolerated error rates and autonomy ceilings. Thwarting AI-enabled attacks: How AI-enabled threats change risk assumptions, from exploitation windows to synthetic media.
Builds on: F2, F9, F10, F15
Sections: Mission, stakeholders and obligations; Risk appetite for AI in defence; Risk assumptions under AI-enabled threats; Risk strategy as code; Linking to enterprise risk management
Practical guides: Writing a risk-appetite statement for security AI
Worked examples: Risk-appetite statement as code with autonomy ceilings and review triggers
Across the usage modes: Risk appetite differs by mode: tolerated error in a Mode 1 assistant that a person checks is not tolerable in a Mode 5 agent that acts; the strategy states an autonomy ceiling per mode.
Security chaos experiment: Verify that a change in a dependency or a new AI system triggers the context and risk review the strategy requires.
Nordvik Region and Hansa Mutual: Nordvik's context is public law, public access and a small team; Hansa's is seven jurisdictions, DORA and a management body that owns ICT risk.
Figure: From context to risk appetite to autonomy ceilings

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

File: 06_roles_and_autonomy.md
Status: complete
Purpose: Define roles, responsibilities and authorities when AI works in red, blue and purple teams, read the six usage modes through a security lens, define the five autonomy levels that run through the book, and show how mode and level are decided together, so that people remain in command whether AI supports a person's judgement or acts with an identity and permissions of its own.
CSF 2.0 Categories: GV.RR Roles, Responsibilities, and Authorities
AI focus: Securing AI systems: Who owns each AI system's security, and who is accountable for the actions of machine identities. AI-enabled cyber defence: The usage modes and autonomy levels, decision rights and the design of human command over defensive AI. Thwarting AI-enabled attacks: Authorities that let the organisation act at machine speed when attacks do, without handing an attacker a privileged machine insider.
Builds on: F7, F9, F13, F16, F11, Q10
Sections: Red, blue, purple and white; The usage modes through a security lens; Autonomy levels for security AI; Deciding mode and level together; Machine identities and accountability; Human command by design; Skills, sourcing and the MSSP
Practical guides: Assigning a usage mode and an autonomy level to a security AI capability
Worked examples: Autonomy-level decision record AIDR-0311 for the SOC investigation agent, including its usage mode and machine identity
Across the usage modes: This chapter defines the security reading of all six modes and how each is paired with an autonomy level.
Security chaos experiment: Verify that the stop path reaches the people who hold it: inject a simulated runaway action by a security agent and measure time to stop.
Nordvik Region and Hansa Mutual: Nordvik keeps security AI in Modes 0, 1 and 4 at Level 0 or 1 and relies on its MSSP; Hansa runs a Mode 5 investigation agent with its own workload identity and argues the case for Level 3 Bounded for reversible containment actions.
Figure: Usage modes against autonomy levels, with the zones where human judgement and machine identity dominate

Chapter 7: Policy, Mandate and Rules of Engagement

File: 07_policy_and_rules_of_engagement.md
Status: complete
Purpose: Set out policy and mandate for AI in cyber defence: security policy that covers AI, acceptable use of offensive AI capabilities, the legal duties that require testing and monitoring, threat-led testing under DORA and TIBER-EU, and rules of engagement as a signed, versioned artefact.
CSF 2.0 Categories: GV.PO Policy
AI focus: Securing AI systems: Policy for the security of AI systems, aligned with AI Act Article 15. AI-enabled cyber defence: Acceptable use and access control for offensive and defensive AI capabilities. Thwarting AI-enabled attacks: Rules of engagement for AI-enabled adversary emulation that reproduce real threats safely.
Builds on: F3, F11, F22, Q7, Q10
Sections: Security policy that covers AI; Duties that require testing and monitoring; Threat-led testing: DORA TLPT and TIBER-EU; The AI Act, data protection and labour law; Acceptable use of offensive AI capabilities; Rules of engagement as code
Practical guides: Drafting rules of engagement for an exercise that uses AI
Worked examples: Rules-of-engagement manifest RoE-NR-2027-001
Across the usage modes: Policy must cover every mode: acceptable use 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 and any AI used in offensive work.
Security chaos experiment: Verify that the policy decision point refuses an offensive action outside the rules of engagement.
Nordvik Region and Hansa Mutual: Nordvik works under one public-law regime and NIS 2; Hansa aligns DORA TLPT under TIBER-DE with UK and Swiss regimes and works-council consultation.
Figure: Obligations mapped to policy, with rules of engagement as the gate for offensive work

Chapter 8: Oversight and AI Supply Chain Risk

File: 08_oversight_and_supply_chain.md
Status: complete
Purpose: Show how the management body oversees AI in cyber defence and how supply-chain risk is managed for AI: models, AI services, security products with embedded AI, MSSPs and the evidence the deployer can demand and test.
CSF 2.0 Categories: GV.OV Oversight, GV.SC Cybersecurity Supply Chain Risk Management
AI focus: Securing AI systems: Supply-chain risk for models and AI services, including Article 55 evidence from providers. AI-enabled cyber defence: Assuring the AI inside security products and managed services before relying on it. Thwarting AI-enabled attacks: Supply-chain compromise as an AI-enabled attack path.
Builds on: F11, F12, F14, F22
Sections: Oversight by the management body; AI in the supply chain; Who tests what; Contract and register; Change-triggered reassessment
Practical guides: Assuring a vendor's AI feature before enabling it in the SOC
Worked examples: Supplier assurance requirements for security AI as code
Across the usage modes: Mode 0 is the supply-chain blind spot: AI switched on by vendors in security products and managed services may already act automatically, so the deployer must learn where and at which effective autonomy.
Security chaos experiment: Verify that a simulated silent change in a supplier's model version is detected and triggers reassessment.
Nordvik Region and Hansa Mutual: Nordvik relies on contracts and its MSSP framework agreement; Hansa adds security AI to its DORA register and tests each model change.
Figure: Oversight and assurance responsibilities between provider, vendor, MSSP and deployer

Part III: Identify

Chapter 9: Asset Management for an Estate That Includes AI

File: 09_asset_management.md
Status: complete
Purpose: Make asset management cover AI: inventories of AI systems, models, agents, prompts, data and the security AI itself; AI-assisted discovery of unmanaged and shadow AI; and asset context that the SOC and the red team can use.
CSF 2.0 Categories: ID.AM Asset Management
AI focus: Securing AI systems: AI systems, models, agents and data as inventoried assets with owners and criticality. AI-enabled cyber defence: AI-assisted asset discovery, classification and enrichment. Thwarting AI-enabled attacks: Unknown assets and shadow AI as the entry points AI-enabled attackers find first.
Builds on: F9, F17
Sections: Assets in an estate that includes AI; AI-assisted discovery and classification; Shadow AI and supplier-enabled features; Criticality and context
Practical guides: Reconciling the AI inventory with discovered assets
Worked examples: Asset record for an agent with owner, criticality and tool permissions
Across the usage modes: Each mode leaves different traces in the inventory: Mode 0 hides inside licensed products, Modes 1 to 3 hide on workstations, Mode 4 and 5 systems must be registered with their machine identities and permissions.
Security chaos experiment: Plant an unregistered AI service in a test subscription and verify that asset discovery finds and classifies it.
Nordvik Region and Hansa Mutual: Nordvik reconciles its AI register with supplier features; Hansa runs discovery across seven markets and the Polish service centre.
Figure: Asset inventory reconciliation with AI-assisted discovery

Chapter 10: AI-Assisted Threat Modelling and Risk Assessment

File: 10_threat_modelling_and_risk_assessment.md
Status: complete
Purpose: Show how AI makes threat modelling continuous and risk assessment evidence-based: threat models generated from architecture code, threat intelligence fused with asset context, attack-path analysis and machine-assisted risk scoring that people review for soundness.
CSF 2.0 Categories: ID.RA Risk Assessment
AI focus: Securing AI systems: Threat models for AI systems using STRIDE extended with ATLAS. AI-enabled cyber defence: AI-generated and AI-maintained threat models and attack-path analysis. Thwarting AI-enabled attacks: AI-enabled adversary capabilities as explicit inputs to risk assessment.
Builds on: F1, F2, F6, F20, Q1
Sections: Threat models that keep up with change; AI-assisted STRIDE and ATLAS analysis; Threat intelligence in risk assessment; Attack-path analysis; Reviewing machine-generated risk
Practical guides: Running an AI-assisted threat-modelling review on a pull request
Worked examples: threat-model.yaml for the citizen-service assistant with AI-proposed and reviewer-accepted threats
Across the usage modes: Threat models differ by mode: in Modes 1 and 2 the main threat is a misled person, in Mode 3 an agent acting with an engineer's credentials, in Mode 5 a manipulated or compromised machine insider.
Security chaos experiment: Change an architecture definition so that a new trust boundary appears and verify that the threat model is regenerated and reviewed.
Nordvik Region and Hansa Mutual: Nordvik starts with its two citizen-facing services; Hansa runs attack-path analysis across the group estate.
Figure: Continuous threat-modelling and risk-assessment loop

Chapter 11: Vulnerability Discovery and Exposure Management at Machine Speed

File: 11_vulnerability_and_exposure.md
Status: complete
Purpose: Show how defenders use AI to find and fix vulnerabilities in their own code and dependencies, prioritise exposure with EPSS, KEV and EUVD, delegate patch decisions in advance and absorb the patch wave without overwhelming reviewers.
CSF 2.0 Categories: ID.RA Risk Assessment, PR.PS Platform Security
AI focus: Securing AI systems: Vulnerabilities in AI components, model files and agent tooling. AI-enabled cyber defence: AI-assisted code review, vulnerability discovery and prioritisation. Thwarting AI-enabled attacks: Patch velocity as a service level against collapsing exploitation windows.
Builds on: F15, F19, Q3, Q8
Sections: What the evidence shows; AI review in the delivery pipeline; The verification bottleneck; Prioritisation signals; Delegated patch decisions and patch velocity; Disclosure and reporting
Practical guides: Defining delegated patch decisions for known-exploited vulnerabilities
Worked examples: Patch-velocity service-level policy as code
Across the usage modes: Mode 3 agents and Mode 4 services accelerate discovery and review, but a Mode 5 agent that applies fixes itself needs the strictest verification and rollback.
Security chaos experiment: Publish a synthetic known-exploited vulnerability for a test asset and verify that prioritisation and the delegated patch decision meet the service level.
Nordvik Region and Hansa Mutual: Nordvik pushes patch service levels into supplier contracts; Hansa runs AI review on its platform code and reports patch velocity under DORA.
Figure: Find–verify–prioritise–fix pipeline with the human verification step

Chapter 12: Adversary Emulation and Continuous Red Teaming with AI

File: 12_adversary_emulation.md
Status: complete
Purpose: Describe how a red team uses AI to emulate adversaries and validate controls continuously: threat-informed scenarios, AI-assisted planning and execution under rules of engagement, breach-and-attack simulation and security chaos engineering as code, and threat-led testing under DORA and TIBER-EU. CSF places the improvements identified from tests and exercises under ID.IM.
CSF 2.0 Categories: ID.IM Improvement
AI focus: Securing AI systems: Safeguards that keep AI used by the red team contained. AI-enabled cyber defence: AI in the red team's workflow from scenario design to reporting. Thwarting AI-enabled attacks: Emulating AI-enabled adversaries, including the speed at which they act.
Builds on: F8, F14, F21, F23, Q6, Q7
Sections: Threat-informed scenarios; Execution under rules of engagement; Lessons from agents that exceeded their mandate; Continuous validation as code; AI-enabled emulation in threat-led testing; Findings the blue team can use
Practical guides: Preparing a safe AI-assisted emulation run
Worked examples: Emulation plan mapped to ATT&CK techniques with safeguards and stop conditions
Across the usage modes: The red team uses Modes 1 to 3 for planning and tooling under its own accountability; AI that executes emulation steps behaves like a Mode 5 system and needs a permission manifest, range separation and a stop path.
Security chaos experiment: Run catalogued, benign technique emulations continuously and verify the expected detections fire.
Nordvik Region and Hansa Mutual: Nordvik contracts its first threat-led exercise; Hansa adds AI-enabled techniques to its TIBER-DE scope and runs HM-SEC-004 continuously.
Figure: Emulation and continuous validation with the white team, safeguards and evidence

Chapter 13: Red Teaming AI Systems and Agents

File: 13_red_teaming_ai_systems.md
Status: complete
Purpose: Red team the organisation's own AI systems and agents: scoping compound systems, taxonomies as test plans, test campaigns turned into versioned suites and release gates, containment tests for agents, and an honest account of the limits of testing.
CSF 2.0 Categories: ID.RA Risk Assessment, ID.IM Improvement
AI focus: Securing AI systems: Red teaming LLM applications, retrieval systems and agents against OWASP and ATLAS categories. AI-enabled cyber defence: AI-assisted generation and analysis of adversarial test cases. Thwarting AI-enabled attacks: Testing whether containment holds when an agent is manipulated or exceeds its mandate.
Builds on: F13, F20, F21, F22, F23, Q4, Q5, Q6
Sections: Scoping the compound system; Taxonomies as test plans; Suites, harnesses and gates; Red teaming agents; The limits of testing
Practical guides: Running a red-team campaign on a retrieval-augmented assistant; Running an escape-path assessment on a production agent
Worked examples: Campaign plan for NR-SEC-002 mapped to OWASP and ATLAS categories; Containment test plan for Hansa's IT-operations agent
Across the usage modes: Each mode is red teamed differently: Mode 0 through vendor evidence, Modes 1 and 2 through data exposure and injection via content, Mode 4 through the full application, Mode 5 through containment, credentials and stop paths.
Security chaos experiment: Re-run AI red-team suites against production configurations on change and verify that guardrails still hold.
Nordvik Region and Hansa Mutual: Nordvik red teams its citizen-service and staff assistants; Hansa its claims assistant, claims-triage agent and IT-operations agent.
Figure: Compound AI system with test surfaces, containment boundaries and the route from finding to gate

Part IV: Protect

Chapter 14: Identity, Authentication and Access for People, Agents and Machines

File: 14_identity_and_access.md
Status: complete
Purpose: Protect identities and access for people, service accounts and agents when attackers use AI: phishing-resistant authentication, approvals that resist synthetic media, task-scoped credentials for agents, and AI-assisted detection of identity misuse.
CSF 2.0 Categories: PR.AA Identity Management, Authentication, and Access Control
AI focus: Securing AI systems: Workload identity, task-scoped credentials and no ambient authority for agents. AI-enabled cyber defence: AI-assisted access reviews and identity-threat detection. Thwarting AI-enabled attacks: Authentication and approvals that resist deepfakes and AI-generated lures.
Builds on: F19, F23, F14
Sections: Identities for people, machines and agents; Phishing-resistant authentication; Approvals that resist synthetic media; AI in access governance
Practical guides: Hardening payment and privileged-access approvals against deepfakes
Worked examples: Synthetic-media-resistant approval policy as code
Across the usage modes: Modes 1 to 3 act with a person's identity, which makes delegated access and session theft the issue; Mode 5 agents have identities of their own, which must be task-scoped, short-lived and never shared.
Security chaos experiment: Issue an over-privileged token to a test agent and verify that it is detected and revoked; send a synthetic out-of-band approval request and verify call-back is enforced.
Nordvik Region and Hansa Mutual: Nordvik prioritises call-back verification for supplier payment changes; Hansa binds agent credentials to task and entity.
Figure: Identity and approval flows for people and agents

Chapter 15: Awareness and Training: Resilience to AI-Generated Deception

File: 15_awareness_and_training.md
Status: complete
Purpose: Treat awareness and training as building resilience against AI-generated deception and as AI literacy for security staff: testing processes rather than individuals, ethical and lawful simulations, and training analysts to verify AI output.
CSF 2.0 Categories: PR.AT Awareness and Training
AI focus: Securing AI systems: AI literacy for everyone who builds or operates AI systems. AI-enabled cyber defence: Training analysts to work with, verify and override security AI. Thwarting AI-enabled attacks: Resilience to AI-generated phishing, vishing and deepfakes, tested on processes.
Builds on: F16, F19
Sections: Deception at scale; Test the process, not the person; Measuring resilience; Training analysts for AI-assisted work
Practical guides: Designing a deepfake-resilience exercise for payment approvals
Worked examples: Exercise design record with consent, scope and success criteria
Across the usage modes: Training differs by mode: verifying suggestions in Modes 1 and 2, supervising agents in Mode 3, and operating and stopping Mode 5 agents.
Security chaos experiment: Measure report rates and time-to-report for announced resilience exercises, without testing individuals covertly.
Nordvik Region and Hansa Mutual: Nordvik combines Article 4 AI literacy with process tests; Hansa tests claims-payment and treasury approvals across markets with works-council agreement.
Figure: Approval process with synthetic-media checkpoints and training loop

Chapter 16: Data and Platform Security with and for AI

File: 16_data_and_platform_security.md
Status: complete
Purpose: Protect data and platforms with and for AI: protecting security telemetry and training data, guardrails and policy points for AI systems, secure configuration and secure software development with AI assistance, and integrity of models and pipelines.
CSF 2.0 Categories: PR.DS Data Security, PR.PS Platform Security
AI focus: Securing AI systems: Data, model and pipeline integrity; guardrails and policy points outside the model. AI-enabled cyber defence: AI-assisted secure configuration, data classification and secure development. Thwarting AI-enabled attacks: Protecting against data extraction, poisoning and AI-accelerated misconfiguration abuse.
Builds on: F3, F4, F17, F20
Sections: Data security for security data; Guardrails and policy points; Secure configuration with AI; Secure development with AI assistance
Practical guides: Applying a guardrail policy to a security AI capability
Worked examples: Guardrail policy for the SOC triage assistant
Across the usage modes: Data exposure grows with mode: pasted telemetry in Mode 1, inherited permissions in Mode 2, workstation secrets in Mode 3, attacker-controlled fields reaching a Mode 4 or 5 model.
Security chaos experiment: Introduce a configuration drift in a test tenant and verify that policy as code blocks or reverts it; plant a canary record and verify data-loss detection.
Nordvik Region and Hansa Mutual: Nordvik keeps alert data on its reserved capacity; Hansa enforces data-residency overlays per market.
Figure: Data and platform controls around security AI

Chapter 17: Technology Infrastructure Resilience Against Machine-Speed Attacks

File: 17_infrastructure_resilience.md
Status: complete
Purpose: Make technology infrastructure resilient against machine-speed attacks: segmentation and zero trust, capacity and degradation modes for security AI, redeployment from known-good definitions and resilience testing.
CSF 2.0 Categories: PR.IR Technology Infrastructure Resilience
AI focus: Securing AI systems: Resilience and fallback for AI systems, including security AI. AI-enabled cyber defence: AI-assisted capacity planning and resilience testing. Thwarting AI-enabled attacks: Segmentation and containment that limit the speed and reach of automated attacks.
Builds on: F5, F6, F23
Sections: Segmentation and zero trust; Redeploy, do not repair; Resilience of security AI; Testing resilience
Practical guides: Defining degradation modes for a security AI capability
Worked examples: Degradation-mode definition for the SOC investigation agent
Across the usage modes: Mode 5 security AI must degrade safely and its failure must not take defence down with it; lower modes fail back to people by design.
Security chaos experiment: Fail a segment, a region or the security AI itself and verify degradation modes and failover.
Nordvik Region and Hansa Mutual: Nordvik depends on its hosting provider and MSSP; Hansa runs failover between Frankfurt and the Polish service centre.
Figure: Resilience layers and degradation modes

Part V: Detect

Chapter 18: The AI-Assisted Security Operations Centre

File: 18_ai_assisted_soc.md
Status: complete
Purpose: Describe the AI-assisted security operations centre: continuous monitoring and adverse-event analysis with AI, from alert intake to investigation and escalation, with autonomy levels, verifiable conclusions and measurable effects on analyst workload and quality.
CSF 2.0 Categories: DE.CM Continuous Monitoring, DE.AE Adverse Event Analysis
AI focus: Securing AI systems: Monitoring AI systems: gateway logs, agent telemetry and event logs under AI Act Article 12. AI-enabled cyber defence: AI-assisted triage, enrichment, correlation and investigation. Thwarting AI-enabled attacks: Detection at machine speed with the authority to act on high-confidence signals.
Builds on: F5, F16, F19, Q9, Q10
Sections: The SOC workflow, step by step; Triage and enrichment with AI; Investigation agents; Monitoring AI systems; Analysts in command; Working with an MSSP
Practical guides: Introducing an AI triage assistant at Level 1 Assisted
Worked examples: Permission manifest for the SOC investigation agent HM-SEC-001
Across the usage modes: The SOC uses every mode at once: vendor verdicts (Mode 0), analyst assistants (Modes 1 and 2), a built triage service (Mode 4) and an investigation agent (Mode 5); each needs its own verification and attacker-controlled alert content is an injection channel for all of them.
Security chaos experiment: Silence a log source or inject benign emulated activity and verify alerting, triage quality and time to detect.
Nordvik Region and Hansa Mutual: Nordvik's NR-SEC-001 runs self-hosted at Level 1 alongside its MSSP; Hansa's HM-SEC-001 moves from Level 2 to Level 3 for reversible actions.
Figure: SOC workflow with AI steps and autonomy levels

Chapter 19: Detection Engineering, Threat Intelligence and Deception as Code

File: 19_detection_intelligence_deception.md
Status: complete
Purpose: Show how AI accelerates detection engineering as code, threat intelligence and deception: from threat report to tested detection, intelligence structured in STIX and graded by people, and honeytokens and decoys as high-signal detection within the law.
CSF 2.0 Categories: DE.CM Continuous Monitoring, DE.AE Adverse Event Analysis
AI focus: Securing AI systems: Detections and decoys for attacks on AI systems and agents. AI-enabled cyber defence: AI-drafted detections, AI-assisted intelligence analysis and AI-generated decoys. Thwarting AI-enabled attacks: Deception that exploits the speed-over-stealth behaviour of automated attackers.
Builds on: F1, F3, F8, F19, Q1, Q2
Sections: Detections as code; From report to tested detection; Threat intelligence with AI; Deception: honeytokens, canaries and decoys; The legal boundary
Practical guides: Taking a threat report to a deployed, tested detection in a day
Worked examples: Sigma rule with test cases and ATT&CK mapping
Across the usage modes: AI-drafted detections from Modes 3 and 4 are reviewed by people; deception aimed at attackers' AI is a defence against their Mode 5 agents.
Security chaos experiment: Trigger a honeytoken and verify the alert path end to end; replay emulation data against new detections.
Nordvik Region and Hansa Mutual: Nordvik replaces supplier defaults with its own detections and plants canary documents; Hansa's HM-SEC-002 drafts detections for review.
Figure: Detection-as-code pipeline with intelligence input and deception signals

Part VI: Respond

Chapter 20: Incident Management and Analysis with AI

File: 20_incident_management.md
Status: complete
Purpose: Apply AI to incident management and analysis: triage and declaration, AI-assisted scoping, timeline reconstruction and forensics, defensible analysis, and incidents in which an AI system or agent is the subject.
CSF 2.0 Categories: RS.MA Incident Management, RS.AN Incident Analysis
AI focus: Securing AI systems: Incidents involving AI systems and agents, with the AI classification step. AI-enabled cyber defence: AI-assisted scoping, correlation, timelines and forensics. Thwarting AI-enabled attacks: Managing incidents that unfold at machine speed.
Builds on: F5, F14, F24, Q5
Sections: Incident management with AI; Timelines and scoping; Defensible analysis; Incidents involving AI
Practical guides: Running an AI-assisted incident tabletop
Worked examples: Incident record with the AI classification step
Across the usage modes: Lower modes speed up a person's analysis; when the incident involves a Mode 5 agent, its machine identity and actions become part of the scope.
Security chaos experiment: Inject a synthetic incident and verify declaration, scoping and the AI classification step.
Nordvik Region and Hansa Mutual: Nordvik coordinates with its MSSP and national CSIRT; Hansa's incident-response team leads across seven markets.
Figure: Incident management and analysis with AI assistance

Chapter 21: Incident Reporting, Communication and Mitigation

File: 21_reporting_and_mitigation.md
Status: complete
Purpose: Cover incident reporting, communication and mitigation: multi-regime reporting clocks under NIS 2, DORA and the AI Act, AI-assisted drafting with human sign-off, and containment and eradication at machine speed within autonomy levels.
CSF 2.0 Categories: RS.CO Incident Response Reporting and Communication, RS.MI Incident Mitigation
AI focus: Securing AI systems: Reporting serious incidents involving AI systems under AI Act Article 73. AI-enabled cyber defence: AI-assisted reporting and bounded automated containment. Thwarting AI-enabled attacks: Mitigation that keeps pace with automated attackers.
Builds on: F5, F23, F24
Sections: Reporting across regimes; AI-assisted communication; Containment at machine speed; Eradication
Practical guides: Mapping one incident to every reporting obligation
Worked examples: Reporting-clock configuration for a multi-regime incident
Across the usage modes: AI may draft reports in Modes 2 and 4 under human sign-off; containment by a Mode 5 agent must stay within bounded, reversible actions.
Security chaos experiment: Start a synthetic multi-regime incident and verify that every reporting clock starts and that bounded containment acts within limits.
Nordvik Region and Hansa Mutual: Nordvik reports to its national CSIRT and DPA; Hansa routes one incident to DORA, AI Act, data-protection and UK and Swiss processes within hours.
Figure: Reporting clocks and mitigation actions by autonomy level

Part VII: Recover

Chapter 22: Recovery Plan Execution with AI: From Incident to Restored Operations

File: 22_recovery_plan_execution.md
Status: complete
Purpose: Make recovery plan execution fast, verified and repeatable with AI: recovery plans and objectives as code, AI-assisted dependency mapping and prioritisation by business impact, restoration from known-good definitions and immutable backups, integrity verification before return to service, and a clear end to recovery.
CSF 2.0 Categories: RC.RP Incident Recovery Plan Execution
AI focus: Securing AI systems: Integrity of backups, images and model artefacts before anything is restored. AI-enabled cyber defence: AI-assisted recovery orchestration: dependency mapping, sequencing, runbook execution at Level 2 or 3, and automated verification of restored services. Thwarting AI-enabled attacks: Recovering from destructive and ransomware attacks run at machine speed, while an automated attacker may still be present.
Builds on: F4, F5, F24
Sections: The neglected Function; Recovery plans and objectives as code; AI-assisted recovery orchestration; Restore, do not repair; Verifying before return to service; Recovering in a contested environment
Practical guides: Executing a recovery plan with AI-assisted sequencing and verification
Worked examples: Recovery plan as code with objectives, dependencies and verification steps
Across the usage modes: Mode 4 services plan and verify recovery for people to execute; Mode 5 orchestration may run catalogued, reversible recovery steps within autonomy limits.
Security chaos experiment: Destroy a test service in an isolated range and verify that orchestrated recovery meets its recovery time and point objectives.
Nordvik Region and Hansa Mutual: Nordvik depends on its hosting provider and suppliers to restore and must sequence citizen-facing services first; Hansa restores across Frankfurt and the Polish service centre under DORA recovery requirements.
Figure: Recovery orchestration from declared incident to verified return to service

Chapter 23: Recovering AI Systems and Security AI

File: 23_recovering_ai_systems.md
Status: complete
Purpose: Recover AI systems, and the security AI the organisation depends on, to a trustworthy state: what must be restored (models, prompts, retrieval stores, agents, permission manifests, evaluation baselines), how to roll back to known-good versions after tampering or poisoning, how to re-evaluate before return to service, and how the security operation keeps working while its own AI is unavailable.
CSF 2.0 Categories: RC.RP Incident Recovery Plan Execution
AI focus: Securing AI systems: Restoring AI systems from registries and evidence: model, prompt and retrieval-store versions, re-evaluation against golden datasets and red-team suites before return to service. AI-enabled cyber defence: Recovering security AI and running the SOC in a degraded mode with manual fallback. Thwarting AI-enabled attacks: Recovering from poisoning, tampering or manipulation discovered after the fact, including agents that exceeded their mandate.
Builds on: F12, F17, F22, F23, F24
Sections: What an AI system consists of when it must be restored; Rolling back to known-good versions; Re-evaluation before return to service; Recovering agents; When security AI is unavailable
Practical guides: Returning an AI system to service after an incident
Worked examples: Return-to-service checklist as code for an AI system
Across the usage modes: Restoring a Mode 5 agent includes its identity, credentials, permission manifest and pending actions, not only its model and prompts.
Security chaos experiment: Corrupt a model or retrieval-store version in a test environment and verify rollback, re-evaluation and the degraded SOC mode.
Nordvik Region and Hansa Mutual: Nordvik restores its citizen-service assistant from its supplier's and its own registries and re-runs NR-SEC-002; Hansa restores the claims-triage agent and runs HM-SEC-001 in degraded mode during recovery.
Figure: Restoring an AI system from registries through re-evaluation to service

Chapter 24: Proactive Recovery: Recoverability, Rehearsal and Communication

File: 24_proactive_recovery.md
Status: complete
Purpose: Turn recovery from a reactive, rarely tested capability into a proactive, continuously verified one: AI-assisted rehearsal and restore testing in isolated ranges, prediction of recovery times against objectives, recoverability findings fed back into Govern, Identify and Protect, and recovery communication with stakeholders, supervisors and the public that is prepared in advance and drafted with AI under human sign-off.
CSF 2.0 Categories: RC.RP Incident Recovery Plan Execution, RC.CO Incident Recovery Communication
AI focus: Securing AI systems: Continuous recoverability testing of AI systems, including restore drills for models and retrieval stores. AI-enabled cyber defence: AI that rehearses recovery, predicts recovery times, finds unrecoverable dependencies before an incident does, and drafts recovery communication. Thwarting AI-enabled attacks: Assume breach: designing for fast recovery so that destructive and extortion attacks lose their leverage.
Builds on: F1, F4, F8, F12, F15
Sections: From reactive to proactive recovery; AI-assisted rehearsal and restore testing; Recovery findings as input to other Functions; Recovery communication; Evidence of recoverability
Practical guides: Setting up a monthly AI-assisted restore drill
Worked examples: Recoverability test definition with objectives, drill schedule and evidence output
Across the usage modes: Restore drills can run as Mode 5 experiments within strict limits; recovery communication is drafted in Modes 2 and 4 and approved by people.
Security chaos experiment: Schedule restore drills as chaos experiments and verify recoverability continuously; verify that prepared recovery communication can be released within the target time.
Nordvik Region and Hansa Mutual: Nordvik uses AI-assisted drills to compensate for a small team and must also communicate with residents and elected politicians; Hansa reports recoverability to its management body and supervisors and communicates with policyholders in seven markets.
Figure: The proactive recovery loop feeding Govern, Identify and Protect

Part VIII: Verification, Improvement and Conclusions

Chapter 25: Security Chaos Engineering with AI: Verifying Security Capabilities Continuously

File: 25_security_chaos_engineering.md
Status: complete
Purpose: Introduce security chaos engineering as the way to verify, continuously and in real time, that security capabilities across all six CSF Functions work as intended: the discipline and its origins in Chaos Monkey, steady-state hypotheses for security, an AI-driven experiment platform, its reference architecture and the safety boundaries that keep it from becoming an incident, the experiment ledger that keeps the SOC's trust, and how results feed the purple loop and the CSF profile.
CSF 2.0 Categories: ID.IM Improvement
AI focus: Securing AI systems: Experiments that verify the controls around AI systems, and the chaos platform itself treated as a tier-0 asset that is protected and red teamed. AI-enabled cyber defence: AI that plans experiments from coverage gaps, threat intelligence and recent changes, and evaluates results against hypotheses; deterministic actuators execute them. Thwarting AI-enabled attacks: Continuous verification at the speed AI-enabled attackers operate, so that silent control failures are found by the organisation first.
Builds on: F1, F4, F8, F13, F23, Q1, Q6, Q9
Sections: From Chaos Monkey to security chaos engineering; Steady-state hypotheses for security; Experiments across the six Functions; A reference architecture; Safety boundaries; Keeping the SOC's trust; From result to improvement
Practical guides: Introducing security chaos engineering in stages
Worked examples: Security chaos experiment manifest; Safety-boundary policy for the chaos platform
Across the usage modes: The chaos platform deliberately splits modes: the planner and evaluator are Mode 4 services without estate credentials, while only narrow deterministic actuators act, so that no AI holds a privileged identity.
Nordvik Region and Hansa Mutual: Nordvik starts with a small, scheduled experiment catalogue in test environments run with its MSSP (NR-SEC-004); Hansa runs a continuous AI-planned programme across the group estate (HM-SEC-006).
Figure: Reference architecture of an AI-driven security chaos engineering platform with its safety boundaries

Chapter 26: Purple Teaming, Measurement and Continuous Improvement

File: 26_purple_teaming_and_improvement.md
Status: complete
Purpose: Close the loop across all Functions: purple teaming that turns every finding into a verified control, metrics that show whether defensive AI improves outcomes, and the continuous improvement that CSF expects, reported to the management body.
CSF 2.0 Categories: ID.IM Improvement, GV.OV Oversight
AI focus: Securing AI systems: Improvement of AI system security from red-team and incident findings. AI-enabled cyber defence: Measuring defensive AI by outcomes, quality and analyst load. Thwarting AI-enabled attacks: Re-testing against evolving AI-enabled techniques.
Builds on: F1, F4, F12, F21, Q4
Sections: The purple loop; Running a purple session with AI; Metrics that matter; Evaluating security AI; Improvement as a programme
Practical guides: Running a quarterly purple-team session
Worked examples: Finding record carried to closure with re-test evidence
Nordvik Region and Hansa Mutual: Nordvik runs its first purple session after its threat-led exercise; Hansa runs quarterly sessions tied to TLPT findings.
Figure: The purple loop updating the CSF profile

Chapter 27: Nordvik Region and Hansa Mutual: Cyber Defence Conclusions

File: 27_conclusions_for_nordvik_and_hansa.md
Status: complete
Purpose: Draw the conclusions for Nordvik Region and Hansa Mutual: their CSF profiles with an AI focus before and after, the decisions they took, the gaps that remain and their next steps.
Builds on: F9, F17
Sections: Nordvik Region; Hansa Mutual; Their CSF profiles compared; Remaining gaps
Worked examples: Current and target CSF profile for each organisation
Nordvik Region and Hansa Mutual: This chapter is the conclusion for both organisations.
Figure: CSF profiles of the two organisations by Function

Chapter 28: Conclusions: AI as an Active Part of Cyber Defence

File: 28_conclusion.md
Status: complete
Purpose: Give the consolidated analysis: the principles of AI as an active part of cyber defence across the CSF Functions, how they extend the series, which open questions are answered and which remain, and a labelled forward look.
Builds on: F17, F18, F19, Q1, Q4, Q9
Sections: Principles by Function; What the series now says; Answered and open questions; Forward look
Nordvik Region and Hansa Mutual: Compares the two organisations' paths in one closing table.
Figure: The series as one argument, from Architecture as Code to AI-enabled defence

Appendices

29_glossary.md: Defines the CSF, red-team, blue-team, AI-security and European regulatory vocabulary used in the book.
30_appendix_a_code_examples.md: Complete versions of the artefacts in the chapters: CSF profiles as code, security chaos experiment manifests and the chaos platform safety-boundary policy, rules-of-engagement manifests, autonomy-level records, permission manifests and containment profiles for security AI, detection rules with tests, evaluation-harness configurations, finding records and metric definitions. No attack tooling.
appendix_templates_and_tools.md: Templates for CSF profiles, rules of engagement, exercise plans, finding records, autonomy-level decisions, purple-session agendas and supplier assurance questions.