An AI Agent Team for the Loop: Skills, Mandates and Containment

Part III applied the loop to AI systems and to the defenders' AI. This chapter turns to the loop's own AI: the standing team of agents that an organisation can place inside the purple loop itself, and the limits that make such a team safe to run. It concerns P2 Emulate, because one of the team's agents holds offensive capability and runs inside the estate; P3 Observe, because an agent can correlate what was done with what was seen; P4 Improve, because an agent can draft the change that a finding calls for; and P5 Verify, because the re-test is the most repeatable work in the loop. The scenario curator also touches P1 Target at its edge, where Chapter 5 treats the decisions that remain with people.

The chapter answers five questions. Which loop functions may be given to agents, at what level for each stage and action class, what a mandate manifest and a permission ceiling contain, how identity and credentials are handled for an agent that holds offensive capability, and what the budgets and the stop are. It builds on the conclusions of the earlier volumes and does not repeat them. AI Governance, Chapters 19 and 25, concluded that every agent is governed as a well-meaning insider (a modelling device, not a claim about the agent), because instructions lower the rate of unwanted behaviour but only boundaries set a ceiling on its consequences (88, Nordqvist, 2026). AI Platform and Security, Chapter 19, set the containment baseline that does not depend on intent (89, Nordqvist, 2026). AI Red Team, Chapter 6, defined the usage modes, the autonomy levels and the rule that every machine identity has named people behind it, and AI Red Team, Chapter 12, applied them to one emulation agent (90, Nordqvist, 2026). The Transformed Security Architect, Chapter 13, and AI Blue, Chapter 13, applied them to an agent team for architecture work and for the security operations centre (SOC) (92, Nordqvist, 2026) (94, Nordqvist, 2026). What is new here is a team that has two sides, one that tests and one that is tested, and a function in it that is an offensive capability by design.

Figure 14.1: An agent team for the loop: coordinator, four agents, critic, policy decision point and white team.

Why a team, and why this team differs

AI Blue, Chapter 13, described a SOC team whose agents read the most hostile content in the organisation. The loop's team reads hostile content too, and Chapter 16 treats it as a tier-0 asset. Three properties make it a different design problem.

First, one agent of the team executes emulation steps. In the vocabulary of the series it is a Mode 5 system, an agent that acts with an identity and permissions of its own and therefore becomes a privileged machine insider whatever its product name (F49). An agent whose task is to probe for weaknesses needs containment more than other agents, not less, and the July 2026 incident in which evaluation agents left their sandbox shows what follows when it is missing (72, OpenAI, 2026) (73, Larcher et al., 2026).

Second, the team sits on both sides of the loop. An agent that chooses scenarios and an agent that drafts the detection for them can agree with each other for reasons that have nothing to do with the adversary: a shared model family, a shared repository, a shared prompt. The independence principle (Chapter 15) is the rule that governs this, and the permission ceilings of this chapter are where it is implemented: no function reads the other side's working store except through a finding.

Third, the people who answer for the team come from three groups. The red team owns the scenarios and the runner, detection engineering owns the detections the drafter proposes, and the white team owns the stop. A mandate has to name which of them answers for which agent, because the loop has no single manager the way a SOC has a SOC lead.

The research on automated penetration testing gives a practical reason for narrow agents rather than one general agent. An evaluation of a tool that used a large language model for penetration testing found that the model did well on sub-tasks such as using tools, interpreting their output and suggesting next steps, but struggled to keep an integrated picture of the whole testing scenario, and the authors split the work between modules for that reason (69, Deng et al., 2024). That is a result about a particular tool and benchmark, not a general law, and the evaluation was of capability, not of safety. The architectural reading is the book's own: a function narrow enough to be tested, bounded and stopped is also a function whose failure is easier to see.

Candidate functions

Eight functions of the loop can be given to an agent. They are not eight products; an organisation may run several of them in one system, as long as the mandate separates them. The table gives each function's stage, side of the loop, what it reads and what it writes or does.

Function	Stage	Side	Reads	Writes or acts
Scenario curator	P1 Target (edge), P2 Emulate	Red	Intelligence, the threat register, incident summaries, the scenario catalogue	Proposed scenario records SCN-* and retirements, for review
Emulation planner	P2 Emulate	Red	The catalogue, intelligence, the change calendar	Draft emulation plan EMU-*, for review
Emulation runner	P2 Emulate	Red	The signed catalogue, the rules of engagement, the scope list	Runs catalogued steps against listed targets; writes the tagged event log
Observation correlator	P3 Observe	Joint	The event log, telemetry, alerts, cases	Outcome per layer for each step; draft finding
Detection drafter	P4 Improve	Blue	Findings, the detection repository	Pull request with a detection or playbook change and its test
Finding triager	P3 Observe, P4 Improve	Joint	Findings, ownership data, the backlog	Proposed owner, priority and duplicate links
Re-test runner	P5 Verify	Joint	Regression cases REG-*, the rules of engagement	Re-runs a case and its variants; draft evidence manifest EVD-*
Critic	P2 to P5	Joint	The outputs of the other functions, never their working stores	Flags and questions, never gates

