Every loop starts with a choice of what to test. This chapter describes how an organisation makes that choice well: how intelligence, the threat register, risk assessment and incidents become a short list of priority techniques and a versioned library of scenarios, who decides what enters the library, and what must be kept out of it. It concerns P1 Target above all. It reaches forward to P2 Emulate, because a scenario is the unit that emulation executes under a signed rules-of-engagement manifest (Chapter 6), and back from P5 Verify, because every re-test result and every coverage gap returns to the list and changes its order.
The choice matters more when AI is in the loop. Emulation that costs little can run every scenario in the library every month, and an agent can draft new scenarios faster than a person can read them. The scarce resource moves from the hours of the red team to the judgement that decides which scenarios are worth running at all. A library chosen for convenience produces a loop that is busy and green and says little about the risks the organisation carries. The chapter argues that targeting is a risk decision with an owner, a record and a review date, and that the commonest failure of P1 Target is a quiet one: testing what is easy to emulate and calling the result coverage.
The chapter builds on four conclusions of the earlier volumes. Architecture as Code (Chapter 9C) established that threat handling belongs in the codebase: intelligence is ingested through pipelines, risk is a versioned record with likelihood, impact, owner and expiring exceptions, and findings return as pull requests (87, Nordqvist, 2025). AI Red Team, Chapter 10, established that threat models live beside the architecture, that AI proposes candidate threats at Level 1 Assisted, that soundness is defined in advance and that a named reviewer decides each candidate; no AI accepts a threat, a risk or an exception (90, Nordqvist, 2026). AI Threat, Chapter 32, established the threat register as code: scenarios with a path to harm, an owner, a decision tier and triggers, with probability omitted on purpose (91, Nordqvist, 2026). AI Blue, Chapter 5, established intelligence as code, the path from a report to a hypothesis, a hunt and a detection requirement, and the verification of what an AI extracts from a report (94, Nordqvist, 2026). This chapter does not repeat them. It takes the next step: from a risk-ranked view of threats to the scenarios that test whether the defence answers them.
Primary topics explored
- From intelligence to scenario
- ATT&CK and ATLAS as vocabulary
- Priority techniques
- The scenario record
- AI-proposed scenarios and who decides
- What not to test
About AI Purple
AI Purple is Book 9 of The Transformed Architecture. It takes the loop between the red team and the blue team as its subject and asks what happens when AI sits on both sides of the table: the five stages of the loop (target, emulate, observe, improve, verify), rules of engagement and safe emulation, continuous emulation, the independence principle, coverage as a claim that needs evidence, the loop's own AI and how to defend it, operating models, decision rights, regulation, and the people involved, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss and AI Blue.
Chief information security officers, heads of security operations, red-team leads, penetration testers, SOC managers, detection engineers, purple-team coordinators and incident commanders, security and AI architects, boards and management bodies, procurement leads, works councils and unions, data protection and audit functions, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 5: Target: Threat-Informed Scenarios, Risk and Priority Techniques in AI Purple gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Stages of the Loop” and is one of 33 drawn from the manuscript.