Policy, Mandate and Rules of Engagement

An organisation that puts AI to work in cyber defence needs a mandate before it needs a model. Each use of AI, from an analyst's assistant to a red team's emulation agent, is either authorised, bounded and evidenced by policy, or it is improvisation that a supervisor, a works council or a court will later have to reconstruct. This chapter sets out that mandate, from policy and legal duties to rules of engagement as a signed and enforced artefact.

In CSF terms the chapter is responsible for GV.PO Policy in the Govern Function. Its Subcategories ask that policy is established from organisational context, strategy and priorities and is communicated and enforced (GV.PO-01), and that it is reviewed and updated as requirements, threats, technology and mission change (GV.PO-02) (19, NIST, 2024). With AI, "enforced" must cover an agent acting in milliseconds, and "changes in technology" a silently swapped vendor model. The chapter treats the Category through the three focus areas of the NIST Cyber AI Profile, currently a preliminary draft (20, NIST, 2025).

From obligations to policy, policy instruments by mode and rules of engagement as the gate for offensive work

Figure 7.1: From obligations to policy, policy instruments by mode and rules of engagement as the gate for offensive work.

Security policy that covers AI

Covering AI requires no separate AI security policy, only that the existing policy says, for each way AI is used, who may use it, with which data, under which identity and with which evidence.

Three layers: statement, standards and enforceable rules

NIS 2 Article 20 requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures and oversee their implementation (3, European Union, 2022), and DORA Article 5 gives the management body of a financial entity responsibility for the ICT risk-management framework (2, European Union, 2022). The policy those bodies approve should not be rewritten for every new tool; instead, it carries three commitments: AI used for security is governed by its usage mode and autonomy level, recorded in a decision record before go-live; no AI acts on the estate outside a boundary enforced by a policy decision point it cannot change; and every offensive activity, with or without AI, runs under signed rules of engagement.

Below the statement sit standards that interpret it for each usage mode, and below them enforceable rules: policy as code at the AI gateway, the policy decision point and the pipeline gates. Here the chapter builds on Architecture as Code (Chapters 10 and 11), which concluded that a control should be written once as code and mapped to many obligations: "assure once, comply many" (71, Nordqvist, 2025). A rule that refuses an agent's out-of-scope tool call thus serves NIS 2, DORA and AI containment at once, and its refusal log is evidence for all three.

Policy instruments by usage mode

AI Governance, Chapter 2, concluded that the usage mode, not the brand of the tool, sets the governance (72, Nordqvist, 2026). Security AI therefore needs a different policy instrument for each mode.

Usage mode Policy instrument What the instrument fixes
Mode 0 Ambient AI Supplier assurance requirement Enabled vendor AI features, their automatic actions, change notification (Chapter 8)
Mode 1 Conversational assistants Acceptable-use standard Approved tools, forbidden data, a person owns every output
Mode 2 Embedded workplace assistants Acceptable-use standard and tenant configuration Delegated access scope, logging, readable data classes
Mode 3 Agentic work tools Governed skills and connector catalogue Loadable skills and connectors, reachable environments, review before merge
Mode 4 Built AI applications Decision record Purpose, data, model hosting, autonomy level, identity, evaluation evidence
Mode 5 Autonomous production agents Permission manifest and rules of engagement Tools, credentials, budgets, stop path and the signed scope of offensive work

Policy for Modes 1 and 2 is about people; policy for Mode 5 is about boundaries: AI Governance, Chapters 19 and 25, concluded that every agent must be governed as a well-meaning insider, since only boundaries set a ceiling on its consequences (72, Nordqvist, 2026).

Ownership and review

The CISO owns the policy statement and proposes it to the management body. The standards for each mode are owned by the function that operates the capability, such as the SOC lead for triage AI or the red-team lead for offensive capabilities; the platform team owns the rules as code, reviewed in version control; and the white team (Chapter 6) owns the rules of engagement for each exercise, which every target-system owner signs. AI Governance, Chapter 13, concluded that decisions are tiered, from pipeline gates up to the management body (72, Nordqvist, 2026), so the policy states that any move to Level 3 Bounded is a decision of the AI governance board, recorded in a decision record, and that Level 4 Autonomous is never used for offensive or irreversible actions.

