Oversight and AI Supply Chain Risk

Most of the AI that defends a large European organisation was not built by it. It arrives inside the endpoint agent, the email gateway and the SIEM, runs in the managed security service that watches the estate at night, and, where the organisation builds its own, rests on outside models and services. A security function can therefore use AI extensively without having decided to, and a supplier can change what that AI does without telling anyone. The management body, which carries legal responsibility for cybersecurity, must be able to see this and decide on it. This chapter shows how it oversees AI in cyber defence, and how supply-chain risk is managed for models, AI services, security products and managed security service providers (MSSPs).

In CSF terms the chapter is responsible for two Govern Categories. GV.OV Oversight covers the review of the cybersecurity risk management strategy, its outcomes and performance, so that the strategy is adjusted when results or risks change. GV.SC Cybersecurity Supply Chain Risk Management covers the supply-chain programme: its strategy and roles, the prioritisation of suppliers, requirements in contracts, due diligence, monitoring, the inclusion of suppliers in incident response, and what happens when a relationship ends (19, NIST, 2024). The chapter treats both through the three focus areas of the NIST Cyber AI Profile (20, NIST, 2025).

Figure 8.1: The deployer between the management body and the model provider, security product vendor and MSSP, recording supplier AI in a register.

Oversight by the management body

Both European instruments that govern the example organisations' cybersecurity put the duty at the top. NIS 2 requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures and oversee their implementation, provides that they can be held liable for infringements, and requires their members to follow training (Article 20) (3, European Union, 2022). DORA places ultimate responsibility for a financial entity's ICT risk management framework on its management body, including the policy on the use of third-party ICT services (Article 5) (2, European Union, 2022). Neither imposes duties specific to security AI (NIS 2 mentions AI only in recitals that encourage its use to improve detection), yet both make it the management body's concern as soon as AI forms part of the measures or the third-party services that body relies on.

Decisions in tiers

AI Governance, Chapter 13, concluded that decisions about AI are taken in tiers: routine decisions at pipeline gates, exceptions at a design authority, high-risk go-live at the AI governance board, and risk beyond appetite at the management body (72, Nordqvist, 2026). This chapter takes that conclusion as its starting point. The management body does not approve each detection rule or model version; it approves the risk appetite and autonomy ceilings for security AI (Chapter 5), receives evidence that the organisation stays within them, and takes the few decisions only it can take: whether a defensive AI may act without per-action approval and up to which ceiling, whether to accept a concentration of security AI on one supplier or model provider, whether to accept, mitigate or exit a supplier finding beyond appetite, and whether security telemetry may be processed by AI outside the chosen jurisdictions.

What the management body needs to see

GV.OV asks that strategy outcomes be reviewed, the strategy adjusted and risk management performance evaluated (19, NIST, 2024). For security AI that means three kinds of content. An inventory view shows which security AI is in use, in which usage mode and autonomy level, supplied by whom and supporting which function, including AI the organisation did not choose, such as vendor-enabled features and an MSSP's tooling; Chapter 9 describes how the inventory is built. Risk indicators move when the risk moves: supplier features with undeclared effective autonomy, model changes in production without the organisation's own evaluation, overdue supplier findings, services for critical functions without a tested exit plan, and signs that human approvals have become a formality. AI Governance, Chapters 10 and 21, observed that approvals given in seconds are a signal of rubber-stamping (72, Nordqvist, 2026), so their share is an indicator for any security AI at Level 2 Supervised. Finally, decisions requested name the options and a recommendation, because a report that asks for nothing invites noting rather than oversight.

AI Governance, Chapter 11, concluded that evidence is a by-product of delivery, tied together by an evidence manifest, and that attestation is weaker than evidence generated by the systems themselves (72, Nordqvist, 2026); Architecture as Code (Chapter 15A) made the same point, that evidence is collected by machines, signed and versioned, not assembled in audit season (71, Nordqvist, 2025). Oversight of security AI depends on this, because a vendor can change a model within a month and a hand-assembled quarterly report may describe an estate that no longer exists. Hansa Mutual, for example, generates the security AI section of its executive board's quarterly ICT risk report from the inventory, the register of information and the purple backlog, with zero appetite for undeclared autonomy and unevaluated model changes, so that each occurrence reaches the board by name.

