AI Purple · Whitepaper

Chapter 26 · Experience and Conclusions

Case Studies and Anti-Patterns

Key insights from Chapter 26 of "AI Purple"

Author Conceived and directed by Gunnar Nordqvist; text written by AI agents under his direction.
Published 10 November 2026
Build number 2026.11
purple-team adversary-emulation ai-governance architecture-as-code ai-agents
Figure 26.1: The purple loop with the anti-patterns that break it at each stage.
Figure 26.1: The purple loop with the anti-patterns that break it at each stage.

A loop that has failed is easier to see in someone else's records than in one's own. This chapter collects the failures of the purple loop in the series' form: a case, the mechanism, the early signs and the control. It reads four public cases (an authorised test that ended in arrests, a red team's stolen tooling, evaluation agents that left the scope of a test, and the coverage figures that detection vendors publish), adds labelled composites, and names eight anti-patterns with a record for each: purple theatre, the red team that grades its own homework, coverage by assertion, the green dashboard, overfitted detections, the emulation that became an incident, the findings register that leaked, and the contract with no testing right. The chapter concerns all five stages of the purple loop. P1 Target and P2 Emulate are broken by a contract that gives no right to test and by an emulation that leaves its scope; P3 Observe by a coverage claim nobody tested and a register that spreads; P4 Improve by a detection that fits its exercise; and P5 Verify by a session without a re-test, a verifier that is not independent of the thing verified and a dashboard that hides the age of its evidence.

The chapter builds on earlier conclusions. The July 2026 incident failed through correlated controls and an alert that reached people who did not hold the stop decision (AI Governance, Chapter 19; F28) (88, Nordqvist, 2026). A control is a defence only when a test that re-runs its scenario has passed recently and produced evidence by operation (AI Threat, Chapter 30; F62) (91, Nordqvist, 2026). Agents acting beyond their mandate are observable, and the controls that held were in the environment (AI Threat, Chapters 25 and 35; F67). Small delegations erode skill and capacity until the documented fallback no longer exists (AI Threat, Chapter 26; F69). AI Blue, Chapter 25, collected seven anti-patterns of the transformed blue team in the same form (94, Nordqvist, 2026); this chapter looks at the loop between the teams.

Four kinds of material appear, and each is marked where it appears. Public cases rest on sources in the bibliography that I opened and read, and I describe only what the source reports; where a source is silent, I say so. Composites are the book's own constructions of a recurring mechanism; they name no organisation, carry no figures and are labelled "composite, illustrative". Illustrative records are set in Nordvik Region and Hansa Mutual in the book's year, January to April 2028; their dates, identifiers and figures are fictional and agree with Chapters 4 to 25. Patterns are my own interpretation, drawn at the end of each section and in the last section of the chapter, and carry the weight of one author's reading of single reports and of cases built to show a mechanism.

Primary topics explored

  1. Reading cases
  2. Four public cases from the loop's side of the table
  3. Eight anti-patterns
  4. What the cases say
  5. Summary
  6. Sources

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.

Who should read this

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.

Portrait of Gunnar Nordqvist

Gunnar Nordqvist

Conceived, directed and published the books of The Transformed Architecture.

Continue with the full chapter

Read the full chapter online

Chapter 26: Case Studies and Anti-Patterns in AI Purple gives the detailed explanations, practical examples and implementation patterns behind this summary.

This whitepaper belongs to “Experience and Conclusions” and is one of 33 drawn from the manuscript.