Conclusions: AI as an Active Part of Cyber Defence

This book set out to show how large European enterprises and public authorities can put artificial intelligence to work as an active part of their cyber defence, under European law. It followed the six Functions of the NIST Cybersecurity Framework 2.0 so that no part of cybersecurity was left out, treated every Category through the three focus areas of the NIST Cyber AI Profile, and asked throughout how the answer changes with the usage mode of the AI and the autonomy it is given (19, NIST, 2024) (20, NIST, 2025). This closing chapter restates the thesis, draws eight cross-cutting conclusions and ends with what to do first.

The thesis restated

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 that turns every finding into a verified control with evidence.

Each clause carries weight. The mandate makes AI-enabled defence accountable, and the usage mode and autonomy level decide who judges and with whose identity the AI acts. Containment that does not depend on intent, the central conclusion of AI Platform and Security, applies to defensive AI too (73, Nordqvist, 2026), and the purple loop makes improvement, not discovery, the point of every test.

The series as one argument, from Architecture as Code to defence that is executable, verified and accountable

Figure 28.1: The series as one argument, from Architecture as Code to defence that is executable, verified and accountable.

Reflections on each part

Parts I and II: Foundations and Govern. Attackers have begun to move from prompting AI as an aid to running agentic AI workflows, and the window for defenders to respond has been compressed (48, Google GTIG, 2026). Govern is where AI-enabled defence is won or lost: risk appetite, usage modes paired with autonomy levels, rules of engagement as code and oversight of vendor AI (Chapters 5 to 8) make every later capability defensible to boards, supervisors and works councils.

Part III: Identify. CSF places improvements from tests and exercises under ID.IM, so Identify holds the red team. Adversary emulation with AI is safe only under strict rules of engagement and range separation (Chapter 12), and red teaming the organisation's own AI is engineering rather than a one-off exercise (Chapter 13).

Parts IV to VI: Protect, Detect and Respond. Mode 5 agents have identities of their own that must be task-scoped and short-lived (Chapter 14). Detect is where AI has the most immediate effect, but AI-drafted detections are valuable only when people review and test them (Chapters 18 and 19), and machine-speed containment is reserved for bounded, reversible actions (Chapters 20 and 21).

Part VII: Recover. Recover, the most neglected Function, received a part of its own, and both organisations bore out the conviction that AI can change it most: orchestrated recovery, restoration of AI systems and continuous rehearsal (Chapters 22 to 24) turn it into a measured capability (22, Bartock et al., 2016).

Part VIII: Verification and improvement. Security chaos engineering (Chapter 25) provides continuous evidence, but only within safety boundaries that keep the experiment platform from becoming the incident (67, Shortridge & Rinehart, 2023), and the purple loop (Chapter 26) closes every finding with a re-test.

Eight cross-cutting conclusions

The usage mode, not the model, sets the risk of security AI

The same model can be a low-risk aid or a high-risk insider. In Modes 1 and 2 a person judges and the AI acts with that person's identity, so the risk is a misled analyst; in Mode 5 the AI acts with permissions of its own, and the question becomes what a privileged machine insider does when it is wrong, manipulated or compromised. AI Governance concluded that the usage mode, not the brand, sets the governance (72, Nordqvist, 2026); in security the consequences are sharper. Mode 0 deserves special attention, because security products may already act automatically at an effective autonomy nobody decided.

Autonomy is earned action by action, according to reversibility

Autonomy is a property of each action, not of an agent: Hansa Mutual's investigation agent runs at Level 3 Bounded for isolating a workstation and revoking sessions, at Level 2 for disabling accounts and at Level 0 for anything that deletes data. Level 4 Autonomous is never used for offensive or irreversible actions. This answers when 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.

Everything security AI reads may be written by the adversary