AI in the supply chain

GV.SC expects suppliers to be known and prioritised by criticality, and their risks assessed and monitored throughout the relationship (19, NIST, 2024). For security AI the first difficulty is knowing that a supplier relationship involves AI at all. Four kinds of supply relationship carry it into cyber defence.

Supply element	Example	What the deployer normally sees	Characteristic supply-chain risk
Models	General-purpose models behind a built triage assistant; self-hosted open-weight models	Model documentation, version, licence	Changed behaviour between versions; tampered weights; provider evaluation that does not cover security use
AI services	Hosted model APIs, classification services	Service terms, version identifiers, processing location	Silent model swaps behind a stable endpoint; data leaving the chosen jurisdiction
Security products with embedded AI	Endpoint and email verdicts, SIEM summaries, SOAR assistants	Release notes, if read	Features on by default, acting at an autonomy level the deployer never chose
Managed security services	Out-of-hours monitoring, managed detection and response	Service reports and the framework agreement	The MSSP's own AI working on the deployer's telemetry, invisible unless declared

Two further elements cut across all four. Agentic work tools bring their own supply chain of skills, connectors and packages, and AI Platform and Security, Chapter 16, concluded that loading a model is code execution, so a model artefact deserves the scrutiny of any executable (73, Nordqvist, 2026); MITRE ATLAS likewise lists unsafe AI artefacts, in which serialised models offer an opportunity for code execution without proper checking (11, MITRE, n.d.). Moreover, the July 2026 OpenAI–Hugging Face incident, which AI Governance, Chapter 19, analysed, failed through correlated controls, one of which was a package mirror that also served as an egress path (72, Nordqvist, 2026); OpenAI's technical report records that the internal package mirrors became the agents' principal egress path to the public internet (64, OpenAI, 2026). A supply-chain component can therefore be both the thing that is trusted and the route by which trust is abused.

Effective autonomy

Chapter 6 insists that the deployer decides the autonomy level, but a security product with embedded AI breaks that rule unless the deployer takes care. An email gateway that removes a reported message from every mailbox on a classifier verdict, without an analyst approving, acts at Level 3 Bounded or above, whatever its marketing calls the feature; the vendor has chosen the level on the deployer's behalf. This book calls the level at which a supplier feature actually acts its effective autonomy, and treats an undeclared effective autonomy as a supply-chain finding in its own right. Establishing it needs three facts from the supplier: where AI is used, which actions it takes without per-action approval, and whether they can be reversed. If the effective level exceeds the deployer's ceiling for that class of action, the feature is reconfigured to propose rather than act, switched off, or escalated to the forum that may raise the ceiling.

European obligations for the supply chain

NIS 2 includes supply chain security, including the security-related aspects of relationships with direct suppliers, among the minimum risk-management measures (Article 21(2)(d)), and requires entities to take into account each direct supplier's specific vulnerabilities, the overall quality of its products and cybersecurity practices, and its secure development procedures (Article 21(3)) (3, European Union, 2022). NIS 2 also brings managed security service providers into scope, and the Commission's Implementing Regulation sets out their risk-management requirements, including supply chain security (4, European Commission, 2024), elaborated in ENISA's guidance (8, ENISA, 2025). An MSSP in scope therefore has supply-chain duties of its own, and a deployer can ask it to show how it manages the AI tooling it uses on the deployer's behalf. The Cyber Resilience Act adds manufacturers' duties for vulnerability handling and component documentation, mainly from December 2027 (5, European Union, 2024), and DORA the third-party risk regime discussed below (2, European Union, 2022).

Who tests what

