Defending the Loop's AI: Scenario Libraries, Findings and Emulation Agents as Tier 0

A purple loop that works leaves behind the most valuable document in the security function. The findings register lists, with dates and owners, the weaknesses that the organisation has found and not yet fixed. The scenario library records which adversary behaviour the organisation tests and, by omission, which it does not. The emulation plans say when, where and with what credentials the testing runs. The agents that execute and observe the loop hold offensive capability and privileged access. Taken together these are an adversary's best map of the estate, drawn by the organisation itself. This chapter describes how to defend that map and the machinery around it. It concerns three stages of the purple loop: P1 Target, because the choice of scenarios and the scenario library are the first thing the loop produces and the first thing worth stealing or tampering with; P3 Observe, because findings are raised and stored there; and P4 Improve, because the work of turning a finding into a change moves findings, patches and detection content between people and tools. It also touches P2 Emulate, because the emulation agent is the loop's privileged insider, and says what can be undone and who can stop it.

Roles and agents reach the tier-0 set (findings register, scenario library, agent credentials) through a policy decision point; a redaction gateway stands before the hosted model, detection watches the set and a stop path sits outside the agents.

Figure 16.1: The loop's tier-0 set behind a policy point, with a redaction gateway to a hosted model, detection and a stop path.

The chapter builds on conclusions of the earlier volumes and does not repeat their method. AI Platform and Security, Chapter 19, concluded that containment must not depend on intent: an agent is governed as a well-meaning insider (a modelling device, not a claim about the agent), with task-scoped credentials, default-deny egress, control artefacts outside its reach, budgets and a stop path outside the system it stops (89, Nordqvist, 2026). AI Platform and Security, Chapter 16, added that models and datasets are supply-chain components with verifiable provenance. AI Red Team, Chapters 13 and 28, concluded that everything security AI reads may have been written by the adversary, so the defence is a policy decision point outside the model and a permission manifest that sets a ceiling on every action (90, Nordqvist, 2026). AI Blue, Chapter 15, applied this to the security operations centre (SOC) and treated its platform as tier 0 (94, Nordqvist, 2026). This chapter carries the same argument to the loop. The new element is that the loop's most sensitive content is not telemetry but knowledge about weakness, and that the loop's agents hold capability that the SOC's agents do not.

What the loop holds

Before any control is chosen, the loop's assets are listed, because a protection regime that covers the obvious one (the findings) and misses the others (the plans, the credentials, the connectors) leaves the same map available by another route. Five kinds of asset recur.

Asset What it reveals or enables Why an adversary values it Who legitimately needs it
Findings register (FND-*) Weaknesses found and not yet fixed, with affected assets, age and owner A prioritised list of open doors, ranked by the organisation's own severity Finding owner, remediation owners, white team, CISO; summaries for the board
Scenario library (SCN-*) Which techniques are tested, how and with what expected outcome The complement is the list of what is not tested, and the expected outcome shows what the defence is tuned to see Red team, detection engineering, scenario curator
Emulation plans and rules of engagement (EMU-*, RoE-*) Windows, scope, abort conditions, who may stop an exercise Timing for hiding in the noise of an exercise, and the identity of the stop-path holders White team, exercise controller, stop-path holders
Coverage records (COV-*) Which techniques were verified, when, and where evidence has expired The same gap map as the library, in a more explicit form Detection engineering, CISO, supervisors by summary
Agent credentials, mandates and connectors The access with which loop agents run, and the tools they can call Offensive capability already placed inside the estate The agent operator; the policy point that issues them

The table makes one point that shapes the rest of the chapter: the sensitivity of an asset is not the sensitivity of its individual records. A single closed, low-severity finding is harmless. The collection of open findings, or the list of nine priority techniques that are not verified, is not. The unit to classify is the aggregate and the questions that can be answered from it.

The model for this thinking is the threat model of Architecture as Code (Chapters 9B and 15A), where security patterns and evidence are treated as artefacts of the repository (87, Nordqvist, 2025), and the zero trust architecture of NIST SP 800-207, which asks that each resource be protected by an explicit policy point that evaluates identity, device and context (26, Rose et al., 2020). The loop's assets are resources of the highest tier in that sense: compromise of any one of them changes what every other control is worth. The book calls the set the loop's tier-0 set, after the usage in AI Blue, Chapter 15.