GV.PO-02 asks for review when circumstances change (19, NIST, 2024), and Implementing Regulation (EU) 2024/2690 expects the security policy to be reviewed at least annually and when significant incidents or significant changes to operations or risks occur (4, European Commission, 2024). Following AI Governance, Chapter 8, which concluded that classification should be triggered by change rather than the calendar (72, Nordqvist, 2026), the triggers are a new usage mode in security work, a proposed change of autonomy level, a new or silently changed model, an incident, finding or failed chaos experiment showing that a rule did not hold, and a new obligation, with an annual review only as backstop.

Duties that require testing and monitoring

For most organisations this book addresses, testing and monitoring are not discretionary, and each test should show which obligation it serves.

NIS 2. Article 21 requires essential and important entities to take appropriate and proportionate measures to manage the risks to their network and information systems, and Article 21(2) lists, among others, incident handling, supply-chain security, vulnerability handling and disclosure, and policies to assess the effectiveness of those measures (3, European Union, 2022). That last item is the legal anchor for testing: an entity that cannot show its measures are effective has not met the obligation. Article 23 adds incident reporting, which presupposes monitoring that detects incidents in time. For certain digital entities, including managed security service providers, Implementing Regulation 2024/2690 specifies the measures, including security testing and the assessment of effectiveness (4, European Commission, 2024), and ENISA's guidance gives examples of evidence (8, ENISA, 2025). Its customers gain a concrete basis for asking about a provider's testing and use of AI.

DORA. Article 24 requires financial entities, other than microenterprises, to maintain a digital operational resilience testing programme and to test systems supporting critical or important functions at least yearly (2, European Union, 2022). Article 26 requires entities identified by their competent authorities to carry out threat-led penetration testing at least every three years on live production systems, including relevant ICT third-party providers, ending with remediation plans and an attestation; Article 27 sets requirements for testers. AI Platform and Security, Chapter 17, concluded that threat-led testing is periodic and continuous suites complement it (73, Nordqvist, 2026), so the continuous automated red teaming of Chapter 12 and the chaos engineering of Chapter 25 belong in the Article 24 programme, each under its own rules of engagement.

Cyber Resilience Act. Part II of Annex I requires manufacturers of products with digital elements to address vulnerabilities without delay, test security regularly and maintain a coordinated vulnerability disclosure policy (5, European Union, 2024); Article 14 reporting applies from 11 September 2026 and the Regulation in full from 11 December 2027. Most organisations here use rather than manufacture security products; nevertheless, procurement can require suppliers to show their vulnerability handling, and the policy must say how a red-team finding in a supplier's product reaches its disclosure channel, by a named role, withheld until addressed.

The table maps the Category's outcomes to these obligations as architectural implications, not legal advice.

Policy outcome NIS 2 and 2024/2690 DORA Cyber Resilience Act AI Act
Policy approved and owned Article 20; Annex security policy Article 5 Manufacturer obligations Provider and deployer duties assigned
Effectiveness tested Article 21(2); Annex security testing Articles 24 to 27 Regular security testing Article 15 for high-risk systems
Vulnerabilities handled Article 21(2) ICT risk-management framework Annex I Part II, Article 14 Article 15 resilience against manipulation
Monitoring in place Article 23 reporting Incident detection and reporting Severe-incident reporting Post-market monitoring

Threat-led testing: DORA TLPT and TIBER-EU

TIBER-EU, the European Central Bank's framework for threat intelligence-based ethical red teaming, structures a test in a preparation phase that agrees scope and procures providers, a testing phase in which targeted threat intelligence becomes scenarios executed against live production systems, and a closure phase in which red and blue teams replay the test and the entity produces a remediation plan (13, ECB, 2025). The white team, which TIBER-EU calls the Control Team, is a small group that knows about the test and can order it to be halted, the blue team is not informed in advance, the threat-intelligence provider and red team are normally external, and the authority's test managers oversee the test. The policy should define the white team's composition, decision rights and availability.

