A Reference Architecture for AI-Enabled Cyber Defence

Security AI tends to arrive by side doors. A vendor switches on an AI verdict in the endpoint product, an analyst pastes an alert into a conversational assistant, the SOAR platform gains an embedded assistant, and a detection engineer starts using a coding agent on a laptop. Together these steps produce an estate in which models read the most sensitive telemetry and act in production outside the gateway, policy point and evidence trail built for every other AI system. This chapter presents a reference architecture that closes those side doors by placing security AI on the governed platform of the earlier volumes, and gives every later chapter a common picture of its layers and ranges.

In CSF 2.0 terms the chapter is responsible, together with Part IV, for two Protect Categories: PR.PS Platform Security, which covers the hardware, software and services of platforms and their management consistent with risk strategy, and PR.IR Technology Infrastructure Resilience, which covers the security architectures that protect asset confidentiality, integrity and availability and organisational resilience (19, NIST, 2024). It treats both through the three focus areas of the NIST Cyber AI Profile (20, NIST, 2025); Chapters 16 and 17 supply the detailed controls. It answers three questions: where security AI sits, where models may run on security telemetry, and how offensive capabilities are separated from production.

Figure 4.1: The six layers of the reference architecture, from telemetry to bounded actions on the production estate, with separated ranges.

Security AI is AI: inheriting the platform

The first decision, placement, settles most of what follows. A triage assistant that summarises alerts, an agent that proposes containment and a harness that runs adversarial tests against the organisation's own assistants are all AI systems: they call models, read content they did not write, invoke tools and leave consequences behind. They should therefore run on the governed AI platform, under the same controls as the citizen-service assistant or the claims-triage agent, rather than beside it.

What the platform already provides

AI Platform and Security, Chapter 4, built a six-layer reference architecture with a cross-cutting control plane for identity, policy, observability and evidence (73, Nordqvist, 2026). Its conclusion, recorded here as foundation F17, is that a platform is under control when every model call and tool call passes a policy point outside the model, when containment holds whatever anyone intends, and when evidence is produced by normal operation (AI Platform and Security, Chapter 25). Security AI does not need a second platform; it needs a place on the first one and the additional layers a security operation requires.

Four inherited components carry most of the weight:

• The AI gateway. Every model call passes a mandatory entry point that authenticates the caller, applies guardrails, routes the request according to policy and emits a trace.
• The policy decision point. Every tool call, from a SIEM query to a containment action, is evaluated against rules in a repository by an engine the model cannot influence. This is the zero-trust principle of NIST SP 800-207 applied to AI: no implicit trust is granted on the basis of where a request comes from, and access is decided per request (23, Rose et al., 2020).
• Containment. The agent's reach is bounded by the platform, not by its instructions. Foundation F23 (AI Platform and Security, Chapter 19) lists task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, budgets and a stop path outside the system they stop, recorded approvals, and detection from telemetry and decoys rather than self-report.
• Evidence. Traces, policy decisions and approvals produced in normal operation are the evidence; nothing is assembled after the fact.

The same applies to the four security dimensions of Architecture as Code (Chapter 9), foundation F6: threat modelling, zero trust, Policy as Code and risk assessment (71, Nordqvist, 2025), from which a security team must not exempt its own tools.

Why security AI needs the controls more, not less

Security tooling has always held unusual privileges, from the SIEM that reads everything to the SOAR platform that holds credentials for firewalls and identity providers. Adding AI puts a model in the path between content and privilege, and the content security AI reads is largely written by the adversary.