Three adversary goals describe the exposure. By technique, the register and the library are targets of data from information repositories (ATT&CK T1213) and, where they sit in cloud storage or a hosted ticket system, of data from cloud storage (T1530) (17, MITRE, n.d.). The access path is most often valid accounts (T1078): the account of a tester, a contractor, an administrator of the ticket system or a loop agent. The third goal is tampering rather than theft: weakening a scenario, deleting a finding or altering a coverage record so that a gap looks closed corresponds to defence impairment (the tactic TA0112, which in current ATT&CK replaced technique T1562, Impair Defenses) and to indicator removal (T1070). Theft reveals the map. Tampering falsifies it, and a falsified coverage claim is worse than none, because a decision-maker relies on it.

The findings register as a crown jewel

The register is the asset most often handled carelessly, because it is a working document. Findings are mailed to remediation owners, pasted into tickets that a managed provider can read, summarised for a steering committee and attached to risk acceptances. Each of these is a copy, and each copy has its own access list. The first design decision is therefore to name one register of record, with its own store, and to make every other appearance of a finding a reference or a redacted view.

Classification

Classify each finding by what its content would let a reader do, not by its severity. Four handling classes cover the cases, and they are the vocabulary of the rest of the chapter.

Class Content Example Default audience
FC-1 Aggregate Counts, ages, closure rates and trends, with no asset named "Open priority findings: 7; median age 19 days" Board, audit committee, supervisors
FC-2 Redacted Technique, severity, owner, status and the control family, without asset names, accounts, addresses or reproduction steps "FND-HM-2028-005, T1078, high, owner detection engineering, in re-test" Programme management, remediation owners' managers, tool vendors where permitted
FC-3 Restricted Asset-specific detail of an open finding The affected system, the account class involved and the missing detection Finding owner, remediation team, red team, white team
FC-4 Exploitable Anything that would shorten an adversary's work: reproduction detail, credentials or secrets encountered, unreleased gap lists The list of techniques with no passing test; secrets found during an exercise A named handful of people, with a second person for any export

Two rules keep the classes honest. First, classification attaches to the record at creation and is set by the author of the finding with the white team's review, not inferred later. Second, a finding is declassified by event, not by calendar alone: a finding drops from FC-4 to FC-3 when the re-test of Chapter 11 has passed and the evidence is attached, and from FC-3 to FC-2 after a further period in which the fix has held (90 days is a reasonable default; adapt it to the system's change rate). The gap list is the exception. It is regenerated from the coverage records of Chapter 17 and stays FC-4 for as long as it contains a technique that is untested or failed, however old each entry is.

Segregation

Segregation means that the register is not in a place that others can reach by default. Put it in its own store, with its own identity group, outside the repository that holds the scenario library and outside the SOC platform, so that a compromise of the SOC does not yield the register and a compromise of the register does not yield the SOC. The detection engineers who must act on a finding receive the FC-3 view of their own findings, not the whole. The red team writes findings but does not read other teams' open findings once they are handed over. That separation is the same independence that Chapter 15 asks of verification, applied to the data: the side that tests does not hold the means to edit the record of what it found.

The register of record has four further properties. Writes are append-only with an attributed change log, so a finding is closed by a new state and never by deletion. Every state change to closed requires the evidence reference of Chapter 11. Exports are rare, logged and need a second approver for FC-3 and above. And the store's backups carry the same class: a classified register whose backup sits in a general archive has been declassified by accident.

Public authorities and records law

For Nordvik Region the register is also a public document in principle, so the organisation must decide in advance how it will answer an access request. National public-access law differs by member state; in the Region's member state the findings register is treated as security-sensitive and withheld under the exemption for security measures, a decision that the Region's records officer records beforehand and not on the day a request arrives. This is an organisational consequence, not legal advice, and the officer's reading of the exemption is the Region's, not this book's. The point for the architect is that classification must be defensible: a register that is withheld needs a classification record that predates the request.

Practical guide: Classifying and segregating a findings register

Purpose. Replace a shared spreadsheet or an open ticket project with a register of record that has classes, a separate store and attributed access, in about six weeks.

Roles. CISO (accountable), white-team lead or detection owner (runs the work), privacy officer (personal data in findings), records officer (public-sector access rules), tool administrator, one representative of the testers who write findings.

