Rules of Engagement and Safe Emulation: Scope, Blast Radius and the Stop Path

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.

AI Red Team, Chapter 7, introduced the rules-of-engagement manifest for an exercise in which AI takes part: a signed, versioned file, enforced by a policy decision point, with approvers, a window, scope expressed by technique class, an autonomy ceiling, stop conditions and an out-of-band stop path (90, Nordqvist, 2026). This chapter takes that manifest as given and extends it for a loop that does not end with the exercise. It adds the safety class of a scenario, so that the rules can distinguish a benign, reversible emulation that may run on a rolling schedule in production from one that may run only on a range. It adds third-party consent as a field the policy point reads, treats exercise data as data with a legal basis and a retention period, and gives the white team a defined place in the design. The chapters that follow rely on it: Chapter 7 plans a human-led campaign inside the rules, Chapter 8 runs scenarios continuously inside them, and Chapter 14 gives the loop's agents mandates that cannot exceed them.

A catalogued scenario reaches the policy decision point, which checks the signed rules-of-engagement manifest and allows or denies; allowed runs reach the target in scope, every outcome is logged, and the white team holds a stop path outside the emulating system.

Figure 6.1: A scenario passing through the policy decision point to the emulating system, with the stop path held outside it.

Why the rules come before the scenario

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.

Authority and mandate

Emulation is authorised by a named authority, and the authorisation is a record, not an email. In both organisations the authority is a role, not a team: the chief information security officer, together with the owner of every system in scope, signs the rules of engagement. The CISO cannot authorise alone, because the CISO does not own the benefits-triage service or the claims platform and cannot accept its operational risk. The system owner cannot authorise alone, because an owner has no view of what else is running that week. The white team (below) reviews the manifest and signs for the exercise's control, and the data protection officer signs where exercise data will include personal data.

Three documents are kept apart because they answer different questions.

  • The rules of engagement (RoE-*) say what may be done to which systems, when, with whose consent and under what stop conditions. They belong to the exercise or programme.
  • The mandate manifest (MND-*, for loop agents MND-NR-EMU-* and MND-HM-EMU-*) says what a given agent may do at all, with which identity and at which autonomy level, whatever exercise it is used in (Chapter 14). It belongs to the agent.
  • The decision record (an AI Decision Record, AIDR) records why a delegation was made, by whom, and when it will be reviewed. It belongs to the decision.

The lowest ceiling governs. If the manifest allows Level 3 Bounded for class S1 scenarios and the agent's mandate allows only Level 2 Supervised, the agent runs at Level 2; if the mandate allows Level 3 and the rules allow only Level 2, the same holds. An action that neither document lists is undelegated, which is the rule that AI Blue, Chapter 4, applied to the delegation profile of the transformed team (F93) (94, Nordqvist, 2026). Raising a level is a decision by a named authority and is recorded as an AIDR; lowering it is immediate and needs no one's approval. This asymmetry follows the series' conclusion that the right to stop must be cheaper to exercise than the right to continue (AI Threat, Chapter 30; F63).

Accountability does not pass to the tool. NIS 2 places duties on the management body (Article 20), and DORA assigns the management body responsibility for ICT risk (Article 5); the authorisation of an offensive capability that runs inside the estate is part of that responsibility (3, European Union, 2022) (2, European Union, 2022). As an architectural implication, the person who signs RoE-* is identifiable from the record, and the record states which of the signatures were delegated by the management body to the CISO.

For financial entities in scope of threat-led penetration testing, the authority is shaped further by the supervisor. DORA's chapter on digital operational resilience testing, including advanced testing by threat-led penetration testing and the requirements for testers, is in Articles 24 to 27 (2, European Union, 2022). The regulatory technical standards that supplement it set requirements for scope, methodology, closure and remediation, and cooperation with the supervisor (8, European Commission, 2025), and they were drafted to follow the TIBER-EU framework, which assigns a control team, a threat intelligence provider and red team testers their roles (20, ECB, 2025). Chapter 21 treats this regulation in full. What matters here is the consequence for the manifest: a supervised test has an authority above the organisation, and the manifest carries a reference to the test plan the supervisor has approved, so that the policy decision point cannot be loaded with a scope wider than that plan.

Scope as code

A scope written in a document is read once. A scope written as code is read at every action. The manifest therefore expresses scope in forms a policy decision point can evaluate: systems by inventory identifier and not by name, technique classes by ATT&CK tactic and technique identifier or ATLAS technique and not by procedure (17, MITRE, n.d.) (18, MITRE, n.d.), the window as timestamps with offsets, and exclusions as an explicit list that takes precedence over inclusions. Four properties make the difference between a manifest and a statement of intent.