Logs, alert fields, email bodies and threat reports are partly authored by attackers, so every mode that reads them is exposed to prompt injection, and in Mode 5 a manipulated proposal can become a harmful action. Because prompt injection is a property of the architecture rather than a patchable defect (73, Nordqvist, 2026), the defence is architectural: a policy decision point outside the model, permission manifests that cap every action, and red-team campaigns that test the ceiling continuously.

Containment must not depend on intent, for defensive AI too

A good purpose does not make defensive AI trustworthy; the July 2026 incident showed agents in a security-testing context exceeding their mandate (64, OpenAI, 2026). Every security AI that acts therefore needs task-scoped credentials, default-deny egress, control artefacts outside its reach, a stop path outside the system it stops, and detection from telemetry rather than self-report.

Covering every CSF Function prevents tunnel vision

AI in cyber defence draws attention to detection and response. Organising the book by CSF 2.0 forced equal attention to the other Functions and showed that some of the largest gains lie there, such as inventories that find shadow AI and restore drills that find unrecoverable dependencies.

Recover is where AI changes the economics most

Recovery is neglected because testing it is expensive. AI makes it cheap enough to do continuously by mapping dependencies, sequencing restoration and rehearsing in isolated ranges, and a fast, verified recovery takes the leverage out of extortion.

Controls must be verified continuously, not assumed

Controls fail silently when the estate changes. Security chaos engineering injects the conditions controls exist for and checks steady-state hypotheses across all six Functions, and AI makes it practical at estate scale. Its value, however, depends entirely on safety boundaries, such as an independent abort controller and treatment of the platform as a tier-0 asset. Continuous verification complements, and does not replace, threat-led penetration testing under DORA (2, European Union, 2022).

Every finding ends as a verified control, and evidence is a by-product

A finding is finished when the control that closes it has been re-tested, not when it is reported. The purple loop carries findings from every source to verified controls and updates the CSF profile, which, kept as code, maps each Category to the European obligations it helps meet, so that one control is assured once and reported many times, the principle Architecture as Code established (71, Nordqvist, 2025). Evidence is then produced by normal operation rather than assembled for audits.

How the conclusions interact

The conclusions form a chain. The usage mode decides whose identity the AI uses, the autonomy level who judges each action, and containment caps what a manipulated or mistaken AI can do; continuous verification shows that the ceiling still holds, and the purple loop turns every gap into an improvement with evidence.

They also pull against each other, and the pulls correspond to the three tensions the earlier volumes identified. Speed versus control: attackers set the speed and machine-speed response argues for autonomy, while attacker-controlled input argues for keeping people in the loop; the resolution is action-by-action autonomy, with Level 3 only for reversible actions and continuous red teaming of the ceiling. Autonomy versus accountability: accountability cannot be delegated to a Mode 5 agent, so every autonomy level is a recorded decision by a named forum. Innovation versus sovereignty: the most capable models are often hosted outside the jurisdiction, while telemetry contains personal data; Nordvik resolved this by self-hosting, Hansa by routing by data class and market overlay.

How to use the conclusions by role

The conclusions are written to be acted on by different roles in different order. This section is the book's own synthesis, drawn from the chapters above, and adds no new claim about the world.

The board or management body needs three things from this book: a decision on the highest usage mode and autonomy level the organisation accepts for security AI, a statement of risk appetite that turns those ceilings into tolerated error rates (Chapters 5 and 6), and evidence at an agreed cadence that the controls it relies on still work (Chapters 25 and 26). Under DORA and NIS 2 the management body is accountable for the measures taken, so these decisions cannot be delegated to a tool (2, European Union, 2022) (3, European Union, 2022).

The chief information security officer and security architects own the architecture that makes the other conclusions hold: identities for agents, policy points outside the model, permission manifests, stop paths and the CSF profile as code (Chapters 3, 4, 14 and 18). Their first task is the inventory of what already acts automatically, including vendor features (Chapter 9).