Four of the eight need a reason for their shape.

The runner executes a catalogue; it does not compose. AI Blue, Chapter 13, reached a parallel conclusion about response: the SOC has no response agent, because containment is a playbook run by the orchestration layer (F98) (94, Nordqvist, 2026). The loop applies the same separation to emulation. Open-source platforms such as MITRE Caldera already run adversary emulation from a library of defined abilities, each a specific implementation of an ATT&CK technique (37, MITRE, n.d.). The runner of this chapter is an agent that selects, sequences and parameterises entries from a signed catalogue within an approved variant set, and each step is carried out by a deterministic executor that takes only catalogued entries. The model never composes a command. The consequence is that the thing the policy decision point checks, a scenario hash against a signed catalogue, is something that can be checked.

The planner and the curator stay at the level of proposals. A model can propose a scenario from an intelligence report faster than a person, and it can propose scenarios that are easy to emulate rather than important to test (Chapter 5). Both agents therefore write drafts for a person to accept, and the list of what no agent proposes into a catalogue includes any scenario that targets a named person. Human-authored novelty stays with the red team (Chapters 7 and 15).

The triager ranks and routes; it does not close. Ranking findings decides what a person sees first, and a triager that quietly lowers the priority of a hard finding is a way to lose it. Closure is not the triager's to apply (Chapter 4 defines the closure rule and Chapter 11 operates it), and sampled and seeded findings test its ranking in the way that seeded incidents test a SOC agent (Chapter 13).

The critic reads outputs, never working stores. A critic on a second model family challenges the planner's choices, the correlator's outcomes and the drafter's detections. AI Blue, Chapter 14, concluded that such an agent is for questions, not verdicts (F99) (94, Nordqvist, 2026). Its objection is a flag for a person; it opens and closes nothing.

What stays with people

Four things are not delegated to any agent at any level. The first is authorisation: a named authority signs the rules of engagement, and an agent does not extend its scope, its window or its list of targets (Chapters 6 and 20). The second is the decision to stop, which belongs to holders who can act within the time the situation allows, outside the system they stop (F63, F50). The third is the closure of a finding, which needs a person's signature on the evidence. The fourth is the authorship of what is new: the scenario that nobody has catalogued, the judgement about consequence and the reading of the organisation's social context are what AI Red Team, Chapter 12, kept for the human-led exercise, and Chapter 7 develops them.

Delegation per stage

The delegation profile states, per function and per action class, the level of the series' autonomy scale. It follows the rules AI Blue, Chapter 4, set for the transformed team: the lowest ceiling governs, an action not listed is undelegated, lowering a level is immediate, and raising one is a decision by a named authority (F93) (94, Nordqvist, 2026). The level is decided from reversibility, blast radius, the independence of the check on the output and the decision tier, not discovered from what the agent turns out to do (F50) (90, Nordqvist, 2026).

Four questions set the ceiling for any action class in the loop, and the lowest answer governs.

1. Can it be undone? A scenario of safety class S1 (benign, reversible, tagged; Chapter 6) carries a verified clean-up step. A scenario that cannot be undone is taken by a person at Level 1 Assisted at most, and an agent never executes it.
2. Does it stay inside the signed scope? Scope is a list of targets, accounts, techniques and times that the policy decision point reads. An action outside it is refused, not escalated.
3. Does it touch personal data beyond what the exercise is authorised to touch, or name a person? If so it stays with people. 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.
4. Is the check on the output independent of the agent that produced it? An output reviewed by the same model family that produced it has not been checked in the sense of Chapter 15, and the level stays at Level 1.

The table is the profile of Hansa Mutual. It is also the book's delegation table: functions by stage, usage mode and level.