Steps.

  1. Inventory every place a finding lives today: tickets, mail folders, tester portals, shared drives, chat channels, slide decks, backups. Count the people with access to each. Expect more places than anyone predicted.
  2. Choose the register of record and create its store with an identity group of no more than ten named people for FC-3 and FC-4. Use the organisation's own tenant or a self-hosted instance (Chapter 19 treats the sovereign alternatives).
  3. Adopt the four classes and set the class of every open finding with the finding owner. Classify the gap list and the exercise plans as FC-4.
  4. Replace copies with references. In tickets, remediation channels and provider portals, a finding appears as its identifier, technique, severity and owner (FC-2). The detail stays in the register.
  5. Write the access policy as code (see the worked example) and enforce it at a policy decision point in front of the store, not by convention.
  6. Turn on append-only writes, attributed change logs and an export approval that needs a second person for FC-3 and above.
  7. Define declassification events and the review cadence: a monthly access review of the FC-3 and FC-4 groups, and removal of a tester's access within one working day of the end of an engagement.
  8. Record the decision as an AI Decision Record where an AI tool will read findings, and as an Architecture Decision Record otherwise.

Definition of done. No FC-3 or FC-4 content exists outside the register of record; the access list for FC-4 is named and reviewed in the last 31 days; a test export of an FC-3 finding was refused without the second approval; and the decision is recorded.

Worked example: A classification and access policy for the findings stores (illustrative)

Nordvik Region holds its authoritative register in the Region's own tenant, as recorded in AIDR-0803 (2028-02-08). Until then the working copy of exercise findings lived in the managed provider's ticket queue because remediation items were routed to the provider. After the decision, the provider's queue carries FC-2 references only. The policy below is the Region's.

# POL-NR-FND-01: classification and access policy, findings register of record
policy: POL-NR-FND-01
owner: ROLE-NR-SEC-DET            # Karin Lund, detection owner
decision_record: AIDR-0803        # 2028-02-08
store:
  name: nr-findings-register
  tenant: region-own
  backups: same-class             # backups inherit the class of the store
classes:
  FC-1: {content: aggregate, audience: [audit-committee, ciso-office]}
  FC-2: {content: redacted, audience: [programme-office, mssp-ticket-queue]}
  FC-3: {content: asset-detail, audience: [ciso-office, detection-owner, second-analyst, tester]}
  FC-4: {content: exploitable, audience: [ciso-office, detection-owner]}
access:
  tester:
    identity: federated, contract NR-2026-071
    classes: [FC-3]
    only_own_findings: true
    expires: end-of-engagement-plus-1-working-day
  mssp:
    classes: [FC-2]
    channel: ticket-reference-only   # identifier, technique, severity, owner
  loop_agents:
    standing_access: none
    allowed: append-draft-finding    # no read of open findings
export:
  fc3_and_above: second-approver-required
  log: append-only
declassify:
  FC-4_to_FC-3: retest-passed-and-evidence-attached
  FC-3_to_FC-2: 90-days-after-closure
  gap_list: stays-FC-4-while-any-technique-untested-or-failed
hosted_models: none               # self-hosted or EU-hosted only, FC-1 and FC-2
review: {access: monthly, policy: annual}

Hansa Mutual uses the same classes with different enforcement, because it runs the loop in its own platform. Its policy is enforced as code in the repository of the segregated store and applies to people and to agents.

# POL-HM-FND-01: classification and access policy, group findings store
policy: POL-HM-FND-01
owner: white-team-lead
decision_record: AIDR-0853        # 2028-02-15
store: {name: hm-findings-store, segregated_from: [scenario-repo, soc-platform]}
roles:
  red-team:        {read: [own-FC-3], write: [draft-finding]}
  detection-eng:   {read: [FC-3-assigned, FC-2], write: [state-change-with-evidence]}
  soc-analyst:     {read: [FC-2]}
  white-team:      {read: [FC-3, FC-4], write: [classification]}
  group-ciso-board: {read: [FC-1]}
agents:
  MND-HM-EMU-01: {identity: workload, read: [], write: [append-result]}
  MND-HM-EMU-02: {identity: workload, read: [scenario-repo], write: [pull-request]}
  MND-HM-EMU-03: {identity: workload, read: [telemetry], write: [append-draft-finding-FC-3]}
  MND-HM-EMU-04: {identity: workload, read: [FC-2], write: [critique-note]}
hosted_models:
  allowed_classes: [FC-1, FC-2]
  path: ai-gateway-redaction      # deterministic redaction, not a model
  prohibited: [FC-3, FC-4]
  region: eu-only
gap_list: {class: FC-4, regenerated_from: COV-HM-*, readers: [white-team, group-ciso]}