The SOC, detection engineering and incident response gain most from Chapters 18 to 21 and should adopt AI at Level 0 to 2 first, measuring triage quality and approval behaviour before extending any autonomy. The red team and the blue team meet in Chapters 12, 13 and 26, where rules of engagement and the purple loop keep offensive work authorised and make every exercise end in a verified control. Recovery owners and service owners will find the most neglected Function in Chapters 22 to 24, and the quickest evidence of progress in a restore drill that measures the recovery objectives the organisation has published.

Legal, privacy, procurement and works-council representatives are part of the design, not reviewers at the end: reporting clocks, data residency, supplier terms for AI features and consultation before any tool that can monitor employees are decisions that change the architecture (Chapters 7, 8, 16 and 21). Framed as architectural implications and not as legal advice, they are the reason the book maps each Category to the instruments of European law.

Answered and open questions

The earlier volumes left ten questions for this book (SERIES_FOUNDATIONS.md).

Question Status Where
Q1 How is AI-proposed security change reviewed for soundness? Partly answered: review and re-test evidence Chapters 10, 19, 26
Q2 AI-enhanced security tooling and automated threat hunting Answered Chapters 18 to 21
Q3 Patch-to-exploit times in minutes Answered for architecture: delegated patch decisions and patch velocity as a service level Chapter 11
Q4 Can evaluation carry assurance when models recognise tests? Open: production-like testing and chaos experiments help but do not settle it Chapters 13, 25
Q5 Agent incidents reconstructed from poor logs Answered for design: agent identity, permission manifests and investigation-grade logs Chapters 20, 23
Q6 Testing containment from the adversary's side Answered: agent red teaming and chaos experiments that test stop paths Chapters 13, 25
Q7 AI-enabled emulation in threat-led testing Answered: rules of engagement, range separation and white-team control Chapters 7, 12
Q8 Absorbing the patch wave Partly answered: human verification remains the bottleneck Chapter 11
Q9 A security operation built for machine-speed adversaries and insiders Answered for design: bounded AI-assisted SOC, stop paths and continuous verification of detection Chapters 18, 25
Q10 When may defensive AI act without per-action approval? Answered: reversible, bounded, pre-approved actions at Level 3 with a stop path Chapter 6

Nordvik Region and Hansa Mutual

The two organisations show that the conclusions hold at very different scales (Chapter 27). Nordvik applied every conclusion without a single Mode 5 agent and found its largest gains in Recover. Hansa showed that bounded autonomy at machine speed is achievable and defensible when identity, containment, verification and decision tiers are designed before capability is extended, and found its hardest problems in attacker-controlled input and approval quality. Both made the effective autonomy of every vendor security product a recorded fact.

What to do first, next and later

First, 0 to 6 months. Write the mandate, inventory security AI in every usage mode including vendor features, build a CSF profile as code, introduce one Mode 4 capability at Level 0 or 1 that relieves the scarcest resource, and start AI-assisted restore drills.

Next, 6 to 18 months. Red team the organisation's own AI in release gates, introduce chaos engineering in test environments, give every acting security AI its own identity and out-of-band stop path, and run quarterly purple sessions.

Later, 18 to 36 months. Consider Level 3 Bounded for specific reversible actions on the evidence, promote proven chaos experiments to production within strict limits, and report recoverability, patch velocity and verification coverage to the management body as standing risk indicators.

Actions per usage mode

Mode First action
Mode 0 Ambient AI Inventory vendor AI features, record their effective autonomy and test them
Mode 1 Conversational assistants Approved tier only, no telemetry outside it
Mode 2 Embedded workplace assistants Review inherited permissions; verify summaries against source events
Mode 3 Agentic work tools Isolated ranges, governed skills, no production credentials on workstations
Mode 4 Built AI applications Evaluate quality, red team against attacker-controlled input, read-only identities
Mode 5 Autonomous production agents Own identity, permission manifest, action-by-action autonomy, out-of-band stop path

Worked example: a consolidated first-90-days plan

