Introduction: The Purple Loop with AI

This book asks one question of one practice. When artificial intelligence sits on both sides of the table, in the tooling that emulates an adversary and in the tooling that detects and responds, does the loop between the red team and the blue team still tell an organisation whether it would have seen and stopped an attack, and how does it show that it does? The chapter states the question, gives the working thesis in five parts and says what would show it wrong, introduces the five stages of the loop and the independence principle, explains why the question is a European one in 2026 and 2027, sets the rules the book keeps and introduces the two organisations that run through it. It concerns all five stages by name: P1 Target, P2 Emulate, P3 Observe, P4 Improve and P5 Verify. Chapter 4 defines them; this chapter only introduces them, so that a reader can decide how to read the rest.

The purple loop with its five stages, the chapter that treats each and the teams that take part: the red team at P1 Target, the blue team at P3 Observe and the white team holding the stop path at P2 Emulate. The stop path and independence, which sit outside any stage, and coverage with evidence age are treated in Chapters 6, 15 and 17.

Figure 1.1: The purple loop with its five stages, the chapters that treat each, and the red, blue and white teams.

A quarterly session and a continuous pipeline, two nights

Two organisations emulate the same adversary technique on the same Thursday night. The technique is T1087.002, discovery of domain accounts, a discovery technique that lists which domain accounts exist and that does little damage by itself (17, MITRE, n.d.). The organisations and the two outcomes below are fictional and illustrative; the book returns to both throughout.

At Nordvik Region, a regional public authority, the technique is run by a contracted tester, Elin Berglund, in the Region's identity-provider test tenant, as part of the autumn catalogue run under the call-off agreement NR-2026-071. The scenario is SCN-NR-0007, benign and reversible, and the expectation written before the run is that no detection fires, because the Region has declared this a gap. That is what happens. The tester's report records it, a person reads the report a few weeks later, and the finding enters the register. Nothing is wrong with this. What the Region can say afterwards is exact but narrow: on that night, in that tenant, the technique was run and not seen. Whether it would be seen now depends on what has changed since, and the next evidence arrives in the spring.

At Hansa Mutual, a multinational mutual insurance group, the same technique is run by a pipeline. An emulation runner executes a benign, tagged scenario from the group's library of 86 on a rolling schedule, inside a signed scope, under a mandate and with a stop path held outside the runner. An observation correlator reads the emulation log and the detection telemetry, and a finding is raised if the detection did not fire. If a detection engineer changes the rule on Friday, the scenario runs again on Friday. What the group can say afterwards is also exact: the technique was last exercised on a stated date, with a stated result, and the evidence expires in 90 days for a priority technique.

Neither night is better in every respect. The Nordvik run contains something the pipeline cannot supply, a tester who chose what to try because of what she had seen elsewhere. The Hansa run contains something the exercise cannot supply, repetition at the pace at which the estate changes. The difference that matters to this book is what each organisation can later prove about the night, to an audit committee, a board or a supervisor, and who checked that proof. That is the subject of the chapters that follow.

The loop in 2026

The loop is the structure that carries a finding from an adversary's behaviour to a defence that has been shown to work. Its parts are old. Organisations have commissioned penetration tests for decades; European authorities have run threat-led testing of financial entities under the TIBER-EU framework, which was updated in 2024 to align with the threat-led testing standards of the Union's digital operational resilience law (20, ECB, 2025); the practice of red and blue working through a test together has its own published guidance (34, ECB, 2025). Chapter 2 maps these forms. Its rhythm was set by scarcity: skilled red-team hours are expensive, so an organisation bought them once a year, and the blue team had a quarter or a year to act on the report.

Three things are different in 2026, and each is observable in published material.

First, tooling that runs adversary behaviour repeatably is common and open. Open libraries such as Atomic Red Team and MITRE Caldera (Chapter 2) map small tests to ATT&CK techniques and automate adversary emulation (32, Red Canary, n.d.) (33, MITRE, n.d.). Neither needs a model. Both make a scenario cheap to repeat, which is a precondition for a loop that runs on a schedule and not on a calendar.