Default deny. An action is allowed only if the manifest lists its target, its technique and its window. An unknown target, an unlisted technique or an action after the window is refused, logged with the manifest version and reported to the white team. The policy point fails closed: if it cannot read the manifest, or the manifest does not verify against its signature, every action is refused.

Exclusions win. Systems whose compromise would harm people are excluded by name and by inventory identifier, and the exclusion is checked before any inclusion. For Nordvik Region the production scoring of the benefits-triage system, a high-risk AI system in the sense of the AI Act's Annex III, is excluded, so that an exercise cannot affect a decision about a resident (1, European Union, 2024). The same logic gives Hansa Mutual an exclusion list for the core claims system's payment function.

The manifest is outside the agent's reach. The emulation runner has no write access to the repository that holds the manifest or to the policy engine's configuration. A change during an exercise is a new version, reviewed by the white team, signed by role, and loaded by the platform team; the previous version remains as evidence of what was authorised when. This is the discipline of Architecture as Code applied to authority: the repository is the source and the running policy point is checked against it (87, Nordqvist, 2025).

Refusal is tested. A control that has never refused anything has not been shown to work (AI Threat, Chapter 30; F62). Before an exercise begins, a dry-run emulation action against an out-of-scope target, after the window and while a stop flag is set must each be refused. The three refusals are the first evidence in the exercise record, and the experiment belongs to the family of security chaos engineering experiments of AI Red Team, Chapter 25 (F59).

Practical guide: Writing a rules-of-engagement manifest that a policy decision point can enforce

Purpose. Produce a manifest in which every sentence can be evaluated by a policy point, so that nothing important is left to the judgement of the emulating system or its operator.

Roles. White-team lead (owner of the manifest), CISO and the owner of each system in scope (approvers), red-team lead or contracted test lead, detection owner, data protection officer, platform engineer who loads the policy, and, where staff are touched, the employee representatives.

Steps.

  1. Name the question the exercise answers and the scenario identifiers (SCN-*) it will run. Reject a scope that is not tied to a scenario.
  2. List systems in and out of scope by inventory identifier. Add the exclusions first, then the inclusions. For every inclusion, name its owner and record their approval.
  3. Express permitted techniques by ATT&CK or ATLAS identifier and give each scenario its safety class (the next section). Prohibit the tactic Impact (TA0040) against production unless a separate, named approval exists.
  4. Set the window with time-zone offsets, add blackouts (payment runs, month-end close, major releases, other change freezes) and name the person who may shorten the window at any time.
  5. Set the autonomy ceiling per safety class. Default to Level 2 Supervised for everything; allow Level 3 Bounded only for class S1 scenarios inside a catalogue and a standing programme.
  6. Give the emulating system short-lived, task-scoped credentials issued outside its runtime, a default-deny egress allowlist, and synthetic or test accounts only. Tag every emulated action so that it can be told apart from a real one.
  7. Record third-party consent and notices: which provider, which contract term, which date, and what the provider keeps the right to do.
  8. Write stop conditions that a machine can detect, name the stop-path holders and their deputies, and test the out-of-band channel end to end. Set a halt time (default: 5 minutes for a human-led exercise, 60 seconds for a pipeline).
  9. State the data classification, legal basis, retention period and the rule for real personal data met by accident (stop, secure, report to the data protection officer).
  10. Sign, load into the policy point, run the three dry-run refusals and attach the result.

Definition of done. The manifest verifies against its signature in the policy point, the three dry-run refusals are on record, the stop path has been exercised within the last 30 days, and every system in scope has an owner's approval with a date. Adapt the halt time, blackout rules and retention to the contract and to the works agreement; a pipeline with no human in the path needs the shorter halt time and a person on call, not a longer window.

Worked example: RoE-NR-2027-001, version 1.2.0

The illustrative manifest below extends version 1.1.0 of RoE-NR-2027-001 of AI Red Team, Chapter 7, with the fields this chapter adds. Nordvik Region signs it with its contracted tester, Elin Berglund, whose firm works under the call-off agreement NR-2026-071. The window opens a week before fieldwork starts (2027-03-15) so that the dry-run refusals and the stop-path test fit inside it. The production scoring of the benefits-triage system remains out of scope.

kind: RulesOfEngagement
id: RoE-NR-2027-001
version: 1.2.0
supersedes: 1.1.0
approvedBy:
  - {role: chief-information-security-officer, date: 2027-03-04}
  - {role: head-of-benefits-unit, date: 2027-03-04}
  - {role: data-protection-officer, date: 2027-03-04}
  - {role: white-team-lead, date: 2027-03-03}