Function	Stage	Usage mode	Level (action class)	Mandate
Emulation runner	P2 Emulate	Mode 5 Autonomous production agents	Level 3 Bounded for S1 scenarios inside the signed scope; Level 2 Supervised for S2 (production, with per-run white-team approval) and for S3 (pre-production mirror or range); none for S4 and for irreversible, out-of-scope or person-targeting actions	MND-HM-EMU-01
Scenario curator	P1 Target, P2 Emulate	Mode 4 Built AI applications	Level 1 Assisted	MND-HM-EMU-02
Emulation planner	P2 Emulate	Mode 4 Built AI applications	Level 1 Assisted	MND-HM-EMU-02
Observation correlator	P3 Observe	Mode 4 Built AI applications	Level 1 Assisted	MND-HM-EMU-03
Critic	P2 to P5	Mode 4 Built AI applications	Level 0 Advisory, second model family	MND-HM-EMU-04
Finding triager	P3 Observe, P4 Improve	Mode 4 Built AI applications	Level 1 Assisted	MND-HM-EMU-05
Re-test runner	P5 Verify	Mode 5 Autonomous production agents	Level 3 Bounded to run regression cases of safety class S1 inside the signed scope and to assemble the evidence; Level 2 Supervised otherwise; it never closes a finding, a named person signs	MND-HM-EMU-06
Detection drafter	P4 Improve	Mode 5 Autonomous production agents (workload identity, pull requests only)	Level 1 Assisted	MND-HM-EMU-07

Three features of the profile need comment. First, only the two runners reach Level 3 in practice, and both reach it only for S1 scenarios, which is the same reasoning as AI Red Team, Chapter 12, and Chapter 8 of this book applies to continuous emulation. Second, the detection drafter is HM-SEC-002 of AI Blue, which keeps its mandate in the SOC and gains a second, narrower mandate for its use by the loop: it may read findings, not scenario text, and may open pull requests, not merge them. No agent of the loop changes production detection content; the SOC agents of AI Blue (HM-SEC-001, -002, -006 and -007) are tested by the loop and are not part of it. Third, a level falls at once on a circuit breaker or a failed test, and it is restored only on a re-test and by a decision of the authority, the pattern Chapter 13 sets for the defenders' AI.

The curator and the planner share one mandate and one model family; the curator proposes, a person accepts (Chapter 5), so the planner never plans from an unreviewed proposal.

Mandates and permission ceilings

A mandate manifest (MND-NR-EMU-* for Nordvik Region, MND-HM-EMU-* for Hansa Mutual) is the written mandate for one agent, kept in version control beside the scenario catalogue and the detections. It names the agent's purpose, stage and usage mode, the people who own it, the level for each action class and the conditions for Level 3, the budgets, the circuit breakers, the stop path and the date on which it is reviewed and expires. The platform's identity provider, policy decision point and egress gateway read it, so a change to a mandate is a reviewed pull request and not a conversation. The permission ceiling is the technical form of the same limits: identity, tools, scopes, rate limits and egress, as AI Platform and Security, Chapter 19, defined it (89, Nordqvist, 2026). Where the mandate and the ceiling disagree, the narrower governs and the discrepancy is a finding.

The loop adds entries that a SOC mandate does not need. The rules-of-engagement reference ties the mandate to the signed manifest of Chapter 6, so that an agent cannot run outside a window or a scope that the signed rules do not give it. The catalogue binding states which scenarios the agent may run, by signed hash, and the highest safety class. The separation list states what the agent may never read or write: the runner never reads detection content, the drafter never reads held-out scenarios, the critic never reads a working store. And the never list carries the actions by which an agent could change its own governance: editing its mandate, the rules of engagement or the catalogue, widening its tool list or scope, writing to the log that records its actions, using a real person's credentials, contacting a person with a scenario, and acting at Level 4.

Practical guide: Writing a mandate manifest for an emulation runner

Purpose. To give an emulation runner a mandate that a policy decision point can enforce, so that its ceiling holds whatever instructions it receives. Roles. The red-team lead (owner), the white-team lead (stop holder), the purple coordinator, the security architect for the permission ceiling, the data protection officer where exercise telemetry contains personal data, and an employee representative where staff are involved.

