Chapter 2 described the loop as it ran before AI joined it: a penetration test, a red team engagement, a tabletop, a purple session, each an event with a start and an end. This chapter explains why that rhythm no longer fits. Four things move faster than a yearly or quarterly event can follow: the window between disclosure and exploitation, the estate that is being defended, the detections that defend it and the list of findings that are meant to improve it. Two more things stay scarce: the hours of people who can emulate an adversary or write a detection, and the patience of a compliance regime that is satisfied by an annual report. The chapter then separates what open tooling already made cheap, repetition, from what AI is expected to make cheaper, variation and drafting, and it keeps apart what AI does not make cheaper.
The chapter concerns every stage of the loop, because the pressure falls on all five. P1 Target is pressed because the list of priority techniques ages faster than its review. P2 Emulate is pressed because an annual campaign samples a moving estate once. P3 Observe is pressed because a detection that fired in March may not fire in September. P4 Improve is pressed because findings wait for a control. P5 Verify is pressed hardest, because a finding is closed only when a re-test passes and the evidence is attached (Chapter 4), and the traditional rhythm has no re-test in it.
The chapter builds on conclusions of the earlier volumes and does not repeat them. AI Platform and Security, Chapter 18, concluded that AI-enabled adversaries collapse the exploitation window and set four commitments against them: patch velocity as a measured service level, detection at machine speed with the authority to act, identity and approvals that resist synthetic media, and AI for defence under oversight, in which human verification is the bottleneck (89, Nordqvist, 2026). AI Threat, Chapter 18, treated cyber offence at machine speed from the standpoint of evidence (91, Nordqvist, 2026). AI Governance, Chapter 24, concluded that patch decisions must be delegated in advance, because a weekly change advisory board cannot sit in the path of a known-exploited vulnerability (88, Nordqvist, 2026). AI Blue, Chapter 3, described the same pressure from the blue team's side: machine-speed adversaries, alert volume and scarce talent (94, Nordqvist, 2026). This chapter takes those conclusions as given and asks what they mean for the loop between the teams, which tests, repairs and re-tests the defence.
Primary topics explored
- The shrinking window
- An estate that changes faster than the test
- Detection decay
- The finding half-life
- Scarce talent on both sides
- The calendar that rewards a report
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 3: The Pressure on the Loop: Machine-Speed Adversaries, Detection Decay and the Annual Test 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.