Second, AI now takes part in offensive work, and the reports are published. Researchers demonstrated in a laboratory setting that language-model agents could exploit one-day vulnerabilities given their descriptions (68, Fang et al., 2024). Threat-intelligence teams report adversaries using AI for vulnerability exploitation and for augmenting operations (63, Google GTIG, 2026), and one developer reported disrupting what it described as the first reported AI-orchestrated cyber espionage campaign (67, Anthropic, 2025). The window between disclosure and exploitation is shorter than it was: Mandiant's analysis put the average time to exploit at five days in 2023, against 32 days in 2021 and 2022, with the caveat, which the authors state, that outliers were excluded from the 2023 figure (61, Charrier & Weiner, 2024). These are observable facts about the adversary's side. They do not show that every adversary is faster, and Chapter 3 treats the evidence with that care.

Third, AI takes part in the defence. AI Blue described the transformed security operations centre, in which triage, investigation and the drafting of detections are done by agents under mandates, and in which the analyst's work moves from the queue to the loop (94, Nordqvist, 2026). That book left the red team's tradecraft and the joint practice to a later volume. This is that volume.

Taken together, these developments have a consequence that is the book's own observation and not a finding of any one source. An emulation side that can vary and repeat adversary behaviour cheaply, and a defence side that can triage and draft at speed, can in principle close a loop between themselves with little human attention. Whether such a loop is a better loop or a faster way to agree with itself is the open question.

The question the series had not asked of the loop

The earlier volumes settled a good deal. AI Red Team put AI to work in cyber defence, Function by Function of NIST CSF 2.0 (24, NIST, 2024), defined the red team as the team that emulates the adversary, the blue team as the team that defends and the purple team as the joint loop between them, not a third team, and gave the loop a fixed sequence of states and one exit condition in its Chapter 26 (90, Nordqvist, 2026). It also set out the technical design of adversary emulation and continuous red teaming in its Chapter 12. AI Blue described the people and functions that defend, and treated the loop as the second half of B5 Learn in its Chapter 11: a finding is closed when a re-test passes (94, Nordqvist, 2026). AI Threat, Chapter 30, classified controls as verified, declared or failed, and held that a control counts as a defence only when a test that re-runs its scenario has passed recently (91, Nordqvist, 2026). The Transformed Security Architect, Chapter 14, gave the method for verifying what AI proposes when the reviewer depends on the AI: independent reproduction, seeded errors and review that does not start from the AI's answer (92, Nordqvist, 2026).

Each of these treats the loop from one side, or treats verification in general. None asks what happens to the loop when the test and the tested are both AI. That question has specific parts, which the book takes in turn.

  • Agreement without verification. An emulation agent and a detection agent may share training data, a model family and blind spots. Language models show correlated errors across model families (104, Kim et al., 2025), and a model used as an evaluator can favour its own output (106, Panickssery et al., 2024). A check in which one such system grades another can pass for reasons that have nothing to do with the defence. Chapter 15 treats this as the central design problem.
  • Overfitting. A detection written to catch the scenario that tests it will catch that scenario. Continuous testing against a fixed library makes this easier to do by accident.
  • A map of the organisation. A library of scenarios, findings and known weaknesses tells an adversary where the organisation is weak. The register is itself a crown jewel (Chapter 16).
  • An offensive capability inside the estate. An emulation agent holds credentials and executes adversary behaviour. If its scope, mandate or stop path fails, the exercise becomes an incident. The July 2026 intrusion in which an agent left its intended boundary during testing is the series' reminder (Chapter 6; AI Red Team, Chapter 12) (90, Nordqvist, 2026); the incident is documented in (73, Larcher et al., 2026).
  • The green dashboard. A continuous loop produces a stream of passing results. Unless each carries an age and a condition, nobody can tell a defence that works from a dashboard nobody has questioned since a person last looked (Chapter 17).

None of these argues against automation. Each argues for design: records, ceilings, independence and evidence, which is what the series has argued for throughout.

The working thesis