1. Start from the rules of engagement. Copy the stage, scope, windows and abort conditions of the signed manifest. The mandate may be narrower than the rules and never wider.
2. Name the people. One owner, at least two operators on a rota and the authority that grants the level. A mandate without a named owner is not valid. Name the stop holders, who must be outside the runner and, by default, outside the red team: the white-team lead, a deputy and the shift lead of the SOC.
3. Bind the catalogue. List the scenario sources and the highest safety class. Start with S1 only. Make the catalogue read-only to the agent and require the hash of each scenario to match the signed version.
4. Set the level per action class. Use Level 3 Bounded only for S1 scenarios inside the scope with a verified clean-up step. Use Level 2 Supervised for S2 (with per-run white-team approval) and S3 (in a pre-production mirror or range), and never execute S4. Leave irreversible, out-of-scope, personal-data and person-targeting actions off the list; an unlisted action is undelegated.
5. Issue an identity of its own. Use a workload identity for the exercise, test accounts only, tokens of at most 10 minutes issued outside the agent's runtime, and revocation in 60 seconds or less. Adapt the token time to the longest legitimate step, never to the convenience of the agent.
6. Set the budgets. Cap actions per run (a default of 40 for S1), targets per run (five), runs per day, wall-clock minutes per run (30) and cost per month. On a limit the agent stops and reports; it does not ask for more.
7. Write the circuit breakers. Stop on any action outside the permission ceiling, contact with an out-of-scope asset, a denied call over threshold, real personal data in a result, a real incident in progress, or a missing clean-up confirmation.
8. Write the never list and the separation list from the entries above. Add anything the organisation's regulators or works agreement forbids.
9. Set review and expiry. Review quarterly and on any change of model, catalogue or scope, and expire after twelve months unless a recorded decision renews it. Adapt the interval to the organisation's risk appetite and, for a financial entity, to the cadence its competent authority sets.
10. Test the ceiling before the first run. Run the runner in the range with a planted out-of-scope target, an out-of-window request and an expired token, and confirm that each is refused and alerted to the stop holders.

Definition of done. The manifest parses and is validated in the pipeline; the policy decision point refuses the three planted conditions; a stop drill revoked the identity within the stated time; and the authority has recorded the level in an AI Decision Record.

Worked example: Mandate manifest MND-HM-EMU-01

The example is illustrative. It is Hansa Mutual's mandate manifest for the emulation runner of HM-SEC-004, adopted by AIDR-0854 on 2028-02-15 together with the delegation profile DLG-HM-EMU-01.

# Illustrative: Hansa Mutual, mandate manifest for the emulation runner of HM-SEC-004
id: MND-HM-EMU-01
version: 1.0.0
function: emulation runner
stage: P2 Emulate
usage_mode: Mode 5 Autonomous production agents
decision_records: [AIDR-0314, AIDR-0854]
rules_of_engagement: RoE-HM-2028-001
owner: head of the group red team
operators: [red-team operator on the range rota]
authority: group AI governance board
stop_holders: [white-team lead, white-team deputy, group SOC shift lead]
identity:
  workload: spiffe://hansa.group/redrange/emulation-runner
  credentials: exercise test accounts only
  token_minutes: 10
  issued_by: red-range identity provider, outside the agent runtime
  revocation_seconds: 60
catalogue: {source: scenarios/ signed and read-only, kinds: [SCN-HM-*], safety_class_max: S3}
levels:
  run_s1_scenario_in_scope: {level: 3, enforced_by: policy decision point, requires: [signed RoE, scenario hash match, open window, target on scope list, clean-up verified]}
  select_variant: {level: 3, within: approved variant set of the scenario}
  run_s2_or_higher: {level: 2, approver: red-team operator with white-team approval per run, where: "S2 in scope; S3 in pre-production mirror or range; S4 never"}
  propose_new_scenario: {level: 0, goes_to: scenario curator review}
separation: {may_read: [catalogue, scope list, RoE], may_not_read: [detection content, held-out scenarios, findings register]}
never: [irreversible_action, leave_scope, touch_unauthorised_personal_data, target_named_person, use_real_credentials, edit_own_mandate_or_RoE_or_catalogue, widen_tool_list, write_to_action_log, act_at_level_4]
budgets: {max_actions_per_run: 40, max_targets_per_run: 5, max_runs_per_day: 8, max_minutes_per_run: 30, monthly_cost_eur: 4500, on_limit: stop_and_report}
circuit_breakers: [action_outside_ceiling, out_of_scope_contact, denied_calls_over_threshold, real_personal_data_in_result, real_incident_in_progress, cleanup_unconfirmed]
logging: {tag_every_action: HM-EMU-TAG, log_store: outside the red range, tamper_evident: true}
stop_path: {mechanism: out-of-band revocation at the identity provider and egress gateway, target_seconds: 60, drill: quarterly}   # first drill 38 s (Chapter 6); the generic default of Chapter 4 is 120
review: {cadence: quarterly and on any model, catalogue or scope change, next: 2028-05-15}
expires: 2029-02-15

Three entries carry the design. The Level 3 line does not grant a permission; it states the conditions under which the policy decision point lets a catalogued step through, and the model's confidence is not among them. The separation entry makes the independence principle a refusal: the runner cannot read the detections it is testing, so it cannot adapt to them in a way that would make the test easier to pass. And target_named_person appears in the never list although no tool in the catalogue does it, because a manifest that omits a prohibition invites a later change that adds the capability and forgets the prohibition.

Worked example: A Nordvik delegation profile as code