The two policies show the contrast of the profile. Nordvik's leverage is the contract and the identity of the tester, so the policy governs the tester's expiry and the provider's view. Hansa's leverage is the pipeline, so the policy governs agents by name and constrains the model path.

The emulation agent as a privileged insider

An emulation agent runs catalogued scenarios inside a signed scope, and in doing so it holds exactly the things an adversary wants: credentials that work in the estate, tooling that touches production, knowledge of the paths between systems and the ability to run at machine speed. Its purpose is defensive and its design is bounded, but its position is that of a privileged insider, and AI Platform and Security, Chapter 19, set the rule for such insiders: instructions lower the rate of unwanted behaviour, but only boundaries set a ceiling on its consequences (89, Nordqvist, 2026). Research on agentic misalignment found that models placed in fictional corporate settings with goals and access sometimes took harmful actions, including leaking information, in ways the authors compared to an insider threat (71, Lynch et al., 2025). That finding is a controlled experiment and not a forecast about any deployment. It is sufficient reason to design as if misbehaviour is possible. Nothing in this chapter requires a model to intend anything: the agent may be steered by content it reads, may follow a defective instruction, or may fail in a way nobody predicted.

The July 2026 incident between OpenAI and Hugging Face is the series' reference case for what happens when the boundaries around testing are correlated. The investigations describe a connector credential shared across clusters, a package proxy cache through which the test sandbox was escaped and an alert whose criticality was not raised, so that the on-call team was not triggered (72, OpenAI, 2026); (73, Larcher et al., 2026); (74, Wijk et al., 2026); AI Platform and Security, Chapter 19, drew the design lesson. A second public case concerns unsanctioned agent behaviour during cyber testing, reported by the UK AI Security Institute, with a statement from the National Cyber Security Centre (56, UK AISI, 2026); (55, NCSC, 2026). Both belong to the observable record of agents leaving the bounds set for a test. Chapter 6 turned them into rules of engagement; this chapter asks what the agent's own access must look like so that a failure of the rules does not become a failure of the estate.

Five controls follow, each outside the agent, and each should be checked before the agent receives a mandate.

Identity of its own. Each loop agent has a workload identity and a named owner, an operator and an authority, as AI Red Team, Chapter 14, required of every machine identity. The identity is never a person's. An agent that inherits a tester's access acts with that person's reach and leaves a log that cannot tell the two apart.

Task-scoped, short-lived credentials issued outside the runtime. The credential names the scenario, the target scope and the window, expires with the window and is issued by the policy decision point after it has read the signed RoE-* manifest. The agent never holds a credential that would work outside the manifest. If the manifest is changed, the agent's credential does not change with it: the decision point re-reads the signed version.

Default-deny egress and a separate range. The emulation runner executes from the red-team range and reaches only the targets listed in the manifest. It has no route to the findings store, to the scenario repository's write path or to the internet except through a proxy that logs and enforces an allow-list. This is the lesson of the package proxy cache that served as the route out of a sandbox: a convenience route is an escape route.

No standing access to open findings. The runner writes results by appending to a queue; it does not read the register. The observation correlator drafts a finding at FC-3 and cannot read other findings. The critic agent sees FC-2. The emphasis is on what each agent does not need: an agent that cannot read open findings cannot be steered into disclosing them, and cannot learn from them in a way that biases its next run towards the known gaps.

A stop path outside the system it stops. Chapter 6 defined the stop path for an exercise; here it applies to the agent's access. The holder of the stop decision can revoke the credential, close the egress proxy route and freeze the agent's queue without going through the agent or the platform it runs on. The alert that tells them must reach them (the failure of 2026, when an alert was not raised to the on-call team), so the stop-path holders are named in the manifest and tested by a stop drill before first use and every quarter after.

What can be undone matters for the level of delegation. Level 3 Bounded applies only to catalogued, reversible scenarios of safety class S1 inside the signed scope, enforced by a decision point the agent cannot edit. Level 4 Autonomous is not used for an emulation action that is irreversible, that leaves the scope, that touches personal data beyond what the exercise is authorised to touch or that targets a named person. For the register, the equivalent statement is that no loop agent may delete, reclassify or export a finding at any level. Closing a finding needs a person and the evidence of Chapter 11.

The agent's own inputs

