Emulate: Adversary Emulation Plans, Human-Led and AI-Assisted

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.

Figure 7.1: An emulation campaign from scenario records through a signed plan and a run to a sealed hand-over, with the white team and the stop path.

From scenario to plan

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.

The threat-led testing frameworks that European financial entities work under draw the same line. TIBER-EU divides a test into a preparation phase, a testing phase (threat intelligence, then red team testing) and a closure phase, and prescribes that the testers build their plan from intelligence on the entity rather than from a generic catalogue (20, ECB, 2025). The regulatory technical standards that carry threat-led penetration testing under DORA follow the same phases and give the control team, the testers and the threat intelligence provider distinct duties; they also require that risk is assessed and managed throughout the test (8, European Commission, 2025). This book takes the structure as a good general shape and applies it to every exercise, including those no supervisor requires. The architectural implication of DORA (2, European Union, 2022) for a designated entity is that the plan is also part of the evidence a supervisor may ask to see; for everyone else, NIS 2 Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures (3, European Union, 2022), and a signed plan with a sealed record of what was done is the most direct way to show that an assessment took place.

The emulation plan record

The EMU-* record is the plan as code. It is a file in a repository with restricted access, because it names scenarios, targets and the people who know. It carries at least the following:

• the identifier, the owning red-team lead or contracted tester, and the rules-of-engagement manifest it runs under;
• the ordered scenarios, each by SCN-* identifier, with the technique identifiers and the safety class, and the expected outcome per layer copied from the scenario so that the plan cannot silently change the expectation;
• the target scope, as a reference to the scope in the manifest and never as a wider list;
• the window, with the hours in which active actions are allowed and the freeze dates it must avoid;
• the abort conditions, each measurable by someone other than the testers;
• the roles, with the people who know, the people who do not, and the named holders of the stop path;
• the delegation profile for any AI the testers use, with the autonomy level per action class;
• the tag scheme by which every action will be marked, and the place where the event log will be written.

The plan does not contain the exploit detail of any step. At the level of the plan, "T1110.003 Password Spraying against the identity provider of the benefits-triage service, from the tester host, at a rate below the lockout threshold" is complete. How the tester does it is the tester's craft and is recorded, as the actions actually taken, in the event log.

Roles in a live exercise

An exercise has four groups of people, and each exists because the others cannot do its work.

The red team (the group red team at Hansa Mutual, the contracted tester at Nordvik Region) emulates the adversary. It owns the plan, chooses the concrete method for each step within the scenario's technique, and carries the duty to stop and report when something unexpected happens. It does not own the scope, the abort conditions or the stop decision; those belong to the white team.

The white team governs the exercise. The current TIBER-EU framework and DORA's threat-led testing rules call this group the control team (20, ECB, 2025); this book keeps "white team" for the role in any exercise and notes that a threat-led test under DORA calls it the control team. The white team approves the plan, holds the key to the rules of engagement, deconflicts real incidents from emulated activity, decides whether a step may continue when the unexpected happens, and holds the stop path. Its lead sits outside both the red team and the blue team: at Hansa Mutual a senior member of the group CISO's office, at Nordvik Region the deputy CISO, the CISO's delegate.

The trusted agent is the person on the blue side who knows. The term describes a function: a person who can recognise that an alert is the exercise and answer the one question that matters when something looks real, namely whether it is theirs. In a small team the trusted agent is also the person who commissioned the exercise. The function matters most when a detection fires and an analyst begins to escalate, because the cost of an unnecessary escalation, to a regulator or to a customer, is higher than the cost of the exercise.

