The loop of the earlier chapters is made of records, mandates and stop paths, and it is run by people. Two professions meet in it: one is paid to find the way through, the other to stop it, and the loop asks them to sit at one table and say exactly where the defence failed. This chapter describes the human side of that arrangement: what each side is rewarded for, what makes a purple session safe enough for the truth to be said, what is known about being tested, what exercises and automation do to the load, and what an organisation owes to staff who are exposed to an exercise without having chosen it. It concerns every stage. P1 Target decides whose systems and which staff are touched, P2 Emulate is where people are tested, P3 Observe is where a result is first read aloud in a room, P4 Improve is where a finding becomes someone's work, and P5 Verify is where a person signs that it is done.
The chapter builds on earlier conclusions. AI Boss, Chapters 13, 14 and 26, concluded that monitoring has a chilling effect, that pace has a cost in health, and that oversight must be real and measured by the review and not the reviewer (93, Nordqvist, 2026). AI Blue, Chapter 21, applied that to the analyst: the research on fatigue in security operations is small and mostly qualitative, measures concern the system and not the person, and tools that log every query can profile the individual and fall within co-determination (94, Nordqvist, 2026). AI Red Team (Chapters 6 and 15) and AI Threat (Chapters 6 and 14) added that skills erode when AI does most of the work (90, Nordqvist, 2026). Chapter 4 of this book defined the roles and the independence principle, and Chapter 6 fixed that an exercise which involves staff is safety class S4.
A word on method. The bibliography contains no study of the wellbeing of red teams, of the effect of a purple session on its participants or of the effect of AI on either. It contains adjacent work: qualitative studies of security operations, one qualitative study of twelve offensive security practitioners, field studies of teams and of observation in other industries, and two large studies of phishing simulations. Each is described by what it measured, in whom and how.
Primary topics explored
- What red and blue are rewarded for
- Trust and blamelessness
- Being tested
- Wellbeing and load
- Staff exposed to exercises
- The purple coordinator as translator
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 23: Red and Blue as People: Trust, Incentives, Safety and Wellbeing in AI Purple gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “People and Career” and is one of 33 drawn from the manuscript.