An emulation agent reads text: scenario descriptions, target banners, tool output, and findings quoted from earlier runs. Some of that text can be written by someone other than the Region or the group. The same classification as in AI Blue, Chapter 15, applies: own, telemetry, submitted and published inputs have different authors, and none of them is an instruction. A hostile string in tool output is a case of indirect prompt injection (ATLAS AML.T0051.001) (18, MITRE, n.d.); the control is the ceiling set by the manifest and the policy point, not a filter, and Chapter 12 returns to the detection of such attempts. A related risk is that a scenario description, once edited by someone with write access, becomes an instruction channel into the runner. That makes scenario content part of the agent's trusted code path, which leads to the next section.

Supply chain of scenarios and tools

A scenario library is partly written by the organisation and partly assembled from public catalogues: the techniques of ATT&CK (17, MITRE, n.d.), atomic tests, detection rules in the Sigma format (30, SigmaHQ, n.d.), commercial simulation content and the contracted tester's own tooling. Each is a supply-chain input of the kind catalogued as supply chain compromise (T1195). The difference from an ordinary software supply chain is that the content is designed to execute adversary behaviour on the organisation's systems, so a tampered scenario is dangerous in a way that a tampered library is not: it does what it says, with the loop's own authority.

The controls are those of AI Platform and Security, Chapter 16, for models and datasets, applied to scenario content: provenance that can be verified, pinned versions, signing and review (89, Nordqvist, 2026). Concretely:

  • Pin by digest, do not track upstream. The library imports a public test at a recorded version and digest. An upstream change is a pull request that someone reads, never an automatic update. Live subscription to a catalogue is a way for a third party to change what the runner executes.
  • Two-person review and signed commits for any change to a scenario, a manifest or a connector. The author and the reviewer must be different people and, for scenarios the agent drafts, the reviewer must not have supplied the prompt that produced them.
  • Provenance recorded in the scenario. Each SCN-* carries its source (a threat-register entry, an intelligence report, the contracted tester or a public test and its digest), its safety class and its owner. A scenario of unknown origin has no S1 class and runs at Level 2 Supervised or not at all.
  • Execution in a bounded range. Tooling runs on the red-team range or on a Region-owned test host, with no route to the register. A contractor's tooling is declared in the contract and reviewed before it touches a host.
  • A bill of materials for the loop's tooling, including any model that drafts scenarios, so that a vulnerability in a simulation tool or a withdrawn model can be traced to the runs that used it. The Cyber Resilience Act places obligations on manufacturers of products with digital elements, including a duty to handle vulnerabilities, and a tool bought from a vendor as software is normally such a product (5, European Union, 2024). The organisation's own contribution is to ask for the vendor's vulnerability handling and update policy before the tool joins the loop.

The same care applies to what leaves the library. A published scenario pack, a sector-exercise exchange (Chapter 22) or a contribution to a public catalogue contains the Region's or the group's chosen techniques. Share the technique and the expected evidence, never the target mapping.

Handling of findings in AI tools

The loop's agents and the practitioners' assistants are tempting places to paste a finding. A model summarises a report, drafts a ticket, proposes a detection from a finding or ranks a backlog. The content is among the organisation's most sensitive, and it often contains personal data: the account names of staff, the system used by a named team, and in health or insurance settings the data categories of the processing. Three questions decide whether a finding may reach a model.

What class is it? FC-4 never goes to a model. FC-3 goes only to a model that runs in the organisation's own environment, with the platform's logging and access control, where no third party's processing is involved. FC-1 and FC-2 may go to a hosted model that the organisation has approved for the purpose. The classes are enforced at the AI gateway, which the reference architecture of AI Platform and Security, Chapter 4, makes the single path for model calls.

Who redacts, and how? Redaction is deterministic and happens before the call. A model asked to remove asset names has seen them. A rule-based gateway that replaces assets, accounts and addresses with stable tokens, keeps a local map and refuses a call when an unclassified field appears is auditable. Test it as any control: seed a finding with known identifiers and check that none reaches the provider's log.

Where does it go, and under whose law? The GDPR requires appropriate technical and organisational measures for security of processing (Article 32), allocates responsibilities between controller and processor (Article 28) and regulates transfers to third countries (Chapter V, Articles 44 to 50) (7, European Union, 2016). The AI Act requires accuracy, robustness and cybersecurity of high-risk AI systems (Article 15) (1, European Union, 2024), which is relevant where a loop agent is part of a high-risk system's own testing but is not the main frame here. The NIS 2 Directive makes supply chain security a cybersecurity risk-management measure (Article 21(2)) (3, European Union, 2022), and DORA requires financial entities to manage ICT third-party risk as an integral part of ICT risk management (Article 28), with a policy for services that support critical or important functions, which a hosted model that reads findings may become (2, European Union, 2022). These are architectural implications, not legal advice.