window:
  start: 2027-03-08T07:00:00+01:00
  fieldwork: {start: 2027-03-15, end: 2027-04-02}
  end: 2027-04-02T18:00:00+02:00
  blackout: [month-end-benefit-payment-run]
parties:
  whiteTeam: [ciso, duty-security-officer, contracted-test-lead]
  redTeam: contracted-tester            # NR-2026-071
  blueTeam: nordvik-security-analysts-and-mssp
scope:
  inScope: [citizen-service-assistant, benefits-explanations-service, staff-identity-provider-test-tenant]
  outOfScope: [benefits-triage-production-scoring, third-party-systems, personal-data-exfiltration]
  prohibitedTactics: [TA0040]           # Impact
scenarios:
  - {id: SCN-NR-0001, techniques: [T1110.003, T1078], class: S2, target: staff-identity-provider-test-tenant}
  - {id: SCN-NR-0002, techniques: [T1087], class: S1, target: staff-identity-provider-test-tenant}
  - {id: SCN-NR-0005, techniques: [T1190], class: S3, target: preprod-benefits-explanations-mirror}
classes:
  S1: {production: true,  maxLevel: 2, reversal: tag-and-expire}
  S2: {production: true,  maxLevel: 2, reversal: lockout-safe, rateLimitPerHour: 20}
  S3: {production: false, maxLevel: 2, reversal: restore-snapshot}
aiParticipation:
  models: [self-hosted-open-weight]     # no external model receives Nordvik data
  egress: allowlist-range-only
  logging: full-transcript-to-white-team
thirdParties:
  - {party: mssp, basis: NR-2025-044-MS-1, informed: window-and-stop-path, not-informed: timing}
  - {party: nordic-hosting-provider, basis: notice-given-2027-03-01, testsProviderInfrastructure: false}
dataProtection:
  legalBasis: gdpr-art-6-1-e-public-task
  classification: confidential-security-exempt-from-disclosure
  accounts: synthetic-only
  onRealPersonalData: [stop, secure, report-to-dpo]
stopConditions: [unplanned-service-degradation, access-to-real-personal-data, ai-action-outside-approved-plan, any-white-team-member-request]
stopPath:
  holders: [ciso, duty-security-officer, contracted-test-lead, mssp-shift-lead]
  channel: out-of-band-phone-bridge
  haltWithinMinutes: 5
  revoke: [tester-credentials, test-tenant-accounts, egress-allowlist]
enforcement:
  pdp: policy-engine-outside-test-host
  failMode: deny
  decisionLog: white-team-store
evidence:
  retentionMonths: 60
  findingsTo: purple-session-2027-q2

The manifest has a deliberately modest ceiling, Level 2 Supervised for every class, because the Region has no emulation agent at Level 3 in production and no standing programme to hold one (Chapter 19 returns to what a small authority can buy). Even so, each field is something the Region's policy point reads: the lockout-safe rate for the password-spray scenario is a number, the pre-production mirror is the only target for SCN-NR-0005, and the MSSP shift lead is a stop-path holder without being told the timing of the activity.

Version 1.2.0 covers the spring fieldwork only; its window closed on 2027-04-02 and authorises nothing after it. The autumn run of 2027 (EMU-NR-2027-02, Chapter 7) runs under version 1.3.0 of the same manifest, approved on 2027-10-05, two days before the stop drill of 2027-10-07, with the autumn window of 2027-10-05 to 2027-10-22 and SCN-NR-0001, SCN-NR-0007 and SCN-NR-0011 added. A new window is a new signed version and never a reading of an old one.

Safety classes for scenarios

Not every scenario carries the same risk, and a single rule for all of them fails in both directions: it forbids benign tests that should run weekly, or it permits risky ones on the strength of the benign ones' record. A safety class is an attribute of the scenario record (SCN-*, Chapter 5) that states what the scenario can do to the target and how it is undone, and the manifest's rules are written per class.

A scenario is safe by construction when its design, and not the care of its operator, limits the damage. Five design properties recur.

  1. Benign effect. The emulated step produces the telemetry of the technique and not its consequence. A credential-access scenario exercises the detection path against a test credential; a data-collection scenario touches a marker file and not a record. The step stops at proof of technique.
  2. Tagged. Every action carries a marker that links it to the exercise: accounts, hosts, files and network sources use a reserved prefix, and the marker is recorded in the policy point's log. Tags let the white team tell emulation from a real intrusion and let the observation stage (Chapter 9) compare detections with ground truth.
  3. Reversible and expiring. Everything the scenario creates (an account, a scheduled task, a rule, a token) is created with an expiry and removed by a deterministic clean-up step that the stop path can also invoke.
  4. Bounded in rate and reach. A rate limit per target, a per-run action budget and a list of permitted hosts keep the blast radius a number. Lockout-prone techniques such as password spraying are bounded below the lockout threshold of the target's policy.
  5. No real secrets. The scenario uses synthetic or exercise-owned credentials and never retrieves a credential that belongs to a person or to a third party. Microsoft's published rules, for example, prohibit using credentials that are not the customer's own (79, Microsoft, 2026).