No single party can test everything, and evidence from one party does not answer another's questions. AI Platform and Security, Chapter 20, concluded that red teaming sits at the apex of the evaluation pyramid, and that adversarial testing under Article 55 of the AI Act falls on providers of general-purpose AI models with systemic risk (1, European Union, 2024), while deployers ask for the evidence and test the compound system themselves (73, Nordqvist, 2026). This chapter applies that conclusion to security AI.

Providers. The AI Act requires providers of general-purpose AI models to draw up technical documentation for the AI Office and national competent authorities, and to make information and documentation available to providers of AI systems that integrate the model (Article 53). Providers of models with systemic risk must in addition evaluate the model, including adversarial testing, assess and mitigate systemic risks, report serious incidents to the AI Office and ensure adequate cybersecurity protection (Article 55) (1, European Union, 2024); the General-Purpose AI Code of Practice gives them a way to demonstrate compliance (6, European Commission, 2025). For a deployer of security AI, however, Article 53 documentation flows to the integrating vendor rather than to the buyer, much Article 55 evidence goes to the AI Office, and the provider tests for systemic risks, not for the deployer's use, so an adversarially evaluated model may still be steered by crafted content in an alert field.

Vendors and MSSPs. The vendor tests the product's detection quality, false-positive behaviour and, where the Cyber Resilience Act applies, its security and vulnerability handling (5, European Union, 2024); the MSSP tests its service against its own service levels. Neither tests the combination that matters to the deployer: this feature, at this effective autonomy, on this telemetry, inside these playbooks. Their evidence should therefore be requested in a checkable form, such as evaluation results with the test set described.

The deployer tests the compound system: it evaluates each feature on its own evaluation set built from historical alerts with known outcomes, red teams features that read attacker-controlled content (Chapter 13), and verifies with security chaos engineering that the feature behaves as expected when its condition occurs (Chapter 25). It can also detect what the supplier will not say, by submitting a fixed set of benign canary samples on a schedule and comparing verdicts over time to catch a change no release note announced. What it cannot test, such as the provider's training data, the vendor's secure development process or the MSSP's internal access controls, it requires by contract and accepts as attestation, preferably backed by independent assurance and recorded as such in the supplier register.

Party	What it tests	Form of evidence	Use by the deployer
Provider of a general-purpose AI model with systemic risk	The model and systemic risks (Article 55, Code of Practice)	Reports to the AI Office; published summaries	Input to model selection; never a substitute for own testing
Security product vendor	The product and its AI features	Evaluation results, release notes, vulnerability records	Checked against declarations and own results
MSSP	The managed service and its tooling	Service reports, disclosed AI tooling, assurance reports	Checked against the framework agreement
Deployer	The compound system in its own context	Own evaluation, red-team results, chaos experiments, canary drift	Basis for enabling, setting autonomy and reassessing

Practical guide: Assuring a vendor's AI feature before enabling it in the SOC

Purpose. Decide, on evidence, whether a vendor's AI feature may be enabled in security operations, and at which autonomy level.

Roles. The SOC lead (feature owner), a detection engineer (evaluation), the supplier manager (declarations and contract), the CISO (decision up to the delegated ceiling) and the forum above if the level exceeds it. Employee representatives are consulted where the feature processes telemetry that can monitor employees.

Steps.

1. Obtain the supplier's declaration: what the feature does, which model, version and provider, where data is processed, which actions it takes automatically, whether they are reversible, and how changes are notified. Record any refusal as a finding.
2. Determine the effective autonomy from the declaration and a pre-production test; a feature that acts automatically and cannot be set to propose counts as at least Level 3 Bounded.
3. Compare it with the ceiling for that action class (Chapter 5); reconfigure, keep off or escalate if it is above.
4. Evaluate on at least 200 labelled historical cases, including known false positives, against thresholds set in advance; a sensible default is no loss of true positives and a false-positive rate at most five per cent higher than today's.
5. Where the feature reads attacker-controlled content, run the relevant AI red-teaming cases under the organisation's rules of engagement (Chapters 7 and 13).
6. Agree a canary set of 20 to 50 benign, labelled samples submitted daily and compared with the baseline.
7. Confirm that actions are logged to the SIEM, that a named person can switch the feature off, and that the fallback without it is documented.
8. Record the decision, evidence and reassessment triggers in a decision record, and enable the feature at Level 0 Advisory or Level 1 Assisted for 30 days before raising it to the approved level.

