A scenario record says which adversary behaviour the organisation wants to test and what it expects to happen. It does not run anything. Between the record and the first action stands the campaign: a plan built from intelligence, a window, a team, a set of people who know and a larger set who do not, and a log of what was actually done. This chapter describes that campaign for the stage the loop calls P2 Emulate, in its human-led and AI-assisted form: how a scenario becomes an emulation plan (EMU-*), who does what in a live exercise, where AI helps with planning, variation and execution and where it stops, and what must be recorded so that the next stage has ground truth to compare against. It touches P1 Target, whose scenario records it consumes and whose rules of engagement (Chapter 6) it works inside, and P3 Observe, to which it hands over a sealed record. Continuous, pipeline-driven emulation is the subject of Chapter 8; this chapter treats the event, because the event is where novelty, judgement and trust are produced.
The chapter is deliberately defensive. Adversary behaviour appears by ATT&CK or ATLAS identifier (17, MITRE, n.d.) (18, MITRE, n.d.) at the level needed to write a plan and a detection, never as a procedure. Every activity described is authorised under a signed rules-of-engagement manifest, runs against the organisation's own or contracted systems and ends in a finding that the blue team can use.
A scenario is a unit of adversary behaviour: a technique set, a source in intelligence or the threat register, an expected outcome per layer, a safety class and an owner (Chapter 5). A plan is a unit of work. It orders scenarios into a campaign, binds them to targets and a window, assigns people, and states the conditions under which the campaign pauses or ends. The difference matters because the same scenario can appear in several plans, and because most of what goes wrong in an exercise goes wrong in the plan, not in the scenario: an overlapping window with a change freeze, a target that turned out to share a credential with a system outside the scope, an abort condition nobody could measure.
Primary topics explored
- From scenario to plan
- Roles in a live exercise
- What a person adds and what AI adds
- AI in planning and variation
- AI in execution and its limits
- Recording what was done
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 7: Emulate: Adversary Emulation Plans, Human-Led and AI-Assisted 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.