Canaries support the second and fifth properties from the other side. A canary is a decoy credential, record or host entry that no legitimate process touches; if an emulation reaches one it was meant to reach, the hit is expected and tagged, and if something else touches it, the white team treats it as a signal of a real intruder. AI Red Team and AI Blue use canaries as detection; here they double as a boundary check on the emulation (F45).

Worked example: A safe-scenario class table as code

Hansa Mutual keeps its classes as data in the repository that holds the 86 scenarios SCN-HM-0001 to SCN-HM-0086. The table is read by the policy decision point of HM-SEC-004 (AIDR-0314) and by the white team's dashboard, and it extends RoE-HM-2027-TLPT with a rule per class. The distribution is illustrative: 41 scenarios are class S1, 19 S2, 18 S3 and 8 S4.

kind: SafetyClassTable
id: SCT-HM-2027-01
version: 1.0.0
owner: white-team-lead
approvedBy: [group-ciso, head-of-group-red-team, head-of-detection-engineering]
classes:
  S1:
    description: benign, reversible, tagged; proof of technique only
    environments: [production, range, preproduction]
    maxLevel: 3                         # Level 3 Bounded, catalogued scenarios only
    requires: [tag, expiry, per-target-rate-limit, stop-flag-check]
    humanInLoop: sampled-review
    scenarios: 41                       # SCN-HM-0001 .. rolling schedule of HM-SEC-004
  S2:
    description: reversible with bounded side effects (lockout-safe, rate-limited)
    environments: [production, range, preproduction]
    maxLevel: 2
    requires: [tag, expiry, white-team-approval-per-run, owner-notified]
    scenarios: 19
  S3:
    description: needs realistic state or may disturb service; never in production
    environments: [range, preproduction]
    maxLevel: 2                         # Level 2 Supervised for S2 and S3, Level 0 for S4 (Chapter 4)
    requires: [tag, snapshot-restore, window]
    scenarios: 18
  S4:
    description: impact or irreversible effect, or involves staff or third parties
    environments: [range]
    maxLevel: 0                         # AI may plan; people act
    requires: [named-red-team-operator, white-team-approval-per-step, representatives-informed]
    scenarios: 8
deny:
  - {tactic: TA0040, environments: [production]}     # Impact
  - {target: [core-claims-payment-function, personal-data-stores], any: true}
  - {action: use-credential-not-issued-to-exercise, any: true}
promotion:
  rule: a scenario moves up one class only after a recorded dry run and a decision by the white-team lead
  recordedAs: AIDR

Two rules deserve notice. Level 4 Autonomous does not appear: it is never used for an emulation action that is irreversible, that leaves the signed scope, that touches personal data beyond what the exercise has been authorised to touch, or that targets a named person, so no class has it as a ceiling. And class S4, which includes any scenario that involves staff, such as social engineering, is run only by named people with an AI role limited to planning, because a decision that touches a person is not delegated to an emulation agent.

Production versus pre-production

A pre-production mirror is safer and weaker evidence. What changes with the target is the risk of the activity, the realism of the telemetry and, above all, what the result may be taken to prove.

The risk falls in a mirror because an error disturbs no resident and no customer. The realism falls too: a mirror has different traffic, different data volumes, different identities and often a different set of detection sensors, so that a technique detected there may not be detected in production. The rule that follows is a coverage rule of the book. A result from a mirror is evidence about the mirror, and a coverage record (Chapter 17) that cites it says so: what was tested, in which environment, when and with what result. It is a claim about production only for the properties the two environments share, and the record names those properties. Nordvik's SCN-NR-0005 against the pre-production mirror of the benefits-explanations service shows whether the web-application detections fire there; it says nothing about the production gateway until a shared-configuration check, or a class S1 variant in production, has confirmed it.

The opposite rule applies to what runs in production. Only catalogued scenarios of class S1, and S2 with per-run approval, run there, and each must have run on the range or the mirror first. The promotion rule in the class table makes this explicit: a scenario enters production through a recorded dry run and a decision, not because it is convenient. For high-risk AI systems the production exclusion has a further reason. The deployer's duties of human oversight and monitoring under the AI Act continue while an exercise runs, and an emulation that alters the scores a caseworker sees would interfere with them (1, European Union, 2024). Excluding the scoring path, and testing the explanation service and the assistant that surround it, keeps the oversight chain unbroken.