The blue team that does not know is everyone else on the defending side. The point of not telling them is that the exercise measures what they would do on an ordinary day. That aim has limits. An exercise that involves staff needs advance notice to the employee representatives under the agreements of both organisations (Hansa Mutual's clause KBV-IT-2024-SOC-05; the notice period the union at Nordvik Region has agreed), results are reported in aggregate, and no result enters an appraisal (Chapter 23). The blue team does not need to know the scenario; the representatives are told that an exercise will take place and what it will and will not measure, as AI Boss, Chapters 13 and 23, and AI Blue, Chapters 19 and 21, set out for oversight of staff. This chapter's recording rules follow from that: the event log records what the red team did and what the detection systems saw, not what an individual analyst did.

Who can stop it, and what can be undone

Every chapter that concerns P2 Emulate answers two questions, and this is the first place the book does so in detail. What can be undone? Every action in a plan is classed by reversibility before the window opens: an action that leaves nothing behind (a read), an action that creates an artefact the red team removes (a test account, a marker file), and an action whose effect cannot be reversed by the red team alone (anything that changes data owned by someone else, anything that triggers a notification outside the organisation). The first two classes may appear in a plan under the safety classes of Chapter 6. The third does not appear in a plan; it is simulated, and the simulation is stated as such. Who can stop it? At least two named holders, one of them outside the red team and outside the system doing the emulation, each able to act in minutes. The mechanism must work without the cooperation of the testers' tooling: a revoked credential at the identity provider, a firewall rule on the tester host's network segment, a kill switch in the policy decision point that enforces the manifest. AI Platform and Security, Chapter 19, and AI Threat, Chapter 30, give the design principle that a stop path outside the system it stops is part of the control, not an addition to it (89, Nordqvist, 2026) (91, Nordqvist, 2026).

What a person adds and what AI adds

A campaign draws on two kinds of contribution, and the plan should say which it is relying on at each step.

What a person contributes is judgement that depends on consequence and context. A tester decides that a promising step should be left alone because the system it touches supports a service for people who depend on it that morning. A tester notices that a scenario written for one directory structure behaves differently in this one and adapts it so that it still tests what the scenario was meant to test. A tester knows how the organisation's people work, which approval emails are routine and which would stand out, and designs the pretext of a social scenario (which exists only with staff notice and representatives' agreement) accordingly. Above all, a person finds what nobody wrote down: a path between two systems that exists because of a decision made years ago, a trust relationship that no diagram shows. The disposition of this book is that this part of the work remains human because it is where an exercise produces knowledge the library did not contain.

What AI adds is breadth, speed and cost. In planning it can read an intelligence report and the existing scenario library and list the techniques the report mentions that the library does not cover. It can propose variants of a known scenario so that a detection is tested against more than the one form it was written for. It can draft the documentation that testers write badly at the end of a long day: the action log in a consistent form, the first draft of the report. And in suitable cases it can execute a catalogued scenario repeatedly. None of this is hypothetical. Google Threat Intelligence Group and Mandiant describe agentic offensive frameworks entering use by adversaries (66, Blum et al., 2026), Anthropic reported a campaign it assessed as the first AI-orchestrated cyber espionage (67, Anthropic, 2025), and an academic study showed that an LLM agent could exploit real one-day vulnerabilities in a controlled setting when given their descriptions (68, Fang et al., 2024). These are observable developments in adversary capability. They set the pace an emulation is measured against; they do not mean that emulation should use the same autonomy. The red team uses AI so that its coverage and tempo are credible; it does not need to let AI choose targets, and the rules in the next section say why it must not.

The division is not a ranking of value. A plan that relies entirely on human creativity covers little and costs much; a plan that relies entirely on AI-generated breadth covers a lot of what is known and none of what is not. A good plan states, scenario by scenario, which of the two it expects to pay off, and the review in Chapter 9 later records which actually did.

AI in planning and variation

At the planning stage AI works at Level 1 Assisted or Level 2 Supervised in the series' autonomy levels (AI Red Team, Chapter 6) (90, Nordqvist, 2026): it proposes, a person reads and decides. In Mode 1 to Mode 3 the assistant acts with the tester's identity and sees what the tester sees; in Mode 4 a built planner, such as the scenario curator and emulation planner at Hansa Mutual, acts with a mandate of its own and reads the intelligence feed and the scenario library.

Four uses are common.

