Before AI joined the work of testing a defence, organisations tested it in six recognisable ways: the penetration test, the red team engagement, the threat-led test, the tabletop, the purple session and breach-and-attack simulation. Each was a sound answer to a particular question, and each produced a record. This chapter describes them as they ran before the transformation, because the rest of the book changes them, and a change can only be judged against a baseline that has been stated. The chapter concerns all five stages of the purple loop, defined in Chapter 4, by name: P1 Target, P2 Emulate, P3 Observe, P4 Improve and P5 Verify. Its argument is that each form tended to leave one stage unfinished, usually P4 Improve or P5 Verify. That classification is the book's own reading of its sources, not a measurement and not independent evidence for the thesis.
The baseline is testing as it was practised before AI took part in the emulation, the observation or the improvement, which means before the usage modes of the series entered the loop (AI Governance, Chapter 2) (88, Nordqvist, 2026). People wrote the scenarios, ran the attacks, read the telemetry and made the fixes. Tools helped, as scripts, scanners, libraries of tests and dashboards, and a few of them already contained machine-learning features. The chapter notes where those features sit, because AI Red Team, Chapter 8, concluded that vendor AI in security products and managed services may already act at an effective autonomy nobody decided (90, Nordqvist, 2026). That is a procurement question about the baseline, and the chapter does not claim to know which products contain such features.
The baseline matters for a second reason. The earlier volumes treated the loop from each side: AI Red Team, Chapter 26, from the red side, as the sequence of finding, control, re-test and evidence, and AI Blue, Chapter 11, from the blue side, as the second half of B5 Learn (90, Nordqvist, 2026) (94, Nordqvist, 2026). Both argued that a finding is closed only when a re-test passes. This chapter asks why, before that rule, so many findings did not close, and what each form of testing contributed and lacked.
Primary topics explored
- What the chapter treats as the baseline
- A short history of the terms
- A map of testing forms
- Who plays what
- The report as the end of the loop
- Why findings stalled
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 2: What the Loop Did Before: Penetration Tests, Red Teams, Tabletops and Purple Sessions in AI Purple gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Loop in Question” and is one of 33 drawn from the manuscript.