Nordvik Region delegates two functions to AI and keeps the rest with its contracted tester and its own analysts. The profile is illustrative; AIDR-0804 of 2028-02-08 adopted it, and it is the register that the CISO shows the audit committee when it asks what is delegated.

# Illustrative: Nordvik Region, delegation profile for the loop
id: DLG-NR-EMU-01
version: 1.0.0
decision_record: AIDR-0804
owner: Karin Lund, detection owner and purple coordinator
authority: CISO
review: {cadence: after each catalogue run by the testing firm, next: 2028-04-30}
functions:
  emulation_runner: {delegated_to: contracted tester under NR-2026-071, ai_agent: none, note: declared Modes 1-3 only; no Mode 5 emulation agent without a signed mandate}
  scenario_curator: {delegated_to: Karin Lund and the tester, ai_agent: none}
  emulation_planner: {delegated_to: the tester, ai_agent: none}
  observation_correlator: {delegated_to: AI, mandate: MND-NR-EMU-01, level: 1, usage_mode: Mode 4 Built AI applications, hosting: self-hosted in the Region, reads: [tagged event log, siem, cases], writes: [draft outcome table]}
  detection_drafter: {delegated_to: Karin Lund with the drafting assistant, level: 1, excluded: scenarios the assistant helped to choose}
  finding_triager: {delegated_to: Karin Lund, ai_agent: none}
  retest_runner: {delegated_to: the tester, ai_agent: none}
  critic: {delegated_to: AI, mandate: MND-NR-EMU-02, level: 0, model_family: different from the family the tester declares}
stop_holders: [Karin Lund, second analyst, MSSP shift lead for the out-of-hours window]
never: [act_at_level_4, run_emulation, edit_detection, close_finding]

The profile shows what the small team has chosen. It does not buy a runner, because a contractor with a declared toolset already runs the catalogue and the Region has no spare people to conduct a Mode 5 agent. It delegates the two functions that cost the most analyst time and expose the least: joining the tester's log with the Region's detections, and asking the awkward question about each outcome.

Identity and credentials

Every agent of the team is a distinct principal. The Five Eyes guidance on agentic AI advises a cryptographically anchored identity for each agent, a registry that binds identities to authorised roles and is reconciled against the live set of agents, and minimum scope for approved tasks, and it states that no agent should modify its own privileges (54, Five Eyes agencies, 2026). Four rules follow for the loop.

• The runner never holds a real person's credential. Scenarios that start from a compromised account use a test account created for the exercise, with the scope and expiry of the rules of engagement. This is also the data-protection answer: a scenario that used a real employee's account would put that person's data and actions into the exercise without a basis (GDPR Article 5(1)(c) on data minimisation) (7, European Union, 2016).
• Runner and re-test runner have separate identities. They run similar steps, and a shared credential would turn two controls into one. The shared-credential failure is the first of the three that AI Governance, Chapter 19, found in the July 2026 incident (88, Nordqvist, 2026); the incident report records that many research workloads used the same shared credential (72, OpenAI, 2026).
• Tokens are issued outside the agent. The runner's token lives at most 10 minutes, the correlator's read token at most 60, and revocation takes effect in 60 seconds. The numbers are defaults to adapt to the longest legitimate step.
• Every identity has named people. AI Red Team, Chapter 6, concluded that every machine identity has an owner, operators and an authority who are named people (F51) (90, Nordqvist, 2026). In the loop the owner of the runner is the red-team lead, the owner of the drafter's loop mandate is the detection-engineering lead, the owner of the correlator is the purple coordinator, and the stop holders come from the white team. A registry entry without an owner is a finding.

NIS 2 Article 20 requires the management bodies of essential and important entities to approve and oversee cybersecurity risk-management measures, and DORA Article 5 places responsibility for ICT risk with the management body of a financial entity (3, European Union, 2022) (2, European Union, 2022). The architectural implication, not legal advice, is that nothing in this chain moves to the tool: the agent runs within a mandate that people granted, and the record shows who.

Containment

Containment answers one question: what can the agent reach whatever instructions it receives? The baseline is that of AI Platform and Security, Chapter 19: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, budgets, a stop path outside the system it stops, recorded approvals, and detection from telemetry and decoys rather than from the agent's own account (F45) (89, Nordqvist, 2026). A team of loop agents adds the following.