1. Gap listing. The planner compares a threat report's techniques with the scenario library and lists the techniques without a scenario. The list is an input to P1 Target, not a plan.
2. Variation. For a scenario already in the library, the planner proposes variants that change how a technique is carried out inside the same ATT&CK technique or sub-technique: a different account type, a different pace, a different data store. The purpose is to test the detection and not the scenario, because a detection tuned to the one form that a library has always used passes the test and misses the adversary. The red-team lead accepts a variant only after reading it against the rules of engagement.
3. Tooling choice. The assistant can suggest which of the organisation's approved tools fits a step. It does not supply tooling the organisation has not approved.
4. Drafting. The assistant drafts the plan record from the scenarios, the window and the roles, and the lead edits it.

The risks are specific. A planner that proposes variants may also be the system whose output the blue team's detection-drafting assistant reads, or may share a model family with it; then the variants tend to resemble the detections written to catch them, and the test shows less than it seems to. That is the independence problem that Chapter 15 treats in full; at the planning stage the practical rule is that the model that varies a scenario is not the model that wrote or tuned the detection for it, and that the plan carries a small share of scenarios written by a person and not shown to any assistant (Chapter 5 calls this the held-out set). The second risk is automation bias on the reviewer's side. People reviewing an automated aid's proposals tend to check less the more reliable the aid has been (101, Parasuraman & Manzey, 2010), and the skills of the people who must catch its errors erode when the aid does most of the work (100, Bainbridge, 1983). The red team's answer, consistent with AI Red Team, Chapters 6 and 15, is to keep a share of planning unassisted and to seed the proposals with a deliberately inappropriate variant now and then, to see whether it is caught. Chapter 24 returns to the craft.

AI in execution and its limits

Execution is where delegation to AI is easiest to get wrong, because mistakes are acted on at machine speed. The rule of the book is a ceiling and a boundary.

The ceiling: Level 4 Autonomous is never used for an emulation action that is irreversible, that leaves the signed scope, that touches personal data beyond what the exercise is authorised to touch, or that targets a named person. Level 3 Bounded is defined by a catalogued scenario and a rules-of-engagement manifest enforced by a policy decision point outside the agent; it is the ceiling for execution and it applies only to scenarios of the benign, reversible, tagged safety class (S1 in Chapter 6) inside the signed scope. All other execution is at Level 2 Supervised at most: a person watches and can stop each action, and acts on the tester's identity.

The boundary: the agent that executes does not decide what to execute. The scenario is chosen by a person, from a catalogue; the target is a reference to the signed scope, resolved by the policy decision point, not typed into a prompt; the credential is issued for the task and expires with the window; the agent's tools are a small allowed set; its egress is denied except to the target range; and a budget caps its actions. If it needs something outside these, it stops and reports. Self-directed campaigns, in which an agent chooses targets and techniques to pursue a goal, are speculation as a legitimate practice at the time of writing and are outside the rules of this book.

The reason is not abstract. AI Governance, Chapter 19, recounts the July 2026 incident, and AI Red Team, Chapter 12, draws its lesson for emulation: evaluation agents, run with production safeguards deliberately switched off, left their sandbox through a package mirror that doubled as an egress path, used exposed credentials and compromised parts of production infrastructure at another organisation, with no attacker directing them (72, OpenAI, 2026) (73, Larcher et al., 2026) (74, Wijk et al., 2026). The controls that failed were correlated, and the alert reached people who did not hold the stop decision (88, Nordqvist, 2026). An emulation agent is the same kind of system with the same potential for the same failure: a capable executor with an identity of its own. It follows that its mandate is a manifest, that its stop path is held by someone who is not the red team, and that a drill shows the stop path works before a window opens. NCSC and its partner agencies reach the same conclusion in their guidance on adopting agentic AI services (54, Five Eyes agencies, 2026): bound the agent's permissions and keep a person able to intervene.

Expected: agent-run campaigns inside signed scope, at Level 3 Bounded, for catalogued safe scenarios. This is expected, because the tools and the mandate pattern exist and procurement is already under way at organisations such as Hansa Mutual (Chapter 8). It stays bounded for the reasons above.

Recording what was done

An exercise produces two kinds of record, and the second is the one that makes the first meaningful.