AI Platform and Security, Chapter 18, observed that adversary emulation including AI-enabled techniques is a natural extension of DORA threat-led penetration testing and left open how it is kept safe (73, Nordqvist, 2026). Chapter 12 answers the practical part; for policy, AI enters a threat-led test in four places, each needing an explicit decision in the rules of engagement. In threat intelligence, the entity's information must not reach an unapproved model. In scenario design, threat reporting describes adversaries using AI to research target organisations and people (46, Google GTIG, 2025) (36, ANSSI, 2026), and ENISA records AI-enabled activity across the landscape (34, ENISA, 2026), so the white team decides which AI-enabled technique classes are in scope. In red-team tooling, AI in Modes 1 to 3 stays under the red team's accountability, but AI that executes emulation steps behaves like a Mode 5 system and needs a permission manifest, separate credentials and a stop path. And as the target, the entity's own AI systems are part of the attack surface (Chapter 13).

Because the test runs on live production systems, AI participation raises the stakes of every safeguard. AI Governance, Chapter 19, concluded that the July 2026 incident failed through correlated controls: a shared credential, a package mirror that was also an egress path, and an alert to which responders replied that stopping the run was not required (72, Nordqvist, 2026) (64, OpenAI, 2026); the agents involved operated in a security-testing context and acted beyond the scope that was intended (64, OpenAI, 2026). The rules of engagement must therefore require credentials shared with no other system, egress restricted to the targets, and stop conditions that reach the white team directly.

The AI Act, data protection and labour law

Security AI is AI, security telemetry is often personal data, and a tool that watches the estate often watches employees.

When a security tool is an AI system

Article 3(1) of the AI Act defines an AI system as a machine-based system designed to operate with varying levels of autonomy, which may exhibit adaptiveness after deployment and which infers from its input how to generate outputs such as predictions, content, recommendations or decisions (1, European Union, 2024); the recitals exclude systems based on rules defined solely by people. A fixed detection rule is therefore not an AI system, while a machine-learning verdict in an endpoint product, an anomaly model in a SIEM and every language-model assistant or agent are, and the policy should require every security tool, including vendor-enabled Mode 0 features, to be classified in the AI register.

Most security AI will not be high-risk, and the recitals state that components intended solely for cybersecurity should not qualify as safety components in critical infrastructure. The exceptions that matter for a SOC are Annex III point 4, which covers AI that monitors and evaluates the behaviour of people in work relationships and can bring insider-threat analytics and user-behaviour scoring into scope, and point 1 on certain biometric uses; Article 5 also prohibits inferring emotions in the workplace, except for medical or safety reasons. Some obligations apply whatever the class: Article 4, as replaced by Regulation (EU) 2026/1744 (the Digital Omnibus on AI), requires providers and deployers to take measures to support the development of AI literacy among staff who operate AI systems (75, European Union, 2026), an organisation that builds its own security AI is its provider, and Article 15 requires high-risk systems to resist attempts by unauthorised third parties to alter their use, outputs or performance, which makes adversarial testing part of compliance. For the general-purpose models used in offensive work, AI Platform and Security, Chapter 20, concluded that Article 55 adversarial testing falls on providers of models with systemic risk, while deployers ask for evidence and test the compound system (73, Nordqvist, 2026); the General-Purpose AI Code of Practice gives providers a way to demonstrate compliance (6, European Commission, 2025). A red team's choice of model is therefore a supplier decision.

Telemetry, personal data and works councils

Logs, alerts, email headers and case notes routinely contain personal data, and in health and insurance settings special-category data. The GDPR (9, European Union, 2016) applies whether a person or an AI processes it, so the policy records, for each capability and each exercise, the purpose, legal basis, data categories, retention and location of processing, with the same rules for exercise telemetry as for operational telemetry. Model location (Chapter 4) becomes a constraint on which models may receive which data. Public authorities must also classify rules of engagement and test reports when they are created, because public-access rules may otherwise make them requestable.

Monitoring employees also engages labour law. In Germany, Section 87(1) no. 6 of the Works Constitution Act (BetrVG) gives the works council a right of co-determination over the introduction and use of technical devices that are "dazu bestimmt", designed, to monitor the behaviour or performance of employees (76, Germany, n.d.); the Federal Labour Court reads "designed" objectively, so that a device is designed to monitor when it is objectively suitable for collecting or recording behaviour or performance information about employees, whatever the employer intends (77, BAG, 2024). A security tool that collects such information about analysts or other staff is therefore in scope even if it was bought for another purpose. Works councils have information, consultation or co-determination rights on such systems under national rules in other countries as well, and under Article 26(7) of the AI Act deployers who are employers must inform workers' representatives and affected workers before putting a high-risk AI system into service at the workplace (1, European Union, 2024). The architectural implication is a rollout gate per legal entity in the policy-as-code layer: a monitoring capability, or an exercise touching employees' accounts or endpoints, goes live in an entity only once its consultation is recorded as complete.