Foundation F20 therefore applies with full force: AI Platform and Security, Chapter 16, concluded that prompt injection is a property of the architecture rather than a patchable defect, that controls must sit outside the model, and that loading a model is code execution (73, Nordqvist, 2026). The OWASP Top 10 for Large Language Model Applications places prompt injection first, names excessive agency as a distinct risk and notes that, given the stochastic influence at the heart of how models work, it is unclear whether fool-proof methods of preventing prompt injection exist (14, OWASP, 2025), and the OWASP Top 10 for Agentic Applications adds tool misuse and identity and privilege abuse (15, OWASP, 2025). NIST's taxonomy of adversarial machine learning distinguishes direct from indirect prompt injection, the latter arriving through content the system retrieves or processes (18, Vassilev et al., 2025). A security assistant that reads an attacker's email is, by construction, exposed to indirect injection. The architecture cannot make the model immune, but it can ensure that a steered model meets a policy point it cannot pass, an identity it cannot widen and an approval it cannot forge. The Five Eyes agencies' guidance on the careful adoption of agentic AI services reaches the same position: privileges, data access and oversight are designed before such services are switched on (40, Five Eyes agencies, 2026).

Three placements, one that works

Placement	What it looks like	What is lost
Beside the platform	Security team runs its own model endpoints and scripts with direct API keys	Gateway, policy point, evidence and containment; the security estate becomes the least governed AI in the organisation
Inside the vendor tool	AI features embedded in SIEM, EDR or SOAR, configured through the vendor console	Visibility of models, data flows and actions
On the platform	Security AI calls models through the gateway and tools through the policy point, with its own identities and evidence	Nothing essential; this is the reference placement

The second placement cannot always be avoided, because vendor AI in endpoint and email protection is Mode 0 Ambient AI that may already act automatically. The architecture therefore records such features with a declared autonomy level and puts their telemetry and configuration under the same evidence and change control.

Worked example: Containment profile for the SOC investigation agent

Illustrative example. Hansa Mutual's SOC investigation agent, HM-SEC-001, enriches alerts and proposes containment. It is a Mode 5 Autonomous production agent with its own workload identity, accepted in AIDR-0311, and starts at Level 2 Supervised: it executes an action only after a person approves it. The containment profile below, in the format of AI Platform and Security, Chapter 19 (73, Nordqvist, 2026), states what the platform guarantees whatever the agent attempts. Because the agent serves all seven markets from Frankfurt, its tokens carry the entity on whose behalf it acts.

# agents/hm-sec-001/containment.yaml - Hansa Mutual, illustrative example
apiVersion: platform.example.eu/v1
kind: AgentContainmentProfile
metadata:
  name: soc-investigation-agent
  useCase: HM-SEC-001
  decisionRecord: AIDR-0311
spec:
  range: blue-tooling
  isolation: {runtime: microvm, lifetime: per-investigation, hostAccess: none}
  identity:
    type: workload-identity
    maxTokenLifetime: 5m
    standingPrivileges: none
    onBehalfOfEntity: required      # token names the market entity of the case
  reach:
    via: tool-gateway               # no SIEM, EDR or IdP credentials in the sandbox
    readTools: [siem-query, edr-telemetry, asset-lookup, ti-lookup]
    proposeTools: [isolate-endpoint, revoke-user-sessions, block-indicator]
    approvalRequired: all-actions   # Level 2 Supervised
  inputs:
    alertContent: untrusted-data    # never treated as instructions
    instructionSources: [skills-catalogue/soc/, playbooks/approved/]
  network:
    egressDefault: deny
    allow: [tool-gateway.hansa.internal, ai-gateway.hansa.internal]
  protectedArtefacts: [agents/hm-sec-001/, detections/, playbooks/]   # read-only
  budgets: {maxSteps: 40, maxProposedActions: 5, maxWallClock: 30m}
  logging:
    sink: append-only://evidence/security-ai/hm-sec-001/
  stop:
    killSwitch: agents.hm-sec-001.enabled
    holders: [soc-shift-lead, group-ciso, incident-commander]
    outOfBand: true                 # does not depend on the agent or its tools

Three lines carry the reasoning of this chapter: the agent holds no credentials for the SIEM, EDR or identity provider, so every action passes the policy decision point; alert content is untrusted, so instructions come only from reviewed artefacts the agent cannot edit; and the stop path is held by people outside the agent. Chapter 6 develops the authority to raise the agent to Level 3 Bounded for reversible actions; the containment profile is what makes that decision safe to take.