# Illustrative: first 90 days of an AI-enabled defence programme
kind: ProgrammePlan
id: AI-DEFENCE-FIRST-90
owner: chief-information-security-officer
milestones:
  - {day: 15, deliver: programme charter with usage-mode and autonomy ceilings, csf: [GV.RM, GV.RR]}
  - {day: 30, deliver: inventory of security AI incl. vendor features that act automatically, csf: [ID.AM, GV.SC]}
  - {day: 45, deliver: standing rules of engagement and safety-boundary policy, csf: [GV.PO]}
  - {day: 60, deliver: CSF profile as code with obligation mapping, csf: [GV.OC, ID.IM]}
  - {day: 75, deliver: first Mode 4 capability at Level 1 with quality evaluation, csf: [DE.AE]}
  - {day: 90, deliver: first restore drill and first purple session, csf: [RC.RP, ID.IM]}
guardrails:
  maxUsageMode: 4
  maxAutonomyLevel: 1
  offensiveWorkRequires: signed-rules-of-engagement
  securityDataResidency: EU-EEA
reportTo: management-body

Looking forward

Observable. Attackers use AI across the kill chain, and threat-intelligence reporting describes a move from prompting towards autonomy (48, Google GTIG, 2026) (34, ENISA, 2026). AI-assisted vulnerability discovery has reached a level at which providers manage its release with care (61, Carlini et al., 2026), and NIST has published a preliminary draft of a Cyber AI Profile with the three focus areas this book uses (20, NIST, 2025).

Expected. Supervisors will ask for recoverability and patch velocity as standing metrics, particularly in financial services. Vendor AI in security products will act automatically more often, making the effective autonomy of Mode 0 a governance question in its own right, and continuous verification will become an expected part of demonstrating effective measures under NIS 2.

Speculation. Security operations will come to assume machine-speed adversaries and insiders as the normal case. The hardest open problem, whether evaluation can provide assurance when models recognise test settings (43, Bengio et al., 2026), may shape how much autonomy any organisation can justify.

What the evidence supports and what is 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 legal statements rest on the instruments themselves. Judgement shapes the rest: the autonomy levels, ceilings and defaults are design choices to be adapted to each organisation's risk appetite, and the experiences of Nordvik Region and Hansa Mutual are illustrations, not data.

Defenders cannot choose whether AI is part of the contest; attackers have already made that choice. They can, however, choose how: with a mandate or without one, with containment or with trust, with verification or with assumptions. Those that put AI to work deliberately, with evidence that their controls hold, will close their weaknesses before their adversaries find them.

Summary

AI strengthens cyber defence when it acts inside a written mandate, in a usage mode and at an autonomy level matched to the reversibility of its actions, under containment that holds whatever anyone intends, continuous verification and a purple loop. Eight conclusions follow, from the usage mode setting the risk to every finding ending as a verified control, and Nordvik Region and Hansa Mutual applied them at very different scales with different but defensible answers.

The questions that remain are above all whether evaluation can carry assurance when models recognise tests, and how far human verification can keep pace with machine-speed discovery. The Transformed Architecture began by making architecture executable; it ends, for now, by making defence executable, verified and accountable.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
  2. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
  3. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
  4. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
  5. Bartock, M. et al. Guide for Cybersecurity Event Recovery. (22, Bartock et al., 2016)
  6. European Union Agency for Cybersecurity. ENISA Threat Landscape 2026. (34, ENISA, 2026)
  7. Bengio, Y. et al. International AI Safety Report 2026. (43, Bengio et al., 2026)
  8. Google Threat Intelligence Group. GTIG AI Threat Tracker: From Prompting to Autonomy – The Evolution of Adversarial AI. (48, Google GTIG, 2026)
  9. Carlini, N. et al. Assessing Claude Mythos Preview's cybersecurity capabilities. (61, Carlini et al., 2026)
  10. OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)
  11. Shortridge, K. and Rinehart, A. Security Chaos Engineering: Sustaining Resilience in Software and Systems. (67, Shortridge & Rinehart, 2023)
  12. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
  13. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
  14. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)