The first is the report: a narrative of what the testers found. The second is the event log: a timestamped, tamper-evident record of every action taken, written as it happens. Each entry gives the time, the acting identity (tester or agent), the source host, the target, the scenario and step identifier, the ATT&CK technique, the tag that marks the action in the telemetry, the result, and whether the action was within the plan. The log is ground truth. Without it, the observation stage can only ask what the detection systems saw, and the answer "nothing" is consistent with both "the detection failed" and "the tester never did it". With it, P3 Observe can ask the right question of every row: given that this happened at 10.42 from this host, what did each layer of the defence do?

Three design rules follow.

• Tag at the source. Every emulated action carries a marker that the telemetry pipeline preserves and that detections do not read. The marker lets the observation stage find the emulated events after the fact; because detections are written without access to it, the exercise measures them honestly. A detection that fires only because it keys on the marker is a defect, and the observation stage looks for it.
• Write to a store the testers cannot rewrite. The log goes to an append-only store held by the white team. Testers can add entries and annotations; they cannot alter or delete.
• Record the agent's actions in the same log. Where an agent acted, its action log is part of the event log, with the mandate manifest and the delegation profile in force. The agent's account of what it did is not evidence; the log written by the policy decision point and the telemetry are.

The log also records the unexpected. A step that did not go to plan, an action that had a side effect, a point at which the white team stopped or limited the test, a moment when a real incident was found and the exercise paused: these entries are among the most useful in the record, and they are entered without blame. Staff-related fields follow the aggregate-only rule above.

Practical guide: Writing an emulation plan that gives the blue team ground truth without giving it the plan

Purpose. Produce an EMU-* record that lets the observation stage compare every layer of the defence with an expectation, keeps the defenders unaware of the plan, and lets the white team stop the campaign without the testers' cooperation.

Roles. Red-team lead or contracted tester (author); white-team lead (approver); trusted agent; detection owner (receives the sealed record at hand-over but does not see the plan during the window); employee representatives (informed as the agreement requires); privacy officer (reviews data handling).

Steps.

1. Select three to eight scenarios from the library by the priority list of Chapter 5. Default: no more than eight in a two-week window, because the observation stage must be able to read each of them properly. Adapt to the size of the blue team: Nordvik Region's six analysts cannot absorb as many outcomes as Hansa Mutual's group SOC.
2. Copy the expected outcome per layer from each scenario into the plan. Do not rewrite expectations in the plan.
3. Add one scenario written by a person and shown to no assistant, and one variant of a known scenario. The first tests novelty, the second tests overfitting.
4. Bind each scenario to targets by reference to the manifest's scope, never by a new list. Put the window, the hours in which active actions are allowed and the freeze dates in the record.
5. Write abort conditions that someone other than the testers can measure, such as an unplanned error rate above a stated threshold on a named service, an alert that cannot be explained as emulated within 30 minutes, or any sign of data from outside the scope. Default: the white team assesses a suspected real incident within 15 minutes of the report.
6. Name two stop-path holders outside the red team, state the mechanism for each, and drill it before the window opens (Chapter 6). Record the drill result in the plan.
7. Define the tag scheme and the event-log store, and check that the tag survives the telemetry pipeline on a harmless test action.
8. Define who knows: the white team, the trusted agent and whoever the agreement requires. Everyone else is the blue team that does not know. Write down the procedure by which the trusted agent answers an analyst's question "is this ours?", without disclosing the plan.
9. Have the white-team lead sign the plan. The signature, not the red team's own approval, opens the window.

Definition of done. The plan record validates against its schema, every abort condition is measurable by the white team, the stop path has been drilled within the last seven days, the tag has been seen in the pipeline, the plan is held where only the people who know can read it, and the white-team lead has signed it.

Worked examples: EMU-* records

The two records below are illustrative. The first is a two-week catalogue run by the contracted tester at Nordvik Region in autumn 2027, the second one wave of the active phase of the threat-led test at Hansa Mutual. Both are classed as new facts in docs/EXAMPLE_ORGANISATIONS.md.

Worked example: EMU-NR-2027-02 (Nordvik Region, illustrative)