Layers of the AI-enabled security operation

A security operation that uses AI is a pipeline from evidence to action, shown in Figure 4.1 as six layers inside the inherited platform.

Telemetry holds logs, alerts, flows, identity and endpoint events and the platform's own AI traces. It is the main channel through which attacker-controlled content reaches models, so the layer tags content by origin, and fields an outsider can influence are passed to models as data, never as instructions. Its completeness is itself an outcome, stated in CSF 2.0 as PR.PS-04, that log records are generated and made available for continuous monitoring (19, NIST, 2024); a model that summarises a quiet log source as benign is wrong in a way no prompt can fix.

Knowledge holds threat intelligence, asset context from Chapter 9, detection rules, playbooks and case notes. It is a target, because a poisoned intelligence feed or an edited playbook changes what security AI proposes. Its sources are therefore registered, signed where possible and versioned, and playbooks that agents read as instructions are protected artefacts that those agents can never write.

Models are served through the gateway, usually as a mix of self-hosted, EU-hosted and cloud models, and which model may see which data is a routing rule in the gateway, not a property of the model. Models are loaded from the platform registry only, because some model file formats can contain executable calls, so that a model file fetched to a workstation is an unvetted executable (11, MITRE, n.d.).

Agents compose models, knowledge and tools into units that pursue a task. Each has its own workload identity in the agent registry, a permission manifest and a containment profile. The identity matters most: an assistant that acts with an analyst's credentials, as in Mode 1 or Mode 2, inherits everything the analyst may do, whereas an agent with its own identity can be scoped and revoked separately and its actions told apart in the evidence (Chapter 14).

Tools are where content becomes consequence. Each is exposed through the tool gateway and registered with an owner, its data classes, its actions and the entities where it may be used, and read and write tools are registered separately, so that an agent can be given wide visibility and narrow agency.

Actions are the boundary with the production estate: bounded, reversible where possible, logged, and tagged with the autonomy level under which they were taken. An action is proposed in the agent layer, where the model has influence; approved in the approval service, outside the agent, by a person at Level 1 Assisted and Level 2 Supervised or by a codified playbook at Level 3 Bounded; and executed by the tool gateway, which re-checks the policy decision. Keeping these three points in different components lets an organisation raise an agent's autonomy for one action without raising it for all, and it is what an auditor examines when asking who decided (Chapter 6).

Policy and evidence sit between every pair of layers: rules decide, for example, whether a telemetry field may reach a model outside the national data centre or whether a proposed action needs approval, and each decision is recorded with its inputs. Every step from alert to action can thus be reconstructed from evidence produced in normal operation, which is the property F17 demands, applied to the security operation itself.

Sovereignty of security data

Security telemetry is among the most sensitive data an organisation holds: alerts name people and devices, case notes describe suspected misconduct, and in a health authority a single alert may contain special-category data, which includes data concerning health (9, European Union, 2016). Its sensitivity decides where models may run on it.

Classifying security data

The architecture classifies security data by content rather than by the tool that produced it:

Class	Typical content	Default hosting for models
Public intelligence	Published advisories, vulnerability records, open threat reports	Self-hosted, EU-hosted or cloud
Restricted intelligence	Shared indicators under handling conditions, internal threat models	Self-hosted or EU-hosted, as the handling conditions allow
Operational telemetry	Alerts, logs, network and identity events with personal data	Self-hosted or EU-hosted under contract with EU/EEA processing
Sensitive case data	Special-category data, employee investigations, incident details under reporting obligations	Self-hosted only

The classes are defaults set in the risk strategy (Chapter 5). The gateway reads the classification of the request's content and routes it only to serving the policy permits, so a triage assistant that receives an alert with health data is routed to the self-hosted model, whatever the analyst would prefer.

Self-hosted, EU-hosted and cloud models