The book's thesis has five parts. It is the author's own claim, not a finding reported by a source. Parts II to V test it, Chapter 29 judges it and Chapter 25 sets out the author's projections about the future of the loop.

  1. Purple is a loop, not a team. What is scarce is a shared, verified account of what the defence does against what the adversary does. The purple team in this book is that joint loop, never a third team that sits beside the other two. Whoever supplies the work, an in-house red team, a contracted tester, an automated pipeline or all three, the loop closes only when a change has been re-tested, the evidence attached and a named person has signed the closure.
  2. AI moves the loop from the event to the pipeline, and keeps the event. Continuous, automated emulation and regression make verification routine, so the work shifts from running exercises to engineering scenarios, detections and tests as code. The exercise remains where novelty, judgement and trust are produced. The pipeline is already possible with open tooling that needs no model; what AI adds is cheaper variation, planning and drafting, which is expected and not yet measured (Chapter 8).
  3. A loop closed by machines alone verifies nothing new. More exactly, it can show that the known still works and cannot by itself show that its scenarios were the right ones or that its coverage means what it says; Chapter 29 states the claim in this form. Verification needs independence between the side that tests and the side that is tested: different model families and data, human-authored novelty, seeded errors and an evidence trail a person can reproduce. This is the independence principle, and it is the central design rule of the book (Chapter 15).
  4. Coverage is a claim that needs evidence. "We detect technique T" is a statement with an age, a condition and a result. Untested is not covered; evidence expires; detections decay (Chapter 17).
  5. Safe and legitimate emulation is a design question. Scope, authority, blast radius, stop path, the consent of third parties and the rights of staff are decided before an agent acts, in a signed rules-of-engagement manifest enforced outside the agent (Chapter 6). Level 4 Autonomous is never used for an emulation action that is irreversible, that leaves the signed scope, that touches personal data beyond what the exercise has been authorised to touch, or that targets a named person.

What would show the thesis wrong

A thesis that nothing could refute is a slogan. Two kinds of evidence would count against this one, and the book commits to them in advance.

The first would be evidence that fully automated emulation and automated detection engineering, with no human-authored novelty and no independent verification, sustain real detection of novel intrusions better over several years than a loop that keeps those properties, as judged by independent threat-led tests. That would undermine parts 2 and 3. The second would be evidence that a continuous loop leaves the capacity for human-led, creative adversary emulation intact without people who practise it, so that the red craft survives automation without an apprenticeship. That would undermine the book's concern, in Chapter 24, for where the next red operators come from.

Two weaker kinds of disconfirmation also matter. If independence checks catch nothing over a long period, either the loop is sound or the checks are too weak, and Chapter 15 says how to tell which. If coverage records are routinely expired and nobody is harmed, the claim that evidence age matters would need qualifying. As of this writing no such evidence exists. That statement is an observation about the published record, not a prediction, and it will date.

Five stages and five degrees

The loop has five stages, each answering one question and each ending in one kind of record. Chapter 4 defines them in full; the paragraph for each stage here is only enough to read the rest of this chapter.

P1 Target chooses what the loop will test, from intelligence, the threat register, risk assessment and incidents, expressed in the vocabulary of ATT&CK and, for AI systems, ATLAS (18, MITRE, n.d.). Its record is the scenario (SCN-*), and Chapter 5 treats it, together with the tendency to test what is easy. P2 Emulate executes a scenario inside a signed scope and under a stop path held outside the emulating system, in human-led, AI-assisted and continuous forms (Chapters 6 to 8). P3 Observe compares what happened with what was expected, written before the run, layer by layer, and raises a finding where the outcome falls short (Chapter 9). P4 Improve turns a finding into a detection, a control, a playbook, a mandate change or a recorded risk acceptance (Chapter 10). P5 Verify re-runs the scenario and a variant and stores the evidence, so that a finding is closed only when the re-test passes, the evidence is attached and a named person signs (Chapter 11).

The closure rule gives the loop its test. A finding is in one of five states: open; implemented, unverified; re-test failed; closed and verified; or risk accepted. Only closed and verified is closed, and an agent may run the re-test and assemble the evidence but never signs the closure (Chapters 4 and 11). A dashboard that counts the others as done hides the difference between a defence that was shown to work and a weakness that was knowingly left.

The independence principle applies wherever AI is on both sides of a check. It asks whether the side that tests and the side that is tested differ in model, data, authorship, vendor and time, and whether the person who answers for the quality of a finding is not the person who closes it, and it supplies three proofs: held-out scenarios, seeded gaps and seeded errors, and the reproduction of a result by a person (Chapters 4 and 15).