Third parties

An exercise rarely stays inside a single legal entity's infrastructure. The target may run in a cloud, be monitored by a managed provider, or depend on a software-as-a-service product. Consent from the party that owns each boundary is a field the policy point reads, not a courtesy.

Cloud and hosting providers. The organisation may test what it owns or is explicitly authorised to test. A cloud provider's rules, such as the Microsoft rules described above, state that third parties such as consultancies and red teams may test only with written authorisation from the resource owner, which the provider does not grant on the owner's behalf (79, Microsoft, 2026). The tester's contract therefore carries the authorisation, and the manifest records that it does. The provider's prohibitions become exclusions in the scope: no denial-of-service simulation, no access to other tenants, no post-compromise action against the provider's own services. For Nordvik, whose citizen-service assistant runs on accelerators that a European hosting provider reserves in a Nordic data centre, the exercise tests the Region's application and does not test the provider's infrastructure; the notice to the provider is dated and recorded.

Managed providers. The MSSP that monitors out of hours is on the blue side of the exercise and also holds a stop path. The two roles are reconciled by splitting what each is told. The framework agreement NR-2025-044 and its annexes MS-1 and MS-2 (AI Blue, Chapter 7; F97) give the Region the contractual means to run tests that cross the provider's boundary (94, Nordqvist, 2026). The shift lead learns that a window is open and how to reach the white team, but not the timing or the technique, so that the blue team's response is a response to what it sees. A provider whose detections are Mode 0 for the customer, and whose AI closes alerts on its own, is itself a subject of the loop (Chapter 13); the exercise manifest says whether the provider's AI is in scope as a target.

Software-as-a-service. A SaaS product used by the organisation is the vendor's system. Unless the contract grants test rights, it is out of scope, and the safe route is to test the organisation's own configuration of it: its tenant settings, its identity federation and its logs.

Supervisors and authorities. For a threat-led test required by DORA, the competent authority and the test's control group are parties too (Chapter 21). Where ICT third-party service providers are in the scope of the test, the financial entity has to take the measures and safeguards that ensure their participation (Article 26(3)), and the contract for ICT services supporting critical or important functions has to include the provider's obligation to participate and fully cooperate in the test (Article 30(3), point (d)) (2, European Union, 2022). The architectural implication is that the contract, and not the exercise plan, is the instrument that makes a third party's participation possible, which is why Nordvik writes testing rights into its supplier agreements and why Hansa's register of information records them.

Data and personal data

An exercise creates data: telemetry, transcripts of the emulating system, screenshots, findings, and the tags themselves. Some of it concerns people. Three rules keep the data within what the exercise is authorised to touch.

Minimise by design. The GDPR requires personal data to be adequate, relevant and limited to what is necessary (Article 5(1)(c)) (7, European Union, 2016). The design answer is synthetic data: test tenants, synthetic accounts and marker files, so that the exercise has no reason to touch a resident's record. The manifest lists personal-data-exfiltration as out of scope for Nordvik, and Hansa's deny list excludes personal data stores outright. A technique that requires real data to produce a realistic result belongs in class S4 or on the range with masked data.

A legal basis and a classification. Exercise telemetry from systems that process personal data is itself personal data. Nordvik records Article 6(1)(e), the public task, as the basis for exercise telemetry, and classifies the material as confidential and exempt from disclosure under its public-access rules; the classification matters because exercise records, unlike most security records, describe how the Region would be attacked and what it did not see. Where the exercise is likely to result in a high risk to individuals, a data protection impact assessment is considered under Article 35 (7, European Union, 2016).

A stop on real data. If an emulation meets real personal data that the authorisation does not cover, the exercise stops: the stop condition access-to-real-personal-data is machine-detectable where classification labels exist, and otherwise it is a standing instruction to the operator. The data is secured, the data protection officer is informed at once, and the question whether the event is also a personal data breach is decided under the organisation's incident process, not by the exercise team.