Self-hosted models keep the most sensitive data under direct governance at the cost of capability; EU-hosted models under contract allow stronger models while the provider joins the attack surface; and cloud models from outside the EU, with the weakest control over location and access, are restricted to content that would do no harm if disclosed.

European instruments turn these choices into obligations. For financial entities, DORA requires contractual arrangements for ICT services to specify the regions or countries where services are provided and data is processed, including the storage location (Article 30(2)(b)), and the AI service behind a security assistant is such an arrangement (2, European Union, 2022). NIS 2 requires measures that include supply chain security, among them the security aspects of relationships with direct suppliers and service providers (Article 21(2)(d)) (3, European Union, 2022). The architectural implication, not legal advice, is that the location of every model that sees security telemetry is recorded, contracted and enforced at the gateway, and that an MSSP's own AI tooling faces the same questions.

Sovereignty is also a defence: alerts reveal what the organisation can and cannot see, and keeping them on controlled capacity reduces the places where an adversary could learn how to stay below the detections.

Separation of ranges

An organisation that uses AI for defence will sooner or later use it for offence on its own behalf, in adversary emulation and adversarial testing of its own AI. These dangerous capabilities are kept in separated ranges, each an environment with its own network boundary, identities, credentials, tooling and evidence store, and with explicit, policy-enforced routes to the others.

Range	What runs there	Route to production	Who has access
Production estate	Business systems, AI systems in service, the platform	Not applicable	Operations; security AI through the tool gateway
Blue tooling	SIEM, SOAR, EDR management, defensive security AI	Read through registered tools; write only through approved actions	SOC, detection engineering, incident response
Red range	Adversary-emulation tooling, including AI-assisted offensive tooling	None, except authorised exercises through a monitored path	Red team only
AI test range	Copies of AI systems, evaluation harnesses, engineers' coding agents	None	Evaluation engineers, AI red team, detection engineers

Blue tooling reads production broadly and changes it only through approved actions. The red range has no standing route into production or blue tooling; an exercise that touches production does so under written rules of engagement, through a path the white team and the SOC can see, and only for its duration (Chapter 7). The AI test range runs copies, never production instances, so that adversarial testing of an assistant cannot become an incident for residents or customers. Mode 3 Agentic work tools used by detection engineers and red-teamers run only in isolated ranges, because an agent acting with an engineer's credentials should not hold credentials that reach production.

Findings are the only route

The one sanctioned route from the red range and the AI test range into blue tooling is the finding, a versioned record closed by a control and verified by re-running the scenario that found it (Chapter 26); offensive tooling never crosses, but the detections derived from it do. Architecture as Code (Chapter 13) already ran security tests, including synthetic attack simulations, against ephemeral environments rather than production (71, Nordqvist, 2025). What changes with AI is the speed and autonomy of the tooling: agentic offensive frameworks can compress work that previously took an operator several hours into minutes (50, Blum et al., 2026), so the containment F23 requires for production agents applies equally inside the red range and the AI test range.

Separation, resilience and platform security

Separated ranges are also how the architecture meets PR.IR, which asks that networks and environments are protected from unauthorised logical access and usage (PR.IR-01), that mechanisms achieve resilience requirements in normal and adverse situations (PR.IR-03), and that adequate resource capacity is maintained (PR.IR-04) (19, NIST, 2024). Ranges limit the blast radius of a compromised agent, a degradation path drops an agent to a lower autonomy level and then to manual playbooks when security AI is unavailable, and reserved capacity keeps the triage assistant running when an incident floods the SOC. For PR.PS, configuration management (PR.PS-01) and prevention of unauthorised software (PR.PS-05) mean that prompts, playbooks, manifests and gateway policy are versioned configuration and models load only from the registry. Chapters 16 and 17 develop these mechanisms.

Mapping to D3FEND and CSF