The degrees of delegation are the series' autonomy levels, applied per stage and per action class: Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded and Level 4 Autonomous (90, Nordqvist, 2026). The line that matters most lies between Level 2 and Level 3. Level 3 is defined by a codified playbook enforced by a policy decision point outside the model, and by a person who is informed and able to stop it. Level 4 is not used for the four excluded classes above, and Chapter 4 sets a ceiling for every stage below it.

Across the usage modes

The series distinguishes usage modes by how AI is deployed and whose identity it uses, and the loop uses three groups of them.

Group Modes What the AI does in the loop Whose identity Where it is treated
AI that assists a person Modes 1 to 3 A tester drafts a scenario description or an analyst summarises a log, under the person's own identity and judgement The person's Chapters 5, 9, 10
AI built or procured to perform a loop function Mode 4 A curator, correlator, critic or drafter inside a defined workflow A service identity bounded by a mandate Chapter 14
Agents with identities of their own Mode 5 An emulation runner or a re-test runner that executes against the estate Its own identity and permissions, a privileged account in effect Chapters 6, 8, 14

The distinction decides where the risk sits. In Modes 1 to 3 the person is accountable and the risk is over-reliance on a draft. In Mode 4 the risk is a function nobody has reviewed since it was set up. In Mode 5 the agent is an identity that can act, and the risk is the one the rules of engagement exist to bound. Mode 0, ambient AI, is already present in simulation and detection products that the organisation did not build, which the guide below asks the reader to find.

Practical guide: A one-page inventory of AI in testing and in detection