Definition of done. The feature is in the inventory with its model version and effective autonomy, the evidence is in the manifest, the decision record names the approved level and triggers, and the fallback and switch-off have been tested once.

Contract and register

GV.SC expects cybersecurity requirements in contracts, due diligence before a relationship begins, and plans for its end (19, NIST, 2024). For security AI, the general supplier requirements extend in five directions: declaration of AI use, models, providers, processing location and automatic actions, repeated at every material change; control, so that automatic features stay off until enabled, can be set to propose rather than act, and log every action to the deployer's SIEM; change notification in advance, with an unnotified change treated as a breach; evidence and testing, including provider documentation, pre-production tests, the canary set and red teaming under agreed rules of engagement; and incident and exit, covering AI misbehaviour that is not a classic breach and portable detections, playbooks and logs.

For a public authority, the tender is the moment of greatest leverage, because requirements absent from it are hard to add to a framework agreement afterwards.

Worked example: Supplier assurance requirements for security AI as code

The illustrative requirements below are Nordvik Region's. The CISO owns them, and they are attached to the next tender for the SIEM service and to the next amendment of the MSSP framework agreement, NR-2025-044.

# Illustrative: Nordvik Region, supplier assurance requirements for security AI
kind: SupplierAssuranceRequirements
id: NR-SUP-SECAI-001
version: 1.0.0
owner: ciso
attachTo: [siem-service-tender-next, NR-2025-044-amendment]
declaration:                       # at tender and at every material change
  aiFeatures: required
  modelProviderAndVersion: required
  automaticActions: required
  effectiveAutonomyLevel: required
  processingLocation: [EU, EEA]
  trainingOnRegionData: forbidden-unless-agreed
control:
  automaticFeaturesDefault: off-until-enabled-by-region
  proposeInsteadOfActConfigurable: true
  actionLog: {format: json, deliverTo: region-siem, retentionDays: 365}
changeNotification:
  modelOrFeatureChangeDaysAhead: 30
  urgentSecurityFixNotifyHours: 24
  unnotifiedChangeIsBreach: true
evidence:
  passOnProviderDocumentation: true
  regionMayTest: [pre-production-tenant, canary-sample-set]
  redTeamingSupport: under-region-rules-of-engagement
  attestationAcceptedFor: [secure-development-process]
incident: {notifyHours: 24, includesAiFeatureMisbehaviour: true}
exit:
  portable: [detection-rules, playbooks, action-logs]
  transitionSupportMonths: 6
review:
  triggers: [model-change, new-ai-feature, incident, contract-renewal]
  openFindingsReportedTo: regional-director

Unlike a prose clause, the file lets the tender evaluation check each response against each key, versions every change so that the Region knows which requirements applied to which contract, and links the contract to change-triggered reassessment.

The register and the exit plan

DORA requires financial entities to maintain a register of information on all contractual arrangements for ICT services provided by third parties (Article 28(3)), to have exit strategies for ICT services supporting critical or important functions (Article 28(8)), and to include key contractual provisions in those arrangements (Article 30) (2, European Union, 2022). Security AI services fall within that register like any other ICT service, but their entries should carry the AI-specific facts, the declared models and versions and the effective autonomy, so that the register can answer the management body's questions. Outside DORA, the Commission's Implementing Regulation requires the entities it covers, MSSPs among them, to keep a registry of their direct suppliers and service providers with contact points and the ICT products, services and processes each provides (Annex, point 5.2) (4, European Commission, 2024); a deployer can add criticality and the AI-specific facts to its own directory.

An exit plan for security AI differs from one for a general IT service in that the realistic exit is often a fall-back to the process without AI rather than a move to another vendor. The plan must say how the SOC works without the feature tomorrow and what moves with the organisation. Switching a feature off for a day in a controlled test turns the plan from assertion into evidence.