A reference architecture earns its keep when it makes coverage visible. The adversary's side is described in MITRE ATT&CK (10, MITRE, n.d.) and MITRE ATLAS (11, MITRE, n.d.). The defender's side has MITRE D3FEND, a knowledge graph of countermeasures organised under tactics such as Harden, Detect, Isolate, Deceive and Evict and linked to the offensive techniques they counter (12, MITRE, n.d.). Each building block is recorded with the D3FEND tactic it implements and the CSF Category it supports, so that a gap shows as a block with no mapping or a Category with no block.

Building block	D3FEND tactic	CSF Category	Chapter
AI gateway and policy decision point	Harden, Isolate	PR.PS Platform Security, PR.AA	4, 14, 16
Workload identities and task-scoped credentials	Harden	PR.AA	14
Default-deny egress and separated ranges	Isolate	PR.IR Technology Infrastructure Resilience	4, 17
Telemetry completeness and log forwarding	Detect	PR.PS, DE.CM	16, 18
Honeytokens and decoys in agent reach	Deceive	DE.CM	19
Out-of-band stop path and revocation	Evict	RS.MI	21

The coarse mapping lets a reviewer trace from an ATT&CK or ATLAS technique in the threat model to the countermeasure, the building block that implements it and the CSF outcome the organisation reports, and so feeds the profile as code of Chapter 3.

Practical guide: Placing a new security AI capability on the reference architecture

Purpose. Place a new security AI capability, whether built, procured or switched on in a vendor tool, on the reference architecture before it reads production telemetry or takes any action. Roles. The capability owner, the AI platform team, the data-protection officer, the CISO for the autonomy decision, and the AI red team for testing.

1. Name the capability and its mode. Register it with a security identifier and state its usage mode and starting autonomy level (Chapter 6); a capability that cannot be given a mode is not ready.
2. Classify the data it reads, assigning each source its highest data class and deriving the permitted hosting from the class table.
3. Choose the range: blue tooling for defence, the red range or AI test range for offence or evaluation. A capability that needs both is two capabilities.
4. Give it an identity and a manifest that lists read and action tools separately, with every tool call through the tool gateway.
5. Write the containment profile, defaulting to five-minute tokens, no standing privileges, default-deny egress, protected artefacts and an out-of-band stop path with named holders; adapt only by recorded decision.
6. Declare untrusted inputs and state where instructions may come from.
7. Test before promotion in the AI test range, including indirect injection through representative alert content, and block promotion if the agreed thresholds are not met.
8. Record the decision in an AI Decision Record that names the owner of the identity and the holder of the decision to change the autonomy level.

Definition of done. The capability calls models only through the gateway and tools only through the tool gateway; its data classes, hosting and range are enforced by policy; it has its own identity, manifest and containment profile; it has passed its pre-production test; and its placement and decision records are merged.

Across the usage modes

The reference architecture applies to every mode, but what it protects differs (Chapter 6).

Mode	Opportunity in the architecture	Characteristic vulnerability	Who judges, with whose identity
Mode 0 Ambient AI	Vendor verdicts at machine speed at the edge	Automatic action outside the gateway and evidence trail	The vendor's logic; the product's
Mode 1 Conversational assistants	Analyst support for reading and drafting	Telemetry pasted outside the routing rules	The analyst; the analyst's
Mode 2 Embedded workplace assistants	Assistance inside SIEM, SOAR and ticketing	Inherits the analyst's privileges; reads attacker content	The analyst; the analyst's
Mode 3 Agentic work tools	Detection engineering and red-team tooling at speed	Engineer's credentials between instruction and review	The engineer at review; the engineer's
Mode 4 Built AI applications	Governed triage and drafting services	Indirect injection through alerts; data location	The analyst; a service identity
Mode 5 Autonomous production agents	Investigation and bounded containment	A well-meaning insider with its own privileges	The approver or playbook; the agent's own

Verifying with security chaos engineering

