This chapter treats adversary emulation as a pipeline that runs without a campaign around it: breach-and-attack simulation, atomic tests and continuous automated red teaming, triggered by change, by schedule and by intelligence. It concerns P2 Emulate above all. It touches P1 Target, because the pipeline can only run what the scenario library holds, P3 Observe, because every execution is worthless without a telemetry tag that lets the result be compared with the expectation, and P5 Verify, because a pipeline that re-runs scenarios is the cheapest regression machinery the loop has. The chapter answers four questions: what runs in the pipeline, where and when; how variation is introduced so that detections are not overfitted to their own tests; what realism costs; and whether continuous automated emulation makes the quarterly human-led session, or most of the red team's human hours, unnecessary. The last question is staged as a debate in four steps, followed by a verdict.
The chapter builds on earlier conclusions. AI Platform and Security, Chapter 17, kept the external exercise for discovery and converted every finding into an automated test that also runs on a schedule (89, Nordqvist, 2026). AI Red Team, Chapter 25, concluded that continuous verification needs catalogued, reversible experiments, a bounded blast radius and a stop path outside the system being stopped, with AI planning and narrow deterministic actuators acting (90, Nordqvist, 2026). AI Threat, Chapter 30, supplied the classification of controls as verified, declared or failed (91, Nordqvist, 2026), and AI Blue, Chapter 11, the rule that every detection built from an exercise carries the exercise's scenario as a regression test (94, Nordqvist, 2026). This chapter asks what changes when the re-running is automatic and frequent.
Three kinds of tool sit behind the phrase continuous emulation, and they differ in what they are good for.
Primary topics explored
- The pipeline
- What runs where
- Scheduling around change
- Variation
- Overfitting and Goodhart
- The cost of realism
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 8: Emulate Continuously: Breach-and-Attack Simulation, Atomic Tests and Automated Red Teaming 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.