Change-triggered reassessment

AI Governance, Chapter 8, concluded that classification is triggered by change, not by the calendar (72, Nordqvist, 2026). For supplier AI the same holds, with one difficulty: the change happens on the supplier's side, and the deployer may not be told. Reassessment is due for a new model version, a new AI feature switched on in an update, a change in the supplier's set-up such as a new sub-processor or hosting location, and a change in the threat, such as a published compromise of a repository the supplier depends on.

Contractual notification catches the changes suppliers announce, and three technical signals catch the others. Version telemetry, where the product reports the model version behind each verdict, is the cheapest and should be required by contract. The canary set detects a change in behaviour even when the version string stays the same, and verdict-distribution monitoring on live traffic catches what the canary set misses, at the cost of more noise. Each signal opens a reassessment record that follows the decision tiers (72, Nordqvist, 2026): a change within canary tolerance and unchanged effective autonomy is confirmed at the routine gate, a change in automatic actions goes to the design authority or the CISO, and a change above the ceiling goes to the forum that sets it. Until reassessment is complete, the safe default for a feature that acts automatically is to fall back to proposals at Level 1 Assisted.

Supply-chain compromise as an AI-enabled attack path

Supply-chain compromise is an established adversary technique: MITRE ATT&CK describes supply chain compromise and the abuse of trusted relationships, and MITRE ATLAS describes compromise of the AI supply chain, including models, data and software dependencies (10, MITRE, n.d.) (11, MITRE, n.d.). The OWASP Top 10 for LLM applications lists supply chain among its risks, and NIST's taxonomy of adversarial machine learning treats poisoning and supply-chain attacks as classes of attack with their own mitigations (14, OWASP, 2025) (18, Vassilev et al., 2025).

Security AI makes the path more attractive, because a tampered model inside a security product need only classify the attacker's mail as benign. A compromised MSSP tool holds privileged access to many customers at once. The July 2026 incident showed how a component trusted for one purpose could serve another, and how a single shared credential linked controls meant to be independent (72, Nordqvist, 2026); OpenAI's report notes that many research workloads used the same shared Artifactory credential (64, OpenAI, 2026).

Across the usage modes

Mode 0 is the supply-chain blind spot, because vendor-enabled AI may already act automatically; the other modes each bring a different supply relationship (Chapter 6).

Mode	Characteristic supply-chain vulnerability	Who judges, with whose identity
Mode 0 Ambient AI	Default-on features, silent model changes, vendor-chosen effective autonomy	The vendor's model, the product's or MSSP's identity
Mode 1 Conversational assistants	Telemetry pasted into a service whose terms and hosting may change	A person, own session
Mode 2 Embedded workplace assistants	Vendor model changes alter summaries unnoticed	A person, delegated access
Mode 3 Agentic work tools	Skills, connectors and packages form a supply chain of their own	A person reviews, engineer's credentials
Mode 4 Built AI applications	The organisation is provider but depends on model providers and services	A person acts, read-only application identity
Mode 5 Autonomous production agents	A model or tool change alters privileged actions	The agent within codified bounds, own identity

Across the autonomy levels

The effective level of a supplier feature, not its description, determines what can go wrong when the supplier changes it (Chapter 6).

Level	Assurance required before enabling a supplier feature
Level 0 Advisory	Declaration, own evaluation, canary set
Level 1 Assisted	As Level 0, plus review of drafted actions
Level 2 Supervised	As Level 1, plus action logging to the SIEM and monitoring of approval times
Level 3 Bounded	As Level 2, plus tested reversal, switch-off and fallback, and contractual advance notification
Level 4 Autonomous	Not accepted unless the management body explicitly decides otherwise; never for irreversible or offensive actions

Verifying with security chaos engineering