Acceptable use of offensive AI capabilities

The capabilities that let a red team emulate an AI-enabled adversary are the capabilities an adversary would use. Research has shown that a language-model agent given the description of a known vulnerability can exploit it (56, Fang et al., 2024), and threat reporting tracks adversaries' use of AI as it moves from assistance towards autonomy (48, Google GTIG, 2026). AI Platform and Security, Chapter 25, concluded that every AI system must be designed twice, as something to protect and as something to contain (73, Nordqvist, 2026), and offensive AI capabilities are the clearest case. The policy therefore treats reconnaissance pipelines, vulnerability-discovery models, emulation agent frameworks and scenario libraries as dual-use controlled assets, under six rules:

  1. Register each in the asset inventory with an owner and a classification, and restrict access to named red-team members and the platform's service identities, reviewed quarterly.
  2. Bind to a mandate: the policy decision point refuses any action that cannot be tied to a valid, signed rules-of-engagement manifest.
  3. Contain offensive AI in isolated ranges with task-scoped credentials, default-deny egress and an external stop path, as AI Platform and Security, Chapter 19, requires.
  4. Log every prompt, tool call and output as exercise evidence available to the white team.
  5. Limit autonomy to Level 2 Supervised, or Level 3 Bounded for catalogued, reversible emulations in a standing programme; Level 4 Autonomous is never used.
  6. Stay inside the perimeter: use offensive AI only against own or contracted systems (Chapter 19 explains why retaliation is out of scope), build nothing beyond the approved scenario, and end every exercise with a defensive improvement.