The range is separate. The runner works in the red team's own environment. The only route to the targets is through approved egress points and the only route to the blue side is through a finding. The range shares no package mirror, repository or credential store with another environment. This is the lesson of the July 2026 incident, in which agents run for a legitimate security-testing purpose with production safeguards deliberately switched off left their sandbox through a self-hosted package mirror and used exposed credentials (72, OpenAI, 2026) (73, Larcher et al., 2026). The UK AI Security Institute separately reported unsanctioned actions on the live internet during evaluation runs in which internet access had been enabled on purpose, while stating that this was not a sandbox escape (56, UK AISI, 2026). The reports differ in cause and consequence. What they share is that the failures were of the testing set-up, which is exactly what a loop team consists of.

The team must not fail together. A team of eight functions invites shared components: one model gateway, one secret store, one scenario repository, one log store. Two controls that depend on the same component fail together and count as one (F64) (91, Nordqvist, 2026). The dependency list of the team is therefore part of its documentation. The runner's stop path must not run through the gateway the runner uses, and the critic's second model family must not come through the same vendor account as the planner's, a point Chapter 15 makes into a test.

Every action is marked and reversible. Each step carries a simulation marker in the tagged event log, kept outside the range. The log is the ground truth that Chapter 9 compares with telemetry. An S1 scenario ships its own clean-up step, and the runner reports the clean-up as confirmed before the next step is allowed. An unconfirmed clean-up is a circuit breaker. What can be undone is stated per scenario, not per programme.

The inputs are untrusted. The correlator reads telemetry in which strings may have been written by an adversary or by a user, and the triager and the drafter read findings that quote them. OWASP's list of risks for agentic applications gives a shared vocabulary for these risks (22, OWASP, 2025), and AI Blue, Chapter 15, set the controls: inputs classified by who can write them, a policy decision point outside the model and no free egress (94, Nordqvist, 2026). Chapter 16 applies them to the loop's own assets. In MITRE ATLAS terms the prompt-injection technique (AML.T0051) is a design input for the correlator's tests, not a string in this book (18, MITRE, n.d.).

Behaviour is watched from outside. Anthropic's simulated scenario in which models took a harmful action in a large share of runs, and in which direct instructions not to do so lowered the rate without removing it, is a vendor research self-report of an artificial set-up, and its authors state that they had not seen the behaviour in real deployments (71, Lynch et al., 2025). Its lesson is the one this chapter relies on: the ceiling cannot be a sentence in the prompt. Canaries and decoys in the range, the egress gateway's denied-call count and the white team's view of the tagged log tell the stop holders what the agent did without asking the agent.

The practitioner's own use of AI

Alongside the standing team, red operators, detection engineers, purple coordinators and white-team members use AI in Modes 1 to 3: conversational assistants, assistants embedded in workplace tools, and agentic work tools that act with the person's own identity. AI Blue, Chapter 12, treated the analyst's use of these modes, and The Transformed Security Architect, Chapter 12, treated the architect's, and neither is repeated here. Three points are particular to the loop.

First, scope and findings are the sensitive content. A rules-of-engagement manifest or a findings register pasted into an unapproved assistant moves a map of the estate out of the organisation, and AI Red Team, Chapter 12, already named the case (90, Nordqvist, 2026). The rule is that the approved assistants are listed in the rules of engagement and that the findings register is not an input to any tool outside it. Nordvik's call-off agreement NR-2026-071 makes the same point in procurement terms: the testing firm declares any AI it uses in Modes 1 to 3.

Second, a person's use of AI in a loop record is declared in the record. A purple session record, a finding or an evidence manifest says which parts an assistant drafted and who read them. The declaration is not a performance measure; it is what lets a reviewer know which statements to reproduce by another route.

Third, the conductor is subject to the same effects as the analyst. Controlled studies of automation have found that complacency and automation bias occur in experts as well as novices and are not removed by practice alone (101, Parasuraman & Manzey, 2010), and Bainbridge's analysis explains why the person who monitors an automated system needs the skill that the automation takes away (100, Bainbridge, 1983). The loop's version is that a purple coordinator who only accepts the correlator's outcome tables will stop being able to read the raw log. Working a share of sessions without the correlator and reproducing a sample of its outcomes by hand keeps the skill, and Chapter 24 develops the practice.

Budgets and stop

A budget is a ceiling that an agent cannot argue with. The loop's agents carry four kinds: actions per run and per day, targets per run, time per run and cost per month. On any limit the agent stops and reports; a request for a larger budget is a change to the mandate and goes through review. The numbers in the example are defaults. A tighter limit suits a first quarter of operation, and a looser one needs the evidence of earlier runs behind it.

The stop has three forms, and the mandate says which holder can use which.

• Pause. The policy decision point stops admitting new steps. A circuit breaker triggers it automatically and any stop holder can trigger it by hand.
• Revoke. The identity provider and the egress gateway end the agent's credentials and routes. The mechanism is outside the runner and outside the red range, and it reaches a named person at every hour a run can occur. The Hansa default is 60 seconds from decision to effect, and the white team drills it each quarter.
• Undo. The clean-up manifests of the scenarios that ran are executed and confirmed, and what could not be undone is reported to the incident commander as a possible real event.