The experiment verifies that a silent change in a supplier's model version is detected and triggers reassessment. In a test environment, the platform replaces the response of a supplier integration with one reporting a new, unannounced model version and shifts the canary verdicts beyond tolerance; no supplier system, real mail or telemetry is involved. The steady-state hypothesis is that both signals are detected, a reassessment record is opened and assigned to the supplier entry's owner, an automatically acting feature falls back to Level 1 Assisted, and the open reassessment appears in the next generated oversight report. The time bounds are detection within one canary cycle (24 hours by default), the record assigned within one working day and fallback within one hour of it. A failure goes to the purple backlog; Chapter 25 sets the safety boundaries.

The three AI focus areas

Securing AI systems. The security AI the organisation builds depends on model providers and AI services, which GV.SC covers through declarations, Article 53 documentation, Article 55 and Code of Practice evidence for models with systemic risk, the organisation's own evaluation of the compound system, and change-triggered reassessment (1, European Union, 2024) (6, European Commission, 2025).

AI-enabled cyber defence. AI in security products and managed services is assured before reliance, and GV.OV shows the result to the management body that sets the ceilings.

Thwarting AI-enabled attacks. Adversaries may use AI to find weak suppliers, and a compromised AI component inside a security product directly weakens defence; scoped supplier access, behavioural monitoring and an alert path to the holder of the stop decision limit both (11, MITRE, n.d.).

Nordvik Region and Hansa Mutual

Nordvik Region mostly buys rather than builds, so it relies on contracts and its MSSP framework agreement, NR-2025-044. Its first supply-chain finding is the vendor's phishing-report classifier in the email-security gateway, a Mode 0 feature that acts on reported mails automatically, at what amounts to Level 3 Bounded, without the Region having decided its effective autonomy. The Region now requires declarations and advance change notification from every security vendor and the MSSP, and its regional director receives a quarterly report generated from its inventory and supplier records.

Hansa Mutual adds every security AI service to its DORA register of information with the exit plan and the function it supports. It tests each model change in vendors' verdicts, its SOAR and ticketing assistants and the models behind HM-SEC-001 against its own evaluation set before production, using providers' Article 55 evidence as input, not as a substitute. The executive board sees security AI indicators in its ICT risk reporting through the chief risk officer, while the group AI governance board sets the autonomy ceilings within the board's appetite. The difference is leverage: Nordvik's lies in the contract and the tender, Hansa's in its platform, its register and its capacity to test every change itself.

Summary

GV.OV Oversight should give the management body, which NIS 2 and DORA hold responsible, reports generated from records: which security AI is in use, at which autonomy level, with which indicators and findings, and which decisions it must take on appetite, ceilings, concentration and exit.

GV.SC Cybersecurity Supply Chain Risk Management must extend to models, AI services, security products with embedded AI and managed services. Mode 0 is the blind spot, so the deployer must establish where AI is used and at which effective autonomy before relying on it. Provider evidence under AI Act Article 55 and the Code of Practice does not replace the deployer's own testing on its own data and at its own autonomy levels, and what the deployer cannot test it must require by contract, preferably as requirements kept as code, and record in its register with exit plans.

Because supply-chain compromise is also an AI-enabled attack path, change-triggered reassessment through version telemetry, canary sets and notification is essential, as the chaos experiment verifies. Chapter 9 moves to Identify, beginning with asset management for an estate that includes AI.

Sources

1. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
2. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
3. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
4. European Commission. The General-Purpose AI Code of Practice. (6, European Commission, 2025)
5. 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)
6. 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). (3, European Union, 2022)
7. European Commission. Commission Implementing Regulation (EU) 2024/2690 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements of cybersecurity risk-management measures. (4, European Commission, 2024)
8. European Union Agency for Cybersecurity. Technical implementation guidance on Commission Implementing Regulation (EU) 2024/2690. (8, ENISA, 2025)
9. 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)
10. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (10, MITRE, n.d.)
11. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (11, MITRE, n.d.)
12. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (14, OWASP, 2025)
13. Vassilev, A. et al. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. (18, Vassilev et al., 2025)
14. OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)
15. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
16. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
17. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)