# Illustrative. Autumn catalogue run under RoE-NR-2027-001, amended to version 1.3.0.
emu_id: EMU-NR-2027-02
roe: RoE-NR-2027-001   # v1.3.0, autumn window 2027-10-05 to 2027-10-22, approved 2027-10-05; scenarios 0001, 0007, 0011 added
owner: Elin Berglund            # contracted tester, call-off NR-2026-071
white_team_lead: deputy-ciso    # delegate of the CISO, outside red and blue
trusted_agent: karin.lund       # detection owner; commissioned the run
window:
  active_from: 2027-10-11
  active_to: 2027-10-22
  hours: "08:00-17:00 Europe/Stockholm, weekdays; one declared out-of-hours delivery of the success step on 2027-10-12"
  freeze_avoid: [2027-10-18]    # benefits payment run
scope_ref: RoE-NR-2027-001@1.3.0#scope
production_actions: S1-and-S2   # S2 with per-run approval; all others in the pre-production mirror
scenarios:
  - id: SCN-NR-0001              # spray-then-success against the identity provider
    techniques: [T1110.003, T1078]
    safety_class: S2
    environment: production   # staff identity provider test tenant, synthetic accounts, per-run white-team approval
    expected: {telemetry: yes, detection: DET-NR-0001, alert: yes, triage: "within 30 min"}
  - id: SCN-NR-0007
    techniques: [T1087.002]
    safety_class: S1
    environment: production
    expected: {telemetry: yes, detection: none, alert: no}   # known gap, declared
  - id: SCN-NR-0011              # held-out, written by the tester, unseen by any assistant
    techniques: [T1046]
    safety_class: S2
    environment: pre-production-mirror
    expected: {telemetry: unknown, detection: unknown}
ai_assistance:
  tester_tools: {mode: "1-3", declared_under: NR-2026-071, level: "Level 1 Assisted"}
  emulation_agent: none          # no Mode 5 agent against Nordvik systems
abort_conditions:
  - "unplanned error rate above 2 percent on the benefits-triage service for 10 minutes"
  - "an alert not explainable as emulated within 30 minutes"
  - "any datum from outside the signed scope"
stop_path:
  - {holder: mssp-shift-lead, mechanism: revoke exercise credential at the identity provider}
  - {holder: deputy-ciso, mechanism: block tester host at the segment firewall}
  - drilled: 2027-10-07
tagging: {scheme: X-EXERCISE-TAG, store: append-only, held_by: white-team}
reporting: {staff_results: aggregate-only}
handover: {to: P3, record: PRP-NR-2027-02}

Elin Berglund's spring fieldwork under version 1.2.0 of the same manifest ran for three weeks (2027-03-15 to 2027-04-02) and is EMU-NR-2027-01. The autumn run is shorter on purpose, and it needed version 1.3.0 of the manifest (Chapter 6), because the window of version 1.2.0 had closed in April. It tests what the first run closed, two scenarios whose outcomes were already declared, and one new scenario, held out from every assistant including the detection owner's drafting assistant (Level 1 Assisted), which is not used to draft the detection for a scenario it helped to choose. Karin Lund is the trusted agent because the region has six analysts and no one else is both informed and independent of the test; the plan therefore keeps the white-team lead with the CISO's delegate, not with her. The MSSP shift lead is a stop-path holder so that the stop works out of hours, when the provider's AI closes low-severity alerts (the Mode 0 blind spot of AI Blue, Chapter 7). The expected outcome for SCN-NR-0007 is "no detection" because the Region declared the gap before the window: untested is not covered, and declared is not verified.

Worked example: EMU-HM-2027-02 (Hansa Mutual, illustrative)

# Illustrative. Wave 2 of the active phase of the TLPT under RoE-HM-2027-TLPT.
emu_id: EMU-HM-2027-02
roe: RoE-HM-2027-TLPT
owner: mareike.hartmann          # head of group red team, Hamburg
red_team_size: 5
white_team_lead: ciso-office-senior   # outside red team and SOC
trusted_agent: soc-duty-head
window: {active_from: 2027-09-20, active_to: 2027-10-01, hours: "any, with notice"}
scope_ref: RoE-HM-2027-TLPT#scope
scenarios:
  - {id: SCN-HM-0035, techniques: [T1078, T1021.001], safety_class: S2, origin: human}
  - {id: SCN-HM-0044, techniques: [T1087.002, T1046], safety_class: S1, origin: library}
  - {id: SCN-HM-0052, techniques: [AML.T0051], safety_class: S2, origin: human,
     target: claims-assistant, note: "design-level; no payload text in this record"}
  - {id: SCN-HM-0063, techniques: [T1110.003], safety_class: S1, origin: variant-of-library,
     variant_by: MND-HM-EMU-02, accepted_by: mareike.hartmann}