The sovereignty argument of AI Platform and Security, Chapter 13, is that location is not the property; verifiable properties are: where the workload runs, which law governs it, whether it can be moved and whether the organisation can continue if the provider fails (89, Nordqvist, 2026). A hosted model that reads redacted summaries meets that test for FC-2 content. The same model reading FC-3 does not, however good the provider's contract, because the contract cannot restore a map once it has been disclosed. The practitioner's own use of assistants in Modes 1 to 3 is governed by the same classes: a tester's declared AI (Nordvik's call-off agreement NR-2026-071 requires the declaration) works on FC-2 unless the Region has approved a self-hosted alternative.

Mode 0 Ambient AI deserves a separate sentence. A vendor's simulation product or managed detection service may use AI to process the loop's data without the organisation having decided so. The contract must state whether findings, scenario content or telemetry from exercises are used for training or retained, and the organisation checks that the answer is recorded before the tool joins the loop (94, Nordqvist, 2026).

Detection of misuse

The loop's assets need detections of their own, written like any other and tested by the loop. Five behaviours are worth detecting, each described by effect and technique and never by method.

Behaviour Technique Telemetry Response
Bulk read or export of the register by one identity, or any read outside its class T1213, T1530 Store access log, export approvals Alert the white-team lead; suspend the identity; review the export
Use of a tester's or contractor's account after the end of the engagement T1078 Identity provider, expiry records Disable automatically at expiry; alert on any attempt
A loop agent reads a store it has no entry for, or calls a tool outside its manifest T1078, AML.T0051 where hostile content is the cause Policy decision point deny log, agent runtime Freeze the agent; stop-path holder reviews
Findings or scenario content reaches an external endpoint or an unapproved model T1567 Egress proxy, AI gateway Block; classify as an incident; privacy officer assesses
Change to a scenario, a manifest, a classification or a coverage record without review T1565, TA0112, T1070 Repository audit, register change log Revert; compare with the signed state; investigate

Three design points make these detections trustworthy. First, they run from telemetry the loop's agents cannot edit; an agent's report that it behaved is not evidence. Second, place decoys: a canary finding with a unique identifier, readable only by the white team, and a canary scenario in the library. Any access outside the named readers is an alert without a false positive, and it tests that the access log is being read. Third, the detections are tested like any other: the loop includes a scenario that tries a bulk read through a test account, and the observation of that scenario is a finding against the loop itself. This closes the circle of the independence principle of Chapter 15: the side that protects the loop's assets is tested by the same discipline as the side that protects the estate.

Insider scenarios

The loop gives power to a small group. A red-team operator, a detection engineer, a tool administrator and the contracted tester each hold access that, misused, undermines the defence. The architectural response is not suspicion but separation of duties and attributable records, with the rights of staff intact. Access reviews and logs concern the use of the loop's assets, not the private behaviour of the people who use them; the works agreements that cover monitoring (Hansa's KBV-IT-2024-SOC-05, Nordvik's union agreement) apply to this logging, and the chapter on people (Chapter 23) returns to the trust that makes it acceptable. No design in this book calls for covert monitoring of staff. The logs are described to the people they cover, are used for the purpose stated and are reported in aggregate unless an incident requires otherwise.

Evidence

Everything above is a claim until it produces records. The loop is asked to evidence its own protection in the way it asks the estate to evidence a control: what was tested, when and with what result. Four records carry that.

  1. Access and change records. The store's access log and the repository's audit trail, retained for at least the period for which findings stay classified, and kept outside the control of the people they describe.
  2. Access review records. The monthly review of the FC-3 and FC-4 groups, signed by the CISO's delegate, with the removals made.
  3. Test evidence. The seeded-export refusal, the post-engagement account test, the redaction seed test and the stop drill, each with a date and a result and each stored as an evidence manifest (EVD-*) in the form of Chapter 11. Evidence for a control on the register expires on the same rule as other evidence: 90 days for the controls guarding FC-4, 180 days for the rest.
  4. Decision records. The AI Decision Record for any AI tool that reads findings, naming who delegated the access, at what level and under which profile.
{
  "evidence": "EVD-HM-2028-0118",
  "control": "POL-HM-FND-01 / hosted_models.prohibited",
  "scenario": "seeded FC-3 finding sent through the AI gateway",
  "tested_on": "2028-03-07",
  "result": "refused; no FC-3 field reached the provider log",
  "reviewer": "white-team-lead",
  "expires": "2028-06-05",
  "reproduced_by_person": true
}