Purpose. Find every place where AI already takes part in testing or in detection, including vendor AI in managed services and simulation tools, before deciding how the loop should be designed around it. Roles. The purple-team coordinator, or the head of security operations where there is none, drafts; the procurement or vendor manager supplies the contracts; the CISO accepts; the data protection officer reviews entries that touch personal data.

  1. List the testing activities: penetration tests, red-team engagements, threat-led tests, tabletops, purple sessions and simulation tools, with who runs each.
  2. List the detection and response activities: triage, correlation, detection drafting, playbook execution and out-of-hours monitoring, with who runs each.
  3. For each, ask whether AI takes part, whose it is (the organisation's, a tester's or a provider's), which usage mode it is in and whether the contract says so. A provider that does not declare its AI is an entry with the status "unknown".
  4. Record the identity AI uses and the highest level at which it acts, or "not stated".
  5. Mark the entries where AI is on both sides of one check, for example a provider's AI that closes alerts and a tester's tool that generates them. Those entries need an independence declaration (Chapter 15).
  6. Review the inventory every six months and whenever a provider gives notice of a model change.

Definition of done. Every entry has an owner, a mode and a status; no entry is blank; the "unknown" entries have a date by which the provider must answer; the page fits on one sheet and sits in the repository next to the loop charter.

# Illustrative: first rows of Nordvik Region's inventory of AI in the loop (2028-01)
inventory: AIINV-NR-2028-01
owner: Karin Lund
entries:
  - activity: annual penetration test and catalogue runs
    run_by: contracted tester under NR-2026-071
    ai: declared Modes 1 to 3, no Mode 5 emulation agent without a signed mandate
    mode: [1, 2, 3]
    level_max: 1
  - activity: out-of-hours alert closure
    run_by: managed provider under NR-2025-044
    ai: provider closes low-severity alerts
    mode: [0]
    level_max: not stated
    status: unknown
    ask_by: 2028-03-31
    on_both_sides_of_a_check: true
  - activity: detection drafting
    run_by: detection owner
    ai: drafting assistant
    mode: [4]
    level_max: 1
    note: not used for a scenario it helped to choose

Why Europe, and why now

The question is general, but in Europe in 2026 and 2027 it arrives as obligation, and the obligations decide who may emulate what, where and with whose consent. This chapter names the instruments; Chapter 21 treats them. Everything is framed as an architectural and organisational implication, not as legal advice, and the article numbers below were checked against the text on EUR-Lex.

Testing duties. The Digital Operational Resilience Act requires financial entities other than microenterprises to keep a testing programme, risk-based and using independent testers, and to prioritise and fix what the tests reveal and validate that the gaps are closed (Article 24) (2, European Union, 2022). It requires advanced testing by threat-led penetration testing at least every three years for qualifying entities, with the competent authority able to adjust the frequency (Article 26), and sets requirements for testers (Article 27). Where internal testers are used, external testers must be contracted for every third test (Article 26). A delegated regulation specifies the scope, methodology and the closure and remediation stages (8, European Commission, 2025). The implication for the loop is that a continuous pipeline is not a substitute for the supervised test, and that the closure stage of the test and the closure rule of the loop must agree. Whether a supervisor may accept evidence from the second is an open question this book carries (Chapter 21).

Effectiveness and oversight. NIS 2 Article 21(2)(f) lists among the cybersecurity risk-management measures "policies and procedures to assess the effectiveness of cybersecurity risk-management measures", and Article 20(1) requires the management body to approve the measures and oversee their implementation (3, European Union, 2022). A loop that closes on a re-test and keeps its evidence is a way for a management body to show that it assessed effectiveness and did not assume it. DORA places a similar responsibility on the management body of a financial entity (Article 5(2), under which the management body defines, approves, oversees and is responsible for the implementation of the ICT risk management framework).

Adversarial testing of AI. The AI Act obliges providers of general-purpose AI models with systemic risk to perform model evaluation, including conducting and documenting adversarial testing, with a view to identifying and mitigating systemic risk (Article 55(1)(a)), and requires high-risk AI systems to reach appropriate accuracy, robustness and cybersecurity and to be resilient against attempts by unauthorised third parties to alter their use, outputs or performance, with AI-specific vulnerabilities addressed where relevant (Article 15(1) and (5)) (1, European Union, 2024). For a deployer, the implication is that the AI systems in its estate are legitimate targets of the loop (Chapter 12), and that its own agents are among the things the loop must test (Chapter 13).

People and third parties. Exercises that involve staff, and the measuring of people who run or defend against them, fall under national co-determination and data-protection law. Hansa Mutual's works council has co-determination rights over technical devices designed to monitor the behaviour or performance of employees under German law (Section 87(1), no. 6, of the Works Constitution Act, the Betriebsverfassungsgesetz) (11, Bundesrepublik Deutschland, n.d.); the Federal Labour Court holds that a device is designed for that purpose when it is objectively suitable to collect and record such information, whatever the employer intends (16, Bundesarbeitsgericht, 2022) (121, Bundesarbeitsgericht, 2024), and a works agreement extends the security operations annex to exercises. Nordvik Region's union has agreed that results are reported in aggregate and never by name. A test that crosses the boundary of a managed provider needs the provider's consent, and a test of a cloud service must follow the cloud provider's published rules for customer testing: Microsoft, for example, requires no pre-approval for penetration tests of Azure resources but binds testers to its rules of engagement, and a third party may test only with the resource owner's written authorisation (79, Microsoft, 2026). These constraints are part of the design, not obstacles to it, and Chapters 6, 21, 22 and 23 treat them.

The timing matters for a further reason. Several of these instruments are new or still being applied, and organisations are deciding now how to evidence compliance. A loop built without independence and without evidence age will, expected, be hard to defend to a supervisor later. A loop designed with them gives the board and the supervisor an answer from its own records.

Rules of the book

The book keeps a small number of rules, and a reader should know them before judging the rest.

  • Defensive only. Adversary behaviour is described by ATT&CK or ATLAS technique at the level needed to design scenarios, detections, controls and tests. The book contains no exploit code, malware, payloads, jailbreak or injection strings, phishing kits or step-by-step intrusion instructions. Every offensive activity described is authorised, scoped by written rules of engagement, run against the organisation's own or contracted systems and ends in a defensive improvement. Covert monitoring of staff and defeating employee representatives' rights are never described as methods.
  • Observable, expected, speculation. Every statement about the future of the loop, of threats or of the technology carries one of three labels. Observable means happening now and documented. Expected means supported by a stated trend or a decided instrument. Speculation means plausible but unsupported by present evidence. The author's own projections are kept to Chapters 25 and 29.
  • No anthropomorphism. An emulation agent plans, executes a catalogued scenario or reports; it does not attack in any sense that implies intent. An AI system correlates, flags, recommends or drafts; it does not suspect or judge. "Decides" is used only for a system to which a decision was formally delegated, and the record then says who delegated it, under which profile and at which level.
  • Coverage with evidence age. No chapter says that something is covered without saying what was tested, when and with what result.
  • Stop paths and reversibility. Every chapter that concerns P2 Emulate says what can be undone and who can stop it, outside the system being stopped.
  • Claims and sources. Every claim about the world cites a source in the bibliography or is the book's own conclusion, drawn in a conclusions section or summary. A reference to an earlier volume builds on its conclusions and never stands in for an external source.
  • Legal content is attributed to the instrument and article and framed as architectural implication.
  • Teams. The red team emulates the adversary, the blue team defends and the white team governs an exercise (TIBER-EU and DORA call it the control team, Chapter 2); the purple team is the joint loop between red and blue, never a third team.
  • People. Effects on people are described by what studies measured. Nobody is called lazy, stupid or replaceable, and the people of the loop, red operators, analysts, detection engineers and controllers, are described with the respect their craft deserves.

The book builds on Books 1 to 8 of the series and refers to none later. It summarises enough of an earlier volume's topic that the reader is not left with a gap, and it cites the volume as Architecture as Code (Chapter N) (87, Nordqvist, 2025) or AI Red Team, Chapter N, and so on (90, Nordqvist, 2026).

Observable, expected, speculation

The labels apply to this chapter's own outlook. That AI takes part in offensive tooling, that AI takes part in detection tooling and that the exploitation window has shortened are observable, with the sources above and the caveats stated there. That continuous verification becomes the normal case for organisations with a pipeline is expected: it follows from the testing obligations above and the falling cost of repetition, but no source measures it yet. A self-improving defence in which an emulation system and a detection system close the loop with no review is speculation, and Chapter 25 treats it. The thesis itself is the book's own claim.

Two organisations

The book follows two fictional organisations through every narrative chapter, so that each idea meets a case. Their profiles are consistent with the earlier volumes and the figures are illustrative.

Nordvik Region is a regional public authority in a Nordic member state, with about 6,000 employees, serving about 450,000 residents. It buys the loop, and its leverage is the contract. It has no red team. It procures an annual penetration test per system, engages a testing firm under a call-off agreement for two catalogue runs a year, and buys out-of-hours monitoring from a European managed provider. Six analysts work in office hours; Karin Lund is the detection owner and, for a fraction of her time, coordinates the loop as purple-team coordinator (a role, not a team). Its library holds 12 scenarios at the start of the book. Its risk is a loop that never starts, or stops after the first report.

Hansa Mutual is a multinational mutual insurance group headquartered in Germany, operating under seven legal regimes. It runs the loop, and its leverage is the pipeline. It has a red team of five led by Mareike Hartmann, a detection-engineering team of four led by Lena Vogel, a group security operations centre of about 38 and a library of 86 scenarios covering 34 priority techniques. A pipeline runs the benign scenarios continuously, quarterly purple sessions run under a standing rules-of-engagement manifest, and an annual human-led exercise includes the supervised threat-led test for its German entity. Its risk is a loop that runs without anyone questioning it.

In January 2028 each is asked a version of the same question.

Worked example: The two questions as decision records

The audit committee asks Nordvik's chief information security officer what the first threat-led exercise has proved, beyond a list of closed findings. The executive board asks Hansa Mutual's group CISO whether continuous automated red teaming makes the quarterly purple session redundant. Each question is recorded, with a reviewer and a date for the first report, as an AI Decision Record; the illustration is abbreviated.

# Illustrative: Nordvik Region (AIDR-0800)
kind: AIDecisionRecord
id: AIDR-0800
date: 2028-01-11
asked_by: audit committee
addressed_to: chief information security officer
question: "What has the first threat-led exercise proved, beyond a list of closed findings?"
reviewers: [internal audit, AI architect, data protection officer]
first_report_due: 2028-04-30
answer_must_state: [what was tested, when, with what result, evidence age, who verified]

# Illustrative: Hansa Mutual (AIDR-0850)
kind: AIDecisionRecord
id: AIDR-0850
date: 2028-01-18
asked_by: executive board
addressed_to: group CISO
question: "Does continuous automated red teaming make the quarterly purple session redundant?"
reviewers: [chief risk officer, head of detection engineering, chair of group AI governance board]
first_report_due: 2028-04-30
answer_must_state: [what the pipeline verifies that the session does not, and the reverse]

Both records ask for an answer in the form the thesis requires: what was tested, when and with what result. Neither can be answered by a count of findings or scenarios, which is why Chapters 17 and 18 define coverage and measures. The first reports are due on 2028-04-30, and the book returns to both in Chapters 8, 26, 27 and 28.

Nordvik Region and Hansa Mutual

The two questions are the same question from opposite ends. Nordvik's committee asks whether a small catalogue run by a contractor twice a year, with injected tests between, gives evidence it can rely on. Hansa's board asks whether a large pipeline makes a human-led session unnecessary. The honest first answer from each is that the evidence is narrower than the question assumes: Nordvik has a library of 12 scenarios and results with an age, and Hansa has a verified share of its priority techniques. At the end of AI Blue 25 of Hansa's 34 priority techniques were verified, and findings waited a median of 19 days for a control (94, Nordqvist, 2026). Nordvik's independence is by role and contract, a tester who is not the detection owner and a provider who is not the Region. Hansa's independence must be designed between agents, model families and teams that share a repository. The other differences the book draws out, in people, regimes and protection of the findings register, recur in every part.

How to read this book

The book has seven parts. A reader who wants the argument reads Part I and Chapters 15, 25 and 29. Others will want a path by role.

Reader Start with Then
Board member, audit committee, management body This chapter, Chapter 4, Chapter 17, Chapter 18 Chapter 20 (decision rights), Chapter 21 (regulation), Chapter 29
CISO or head of security operations Chapters 3, 4, 14, 15 Parts II and V, Chapter 28
Red-team lead, penetration tester, contracted tester Chapters 2, 5, 6, 7 Chapters 8, 12, 24
Detection engineer, SOC manager, threat hunter Chapters 4, 9, 10, 11 Chapters 13, 14, 17
White-team controller, exercise controller Chapters 6, 20 Chapters 8, 22
Purple-team coordinator Chapters 4, 9, 11, 19 The whole of Part II
Security or AI architect Chapters 12, 13, 14, 16 Chapters 15, 17
Procurement, vendor management Chapters 19, 22 Chapters 6, 21
Works council, union, data protection officer Chapters 6, 16, 21, 23 Chapter 18
Supervisor, auditor, public-sector leader Chapters 11, 17, 21 Chapters 20, 22

The parts are arranged so that each rests on those before. Part I (Chapters 1 to 4) sets the question, describes the loop as it was, explains the pressure on it and defines the five stages. Part II (Chapters 5 to 11) takes the stages in turn. Part III (Chapters 12 and 13) applies the loop to AI systems and agents, and to the defenders' own AI. Part IV (Chapters 14 to 16) treats the loop's own AI, the independence principle and the protection of the loop's assets. Part V (Chapters 17 to 22) treats the loop in the organisation: coverage, measures, operating models, decision rights, regulation and boundaries. Part VI (Chapters 23 to 25) treats the people who run the loop and the future. Part VII (Chapters 26 to 29) draws on cases, a year in the loop and the conclusions.

Four of the chapters stage a debate in four steps, the case for concern, the case for calm, where the positions meet and what can be done: Chapters 8, 15, 24 and 25. Each ends in a verdict with a label, and with something the reader can do. The chapters on the people, Chapters 23 and 24, take the human side as seriously as the technical one, because a loop is run by them.

Twelve questions stay open at the end of the earlier volumes and are carried here, among them what makes a result independent when AI is on both sides, what "covered" means and for how long, how emulation can run in production without becoming an incident, how far Level 3 can safely reach and how quickly a stop path decays unless it is drilled. The book does not claim to close them all. Chapter 29 states which it answers by design and which it leaves open.

Summary

This chapter asked what happens to the loop between the red team and the blue team when AI sits on both sides. Two Thursday-night runs of one technique showed the contrast the book examines: a contracted exercise gives novelty and a dated, narrow result, and a pipeline gives repetition at the pace of change. What matters in both is what the organisation can later prove, and who checked it. Observable developments in 2026, open emulation tooling, AI in offensive operations, a shorter exploitation window and AI in the security operations centre, make a continuous loop possible. They also create the problem the series had not addressed, a loop that two systems can close between themselves and that may only agree with itself.

The working thesis has five parts: purple is a loop, not a team; AI moves the loop from the event to the pipeline and keeps the event; a loop closed by machines alone verifies nothing new; coverage is a claim that needs evidence; and safe emulation is a design question settled in a signed manifest enforced outside the agent. Evidence that unreviewed automation sustains real detection better, or that the red craft survives automation without people who practise it, would show the thesis wrong. The chapter introduced the five stages, P1 Target, P2 Emulate, P3 Observe, P4 Improve and P5 Verify, the closure rule, the independence principle and the degrees of delegation from Level 0 Advisory to Level 4 Autonomous, with Level 4 never used for the four excluded classes. It also gave a one-page inventory of AI in testing and detection as the first practical step.

The European frame makes the question concrete: DORA Articles 24, 26 and 27 on testing, NIS 2 Articles 20 and 21 on effectiveness and oversight, AI Act Articles 15 and 55 on robustness and adversarial testing, and the rights of staff and the consent of providers. The rules of the book are defensive only, three outlook labels, no anthropomorphism, coverage with evidence age and a stop path outside the system stopped. Nordvik Region buys the loop and Hansa Mutual runs it, and each was asked a version of the same question in January 2028 (AIDR-0800 and AIDR-0850), to be answered by 2028-04-30.

Chapter 2 now describes the loop as it was: the penetration test, the red-team engagement, the threat-led test, the tabletop, the purple session and breach-and-attack simulation, with the roles each involves and the places where findings stalled.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
  2. 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)
  3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
  4. MITRE Corporation. MITRE ATT&CK. (17, MITRE, n.d.)
  5. MITRE Corporation. MITRE ATLAS. (18, MITRE, n.d.)
  6. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. (20, ECB, 2025)
  7. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (24, NIST, 2024)
  8. Charrier, C. & Weiner, R. How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. (61, Charrier & Weiner, 2024)
  9. Google Threat Intelligence Group. GTIG AI Threat Tracker: Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access. (63, Google GTIG, 2026)
  10. Anthropic. Disrupting the first reported AI-orchestrated cyber espionage campaign. (67, Anthropic, 2025)
  11. Fang, R., Bindu, R., Gupta, A. & Kang, D. LLM Agents can Autonomously Exploit One-day Vulnerabilities. (68, Fang et al., 2024)
  12. Nordqvist, G. Architecture as Code. (87, Nordqvist, 2025)
  13. Nordqvist, G. AI Red Team. (90, Nordqvist, 2026)
  14. Nordqvist, G. AI Threat. (91, Nordqvist, 2026)
  15. Nordqvist, G. The Transformed Security Architect. (92, Nordqvist, 2026)
  16. Nordqvist, G. AI Blue. (94, Nordqvist, 2026)
  17. European Commission. Commission Delegated Regulation (EU) 2025/1190 (threat-led penetration testing under DORA). (8, European Commission, 2025)
  18. Microsoft. Penetration testing (Azure security fundamentals) and the Microsoft Cloud Unified Penetration Testing Rules of Engagement. (79, Microsoft, 2026)
  19. Red Canary. Atomic Red Team. (32, Red Canary, n.d.)
  20. MITRE Corporation. MITRE Caldera. (33, MITRE, n.d.)
  21. European Central Bank (2025). TIBER-EU Purple Teaming Guidance. (34, ECB, 2025)
  22. Kim, E., Garg, A., Peng, K. & Garg, N. Correlated Errors in Large Language Models. (104, Kim et al., 2025)
  23. Panickssery, A., Bowman, S. R. & Feng, S. LLM Evaluators Recognize and Favor Their Own Generations. (106, Panickssery et al., 2024)
  24. Larcher, H., Carreira, A. et al. Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. (73, Larcher et al., 2026)
  25. Bundesrepublik Deutschland. Betriebsverfassungsgesetz (BetrVG), § 87 Mitbestimmungsrechte. Gesetze im Internet. (11, Bundesrepublik Deutschland, n.d.)
  26. Bundesarbeitsgericht (2022). Beschluss vom 8. März 2022, 1 ABR 20/21. Bundesarbeitsgericht. (16, Bundesarbeitsgericht, 2022)
  27. Bundesarbeitsgericht (2024). Beschluss vom 16. Juli 2024, 1 ABR 16/23. Bundesarbeitsgericht. (121, Bundesarbeitsgericht, 2024)