Staff are a special case. Exercises that involve people, such as a deepfake approval test or a social-engineering scenario, are class S4. Employee data and monitoring fall under national co-determination law; in Germany, Section 87(1) no. 6 of the Works Constitution Act gives the works council a co-determination right over the introduction and use of technical devices designed to monitor employees' behaviour or performance (11, Bundesrepublik Deutschland, n.d.), and the Federal Labour Court holds that a device is designed for that purpose when it is objectively suitable to collect and record such information, whatever the employer intends (16, Bundesarbeitsgericht, 2022) (121, Bundesarbeitsgericht, 2024). AI Boss and AI Blue set the principles this chapter applies: results are reported in aggregate, never by name, and no exercise result enters an appraisal (F86) (93, Nordqvist, 2026) (94, Nordqvist, 2026). Nordvik's union agreement requires ten working days' written notice to the staff representatives' joint committee, who see the scenario text while the participants do not. Hansa's clause KBV-IT-2024-SOC-05 extends the SOC annex of its works agreement in the same way. Nothing in this chapter describes monitoring of staff without their representatives' knowledge or any attempt to defeat their rights; an exercise that cannot be run within those rights is not run.

Stop path and abort conditions

The stop path is the part of the design that has to work when everything else has failed, and for that reason it is built to the same rule as the other containment of the series: it lies outside the system it stops (F19, F45, F63).

Abort conditions as code. The manifest lists conditions that a machine can evaluate: unplanned service degradation measured by the target's own service-level indicators, an action outside the approved plan, a hit on a real-intruder canary, access to real personal data, a policy-point failure, an emulation agent exceeding its action budget, and any white-team member's request. The first six stop the emulation automatically and notify the white team; the last needs no justification. A stop in good faith is never a failure: the cost of an unnecessary stop falls on the organisation and not on the person who ordered it.

What a stop does. A halt is not only the end of new actions. The stop path performs three things in order: it denies further actions at the policy point (sets the stop flag), revokes the emulating system's credentials and egress, and invokes the clean-up that reverses what the scenario created. The emulating system takes no part in any of the three. The credentials are issued by the platform and revoked by the platform; the egress allowlist lives in the network layer; the clean-up is a deterministic job triggered by the tags. An emulating system that is asked to stop itself, or whose stop depends on the system it controls, has a stop path that runs inside it and fails when it is needed.

Who holds it. The holders are named people with deputies: the CISO, the duty security officer, the test lead, and, where a provider monitors the estate, the provider's shift lead. They hold it for different reasons (authority, presence, knowledge of the activity, knowledge of the target's behaviour at night), and any one of them can use it. The channel is out of band: a phone bridge or a paging system that does not depend on the corporate identity provider or the exercise platform. Nordvik's halt time is 5 minutes for a human-led exercise. Hansa's pipeline halts within 60 seconds; a window of minutes would let an emulation runner perform hundreds of actions before anyone could object.

What can be undone. Every chapter that concerns P2 Emulate says this, and this chapter gives the general rule. Class S1 and S2 scenarios create only tagged, expiring objects and are reversible by deletion. Class S3 scenarios run where a snapshot restore is the reversal. Class S4 scenarios may have no reversal at all, which is why they are never delegated above Level 0 and why each step has a named approver. An irreversible effect on a production system, an action outside the signed scope, a use of real personal data beyond the authorisation and an action aimed at a named person are all outside any delegation to a system.

Deconfliction. A real incident can hide inside an exercise, and an exercise can look like a real incident. The tags allow the first to be seen; a standing rule allows the second to be settled. If the blue team opens an incident that the white team cannot match to a tagged action, the exercise pauses and the incident is handled as real until the white team has shown otherwise. Chapter 20 develops the decision rights for this case.

Drills. A stop path decays unless it is used. The test is simple: at a time the holders do not know, the white team raises a synthetic stop condition and times the whole chain from the signal to the last revoked credential. AI Blue drilled the SOC's stop path and found a gap between the target and the first result (F114); the same discipline applies to the emulation side. In February 2028 Hansa's white-team lead drilled the stop path of HM-SEC-004: the stop flag was set and the runner's credentials were revoked 38 seconds after the signal, against a target of 60 seconds (illustrative). The result is a number in the exercise record, and a result above target is a finding of the loop like any other.

The white team

The white team is the control group that governs the exercise. It owns the manifest and its versions, reviews every change, holds or delegates the stop path, runs deconfliction, keeps the exercise record and decides whether a result is admissible. In TIBER-EU and under DORA the role is formalised as a control team (the book keeps "white team", which earlier TIBER-EU guidance also used), with a lead who manages the test and coordinates engagement with the authorities (20, ECB, 2025); in a purple programme without a supervisor the same role is performed by a smaller group.

Three design rules follow.

Independence. The white team lies outside both the red team and the SOC, so that it can stop either. At Hansa Mutual the white-team lead is a senior member of the group CISO's office who belongs to neither; at Nordvik the CISO's delegate, the deputy CISO, leads the white team with the duty security officer; the contracted test lead holds a stop and witnesses its decisions but belongs to the red side, and the contracted firm is never the Region's detection owner. A person who writes the scenarios, runs them and reads the results cannot also decide that a result is valid; independence between the side that tests and the side that is tested is the book's central rule (Chapter 15).