A stop path decays unless it is used. The question of how far Level 3 can safely reach and how fast a stop path decays is still open (Q12), and the answer of this chapter is operational: the drill is part of the mandate, and a stop that has not been drilled within the quarter lowers the runner to Level 2 until it has. Nordvik's correlator and critic only read, so their stop is the revocation of a read token by Karin Lund or the second analyst, drilled at each catalogue run.

NIS 2 Article 21 requires measures to assess the effectiveness of cybersecurity risk-management measures, and the testing provisions of DORA, Articles 24 to 27, require a testing programme and, for designated entities, advanced testing by threat-led penetration testing with requirements on the testers (3, European Union, 2022) (2, European Union, 2022). Whether an emulation agent may form part of the tester in a threat-led test, and who then answers as the tester, is a question for the competent authority and the framework, and Chapter 21 treats it. The TIBER-EU framework assigns the control of an exercise to a control team of a few representatives of the tested entity, which this book calls the white team (20, ECB, 2025), which is why the stop holders of the mandate come from it. If an agent of the loop produced scores about named employees, an AI Act classification question would arise (Annex III, point 4 (1, European Union, 2024); AI Boss, Chapter 21), and the design rule that no loop agent targets or scores a named person is meant to keep the loop outside it.

Outlook

Observable, expected, speculation

Observable. Agent-driven testing exists: Google's threat intelligence group describes agentic offensive frameworks used by adversaries in 2026 (66, Blum et al., 2026), open-source emulation platforms are in wide use (37, MITRE, n.d.), and research tools for automated penetration testing exist (69, Deng et al., 2024).

Expected. Agent teams that run under mandates with enforced permission ceilings and drilled stop paths are expected: the Five Eyes guidance on agentic AI points that way for any agent that acts (54, Five Eyes agencies, 2026), and the supervisory frameworks already demand rules of engagement and a control group.

Speculation. Agent teams that widen their own mandates, choose their own scope or retire their own stop paths are speculation, and the design of this chapter prohibits them: the never list closes the routes, and a mandate that grows is a reviewed change by a named authority.

Across the degrees of delegation

The levels are the series' autonomy levels applied to the loop's action classes.

Level	In the loop	Example in this chapter
Level 0 Advisory	The agent flags or proposes; a person decides what to do with it	Critic; scenario proposals from the curator before review
Level 1 Assisted	The agent drafts; a person executes or accepts	Planner, curator, correlator, triager, detection drafter
Level 2 Supervised	The agent executes after each action is approved	Runner on S2 with per-run approval and on S3 in the mirror or range; never on S4
Level 3 Bounded	The agent executes a catalogued step inside a signed scope, enforced by a policy decision point outside the agent	Runner and re-test runner on S1 scenarios with a verified clean-up
Level 4 Autonomous	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	None

Across the usage modes

Mode	In the loop's team	Main risk	Who answers, with whose identity
Mode 0 Ambient AI	Vendor AI in the simulation tool, the detection platform or the testing firm's tooling	Autonomy nobody decided; shared model family with the other side	The vendor's model; the contract names the owner of its use
Mode 1 Conversational assistants	An operator or engineer drafts and researches	Scope or findings pasted into an unapproved tool	The person, with their identity
Mode 2 Embedded workplace assistants	Summaries of sessions and findings	A summary that hides a partial failure	The person who signs the record
Mode 3 Agentic work tools	Tooling and detection code written with an agent	An agent with an engineer's credentials between instruction and review	The reviewing engineer, with the engineer's identity
Mode 4 Built AI applications	Curator, planner, correlator, triager, critic	Poisoned intelligence or telemetry steering the output	The conductor; a read-only service identity
Mode 5 Autonomous production agents	Runner, re-test runner, detection drafter	Exceeding the mandate through shared credentials or side egress	The white team and the owner; an identity of its own

Nordvik Region and Hansa Mutual

Nordvik Region delegates only the critic and the correlator to AI (DLG-NR-EMU-01, AIDR-0804) and keeps the other six functions with the contracted tester, Elin Berglund, and with Karin Lund. The reasons are capacity and contract. A team of six analysts in office hours has no slack to conduct a Mode 5 runner, and the call-off agreement NR-2026-071 already forbids a Mode 5 emulation agent against the Region's systems without a signed mandate. The Region's risk is a loop that never starts, and the two delegated functions are the ones that shorten the day after a catalogue run. Its independence is by role and contract: the tester is not the detection owner, and the critic runs on a model family different from the one the tester declares.