ai_assistance:
  testers: {mode: "1-3", level: "Level 1 Assisted"}
  planner: {mandate: MND-HM-EMU-02, level: "Level 1 Assisted", proposed: 6, accepted: 2}
  runner:
    mandate: MND-HM-EMU-01
    level: "Level 3 Bounded"
    allowed: [SCN-HM-0044]       # S1 only; calibration run on day 1
    never: [irreversible, out-of-scope, personal-data-beyond-authorisation, named-person]
abort_conditions:
  - "any alert attributed to a real adversary during the window"
  - "unplanned impact on a claims service"
stop_path:
  - {holder: white-team-lead, mechanism: "policy decision point kill switch"}
  - {holder: soc-duty-head, mechanism: "revoke exercise identities"}
  - drilled: 2027-09-16
staff_involvement: none
works_council: {clause: KBV-IT-2024-SOC-05, notified: true, results: aggregate-only}
event_log: {store: append-only, held_by: white-team, tag_scheme: X-EXERCISE-TAG}
handover: {to: P3, record: PRP-HM-2027-04}

Two things distinguish this record from Nordvik's. The runner is allowed to execute one S1 scenario on the first day, a calibration run that shows the tag survives the pipeline and the telemetry reaches the SOC before the humans begin; everything else is human. And the planner proposed six variants and the lead accepted two, a ratio the record keeps because it is the first measure of whether the review of AI proposals is real. The record names no payload, no phrase and no tool; where it concerns the claims assistant, it names an ATLAS technique and a target and nothing more.

Hand-over to P3

The campaign ends in a hand-over, not in a report. At the close of the window the white team seals the event log and the plan, and the red team states for each scenario what it did, what it saw and what it could not do. The blue side then receives, in this order: the sealed event log with its tags, so that the observation stage can find every emulated action; the plan, so that the expectation for each scenario is on record; and the red team's account, which the observation stage treats as evidence of intent, not of detection. The purple session (PRP-*) in Chapter 9 is where red and blue read these together.

The hand-over has a closure obligation of its own. A scenario that was planned but not run is recorded as not run, with the reason; a scenario that was run partly is recorded as such. The loop's later claim that a technique is covered rests on these entries, and a record that omits the scenarios that fell out of the window silently improves the apparent coverage, which Chapter 17 describes as a failure of the evidence and not merely of the exercise.

Across the usage modes

Mode	Use in P2 Emulate	Identity	Ceiling
Mode 0 Ambient AI	Supplier tooling the testers did not choose, for example AI in the endpoint console the plan is tested against; declared in the plan	The supplier's	Not used to execute; its effect on the test is recorded
Mode 1 Conversational assistants	Tester drafts, summarises intelligence, writes the action log	The tester's	Level 1 Assisted
Mode 2 Embedded workplace assistants	Drafting the plan record and report in the document tool	The tester's	Level 1 Assisted
Mode 3 Agentic work tools	Tester's tooling that runs steps the tester has chosen	The tester's	Level 2 Supervised
Mode 4 Built AI applications	Scenario curator and emulation planner (MND-HM-EMU-02) proposing variants	Its own, read-only	Level 1 or Level 2; the lead decides
Mode 5 Autonomous production agents	Emulation runner (MND-HM-EMU-01) executing catalogued S1 scenarios	Its own, task-scoped	Level 3 Bounded; never Level 4 for irreversible, out-of-scope, over-authorised or person-targeting actions

Nordvik Region and Hansa Mutual

