AI Red Teaming and Emulation Tools
A practitioner who has to test a defence, or an AI system, on purpose needs a small number of tools before anything else: a signed statement of what may be done and who may stop it, a plan that says what will be done and what the defence is expected to do about it, a way to execute the plan safely, and a record in which the result can be read by the people who must change something. This chapter collects those tools. It serves the activity of authorised testing: adversary emulation against an organisation's defences, and AI red teaming of the organisation's own AI systems. Both are defensive in purpose. Every activity described here is authorised, scoped by written rules of engagement, run against the organisation's own or contracted systems and ends in a defensive improvement; the chapter gives no attack tooling, exploit code, payloads or test inputs, and the tools it describes contain none.
The chapter treats all four kinds of tool. The artefacts are the rules-of-engagement manifest, the emulation plan, the campaign plan, the pipeline definition and the finding record. The methods are the practical guides of AI Red Team and AI Purple for preparing a safe run, running a campaign and keeping a continuous pipeline, together with the seven-class outcome taxonomy. The third-party tools and standards are the threat-led testing framework TIBER-EU, the two open emulation libraries Atomic Red Team and MITRE Caldera, the class of breach-and-attack simulation products and the published testing rules of three cloud providers. The own tools of the series in this field are artefacts, not software: the repositories ship no emulation engine, and the chapter says so where it matters. The tools come mainly from AI Red Team (Chapters 7, 12 and 13, and Appendix A) (4, Nordqvist, 2026) and AI Purple (Chapters 6 to 9 and Appendix A) (9, Nordqvist, 2026), with smaller contributions from AI Platform and Security (3, Nordqvist, 2026), The Transformed Security Architect (6, Nordqvist, 2026) and AI Blue (8, Nordqvist, 2026).
Figure 11.1 shows the order in which the tools are used. The rules of engagement come first and the white team's signature opens the window; the plan binds each step to the rules; execution passes through a policy decision point that sits outside the executor; and the result leaves as a finding that ends in a defensive change and, in Chapter 14, a regression case.
Figure 11.1: An authorised test from scope to finding. The stop path and the policy decision point sit outside the system that executes the test.
Rules of engagement
Every other tool in this chapter depends on this one. A test that touches production systems, uses AI to execute steps, or involves people who did not agree to it is lawful and safe only because something written, signed and enforceable says what may happen. AI Red Team, Chapter 7, treats the rules of engagement as a signed, versioned artefact rather than a letter (4, Nordqvist, 2026); AI Purple, Chapter 6, makes the same manifest machine-readable and enforced by a policy decision point outside the agent (9, Nordqvist, 2026). Three tools belong to the family: the manifest itself, the framework that prescribes the roles around it, and the providers' published rules for testing what runs in their clouds.
Rules-of-engagement manifest
| Kind | Artefact |
| Origin | AI Red Team, Chapter 7 and Appendix A (07_CODE_ROE); AI Purple, Chapter 6 and Appendix A (RoE-NR-2027-001) |
| Purpose | A signed, versioned manifest of scope, window, permitted tactics or scenarios, AI participation, stop conditions and stop path for an exercise |
| Use when | Before any exercise, pipeline or chaos experiment that touches a system, uses AI to plan or execute steps, or involves staff; again at every change of scope |
| Inputs | Scenario records, the data-protection assessment, consent and notice records, third-party agreements, the decision-rights table of the white team |
| Outputs | The manifest, its approvals, the decision log of the policy decision point, the evidence retained for the findings |
| Identifier family | RoE-NR-*, RoE-HM-* (for example RoE-HM-2027-TLPT, RoE-HM-2027-PURPLE) |
| Full template | AI Red Team, Appendix A, 07_CODE_ROE (the earlier, shorter form); AI Purple, Appendix A, "Rules-of-engagement manifest RoE-NR-2027-001" (version 1.2.0, quoted below) |
The manifest answers six questions. Who approved it, and on what date. Which systems are in scope, which are out of scope and which tactics are prohibited. Which scenarios may run and in which safety class. Whether AI takes part, with which models and under which logging. Which third parties were told what. And, last and most important, which conditions stop the test, who holds the stop and by what channel. AI Purple adds two things to the shorter manifest of AI Red Team: a division of scenarios into safety classes with a reversal method each, and an enforcement block that names a policy decision point outside the test host, failing closed. The second addition is the one that matters for AI: a rule that only the red team reads is a promise, whereas a rule that a deterministic component evaluates before each action is a control.
The version quoted here is the one in AI Purple, Appendix A, version 1.2.0 of the Nordvik Region manifest for the spring 2027 window. The book marks it illustrative; the identifiers are the book's own.
kind: RulesOfEngagement
id: RoE-NR-2027-001
version: 1.2.0
supersedes: 1.1.0
approvedBy:
- {role: chief-information-security-officer, date: 2027-03-04}
- {role: head-of-benefits-unit, date: 2027-03-04}
- {role: data-protection-officer, date: 2027-03-04}
- {role: white-team-lead, date: 2027-03-03}
window:
start: 2027-03-08T07:00:00+01:00
fieldwork: {start: 2027-03-15, end: 2027-04-02}
end: 2027-04-02T18:00:00+02:00
blackout: [month-end-benefit-payment-run]
parties:
whiteTeam: [ciso, duty-security-officer, contracted-test-lead]
redTeam: contracted-tester # NR-2026-071
blueTeam: nordvik-security-analysts-and-mssp
scope:
inScope: [citizen-service-assistant, benefits-explanations-service, staff-identity-provider-test-tenant]
outOfScope: [benefits-triage-production-scoring, third-party-systems, personal-data-exfiltration]
prohibitedTactics: [TA0040] # Impact
scenarios:
- {id: SCN-NR-0001, techniques: [T1110.003, T1078], class: S2, target: staff-identity-provider-test-tenant}
- {id: SCN-NR-0002, techniques: [T1087], class: S1, target: staff-identity-provider-test-tenant}
- {id: SCN-NR-0005, techniques: [T1190], class: S3, target: preprod-benefits-explanations-mirror}
classes:
S1: {production: true, maxLevel: 2, reversal: tag-and-expire}
S2: {production: true, maxLevel: 2, reversal: lockout-safe, rateLimitPerHour: 20}
S3: {production: false, maxLevel: 2, reversal: restore-snapshot}
aiParticipation:
models: [self-hosted-open-weight] # no external model receives Nordvik data
egress: allowlist-range-only
logging: full-transcript-to-white-team
thirdParties:
- {party: mssp, basis: NR-2025-044-MS-1, informed: window-and-stop-path, not-informed: timing}
- {party: nordic-hosting-provider, basis: notice-given-2027-03-01, testsProviderInfrastructure: false}
dataProtection:
legalBasis: gdpr-art-6-1-e-public-task
classification: confidential-security-exempt-from-disclosure
accounts: synthetic-only
onRealPersonalData: [stop, secure, report-to-dpo]
stopConditions: [unplanned-service-degradation, access-to-real-personal-data, ai-action-outside-approved-plan, any-white-team-member-request]
stopPath:
holders: [ciso, duty-security-officer, contracted-test-lead, mssp-shift-lead]
channel: out-of-band-phone-bridge
haltWithinMinutes: 5
revoke: [tester-credentials, test-tenant-accounts, egress-allowlist]
enforcement:
pdp: policy-engine-outside-test-host
failMode: deny
decisionLog: white-team-store
evidence:
retentionMonths: 60
findingsTo: purple-session-2027-q2
Two cautions follow from the series itself. First, the same identifier, RoE-NR-2027-001, names the shorter manifest in AI Red Team (window 8 March to 2 April 2027, permitted tactics listed by name) and the longer one in AI Purple; the second book states that it extends the first, and the version number is the way to tell them apart. Second, the manifest is only as good as the stop path it names. AI Red Team, Chapter 12, draws the lesson of the July 2026 agent incident for emulation programmes: a credential shared across workloads, a mirror that was also an egress path and an alert that reached people without the stop decision are the three failures to design out, by exercise-specific identities, no shared supporting services and a stop path that goes to the white team (4, Nordqvist, 2026).
Threat-led testing (DORA TLPT and TIBER-EU)
| Kind | Method |
| Origin | AI Red Team, Chapters 7 and 12 |
| Purpose | Threat-intelligence-based red teaming run by a white team, under the TIBER-EU framework |
| Use when | An entity must or chooses to test its critical functions against realistic adversaries on live production systems |
| Inputs | Targeted threat intelligence, the scope agreed with the authority, the rules of engagement |
| Outputs | A test report, a replay of the test by red and blue, a remediation plan |
TIBER-EU, the European Central Bank's framework, structures a test in three phases. A preparation phase agrees scope and procures providers; a testing phase turns targeted threat intelligence into scenarios executed against live production systems; a closure phase has red and blue teams replay the test and the entity produce a remediation plan (76, ECB, 2025). The roles that matter to the tools are the white team (the framework itself calls it the control team), a small group that knows about the test and may order a halt of it, and the blue team, which is not informed in advance. AI Red Team, Chapter 7, says that the policy should define the white team's composition, decision rights and availability, and identifies four places where AI enters a threat-led test and needs an explicit decision in the rules of engagement: threat intelligence (the entity's information must not reach an unapproved model), scenario design, red-team tooling and the entity's own AI systems as the target (4, Nordqvist, 2026). The chapter on cross-border testing in AI Purple adds that Regulation (EU) 2022/2554 (DORA) allows pooled testing under Article 26(4) and lists, among the contract provisions for critical or important functions, the provider's obligation to cooperate in the entity's threat-led test (Article 30(3)(d)) (9, Nordqvist, 2026) (197, European Union, 2022). As architectural implications, not legal advice: the right to test is a contract requirement to be placed before the provider is chosen.
TIBER-EU
| Kind | Third-party tool (framework) |
| Origin | AI Red Team, Chapters 1, 2, 6, 7, 12, 25, 26 and 27; AI Purple, Chapters 2, 7, 20 and 21; AI Operations, Chapters 19 and 24 (mentioned in passing) |
| Purpose | The ECB framework for threat-intelligence-based ethical red teaming, including purple teaming and procurement guidance |
| Use when | Organising or procuring a threat-led test, or defining the roles of a white team |
| Inputs and outputs | As the framework defines; the series claims nothing about its detailed requirements beyond the phases and roles above |
The framework is a standard, not software. The series uses it for three things: the division into white (in the framework, control), red and blue teams; the idea that the blue team learns of the test only at the end; and, in the TIBER-EU Purple Teaming Guidance, the practice of purple teaming, in which red and blue work together (77, ECB, 2025). The framework's own text governs; the series does not restate its procedures. Three inventory entries (one in AI Red Team, two in AI Purple and AI Operations) describe the same framework and are treated here as one entry; Appendix A lists all three.
Provider penetration-testing rules
| Kind | Third-party tool (published rules) |
| Origin | AI Purple, Chapter 22 |
| Purpose | The published rules under which customers may test what they run in the Microsoft, Amazon Web Services and Google Cloud environments |
| Use when | Planning any test that touches resources in a public cloud; re-read before every window |
The three pages differ and change. As AI Purple, Chapter 22, read them on 10 November 2026: Microsoft requires no pre-approval and applies its published rules of engagement (211, Microsoft, 2026); Amazon Web Services needs a Simulated Events form for covert red, blue and purple team simulations and other simulated events (212, AWS, 2026); Google Cloud asks that the test affect only the customer's own projects and follow its acceptable use policy (213, Google Cloud, n.d.). A reference that restates them would be out of date at once, so the chapter keeps only the practice: record the date on which each page was read and re-read it before the window opens. Shared responsibility decides what a test can claim; "the Region's tenant configuration, tested on a date" is a statement a test can evidence, "the cloud is covered" is not.
Emulation plans
An emulation plan turns a signed set of rules into a sequence of steps. The two books give two forms. The plan of AI Red Team is the technical design of a threat-led exercise with AI in the loop; the plan of AI Purple is the record that feeds the loop's observation stage, with the expected outcome of every layer written in advance.
Emulation plan (ATT&CK-mapped)
| Kind | Artefact |
| Origin | AI Red Team, Chapter 12 |
| Purpose | A plan for an AI-assisted adversary emulation with ATT&CK mapping, safeguards and stop conditions |
| Use when | An emulation step is executed or planned by AI, or the plan has to prove that no step exceeds the permission manifest |
| Inputs | The signed manifest, an adversary profile from threat intelligence, the expected detections and controls |
| Outputs | An approved, versioned plan; the tamper-evident log outside the red range; findings |
| Identifier family | HM-TLPT-* (the example); the plan names the manifest it is bound to |
| Full template | AI Red Team, Chapter 12 (quoted below, steps abbreviated) |
Each step names a technique in MITRE ATT&CK (67, MITRE, n.d.), an executor (operator or AI agent), an autonomy level and the detection or control it expects. The safeguards block binds any AI executor to a permission manifest, a maximum number of actions and runtime, and a prohibition on writing to targets; credentials are issued by the white team with a short lifetime and one-action revocation. The example below is one scenario of Hansa Mutual's threat-led exercise.
# Illustrative: Hansa Mutual, one scenario of RoE-HM-2027-TLPT (extract)
kind: EmulationPlan
id: HM-TLPT-2027-S2
rulesOfEngagement: RoE-HM-2027-TLPT
adversaryProfile: TI-HM-2027-04
flag: read-access-to-claims-payment-queue
tempo: machine-speed # agreed in advance with the white team
steps:
- {id: S2-1, attack: T1078, executor: operator, autonomyLevel: 1,
start: white-team-test-account, expect: {detection: DET-ID-031}}
- {id: S2-2, attack: T1087, executor: ai-agent, autonomyLevel: 2,
expect: {detection: DET-AD-012, withinMinutes: 10}}
- {id: S2-3, attack: T1069, executor: ai-agent, autonomyLevel: 2,
expect: {detection: DET-AD-014, withinMinutes: 10}}
- {id: S2-6, attack: T1567, executor: operator, autonomyLevel: 1,
data: canary-records-only, expect: {control: CTRL-DLP-003}}
safeguards:
aiAgent: {mode: 5, permissionManifest: PM-RT-2027-02, maxActions: 400,
maxRuntimeMinutes: 90, mayWriteToTargets: false}
credentials: {issuedBy: white-team, ttlHours: 8, revocation: one-action}
egress: {default: deny, allow: [rt-c2-endpoint-approved]}
sharedServicesWithOtherRanges: none
stopConditions:
- production-service-health-below-threshold
- out-of-scope-asset-touched
- real-incident-declared
- ai-action-outside-permission-manifest
stopPath:
holders: [white-team-lead, white-team-deputy]
mechanism: out-of-band-credential-and-egress-revocation
logging: {tamperEvident: true, location: outside-red-range}
The book reports what the plan found: steps S2-2 and S2-3 completed in under a minute and DET-AD-012 fired, but the alert was queued at medium severity and triaged after 47 minutes. The detection was not missing; its severity assumed a human tempo. The closing control raised the severity for high-rate directory enumeration from a single identity and was verified by replaying both steps until the alert reached triage within ten minutes (4, Nordqvist, 2026).
Emulation plan (EMU-*)
| Kind | Artefact (with the method "Emulation plan giving ground truth without the plan") |
| Origin | AI Purple, Chapters 7 and 8, Appendix A ("Emulation plan EMU-NR-2027-02", "Emulation plan EMU-HM-2027-02") and Appendix B.5 |
| Purpose | Sequences scenarios into a campaign with scope, window and abort conditions, so that the observation stage can compare every layer of the defence with an expectation |
| Use when | Planning a campaign or catalogue run whose blue team does not know the plan |
| Inputs | Three to eight scenario records, the manifest's scope by reference, the expected outcome per layer copied from each scenario |
| Outputs | A signed plan; ground truth held where only those who know can read it; a tag scheme; the hand-over to the purple session record |
| Identifier family | EMU-* |
| Full template | AI Purple, Appendix A (two worked examples; not repeated here) |
The practical guide of AI Purple, Chapter 7, is worth following in order. Select three to eight scenarios from the library by the priority list. Copy the expectation per layer from each scenario without rewriting it. Add one scenario written by a person and shown to no assistant, and one variant of a known scenario, because the first tests novelty and the second tests overfitting. Bind targets by reference to the manifest, never by a new list. Write abort conditions that someone other than the testers can measure. Name two stop-path holders outside the red team and drill the stop before the window opens. Check that the exercise tag survives the telemetry pipeline on a harmless action. Decide who knows, and have the white-team lead sign: the signature, not the red team's own approval, opens the window (9, Nordqvist, 2026). The Nordvik plan EMU-NR-2027-02 records that no Mode 5 agent runs against Nordvik systems; the Hansa plan EMU-HM-2027-02 names the planner and runner mandates. Both identifiers are illustrative.
Preparing a safe AI-assisted emulation run
| Kind | Method |
| Origin | AI Red Team, Chapter 12 (Practical guide) |
| Purpose | Prepare a run in which AI assists or executes steps so that it tests what it should and cannot exceed its mandate |
| Use when | Any AI component executes emulation steps |
| Inputs | The signed manifest and bound plan, a permission manifest for each executing AI component |
| Outputs | Credentials with a lifetime no longer than the window, a tested stop path, honeytokens and canary records, a log outside the red range |
Seven steps: confirm that the manifest names the AI tools and where each runs; bind the plan to the manifest; classify every executing AI component as Mode 5 with a permission manifest; have the white team issue exercise credentials (by default eight hours) and test one-action revocation; verify that the range shares no supporting service and egress is denied except for named routes; test the stop path end to end at the hours of the run, including the out-of-hours holder; and plant canary records so that no real personal data is touched. The defaults are a few hundred actions and 90 minutes per AI-executed scenario, Level 2 Supervised for read-only steps in production and Level 1 Assisted for anything that changes state (4, Nordqvist, 2026).
Continuous emulation
A campaign tests a defence once; the estate changes daily. AI Red Team, Chapter 12, and AI Purple, Chapter 8, therefore treat emulation as a pipeline with triggers, a cadence and variation. The family has two artefacts, three methods and three third-party tools.
Continuous emulation pipeline definition
| Kind | Artefact |
| Origin | AI Purple, Chapter 8, Appendix A ("Pipeline definition for HM-SEC-004") and Appendix B.6 |
| Purpose | Defines triggers, gates, variation, tagging and the abort path for continuous emulation |
| Use when | Catalogued, benign scenarios run without a campaign around them |
| Inputs | The signed manifest, the scenario library, the mandate of the emulation runner, the consent register |
| Outputs | Tagged runs, results joined to detections, evidence with an expiry |
| Identifier family | HM-SEC-004 (the pipeline), MND-HM-EMU-* (its mandates), AIDR-0314 (its decision record) |
| Full template | AI Purple, Appendix A |
In the template, delegation is explicit: safety class S1 inside scope at Level 3 Bounded, anything above S1 at Level 2 Supervised, Level 4 never. Triggers come in three kinds: change (a merged detection, a changed connector or mandate, a provider's model notice, within 24 hours), schedule (priority techniques at most 30 days old) and intelligence (a named intake with a deadline). Gates include a policy decision point and a consent register, and hold-back rules suspend the pipeline during a change freeze, a major incident or provider maintenance. The variation block fixes a held-out share of scenarios; the pipeline default there is a quarter, while the library default stated in AI Purple, Chapter 15, is 15 per cent and at least eight scenarios, a difference the book notes in the template itself (9, Nordqvist, 2026).
Continuous emulation schedule and variation policy
| Kind | Artefact (with the methods "Continuous emulation trigger and cadence choice" and "Continuous emulation with variation") |
| Origin | AI Purple, Chapter 8 (Practical guide) and Appendix B.6 |
| Purpose | Sets what runs, where, when and with what variation |
| Use when | Choosing cadence for a pipeline, or reviewing it every six months |
| Full template | Not given; Appendix B describes it and the chapter's practical guide illustrates part of it |
The practical guide sets the schedule trigger at one third of the evidence expiry for priority techniques (30 days for a 90-day expiry) and one half for the rest, attaches a change trigger to every detection, connector and mandate, caps the volume of generated alerts at a quarter of the alert budget, logs every hold-back with the technique's evidence age, and drills the stop path quarterly against a default target of two minutes. Variation exists to prevent overfitting: AI Purple names signature fitting, in which a rule matches the exact artefacts of the public form of an atomic test, as the first example (9, Nordqvist, 2026).
Atomic Red Team
| Kind | Third-party tool (open-source library) |
| Origin | AI Purple, Chapters 1, 2, 8 and 19 |
| Purpose | An open library of small tests mapped to ATT&CK techniques; the basis of the Nordvik atomic-test subset |
| Use when | A narrow question is enough: does this telemetry source record this behaviour, and does this detection fire |
Atomic Red Team is open-source software maintained by Red Canary and published under the MIT licence (207, Red Canary, n.d.). The series uses it for single-technique, reproducible tests that an organisation can read in full before they run and pin by revision. The same openness is its limit: defenders and adversaries read the same catalogue, so a detection tuned only to the public form of a test proves little. Nordvik Region's plan EMU-NR-2028-01 (illustrative) runs a human-run subset with the catalogue revision pinned at signature.
MITRE Caldera
| Kind | Third-party tool (open-source platform) |
| Origin | AI Purple, Chapters 1, 2, 8 and 19 |
| Purpose | An open-source platform that automates adversary emulation, built on ATT&CK |
| Use when | A planned, chained emulation is needed and a deterministic executor can run catalogued abilities inside a signed scope |
MITRE describes Caldera as a platform for automating adversary emulation, assisting manual red teams and automating incident response, released as open source under the Apache-2.0 licence; the repository's links now point to the Apache Software Foundation's Apache Caldera project, to which MITRE contributed the open-source core (208, MITRE, n.d.). The series claims no more than that, and what it adds is a design position: a planner that proposes and a runner that executes catalogued abilities carry different risks, and the planner is kept away from estate credentials.
Breach-and-attack simulation (BAS)
| Kind | Third-party tool (class of commercial products) |
| Origin | AI Purple, Chapter 2 |
| Purpose | Software that runs a catalogue of emulated attack behaviours on a schedule |
| Use when | A control must be re-tested more often than the estate changes, and a person is ready to turn each failure into a change |
A practitioner explainer describes BAS as an "automated and continuous software-based approach to offensive security" that is "not intended to replace" other protocols (210, Schneider, 2024). AI Purple draws the limit: BAS shows that a control blocked or detected a catalogued behaviour on a tested path; it does not show that anyone triaged and acted, nor that untested behaviours are covered (9, Nordqvist, 2026). No product is named or endorsed.
Testing AI systems
AI red teaming, as AI Red Team, Chapter 13, defines it, is the practice of adversarially testing AI systems under authorisation and written rules of engagement, ending in a defensive improvement. The tools differ from emulation in what they are mapped to: the OWASP Top 10 for LLM Applications (70, OWASP, 2025) and MITRE ATLAS (68, MITRE, n.d.) take the place of ATT&CK. The test inputs are adversarial by nature, and so the series keeps them out of its text: plans carry no test inputs, and scenario libraries record outcomes, not the content that produced them.
AI red-team campaign plan
| Kind | Artefact |
| Origin | AI Red Team, Chapter 13 |
| Purpose | A campaign plan for an AI system mapped to OWASP and ATLAS categories |
| Use when | Before a time-boxed campaign against a copy of an AI system |
| Inputs | The system's six elements in scope, an inventory of who can place content in each retrieval source, the risk register entries |
| Outputs | A findings register, scenario cases for the library, an evidence bundle |
| Identifier family | NR-SEC-*-C* |
| Full template | AI Red Team, Chapter 13 (quoted below) |
Nordvik Region's first campaign under NR-SEC-002 runs against a copy of the citizen-service assistant in a separated test range with synthetic data. Each objective states a property that must hold, tags it to the taxonomies and the risk entry, and lists what is not applicable and why.
# Illustrative: Nordvik Region, campaign plan for NR-SEC-002, wave 1 (extract)
kind: AIRedTeamCampaignPlan
id: NR-SEC-002-C01
decision_record: AIDR-0302
rules_of_engagement: RoE-NR-2027-003
system: citizen-service-assistant
target:
environment: test-range-copy
prompt_template: citizen-service/v7
data: synthetic-only
out_of_scope: [production, real-resident-accounts, provider-infrastructure]
objectives:
- id: OBJ-01
statement: Instructions placed in retrievable content do not change the assistant's task
owasp_llm: LLM01 Prompt Injection
atlas: AML.T0051
risk_entry: NR-RISK-AI-014
- id: OBJ-03
statement: Content added to the index outside the publishing workflow is not retrievable
owasp_llm: LLM08 Vector and Embedding Weaknesses
atlas: AML.T0070
risk_entry: NR-RISK-AI-016
- id: OBJ-04
statement: Answers about benefits cite a published source or state that none exists
nist_ai_600_1: Confabulation
not_applicable:
- owasp_llm: LLM06 Excessive Agency
reason: The assistant has no tools that change state
deliverables: [findings-register, scenario-cases-to-library, evidence-bundle]
The significant finding fell under OBJ-03: a page withdrawn from the public website was still in the retrieval index, because withdrawal did not trigger re-indexing, and the assistant cited it as current guidance. The closing control made withdrawal remove the document from the index within one hour, and the finding closed only when a new suite case confirmed this against the next release (4, Nordqvist, 2026).
Running a red-team campaign on a retrieval-augmented assistant
| Kind | Method |
| Origin | AI Red Team, Chapter 13 (Practical guide) |
| Purpose | Run an AI red-team campaign from taxonomy to gating suite |
| Use when | A retrieval-augmented assistant is to be tested before or after a significant change |
Six steps: scope the six elements under rules of engagement limited to a copy with synthetic data; inventory who can place content in each retrieval source; build the plan from the OWASP list with ATLAS tags and risk entries; prepare a synthetic corpus with canary documents; run time-boxed rounds (by default two weeks of testing and one of triage, critical findings reported within one working day); and convert each finding into library cases that fail against the unfixed and pass against the fixed configuration. The defaults are five runs per case, zero tolerance for cross-user and system-prompt disclosure, and at most two per cent unsupported answers where other controls bound the harm. The result is a gate that runs on every change that can alter behaviour. The reasoning for continuous suites comes from AI Platform and Security, Chapters 17 and 20, which concluded that the external exercise is for discovery and every finding becomes a versioned case run in the pipeline (see the method "Red teaming and continuous security testing" below) (3, Nordqvist, 2026). Continuous suites do not replace the threat-led testing that DORA provides for financial entities (197, European Union, 2022).
Red teaming the SOC's AI
| Kind | Method |
| Origin | AI Blue, Chapter 15 |
| Purpose | Authorised campaigns that test the ceiling of the security operations centre's AI agents |
| Use when | A security agent reads content an adversary could have written, and holds the authority to act |
| Outputs | A scenario library in version control, exercise findings in the finding register, re-tests |
| Identifier family | RoE-HM-2027-SOC-01, FND-HM-2027-014 (the examples) |
The SOC's AI sits in the detection and response path, so the exercise must not blind the SOC or leave a live action armed. The rules of engagement therefore state which actions are simulated and not executed, the stop condition and the person who holds the abort. The library is organised by technique and trust class, not by wording. AI Blue reports one illustrative finding: the policy decision point denied an out-of-scope isolation request, so the action control held, but a case note written by the triage agent repeated part of the planted text and the investigation agent read the note as trusted (8, Nordqvist, 2026). A control that depends on a model's cooperation is reclassified from verified to declared until a fix is tested.
Other methods in the family
| Method | Origin | One-line purpose |
|---|---|---|
| Red teaming and continuous security testing | AI Platform and Security, Chapters 17 and 20 | Convert findings into automated tests that run in CI, including weekly to catch drift in a third-party model |
| Second agent as adversary | The Transformed Security Architect, Chapter 14 | Use a second agent to challenge a proposal without trusting either: the critic lists objections and never approves, reads the diff before the rationale, runs on a different model family where one exists, and a human disposes of each objection |
The second row is a review technique, not an emulation tool, and sits here because the inventory assigned it to the family; Chapter 14 returns to it among the independence controls.
Reading and reporting results
Emulation finding record
| Kind | Artefact |
| Origin | AI Red Team, Chapter 12 |
| Purpose | A structured finding from an emulation run that the blue team can use |
| Use when | An emulated step ends below its expectation |
| Inputs | The plan step, the expectation, the observation, the control or detection identifiers |
| Outputs | A finding with a closing action and a re-test |
| Identifier family | FND-* |
| Full template | AI Red Team, Chapter 12 (JSON, quoted below) |
{
"kind": "EmulationFinding",
"id": "FND-NR-2027-001-04",
"rulesOfEngagement": "RoE-NR-2027-001",
"planStep": "S1-3",
"attack": {"technique": "T1078", "name": "Valid Accounts"},
"system": "citizen-service-assistant-admin-console",
"expected": {"detection": "Sign-in to admin console from unmanaged device", "withinMinutes": 15},
"observed": {"detection": "none", "window": "out-of-hours",
"note": "MSSP rule set did not include the console's identity logs"},
"control": "CTRL-NR-MON-011",
"severity": "high",
"classification": "restricted",
"closingAction": {"type": "detection", "implementedBy": "MSSP under NR-2025-044"},
"retest": {"method": "replay planStep S1-3 out of hours", "status": "passed", "observedWithinMinutes": 9},
"csf": ["ID.IM-02", "DE.CM"]
}
The step reached its target undetected because the console's identity logs had never been sent to the SIEM; the closing control was a log-forwarding change and a detection rule, and the finding closed only when the replayed step raised an alert that the managed provider's shift lead handled in time. Watch the identifier: FND-* names this JSON record in AI Red Team, Chapter 12, and a YAML finding record in Chapter 26 of the same book, and Chapter 14 returns to the second.
Outcome taxonomy
| Kind | Method |
| Origin | AI Purple, Chapter 9 |
| Purpose | A seven-class classification of what happened to each emulated step |
| Use when | Comparing an emulation with the expectation written before it |
Each step ends in exactly one outcome, the last layer at which the defence did what the expectation said: prevented, detected, alerted but not triaged, triaged but not acted on, missed, no telemetry, not tested. Three rules keep it usable: the outcomes are mutually exclusive and ordered by layer; "detected" demands the whole chain, so an alert closed by automation without a qualified decision is "alerted but not triaged"; and "not tested" is an outcome, not an absence (9, Nordqvist, 2026). The taxonomy is the vocabulary of the purple session record in Chapter 14.
Across the usage modes
The red team uses Modes 1 to 3 for planning and tooling under its own accountability; AI that executes emulation steps is treated as Mode 5. The autonomy level is set per step in the plan, as AI Red Team, Chapter 12, defines it, and Level 4 Autonomous is not used for any emulation action that is irreversible, leaves the signed scope, touches personal data beyond what the exercise may touch or targets a named person (4, Nordqvist, 2026) (9, Nordqvist, 2026).
| Mode | How the tools differ | Limit |
|---|---|---|
| Mode 0 Ambient AI | Tested products contain vendor AI whose real behaviour an exercise reveals | Handle by contract terms; no control by the tester |
| Mode 1 Conversational assistants | Faster intelligence extraction and report drafting | Scope and findings are not pasted into unapproved tools |
| Mode 2 Embedded workplace assistants | Summaries of findings for stakeholders | A summary is never the record |
| Mode 3 Agentic work tools | Tooling built quickly in an isolated range | An agent with an engineer's credentials sits between instruction and review |
| Mode 4 Built AI applications | Planner and evaluator for continuous validation; scenario curator | Read-only service identity; Level 1 to 2; a person signs |
| Mode 5 Autonomous production agents | Executes catalogued scenarios at an adversary's tempo | Permission manifest, exercise-specific identity, stop path held by the white team; Level 3 only for benign, reversible, tagged S1 scenarios |
Nordvik Region and Hansa Mutual
Nordvik Region buys testing. A contracted tester (call-off NR-2026-071) runs its campaigns under RoE-NR-2027-001; the stop-path holders include the managed provider's out-of-hours shift lead; and the plan EMU-NR-2027-02 states that no Mode 5 agent runs against Nordvik systems. Its AI red-team campaign NR-SEC-002-C01 runs against a copy of the citizen-service assistant with synthetic data.
Hansa Mutual runs testing. A group red team of five, led by the head of the group red team, runs a threat-led exercise under RoE-HM-2027-TLPT, with AI executors classified as Mode 5, and its continuous pipeline HM-SEC-004 runs benign S1 scenarios at Level 3 Bounded under mandate MND-HM-EMU-01. Its stop-path target for the runner is 60 seconds, against a generic default of 120. The difference lies in who holds the tools, not in the discipline: both sign a manifest before anything runs, and both keep the stop path outside the executor.
Treatment of the slice
All 25 inventory entries of the slice are accounted for. Seventeen ### entries treat 23 of them, because the two rules-of-engagement manifests are one entry, the three TIBER-EU entries are one, and the ground-truth method and the two continuous-emulation methods are treated with the artefacts they serve. The two remaining methods are named in the family table above. Appendix A holds every entry with its originating location, including the variants not repeated here.
Summary
The tools of authorised testing form a chain that fails at its weakest link. The rules-of-engagement manifest is first because everything else is lawful and safe only inside it, and it works as a control only when a component outside the executor enforces it. The emulation plan and the campaign plan make a test repeatable and comparable by writing the expectation before the run; the finding record and the outcome taxonomy make the result usable by the people who must change something. The open libraries (Atomic Red Team, Caldera) and the product class of breach-and-attack simulation give cadence and breadth, and their limit is the same: they show that a control reacted to a catalogued behaviour, not that anyone acted or that uncatalogued behaviour is covered. For AI systems, red teaming maps to OWASP and ATLAS and keeps adversarial inputs out of every record. Across all of them the series' rule holds: say what can be undone, who can stop it and from where, and end in a defensive improvement. The next chapter turns to the detection and investigation tools that receive these findings, and Chapter 14 to the tools that prove a finding is closed.
Sources
- Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
- Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (4, Nordqvist, 2026)
- Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (6, Nordqvist, 2026)
- Nordqvist, G. AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (8, Nordqvist, 2026)
- Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
- MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (67, MITRE, n.d.)
- MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. (68, MITRE, n.d.)
- OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (70, OWASP, 2025)
- European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. (76, ECB, 2025)
- European Central Bank. TIBER-EU Purple Teaming Guidance. (77, ECB, 2025)
- European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (197, European Union, 2022)
- Red Canary. Atomic Red Team: a library of tests mapped to the MITRE ATT&CK framework. (207, Red Canary, n.d.)
- MITRE Corporation. MITRE Caldera: a platform for automating adversary emulation, assisting manual red teams and automating incident response. (208, MITRE, n.d.)
- Schneider, J. What are breach and attack simulations?. (210, Schneider, 2024)
- Microsoft. Penetration testing (Azure security fundamentals) and the Microsoft Cloud Unified Penetration Testing Rules of Engagement. (211, Microsoft, 2026)
- Amazon Web Services. Penetration Testing. (212, AWS, 2026)
- Google Cloud. Cloud Security FAQ. (213, Google Cloud, n.d.)