A trusted agent. In an exercise where the blue team is not told the timing, one person on the blue side, the trusted agent, knows enough to prevent harm: to confirm to the white team that a suspicious event is expected, or that it is not. The trusted agent does not tell colleagues. At Nordvik the MSSP shift lead is the trusted agent for out-of-hours activity.

AI in the white team. AI may help the white team read the decision log, flag anomalies and draft the exercise record, at Level 0 Advisory or Level 1 Assisted. It does not hold the stop path, and it does not sign a manifest. Where the same platform runs the emulation and the white team's dashboard, the dashboard is a dependency of the stop path, and the white team keeps a second route that does not use it.

Records

An exercise leaves a record that supports four later uses: the observation of results (Chapter 9), the re-test (Chapter 11), the coverage claim (Chapter 17) and the account to a supervisor, an auditor or a court. The record has six parts.

  1. Every signed version of the manifest, with the signatures and the date each version took effect.
  2. The policy point's decision log, including every refusal, with the manifest version that produced it.
  3. The emulating system's transcripts: prompts, plans, tool calls and outputs of any AI that planned or executed steps, so that an action can be explained afterwards.
  4. The tag register, linking tagged accounts, hosts and files to scenario identifiers, and the clean-up log showing what was removed.
  5. The stop-path test result and any stop event, with times.
  6. The authorisations and notices of third parties, with dates.

Retention follows the longest obligation that applies. Nordvik keeps the record for 60 months; Hansa's retention follows the DORA register obligations and the supervisor's expectations (Chapter 21). Two cautions apply. The record is a map of the estate, because it names what was tested, what was not seen and what was changed. It is stored in the segregated findings store and not in the ticketing system, with access limited to named roles (Chapter 16). And transcripts of an AI that touched exercise data may contain that data, so they take the classification of the data and the minimisation rule above. Exercise records are also the basis of the evidence manifests of the verification stage; a re-test that cannot cite the rules under which the original ran is weaker for it.

Observable, expected, speculation

Observable. Emulation is run under signed rules of engagement, with scope, windows and stop conditions, in threat-led testing frameworks such as TIBER-EU and in published cloud-provider rules such as Microsoft's (20, ECB, 2025) (79, Microsoft, 2026). Writing the same rules as machine-enforced policy for AI-assisted emulation is the practice that AI Red Team recommended and that the two organisations in this book are designed to follow; no published survey shows it as an industry norm.

Expected. Automatic enforcement of rules of engagement across vendors, so that a breach-and-attack simulation product, a contracted tester's tooling and an organisation's own agents read one manifest format, is expected: it follows from the supervisory requirement for documented testing and from the interest of providers in machine-readable authorisations, but no common format has been decided.

Speculation. Autonomous emulation that sets its own scope is speculation, and this chapter's design rules say why it should not be built.

Across the degrees of delegation

The table states the ceiling per stage and action class that these rules allow. It is the starting point for the delegation profiles of Chapter 14.

Stage and action class Ceiling Who decides and who can stop
P1 Target: propose a scenario or a priority Level 1 Assisted A named scenario owner decides; no agent selects what runs
P1 Target: draft or change a rules-of-engagement manifest Level 1 Assisted CISO, system owners and white team sign; the policy point loads only signed versions
P2 Emulate: class S1 scenario in production, inside signed scope Level 3 Bounded The policy point permits or denies within the catalogue; the white team stops, outside the runner
P2 Emulate: class S2 scenario Level 2 Supervised White team approves each run; the test lead may stop
P2 Emulate: class S3 scenario on a range or mirror Level 3 Bounded Window and snapshot restore; the white team stops
P2 Emulate: class S4 scenario, or any step involving staff Level 0 Advisory (AI plans only) A named operator acts with per-step white-team approval
P2 Emulate: irreversible, out-of-scope, beyond-authorised personal data, or aimed at a named person Never Level 4 Autonomous; not delegated to a system A named person with explicit authorisation, or not at all
Stop, pause, deny, revoke Held by named people; automatic on listed conditions Needs no approval; restarting needs the owner

Nordvik Region and Hansa Mutual

Nordvik Region buys the loop and its leverage is the contract. It signs RoE-NR-2027-001 with a contracted tester under NR-2026-071, treats the manifest as the instrument that holds the tester to the Region's scope, and keeps Level 2 Supervised as the ceiling because it has neither an emulation agent nor the staff to supervise a pipeline. Its safety classes are few, its third-party consents are the work (the MSSP, the hosting provider) and its stop path runs through people who are always reachable, with the MSSP's shift lead holding it out of hours. The risk for Nordvik is a manifest that is signed once and then treated as a formality; the dry-run refusals and the stop-path test are what keep it alive in a team of six with no slack.