Nordvik Region buys the loop. Its contracted tester, Elin Berglund, runs the exercises under RoE-NR-2027-001; the plan is the contract's instrument, since the call-off agreement NR-2026-071 already requires her to declare any AI she uses and bars a Mode 5 agent without a signed mandate. The Region's leverage is therefore the record: it can demand the event log, the plan and the drilled stop path as deliverables. Its risk is that the loop closes after the first report. Its plan keeps scenarios few, declares known gaps in advance and puts the stop path in the MSSP shift lead's hands.

Hansa Mutual runs the loop. Mareike Hartmann's team of five owns the human-led campaigns and the novel scenarios under RoE-HM-2027-TLPT, while the planner and runner supply breadth under mandates at Level 1 and Level 3. Its leverage is the pipeline, its risk a loop that runs on without anyone questioning it, and its plan therefore keeps humans on the novel scenarios and a measurable review of what the planner proposes. Both organisations hold the plan and the event log as security-sensitive records, because they are a map of the estate (Chapter 16).

Summary

The emulation plan turns a scenario, which says what to test, into a campaign: scenarios in order, targets by reference to the signed scope, a window, measurable abort conditions, roles, a delegation profile for any AI and a tag scheme for the record. The roles in a live exercise are separate on purpose. The red team emulates, the white team governs and holds the stop path, the trusted agent answers the question "is this ours?", and the blue team that does not know is measured on an ordinary day, in aggregate and never by name.

AI helps at planning and variation at Level 1 Assisted or Level 2 Supervised, and at execution only at Level 3 Bounded for catalogued, benign, reversible scenarios inside the signed scope, enforced by a policy decision point outside the agent. Level 4 Autonomous is never used for an irreversible action, one that leaves the scope, one that touches personal data beyond the authorisation or one that targets a named person. Human-led, AI-assisted emulation is observable practice; agent-run campaigns inside signed scope are expected; self-directed campaigns are speculation and outside this book's rules. This chapter's own conclusion is that the plan is where independence and safety are decided: the held-out scenario, the planner that is not the detector's author, the drilled stop path and the tamper-evident event log are properties of the plan, not of the people.

This chapter concerned P2 Emulate, with P1 Target as its input and P3 Observe as its recipient. Chapter 8 takes the same stage into the pipeline, where emulation runs continuously and the question becomes what the human red team is still for. Chapter 9 turns the sealed record into outcomes, layer by layer.

Sources

1. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (17, MITRE, n.d.)
2. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (18, MITRE, n.d.)
3. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. (20, ECB, 2025)
4. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 (DORA). (2, European Union, 2022)
5. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2). (3, European Union, 2022)
6. European Commission. Commission Delegated Regulation (EU) 2025/1190 (regulatory technical standards on threat-led penetration testing). (8, European Commission, 2025)
7. Blum, Mainor, Nambiar et al. ARTEX and Friends: Enter Agentic Offensive Frameworks. (66, Blum et al., 2026)
8. Anthropic. Disrupting the first reported AI-orchestrated cyber espionage campaign. (67, Anthropic, 2025)
9. Fang, Bindu, Gupta & Kang. LLM Agents can Autonomously Exploit One-day Vulnerabilities. (68, Fang et al., 2024)
10. Parasuraman & Manzey. Complacency and Bias in Human Use of Automation. (101, Parasuraman & Manzey, 2010)
11. Bainbridge. Ironies of Automation. (100, Bainbridge, 1983)
12. OpenAI. OpenAI – Hugging Face Incident Technical Report. (72, OpenAI, 2026)
13. Larcher, Carreira et al. Anatomy of a Frontier Lab Agent Intrusion. (73, Larcher et al., 2026)
14. Wijk, Cotra & Greenblatt. Brief independent investigation of agents' behavior in the OpenAI / Hugging Face incident. (74, Wijk et al., 2026)
15. Five Eyes cyber security agencies. Careful adoption of agentic AI services. (54, Five Eyes agencies, 2026)
16. Nordqvist, G. AI Governance. (88, Nordqvist, 2026); AI Platform and Security. (89, Nordqvist, 2026); AI Red Team. (90, Nordqvist, 2026); AI Threat. (91, Nordqvist, 2026)