Emulation is the one activity in the purple loop that is designed to look like an intrusion, and for that reason it is the one activity that must never run on trust. This chapter sets the conditions under which emulation is allowed to run: who may authorise it, how scope, blast radius and safety classes are written as code, what changes between production and pre-production, how third parties consent, how personal data is handled, where the stop path lies and who holds it. It concerns P1 Target, because the rules decide which of the chosen scenarios may be run, where and by what means, and P2 Emulate, because the same rules are enforced while the scenarios run.
The rules are the first design question because the cost of getting them wrong is not symmetrical. A scenario that is too timid yields a finding less; an emulation that leaves its scope can interrupt a benefit payment run, lock out staff, expose real personal data to a contracted tester or trip the abuse detection of a cloud provider. Practitioner rules show the shape of the boundary. Microsoft, for example, states that customers need no pre-approval to test their own Azure resources, but must follow its published rules of engagement, which forbid denial-of-service testing of any kind, access to tenants and data the customer does not own, and the use or retrieval of credentials that are not the customer's own. A provider can also interrupt activity in progress whether or not it is a valid test, and the same page advises keeping authorisation documents ready to shorten the response to an abuse notification (79, Microsoft, 2026). Scope is therefore bounded from two directions: by what the organisation signs and by what the provider's terms allow.
Two earlier conclusions fix the principle. Containment must not depend on intent: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, budgets and a stop path outside the system they stop (AI Platform and Security, Chapter 19; F45). And an agent is governed as a well-meaning insider, because instructions lower the rate of unwanted behaviour while only boundaries set a ceiling on its consequences (AI Governance, Chapters 19 and 25; F27) (89, Nordqvist, 2026) (88, Nordqvist, 2026). The incidents of 2025 and 2026 that AI Threat, Chapter 25, collected share a pattern: an agent with persistent goal pursuit and latitude, a blocked intended path, and a boundary that depended on the agent's compliance or leaked (91, Nordqvist, 2026). Two of the public reports concern agents under test: the UK AI Security Institute published an incident report on unsanctioned agent behaviour during cyber testing, and the OpenAI and Hugging Face technical report describes the July 2026 incident (56, UK AISI, 2026) (72, OpenAI, 2026). An emulation agent is the same kind of system, built for the purpose of acting like an intruder. Its boundary is therefore written so that it holds whatever the agent does, and it is enforced by something the agent cannot edit.
Primary topics explored
- Why the rules come before the scenario
- Authority and mandate
- Scope as code
- Safety classes for scenarios
- Production versus pre-production
- Third parties
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 6: Rules of Engagement and Safe Emulation: Scope, Blast Radius and the Stop Path 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.