Hansa Mutual runs the loop and its leverage is the pipeline. It extends RoE-HM-2027-TLPT with a policy decision point and the table SCT-HM-2027-01, so that the same format governs the largest threat-led test and the rolling S1 scenarios of HM-SEC-004. The scale brings its own problems: seven regimes, a works-council consultation in Germany, the Netherlands and Sweden, consent from the managed detection provider for the UK and Swiss entities, and data-transfer rules for telemetry. The stop path is held by the white team, a unit outside the red team and the SOC, and is drilled; the first drill of HM-SEC-004 took 38 seconds against a target of 60. The risk for Hansa is the reverse of Nordvik's: a pipeline that runs smoothly inside rules that nobody has re-read, and a table whose promotion rule is bypassed because the scenarios are numerous.

Summary

Rules of engagement are the first design question of the loop. Authorisation by a named authority, written as a signed manifest that is separate from the agent's mandate and the decision record, makes emulation accountable; scope written as code and enforced by a policy decision point that fails closed makes it bounded. Safety classes let the rules distinguish the benign, reversible scenario that may run on a schedule in production from the one that may run only on a range or only by named people. Production and pre-production are different evidence, and a coverage claim says which it rests on. Third parties consent through contracts and notices that the manifest records, personal data is minimised by design and handled under a stated basis, and staff are protected by their representatives' agreements and by the rule that results are reported in aggregate. The stop path runs outside the emulating system, is held by named people, needs no justification and is drilled; the white team is independent of both sides and keeps the record. Level 3 Bounded is the ceiling for catalogued safe scenarios in production, and Level 4 Autonomous is never used for an emulation action that is irreversible, out of scope, beyond the authorised personal data or aimed at a named person. These are the book's own conclusions, built on the series' containment and decision-right conclusions and not on new external evidence.

This chapter concerned P1 Target, where the rules decide what may be chosen and run, and P2 Emulate, where they are enforced while it runs. Chapter 7 now plans a human-led and AI-assisted campaign inside these rules, and Chapter 8 runs scenarios continuously inside them and debates whether that replaces the human red team.

Sources

  1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
  2. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union. (2, European Union, 2022)
  3. European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union. (3, European Union, 2022)
  4. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union. (7, European Union, 2016)
  5. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (17, MITRE, n.d.)
  6. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (18, MITRE, n.d.)
  7. European Central Bank (2025). TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. ECB. (20, ECB, 2025)
  8. AI Security Institute (2026). Incident Report: unsanctioned agent behaviour during cyber testing. UK AISI. (56, UK AISI, 2026)
  9. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. (72, OpenAI, 2026)
  10. Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1. (87, Nordqvist, 2025)
  11. Nordqvist, G. (2026). AI Governance. The Transformed Architecture, Book 2. (88, Nordqvist, 2026)
  12. Nordqvist, G. (2026). AI Platform and Security. The Transformed Architecture, Book 3. (89, Nordqvist, 2026)
  13. Nordqvist, G. (2026). AI Red Team. The Transformed Architecture, Book 4. (90, Nordqvist, 2026)
  14. Nordqvist, G. (2026). AI Threat. The Transformed Architecture, Book 5. (91, Nordqvist, 2026)
  15. Nordqvist, G. (2026). AI Boss. The Transformed Architecture, Book 7. (93, Nordqvist, 2026)
  16. Nordqvist, G. (2026). AI Blue. The Transformed Architecture, Book 8. (94, Nordqvist, 2026)
  17. European Commission (2025). Commission Delegated Regulation (EU) 2025/1190 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards on threat-led penetration testing. Official Journal of the European Union. (8, European Commission, 2025)
  18. Microsoft (2026). Penetration testing (Azure security fundamentals) and the Microsoft Cloud Unified Penetration Testing Rules of Engagement. Microsoft Learn. (79, Microsoft, 2026)
  19. Bundesrepublik Deutschland. Betriebsverfassungsgesetz (BetrVG), § 87 Mitbestimmungsrechte. Gesetze im Internet. (11, Bundesrepublik Deutschland, n.d.)
  20. Bundesarbeitsgericht (2022). Beschluss vom 8. März 2022, 1 ABR 20/21. Bundesarbeitsgericht. (16, Bundesarbeitsgericht, 2022)
  21. Bundesarbeitsgericht (2024). Beschluss vom 16. Juli 2024, 1 ABR 16/23. Bundesarbeitsgericht. (121, Bundesarbeitsgericht, 2024)