For defenders, the most common failure is an analyst pasting alert data into an unapproved assistant for a quick summary. The acceptable-use standard for Modes 1 and 2 names the approved tools, lists the data that must never be entered (alert payloads, case material, credentials, personal data beyond the tool's approval) and states that a person verifies every output used in a decision, explaining why: an email, a log line or a sample can carry text crafted to steer a model that reads it (14, OWASP, 2025). For Mode 3, acceptable use becomes the skills and connector catalogue, and for Modes 4 and 5 it lives in decision records and permission manifests, because no person stands between instruction and action.

Rules of engagement as code

Rules of engagement are the gate through which all offensive work passes, as Figure 7.1 shows. When AI takes part, actions happen faster than a person can consult a document, the AI may propose actions no one planned, and its transcripts become part of the record, so the rules must be machine-readable and enforced. A manifest names approvers, including every target-system owner; the window; the parties; the scope, with technique classes expressed by ATT&CK tactic or ATLAS technique rather than by procedure (10, MITRE, n.d.) (11, MITRE, n.d.); AI participation, meaning models, hosting, maximum autonomy level, credentials, egress and logging; safeguards; stop conditions and an out-of-band stop path; deconfliction, so that a real incident is never dismissed as a test; and the evidence and its route to the purple loop of Chapter 26.

The manifest lives in version control. A change is a pull request reviewed by the white team and signed by role, and a change during an exercise produces a new version that must be signed before the policy decision point accepts it, while the previous version remains as evidence of what was authorised when. This is the discipline Architecture as Code applies to infrastructure changes (71, Nordqvist, 2025). Enforcement follows the condition AI Platform and Security, Chapter 25, set for a platform under control: every model and tool call passes a policy point outside the model (73, Nordqvist, 2026). The policy decision point thus checks every AI-proposed action against the signed manifest's approvals, window, scope, tactics, autonomy level, human approval and stop flag. A refused action is logged with the manifest version, and because an AI action outside the plan is a stop condition, it reaches the white team at once.

Practical guide: Drafting rules of engagement for an exercise that uses AI

Purpose. Produce an enforceable manifest before any exercise in which AI proposes or executes offensive actions.

Roles. White-team lead (owner), CISO and target-system owners (approvers), test lead, data-protection officer, platform team and, where employees are touched, their representatives.

Steps.

  1. Record the obligation the exercise serves and the evidence it must produce.
  2. List systems in and out of scope by inventory identifier, express permitted techniques by ATT&CK tactic or ATLAS technique, and prohibit impact techniques against production by default.
  3. Default AI participation to Level 2 Supervised, each action approved by the test lead.
  4. Require window-bound task-scoped credentials, an egress allowlist, full transcript logging, synthetic accounts and per-target rate limits.
  5. Write machine-detectable stop conditions, name the stop-path holders and test the out-of-band channel.
  6. Define deconfliction, classification, retention and the purple session that receives findings.
  7. Merge, sign, load into the policy decision point, and confirm that a dry-run out-of-scope action is refused.

Definition of done. The manifest is signed, an out-of-scope test action is refused, the stop path is tested end to end, and findings route to a dated purple session.

Worked example: Rules-of-engagement manifest RoE-NR-2027-001

The illustrative manifest below, abridged from Appendix A, governs Nordvik Region's first threat-led exercise against its citizen-facing services. The production scoring of the benefits-triage system, a high-risk AI system, is out of scope, so the exercise cannot affect decisions about residents.

kind: RulesOfEngagement
id: RoE-NR-2027-001
version: 1.1.0
approvedBy:
  - {role: chief-information-security-officer, date: 2027-02-22}
  - {role: head-of-benefits-unit, date: 2027-02-23}
window:
  start: 2027-03-08T07:00:00+01:00
  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
  blueTeam: nordvik-security-analysts-and-mssp   # not informed of timing
scope:
  inScope: [citizen-service-assistant, benefits-explanations-service, staff-identity-provider-test-tenant]
  outOfScope: [benefits-triage-production-scoring, third-party-systems, personal-data-exfiltration]
  permittedTactics: [reconnaissance, initial-access, credential-access, discovery, lateral-movement, collection]
  prohibitedTactics: [impact]
aiParticipation:
  maxAutonomyLevel: 2                 # each AI-proposed action approved by the test lead
  models: [self-hosted-open-weight]   # no external model receives Nordvik data
  egress: allowlist-range-only
  logging: full-transcript-to-white-team
dataProtection:
  legalBasis: gdpr-art-6-1-e-public-task
  classification: confidential-security-exempt-from-disclosure
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
evidence:
  retentionMonths: 60
  findingsTo: purple-session-2027-q2

Self-hosted models keep personal data in exercise telemetry inside the Region, and every AI-proposed action needs the test lead's approval, the Level 2 Supervised ceiling in the Region's programme charter. The MSSP's shift lead holds the stop path because the MSSP monitors out of hours. Each gap the blue team missed becomes a control in the purple session, verified by re-running the scenario.

Across the usage modes

Policy must reach every mode, with the instruments set out earlier (see Chapter 6).

Mode Characteristic vulnerability Who judges, with whose identity
Mode 0 Ambient AI Vendor-changed features act outside the policy The vendor's model, the product's identity
Mode 1 Conversational assistants Sensitive data pasted into unapproved tools; steering text A person, own identity
Mode 2 Embedded workplace assistants Delegated access wider than the task A person, delegated identity
Mode 3 Agentic work tools Engineer's credentials used between instruction and review A person reviews, engineer's identity
Mode 4 Built AI applications Manipulated inputs; scope creep beyond the recorded purpose A person per the level, service identity
Mode 5 Autonomous production agents Well-meaning insider outside scope; correlated control failure Policy decision point and stop-path holders, own identity

Across the autonomy levels

The level determines the approvals required (see Chapter 6).

Level Defensive use under the policy Offensive use under rules of engagement
Level 0 Advisory Suggestions to analysts AI proposes scenarios; people act
Level 1 Assisted A person executes AI drafts The tester executes prepared steps
Level 2 Supervised Each action approved Default ceiling: each step approved by the test lead
Level 3 Bounded Reversible actions, decided by the AI governance board Only catalogued, reversible emulations in a standing programme
Level 4 Autonomous Never for irreversible actions Never used

Verifying with security chaos engineering

An enforced policy must be shown to refuse what it forbids. The experiment injects synthetic actions from a test AI participant outside a signed manifest: an out-of-scope target, an action after the window, and an action while a stop flag is set. The steady-state hypothesis is that the policy decision point refuses every variant before any request reaches the target, logs the refusal with the manifest version and notifies the white team within five minutes. Chapter 25 describes the platform and its safety boundaries.

The three AI focus areas

Securing AI systems. Policy sets the security requirements for the organisation's AI systems, aligned with Article 15 of the AI Act for high-risk systems, and makes their adversarial testing a scheduled duty (1, European Union, 2024).

AI-enabled cyber defence. Defensive AI acts within decision records and permission manifests, offensive AI capabilities are controlled assets bound to rules of engagement, and the right to raise either's autonomy rests with named decision tiers (20, NIST, 2025).

Thwarting AI-enabled attacks. Rules of engagement let AI-enabled emulation reproduce reported adversary techniques safely and with evidence.

Nordvik Region and Hansa Mutual

Nordvik Region works under one public-law regime and the national transposition of NIS 2, which keeps its policy short: acceptable use of the conversational assistant in Mode 1 with no alert data pasted into it, decision records for Mode 4 capabilities such as NR-SEC-001, and no security AI acting with an identity of its own. Its first threat-led exercise runs under RoE-NR-2027-001, and because its MSSP falls directly under Implementing Regulation 2024/2690, the Region uses the Regulation and the ENISA guidance as the checklist for what it asks the provider to evidence.

Hansa Mutual aligns DORA threat-led penetration testing under TIBER-DE with the UK and Swiss regimes and with works-council consultation in Germany, the Netherlands and Sweden. RoE-HM-2027-TLPT governs the largest exercise, the same format governs the continuous automated red teaming of HM-SEC-004, and any move of HM-SEC-001 to Level 3 Bounded is a decision of the group AI governance board. The difference lies in the number of regimes the rules of engagement must satisfy; the artefact itself is the same.

Summary

GV.PO Policy for AI in cyber defence must cover every usage mode and be enforceable: acceptable use for Mode 1 and Mode 2 assistants, a governed catalogue for Mode 3 agentic work tools, decision records for Mode 4 built AI applications, and permission manifests and rules of engagement for Mode 5 agents and offensive AI. The policy has three layers, a statement, standards per mode and rules as code, and is reviewed when something changes. Raising a security AI to Level 3 Bounded is a decision of the AI governance board, and Level 4 Autonomous is never used for offensive or irreversible actions.

Testing is a duty under NIS 2 and DORA, with threat-led testing run by a white team under TIBER-EU; security AI is AI under the AI Act, telemetry is personal data, and monitoring engages works councils. Offensive AI capabilities are dual-use assets to be registered, restricted, bound to a mandate, contained and logged, and rules of engagement are a signed, versioned artefact enforced for every AI action, which the chapter's chaos experiment verifies. Chapter 8 turns to oversight by the management body and to the risks that enter through the AI supply chain.

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. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
  4. 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)
  5. European Union Agency for Cybersecurity. Technical implementation guidance on Commission Implementing Regulation (EU) 2024/2690. (8, ENISA, 2025)
  6. 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)
  7. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. (13, ECB, 2025)
  8. 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)
  9. 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)
  10. European Commission. The General-Purpose AI Code of Practice. (6, European Commission, 2025)
  11. Google Threat Intelligence Group. Adversarial Misuse of Generative AI. (46, Google GTIG, 2025)
  12. ANSSI and CERT-FR. L'IA générative face aux attaques informatiques: synthèse de la menace en 2025. (36, ANSSI, 2026)
  13. European Union Agency for Cybersecurity. ENISA Threat Landscape 2026. (34, ENISA, 2026)
  14. Google Threat Intelligence Group. GTIG AI Threat Tracker: From Prompting to Autonomy – The Evolution of Adversarial AI. (48, Google GTIG, 2026)
  15. Fang, R., Bindu, R., Gupta, A. and Kang, D. LLM Agents can Autonomously Exploit One-day Vulnerabilities. (56, Fang et al., 2024)
  16. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (14, OWASP, 2025)
  17. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (10, MITRE, n.d.)
  18. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (11, MITRE, n.d.)
  19. OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)
  20. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
  21. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
  22. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)
  23. 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)
  24. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). (75, European Union, 2026)
  25. Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), § 87 Mitbestimmungsrechte. (76, Germany, n.d.)
  26. Bundesarbeitsgericht. Beschluss vom 16. Juli 2024, 1 ABR 16/23 (Headset-System). (77, BAG, 2024)