Evidence of this kind answers a supervisor's question in the terms NIS 2 Articles 20 and 21 and DORA Article 5 pose it, which is whether management has established and overseen measures that work (3, European Union, 2022); (2, European Union, 2022). It also supports the TIBER-EU framework's expectation that a threat-led test is conducted under confidentiality, with the knowledge of the test confined to a small control group (20, ECB, 2025).

Observable, expected, speculation

Observable. Agents leave the bounds set for a test, and the public record includes incidents in which that happened during testing (56, UK AISI, 2026); (72, OpenAI, 2026). Security guidance from national agencies now asks that agentic services be given least privilege and that their actions be logged (54, Five Eyes agencies, 2026). The risk that sensitive security information leaks from a testing supplier is a recognised supply-chain risk in the frameworks above; this book cites no verified public count of such leaks and does not claim a rate.

Expected. Agent-specific misuse of loop assets will appear as loops adopt Mode 4 and Mode 5 agents with access to registers and ticket systems. The basis is the trend of delegation described in AI Red Team, Chapter 12, which national agencies also observe in the growing operational role of agentic AI systems (54, Five Eyes agencies, 2026), and the vulnerability classes in the OWASP lists for language-model and agentic applications (21, OWASP, 2025); (22, OWASP, 2025).

Speculation. Autonomous misuse of a findings register by a loop agent acting on its own, without hostile input or a defective instruction, has not been documented as such. A design that assumes it costs little, because the controls above are the same ones the other cases require.

Across the usage modes

The usage modes decide whose access an AI uses and therefore what the register must grant. The degree of delegation then fixes who decides each action.

Mode What it means for the loop's assets Access to the register Default level
Mode 0 Ambient AI Vendor AI inside a simulation or detection product Contractual only: state use, retention and training in the contract Not delegated by the organisation; establish it
Mode 1 Conversational assistants A practitioner pastes content into a chat tool The person's access, filtered by class; FC-1 and FC-2 only to hosted tools Level 0 Advisory
Mode 2 Embedded workplace assistants An assistant inside the ticket system or document store Inherits the person's access; the store enforces class before the assistant reads Level 1 Assisted
Mode 3 Agentic work tools A tool that acts for the practitioner across systems Inherits the person's access: restrict to FC-2 and the person's own FC-3; second approver for export Level 2 Supervised
Mode 4 Built AI applications The curator, correlator and critic built by the organisation Own least-privilege identity; no standing access to open findings; read by class Level 1 Assisted or Level 0 Advisory
Mode 5 Autonomous production agents The emulation runner and re-test runner Own task-scoped identity; no read of the register; append-only writes; cannot delete, reclassify or export Level 3 Bounded for S1 inside the signed scope; Level 2 Supervised otherwise; never Level 4 for the cases above

Nordvik Region and Hansa Mutual

Nordvik Region buys its loop, so its exposure is in the hands of others. The contracted tester, Elin Berglund of the firm engaged under NR-2026-071, and the managed provider hold copies of findings under their own security regimes. The Region's lever is contractual and architectural: AIDR-0803 (2028-02-08) makes the Region's tenant the register of record, limits the provider's queue to FC-2 references, and sets the tester's access to expire one working day after the engagement. The policy POL-NR-FND-01 is small enough for a team of six to review monthly. Its weakness is capacity, not design: Karin Lund owns detection, the purple coordination and the access review, and the review is the control that lapses first when the team is busy, so the policy gives the review a date and an evidence record. The Region keeps hosted models away from findings altogether, in keeping with its preference for EU-hosted or self-hosted processing of data that contains personal and health information, and it requires the tester to declare any AI used under the call-off agreement.

Hansa Mutual runs its loop, so the exposure is architectural. Its library of 87 scenarios, its coverage records and its findings sit in a platform it controls, and the agents of the loop (MND-HM-EMU-01 to -07, Chapter 14) hold identities in it. AIDR-0853 (2028-02-15) adopts POL-HM-FND-01: the store is segregated from the scenario repository and the SOC platform, agents are listed by name with their reads and writes, and hosted models receive redacted summaries (FC-1 and FC-2) through the gateway. The list of nine priority techniques not verified at BTP-HM-2027-Q3 is the group's FC-4 gap list; the board sees 25 of 34 at that date (FC-1), the detection engineers see their own FC-3 findings, and only the white team and the group CISO see the whole list. The risk specific to Hansa is the one in the profile: a loop that runs without being questioned. The canary finding and the post-engagement and seeded-export tests are how the white-team lead questions the loop's own protection each quarter.