The architecture's claims are testable on the platform of Chapter 25. In one experiment, a test agent in blue tooling is issued a token with broader scope than its manifest allows; the steady-state hypothesis is that the policy decision point refuses the call and the refusal appears in the evidence store within one minute. In another, a benign connection attempt from the AI test range towards a production address must be blocked at the range boundary and alerted to the SOC within fifteen minutes. Each injects a condition, not an attack.

The three AI focus areas

Securing AI systems. Security AI inherits the gateway, policy decision point, containment and evidence of the governed platform, and its identity, manifest and containment profile are configuration under version control, so PR.PS for security AI is an inherited property rather than a separate project.

AI-enabled cyber defence. The six layers show where AI helps the defender, and the separation of proposal, approval and execution shows where people stay in command.

Thwarting AI-enabled attacks. Sovereignty of security data limits who can learn what the defender sees, and separated ranges keep an offensive capability, a compromised agent or a misbehaving test from reaching production or blue tooling.

Nordvik Region and Hansa Mutual

Nordvik Region self-hosts its security AI on capacity that a European hosting provider reserves for it in a Nordic data centre. Because alert data contains personal and health data, the SOC triage assistant NR-SEC-001 runs there with a read-only service identity, behind the same gateway as the citizen-service assistant, and its placement record, accepted in AIDR-0301, classifies its highest input as sensitive case data, so no request can be routed elsewhere. The Region has no red range of its own: the contracted tester for RoE-NR-2027-001 works from the tester's environment against systems named in scope, and the AI red-teaming of NR-SEC-002 runs against copies of its assistants in a separated test range. Vendor AI in its endpoint and email protection is recorded as Mode 0 with its autonomy level declared.

Hansa Mutual runs its security AI on the Frankfurt group platform, with market overlays applying national rules to each entity's telemetry. HM-SEC-001 acts under the containment profile above, and its entity-scoped tokens prevent a case from one market being used to reach another. All four ranges are separated, the detection engineers' coding agents work only in isolated ranges, and the continuous automated red teaming of HM-SEC-004 has no route into blue tooling except through findings. The two differ in how many ranges they need and who operates them, not in the principle that security AI inherits the platform's controls.

Summary

Security AI is AI, and it belongs on the governed platform, whose gateway, policy decision point, containment and evidence matter more for it than for most systems because so much of what it reads is written by the adversary. PR.PS Platform Security thereby becomes an inherited property. The six layers from telemetry to action give every later chapter a common picture, and keeping proposal, approval and execution apart allows autonomy to be raised one action at a time. Security telemetry is classified by content, and model location is enforced as a routing rule at the gateway.

Separated ranges for production, blue tooling, the red range and the AI test range keep offensive capabilities and compromised agents away from what they should not reach, make findings the only route from offence to defence, and support PR.IR Technology Infrastructure Resilience. Mapping to D3FEND and CSF makes coverage visible. Chapter 5 turns to Govern, starting with the organisational context and risk strategy that decide how far security AI may act.

Sources

1. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)
2. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
3. MITRE Corporation. MITRE D3FEND: A knowledge graph of cybersecurity countermeasures. (12, MITRE, n.d.)
4. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (10, MITRE, n.d.)
5. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (11, MITRE, n.d.)
6. Rose, S., Borchert, O., Mitchell, S. & Connelly, S. Zero Trust Architecture. (23, Rose et al., 2020)
7. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
8. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
9. Five Eyes cyber security agencies: ASD's ACSC, CISA, NSA, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK. Careful adoption of agentic AI services. (40, Five Eyes agencies, 2026)
10. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (14, OWASP, 2025)
11. OWASP Foundation. OWASP Top 10 for Agentic Applications for 2026. (15, OWASP, 2025)
12. Vassilev, A., Oprea, A., Fordyce, A., Anderson, H., Davies, X. & Hamin, M. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. (18, Vassilev et al., 2025)
13. 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)
14. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
15. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). (9, European Union, 2016)
16. Blum, Mainor, Nambiar et al. ARTEX and Friends: Enter Agentic Offensive Frameworks. (50, Blum et al., 2026)