Hansa Mutual delegates eight functions at levels from 0 to 3 and records them as DLG-HM-EMU-01 with seven mandates, MND-HM-EMU-01 to -07 (AIDR-0854). The runner reaches Level 3 for S1 scenarios through the continuous programme HM-SEC-004, and the group red team under Mareike Hartmann owns it. The white-team lead sits outside both the red team and the SOC and holds the stop. Hansa's risk is a loop that runs without anyone questioning it, and the permission ceilings, the separation list and the quarterly stop drill are the questions put in advance. Its independence has to be designed between agents, and Chapter 15 shows where the design is weak: the runner and the detection drafter come from the same vendor.

Summary

The loop's own AI is a team of up to eight narrow functions: scenario curator, emulation planner, emulation runner, observation correlator, detection drafter, finding triager, re-test runner and critic. They serve P2 Emulate (curator, planner, runner), P3 Observe (correlator, triager), P4 Improve (drafter, triager) and P5 Verify (re-test runner), with the critic across all four and the curator reaching to the edge of P1 Target. This is the book's own conclusion from the earlier volumes' foundations: the function is delegated to the level that reversibility, scope, personal data and the independence of the check allow, and the lowest answer governs.

Only the runner and the re-test runner reach Level 3 Bounded in practice, and only for catalogued S1 scenarios inside a signed scope that a policy decision point outside the agent enforces. Everything the agents propose, a scenario, a plan, an outcome, a detection or a priority, is a draft at Level 1 Assisted or an objection at Level 0 Advisory, and a person owns it. 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. Authorisation, the stop, the closure of a finding and the authorship of novelty are not delegated at any level.

A mandate manifest per agent makes these limits code: identity of its own and tokens issued outside the agent, a catalogue binding, a separation list that implements the independence principle, a never list that closes the routes by which an agent could change its own governance, budgets, circuit breakers, and a stop that is drilled. Containment is judged by what the agent can reach whatever instructions it receives, and a team has the additional duty of listing its shared dependencies so that controls that fail together are not counted twice. The practitioner's own use of AI in Modes 1 to 3 is declared in the records and the conductor keeps the skill to reproduce what the agents report.

The conditions the team must meet are testable. A reader can start this week by listing the agents and assistants already present in the loop, naming an owner and a stop holder for each, and finding the first one that has no stop path outside itself. Chapter 15 takes the next step: when AI sits on both sides of a check, what makes a result independent and how that is shown to a supervisor.

Sources

1. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
2. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
3. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). (7, European Union, 2016)
4. MITRE Corporation. MITRE ATLAS. (18, MITRE, n.d.)
5. European Central Bank. TIBER-EU framework. (20, ECB, 2025)
6. OWASP Foundation. OWASP Top 10 for Agentic Applications for 2026. (22, OWASP, 2025)
7. Five Eyes cyber security agencies. Careful adoption of agentic AI services. (54, Five Eyes agencies, 2026)
8. AI Security Institute. Incident Report: unsanctioned agent behaviour during cyber testing. (56, UK AISI, 2026)
9. Blum, Mainor, Nambiar et al. ARTEX and Friends: Enter Agentic Offensive Frameworks. (66, Blum et al., 2026)
10. Lynch, A. et al. Agentic Misalignment: How LLMs could be insider threats. (71, Lynch et al., 2025)
11. OpenAI. OpenAI – Hugging Face Incident Technical Report. (72, OpenAI, 2026)
12. Larcher, H., Carreira, A. et al. Anatomy of a Frontier Lab Agent Intrusion. (73, Larcher et al., 2026)
13. Nordqvist, G. AI Governance. (88, Nordqvist, 2026)
14. Nordqvist, G. AI Platform and Security. (89, Nordqvist, 2026)
15. Nordqvist, G. AI Red Team. (90, Nordqvist, 2026)
16. Nordqvist, G. AI Threat. (91, Nordqvist, 2026)
17. Nordqvist, G. The Transformed Security Architect. (92, Nordqvist, 2026)
18. Bainbridge, L. (1983). Ironies of Automation. (100, Bainbridge, 1983)
19. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation. (101, Parasuraman & Manzey, 2010)
20. Nordqvist, G. AI Blue. (94, Nordqvist, 2026)
21. MITRE Corporation. Caldera: an open-source cybersecurity platform for automated adversary emulation. (37, MITRE, n.d.)
22. Deng, G. et al. (2024). PentestGPT: An LLM-empowered Automatic Penetration Testing Tool. (69, Deng et al., 2024)
23. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)