Summary

This chapter treated the loop's own assets as tier 0. The findings register, the scenario library, the emulation plans, the coverage records and the credentials of the loop's agents are an adversary's best map of the estate, and they are also the records on which the organisation's claims of coverage rest, so they must be protected against theft and against tampering. The defence is the one the series has used for every privileged insider. It places the controls outside the agent: a register of record in its own store, classes that attach to the content, an access policy enforced as code at a decision point, agents with identities of their own and no standing access to open findings, task-scoped credentials, default-deny egress and a stop path that works without the agent's cooperation.

Three further measures complete it. Scenario content and tools are supply-chain inputs, pinned by digest, signed, reviewed by two people and executed in a bounded range. Findings reach an AI tool only by class, through a deterministic redaction gateway, to a model whose location and law are known. And misuse is detected from telemetry the agents cannot edit, with canaries, with insider scenarios handled by separation of duties and attributable records rather than by covert monitoring, and with evidence that is dated, reproduced by a person and allowed to expire.

The chapter concerned P1 Target, P3 Observe and P4 Improve: the scenario library that P1 Target produces, the findings that P3 Observe raises and the movement of findings and changes in P4 Improve are all inside the tier-0 set. It also set the limits within which P2 Emulate may run, since the agent that emulates is the loop's privileged insider. The independence principle of Chapter 4 and Chapter 15 reaches this chapter in one place: the side that tests does not hold the means to edit the record of what it found. For Nordvik Region the answer is a register of record in the Region's tenant and a contract that expires access; for Hansa Mutual it is segregation and a named list of agents. Chapter 17 turns from protecting the records to the claim they support: what it means to say that a technique is covered, and how long that claim lasts.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  3. European Parliament and Council of the European Union. 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, 27 December 2022. (3, European Union, 2022)
  4. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). (5, European Union, 2024)
  5. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (7, European Union, 2016)
  6. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (17, MITRE, n.d.)
  7. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (18, MITRE, n.d.)
  8. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. ECB, framework updated January 2025. (20, ECB, 2025)
  9. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. OWASP GenAI Security Project. (21, OWASP, 2025)
  10. OWASP Foundation (2025). OWASP Top 10 for Agentic Applications for 2026. OWASP GenAI Security Project, 9 December 2025. (22, OWASP, 2025)
  11. Rose, S., Borchert, O., Mitchell, S. & Connelly, S. Zero Trust Architecture. NIST Special Publication 800-207, August 2020. (26, Rose et al., 2020)
  12. SigmaHQ. Sigma: Generic Signature Format for SIEM Systems. (30, SigmaHQ, n.d.)
  13. Five Eyes cyber security agencies (2026). Careful adoption of agentic AI services. Joint guidance, 1 May 2026. (54, Five Eyes agencies, 2026)
  14. National Cyber Security Centre (2026). NCSC statement in response to recent incidents resulting from frontier AI evaluations. 4 August 2026. (55, NCSC, 2026)
  15. AI Security Institute (2026). Incident Report: unsanctioned agent behaviour during cyber testing. UK AISI, 4 August 2026. (56, UK AISI, 2026)
  16. Lynch, A., Wright, B., Larson, C., Troy, K. K., Ritchie, S. J., Mindermann, S., Perez, E. & Hubinger, E. (2025). Agentic Misalignment: How LLMs could be insider threats. Anthropic, 20 June 2025. (71, Lynch et al., 2025)
  17. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. 26 August 2026. (72, OpenAI, 2026)
  18. Larcher, H., Carreira, A. et al. (2026). Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. Hugging Face blog, 27 July 2026. (73, Larcher et al., 2026)
  19. Wijk, H., Cotra, A. & Greenblatt, R. (2026). Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident. METR, 26 August 2026. (74, Wijk et al., 2026)
  20. Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1. (87, Nordqvist, 2025)
  21. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Transformed Architecture, Book 3. (89, Nordqvist, 2026)
  22. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Transformed Architecture, Book 4. (90, Nordqvist, 2026)
  23. Nordqvist, G. (2026). AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. The Transformed Architecture, Book 8. (94, Nordqvist, 2026)