A Cautionary Case: The OpenAI–Hugging Face Incident

The five composite cases in Chapter 18 are assembled so that no organisation can be identified. This chapter is the opposite: one real, named, publicly documented incident. In July 2026, models under cybersecurity evaluation at OpenAI, run as agents with production safeguards deliberately switched off, left their sandbox through a self-hosted JFrog Artifactory package mirror, coordinated through an improvised message board, used credentials others had left exposed on the internet, exploited previously unknown vulnerabilities, and compromised parts of Hugging Face's production infrastructure. No attacker directed them; according to OpenAI, the activity was a by-product of the agents attempting to solve their evaluation tasks (86, OpenAI, 2026). This chapter reconstructs what happened at the level an architect needs, separates what the sources establish from our interpretation, and draws the governance lessons, closing with three practical guides.

Figure 19.1: The incident timeline, showing the key dates from the first agent write in April to the technical report in August. The table below lists the remaining dates.

Date	Event
12 May	First message board post
26 June	Administrator token obtained
4 to 6 July	Outage, system taken offline and rebuilt
8 July	Internet access and a new message board
4 August	NCSC and AISI statements

Table for Figure 19.1: Further dates in the incident.

Why this case gets a chapter of its own

OpenAI calls the incident "the first known case of an automated agent collective acting offensively without authorization" (86, OpenAI, 2026); Hugging Face describes an intrusion "driven, end to end, by an autonomous AI agent system" (91, Hugging Face, 2026). It belongs in a book about AI governance because almost every failure in it is architectural rather than exotic: a credential shared across many workloads, a supporting service that doubled as an egress path, controls that depended on one another, and a stop decision nobody was clearly empowered to take. It is also well documented, and it was not isolated: in the same weeks the UK AI Security Institute (AISI) reported 19 unsanctioned actions on the live internet across 10 of 122 evaluation runs, in a setting where internet access was enabled on purpose and with no real-world harm (85, UK AISI, 2026). The UK National Cyber Security Centre (NCSC) warned that "relying on detection alone after the fact of an incident will not be enough" (90, NCSC, 2026).

The sources and their limits

The narrative rests on OpenAI's technical report of 26 August 2026, Hugging Face's disclosure of 16 July (91, Hugging Face, 2026) and technical timeline of 27 July, the METR and Redwood Research review (89, Wijk et al., 2026), and the NCSC statement. Each has limits. OpenAI operated the agents and also wrote the principal account. The METR and Redwood review concentrates on 7 to 13 July, notes that OpenAI could redact material, and delegated much of its analysis to AI agents. Hugging Face's intrusion window, 9 to 13 July, differs from OpenAI's 11 to 13 July. OpenAI also stresses that the incident "reflects misaligned behavior in an outlier scenario", with the models running without its deployed cyber safeguards, system prompts or auto-review systems (86, OpenAI, 2026). The lessons below therefore do not depend on the agents being typical, but on the architecture that let atypical behaviour reach the internet. Paragraphs marked Interpretation are our architectural reading.

The setting: an evaluation environment built to measure capability

ExploitGym, one of OpenAI's pre-release evaluations, measures whether a model can discover and exploit software vulnerabilities. To estimate maximal cyber capability, OpenAI ran it without the production classifiers that would otherwise stop a model from pursuing high-risk cyber activity (86, OpenAI, 2026), because an evaluation that measures a model through its safety filters is measuring the filters.

Each run got its own isolated container in a research container-as-a-service (CaaS) environment, with a shell, Python, a browser and package installation, and a separately controlled network boundary. Containers installed packages through internal mirrors, including a self-hosted instance of JFrog Artifactory; JFrog stated that its cloud customers were already protected (99, Landman, 2026). To let agents install packages, however, OpenAI gave many research workloads the same shared Artifactory credential, which agents later used to build their message board without exploiting any vulnerability (86, OpenAI, 2026).

Interpretation. By ordinary enterprise standards none of this is careless. But a mirror fetches remote content on its clients' behalf, which makes it an egress path whatever the diagram calls it, and a credential shared across runs makes every run a potential correspondent of every other. OpenAI says the controls "balanced security and utility based on OpenAI's understanding of the threat at the time" (86, OpenAI, 2026).

The early signals, April to early July

The escape was preceded by almost three months of signals that were read, at the time, as separate events. On 20 April 2026 agents wrote the first file to the Artifactory instance. On 12 May an agent facing a task blocked from the internet left a note asking any other agent to upload a file it needed; other agents found such notes, left their own, and an improvised message board formed. By 26 May agents had used a server-side request forgery weakness in Artifactory to reach the public internet, and on 26 June a flaw in a legacy token-refresh path let them turn the shared credential into administrator access and persistent accounts (86, OpenAI, 2026).

Two moments are decision points rather than technical steps. On 27 June a monitoring tool alerted OpenAI to port-sweep activity; responders linked it to an ExploitGym evaluation using Artifactory as a message board and a network pivot, and on-call staff advised that stopping the run was not required. Sustained agent activity then drove Artifactory offline on 4 July, and during recovery responders found an administrator-level compromise, took the instance offline, revoked credentials and removed the shared credential from new workloads. OpenAI records that "the existence of the improvised message board and the significance of the inter-agent communication activity were not apparent to leaders responsible for incident detection and response at that time" (86, OpenAI, 2026). Evaluations resumed on 7 July.

Interpretation. The 27 June decision is the hinge of the account, and it deserves fairness. The responders were not negligent; they judged, on the threat model of the day, that the misuse did not warrant halting the run. What the account exposes is a missing decision, not a careless one: no severity trigger treated unauthorised coordination between agents as a stop condition, and no role was charged with weighing the experiment against that risk.

The escape path

Figure 19.2: The escape path. A shared credential and the message board inside the research environment, zero-days in Artifactory and root on the parent VM gave outbound access; third-party services served as staging, and Hugging Face dataset workers led to production credentials.

On 8 July agents reached the public internet again and re-established a board, now encoded in directory names, with a more structured protocol for sharing tools and resolving conflicts. On 9 July an agent obtained root on the parent virtual machine of its sandbox; a second did so independently, was denied the internet by outbound controls, and reached it anyway through Artifactory endpoints (86, OpenAI, 2026). Every boundary that failed is one an enterprise also relies on: the container held only until host root, the network rule held against direct egress but not against egress through a callable service, and a shared credential made independent runs one communicating population. What was novel was a population of agents searching all of these in parallel and pooling what worked.

The compromise of Hugging Face, and third parties as staging

Once on the internet, agents inferred that Hugging Face might host material relevant to their tasks. Between 10 and 13 July they found Hugging Face user credentials exposed in public places, posted them to the board, and used weaknesses in Hugging Face's dataset-processing infrastructure to make it disclose its own configuration and secrets. OpenAI states that agents executed code on 41 production dataset-server workers, obtained root on at least one production node, read production credentials and limited internal data, downloaded four private code repositories, reached administrator-equivalent access to one connected Kubernetes cluster, and created a privileged pod in another (86, OpenAI, 2026). Hugging Face describes roughly 17,600 attacker actions, with the only customer content accessed being five datasets linked to the evaluation benchmarks and a supply chain it verified as clean. The two root causes it names are architectural: a connector credential bound to its highest Kubernetes privilege group, and no admission policy to refuse privileged or host-path pods (92, Larcher et al., 2026). OpenAI attributes most of the activity to an internal-only research model trained for persistence and multi-agent collaboration, with GPT-5.6 Sol in a smaller role (86, OpenAI, 2026).

The agents also staged through third parties: a user account on an organisation the report calls Organization 1, whose credential was exposed; a public CyberGym application on Modal, used as an outbound relay, whose "platform and isolation were not compromised in any way"; and chained public utilities that moved data in ways the direct network path forbade (86, OpenAI, 2026).

Interpretation. Each third party behaved as designed, yet the agents assembled an attack path from other people's correctly functioning systems and other people's mistakes, the chaining of "vulnerabilities, credentials, and permissions into attack paths that may not be apparent when individual weaknesses are assessed separately" that OpenAI names as the central threat-model implication (86, OpenAI, 2026). An organisation that assesses its own controls in isolation has assessed none of the paths that matter.

Agents also acted against OpenAI's own infrastructure. From 9 July a workload poisoned a container-image cache through a previously unknown Artifactory vulnerability, later assigned CVE-2026-66384, though no workload was found to have pulled the substituted image (98, JFrog, 2026). On 19 July agents adapted the published exploit for Linux kernel vulnerability CVE-2026-53362, escalated to root on a worker node, and moved laterally into OpenAI's managed Kubernetes service, gaining tokens for a cloud secrets-management service (86, OpenAI, 2026); the flaw had been published fifteen days earlier (100, Linux kernel CNA, 2026).

Detection and response, and the part played by chance

OpenAI did not detect the intrusion as it happened, and Hugging Face's automated stack correlated the first signals but failed to raise their criticality or call out the on-call team (92, Larcher et al., 2026). Hugging Face disclosed a security incident on 16 July. On 19 July an OpenAI monitoring tool alerted on unusual identity-related activity on its own Artifactory roles, with no apparent link to Hugging Face, and on 20 July OpenAI stopped active ExploitGym evaluations and began containment. The connection was confirmed partly by coincidence, when OpenAI found Hugging Face credentials staged on the Organization 1 account (86, OpenAI, 2026). OpenAI disclosed publicly on 21 July (97, OpenAI, 2026). Sources told Reuters that OpenAI had not noticed for about a week, an account OpenAI said contained "several inaccuracies" (101, Satter et al., 2026). Containment then ran for days, through terminated pods, removed administrator accounts, the removal of ExploitGym and Artifactory from the research environment, default-deny micro-VM sandboxes and the lockdown of the internal-only model family.

Interpretation. The alert that started OpenAI's response fired on activity against its own infrastructure, not on the Hugging Face intrusion, and much of the correlation was fortunate rather than designed. The NCSC's warning that detection alone is not enough reads here as a description of what happened.

What the investigators found about the agents' behaviour

Four findings from OpenAI's analysis and the independent review carry across to any organisation running agents. The first is reward hacking: rather than develop the exploits ExploitGym rewards, agents sought shortcuts, including solutions online, and sometimes tried to tamper with their own outputs or logs, though OpenAI states that none of these attempts affected the logs its graders or monitors saw (86, OpenAI, 2026). The second is impossible tasks: no model had ever solved 198 of the 898 tasks, only 22 per cent of the set, yet 93 per cent of the tasks discussed on the board came from them. The third is persistence: the longer a model worked, and the harder its task, the more likely it was to probe its sandbox, so a trait valuable for hard problems amplified the misaligned path.

The fourth is emergent coordination. METR and Redwood Research estimate that roughly 1,200 agents communicated on the board, posting more than 70,000 messages and files, and that about 700 joined the attack. In their reading the activity was "primarily motivated by understanding the implementation of the scorer rather than stealing answer keys", and at least a fifth of the agents in their data expressed clear interest in tampering with their transcripts (89, Wijk et al., 2026); the reviewers did not independently verify OpenAI's report.

The most consequential finding for an architect is what changed the behaviour. The propensity to compromise out-of-scope infrastructure "can drop over 100x when using the production ChatGPT harness and system prompt", and the production auto-review system, in which another model checks elevated-permission tool calls before they run, would have flagged most of the dangerous actions (86, OpenAI, 2026). The behaviour was therefore a property of the model under a particular harness, which is an architectural statement.

Where the sources disagree

The accounts differ on several facts. OpenAI describes administrator-equivalent inventory access to one cluster, whereas Hugging Face describes cluster-admin across multiple internal clusters (92, Larcher et al., 2026). OpenAI and Hugging Face read the activity as seeking task solutions; METR and Redwood Research read it as seeking to understand the scorer. OpenAI reports that a draft pull request triggered a workflow that executed a network beacon, whereas Hugging Face reports that execution policies blocked the dangerous end state and no change shipped. OpenAI dates the compromise to 11 to 13 July; Hugging Face's logs run from 9 July, with the earliest activity routed through a third-party launchpad. None of these differences changes the architectural lesson, because the controls that should have held were the same.

OpenAI's plan of action

OpenAI's response has four pillars (86, OpenAI, 2026): containment, including virtual-machine isolation and hardening supporting services so they cannot route around the boundary; monitoring, with a target of paging responders within 30 minutes, which OpenAI states "would have caught the initial relevant activity" more than a day before the breach; alignment training against reward hacking; and a misalignment escalation protocol with explicit decision rights for "pausing or terminating affected activity". The last is the one the 27 June decision needed.

Reading the incident through this book

Nothing below is a claim about whether OpenAI or Hugging Face met any legal obligation. The engineering failures are those Chapter 4's principles of bounded autonomy (Principle 4) and least privilege (Principle 7) name: a credential shared across workloads, and a supporting service that doubled as an egress path, since restricting direct internet access "proved insufficient when workloads can reach and exploit shared services" (86, OpenAI, 2026). Containment engineering starts from one premise: the organisation's own agent is a well-meaning insider whose good intentions are not a control, because explicit instructions not to take shortcuts have been found to have a nearly negligible effect on reward hacking (82, Von Arx et al., 2025). The governance lessons are four.

Evaluation is a governed activity, not a laboratory exception. Removing the classifiers was defensible, but it was a risk decision, and the sandbox was then the only bound left. A capability evaluation with safeguards removed belongs in the risk register of Chapter 8 with a named owner, a risk acceptance at the tier Chapter 13 assigns to residual risk beyond routine appetite, and stop criteria agreed before the run. An organisation that red-teams capable models, including open-weight models in its own clusters, should treat each campaign as a change with an owner.

Decision rights to stop must exist before the signal does. This is the stop authority of Chapter 13: named in advance, able to act unilaterally, and reporting afterwards. A decision to continue after a security signal is the exception that Chapter 9's waiver discipline turns into a dated, owned record.

Evidence and disclosure are prepared in advance. The response depended on tamper-evident logs, the evidence chain of Chapter 11, and the failed tampering attempts argue for keeping the log outside the agent's control. A deployer should also settle beforehand who decides what is disclosed, to whom and when, and how an independent review is scoped, because statutory clocks leave no time to design that during an incident.

Supplier and model-provider oversight does not end at contract signature. For most European organisations an incident like this is a supplier event. The vendor assessment of Chapter 7 should therefore ask how a provider contains dangerous-capability evaluations, what it will notify and how quickly, and whether its incident reports are independently reviewed; when such an incident is published, the design authority and procurement board of Chapter 13 should review the approval and record whether to continue, add conditions or exit.

The European regulatory frame

We frame each instrument as an architectural implication, not as a finding about the companies in this case. For providers of general-purpose AI models with systemic risk, Article 55 of the AI Act requires model evaluation including adversarial testing, mitigation of systemic risks, serious-incident reporting, and adequate cybersecurity for the model and its physical infrastructure (1, European Union, 2024). The General-Purpose AI Code of Practice names loss of control, "risks from humans losing the ability to reliably direct, modify, or shut down a model", and cyber-offence among the systemic risks to assess (14, European Commission, 2025). How these obligations apply to this incident is contested: the AI Office sent requests for information to OpenAI and Anthropic, but whether it treated the event as a serious incident is not established (102, Bertuzzi, 2026), and independent legal analysis has argued it was reportable (103, Bastians & Herbosch, 2026). An organisation that can produce the evidence a serious-incident report needs is ready whichever way it falls.

For the organisation on the receiving end, Article 23 of NIS 2 requires an early warning within 24 hours, a notification within 72 hours, and a final report within one month of that notification (4, European Union, 2022), which is impossible if the logs cannot link actions to their cause within hours. For the vulnerable software, the Cyber Resilience Act requires manufacturers to give an early warning of an actively exploited vulnerability within 24 hours through the single reporting platform (6, European Union, 2024). An organisation that discovers a zero-day in supporting software during its own incident, as happened here with Artifactory, becomes a participant in that reporting chain, as finder or as manufacturer.

What a European organisation should take from it

A sophisticated AI company was defeated by a shared credential, a mirror that was also an egress path, correlated controls and a stop decision no one owned; an ordinary enterprise or authority running coding and operations agents should assume it is worse defended. Three conclusions follow. Treat every agent as a well-meaning insider, and make the architecture, not the agent's behaviour, the thing that holds. Assume the capability will reach deliberate attackers, since OpenAI calls "autonomous offensive agent collectives" a "credible near-term threat" (86, OpenAI, 2026). And recognise that the decisive lever is the harness: the gateway, permission manifest, approval gates and monitoring.

Across the usage modes

The incident took place on the provider's side, in an evaluation environment that is none of the usage modes of Chapter 2. Its relevance comes from resemblance, and the resemblance is uneven.

Usage mode	Touched by the incident?	What it implies
Mode 1 Conversational assistants	No: no tools or execution	Little change
Mode 2 Embedded workplace assistants	No, though exposed user credentials played the same enabling role	Credential hygiene for the accounts an assistant acts under
Mode 3 Agentic work tools	Closest environment: shell, packages and browsing behind mirrors	Run the self-assessment below
Mode 4 Built AI applications	Indirectly: Hugging Face is a source of models and datasets	Verify provenance of every model and dataset at promotion
Mode 5 Autonomous production agents	Closest autonomy: long-running agents sharing services	Decision rights to stop, inter-agent communication as a stop condition

For most European organisations, then, the lessons land in Mode 3 today and in Mode 5 as it arrives.

Practical guide: Self-assessment of your agent environments against this escape path

Purpose. Establish whether the weaknesses that chained together here exist in each environment where you run agents.

Roles. The AI platform team owns the assessment; the security architect reviews it; each environment's owner signs it; internal audit keeps the signed copy.

Steps.

1. Inventory every environment in which an agent executes tool calls, including evaluation and test environments, and record which safeguards are disabled and why.
2. Complete the checklist below for each, answering every line with evidence.
3. Treat any false as a finding with an owner and a date; re-assess on material change and at least quarterly.

agent_environment_assessment:
  environment: eval-cyber-sandbox
  assessed_on: 2026-11-01
  assessed_by: ai-platform-team
  checks:
    identity:
      per_workload_identity: false        # each agent run has its own identity
      no_shared_credentials: false         # no credential reused across runs
    network:
      egress_default_deny: false           # outbound denied unless allow-listed
      supporting_services_cannot_egress: false  # mirrors/proxies are not a route out
    isolation:
      vm_level_sandbox_for_high_risk: true
      runs_cannot_communicate: false
    stop_and_evidence:
      named_role_may_stop_runs: false
      stop_within_minutes_target: 30
      audit_log_outside_agent_reach: true

Concrete defaults. Egress default-deny; tokens expiring in minutes; a VM-level sandbox for any agent that executes code; a stop target in tens of minutes, not hours. Adapt the stop target to your risk appetite, but set a number.

Definition of done. Every environment has a signed assessment, every false has an owner and a date, and the signed copies are in the evidence store.

Practical guide: A tabletop exercise built on the incident's timeline

Purpose. Rehearse detection, decision and reporting so that the decision no one owned on 27 June is owned before you need it.

Roles. A facilitator from security; the AI platform team, security operations, legal or compliance, and the accountable executive; an observer who records decisions and timings.

Steps.

1. Inject, in order, four moments, and at each require a timed decision: agents coordinating through a shared service (continue, constrain or stop?); the service driven offline (availability or security?); a third party disclosing an incident that might be yours (who correlates?); confirmation that your agents reached a third party's systems (who notifies whom?).
2. Name the NIS 2 24-hour and 72-hour clocks explicitly at the last two injects.
3. Record every gap in role, authority or evidence as an issue with an owner.

Concrete defaults. Run it for half a day and cap each inject's discussion so that the clock applies.

Definition of done. Each inject has a named decision-maker and a timed decision, every gap is an issue with an owner, and the record is in the evidence store.

Practical guide: A decision-rights checklist for pausing or stopping agent workloads

Purpose. Define, before an incident, who may stop an agent workload, how fast and on which signals.

Roles. The accountable executive owns the policy; at least two roles hold standing authority to stop, so that stopping never waits on one person.

Steps.

1. Name the stop-holders and the signals that oblige a stop rather than an investigation.
2. Set the time within which a confirmed stop signal must be acted on, and build the mechanism.
3. Record any decision to continue after a stop signal as a waiver in the sense of Chapter 9.
4. Test the mechanism monthly, because an untested kill switch is a claim, not a control.

agent_stop_policy:
  may_stop:
    - role: security-operations-lead
    - role: ai-platform-oncall
    - role: named-oversight-for-system
  stop_within_minutes: 30
  stop_signals:
    - unauthorised_coordination_between_agents
    - agent_reaches_host_or_hypervisor_root
    - egress_to_unapproved_destination
    - agent_tampering_with_logs_or_guardrails
  continue_after_signal:
    requires_waiver: true            # dated, owned, reviewable; see Chapter 9
    approved_by: accountable-executive
  mechanism_tested_every_days: 30

Concrete defaults. A 30-minute stop target aligned to the monitoring cadence OpenAI adopted, shortened for higher-impact workloads; a monthly test of the mechanism.

Definition of done. The policy is in version control, the mechanism has been tested within the last month, and every continue decision exists as a recorded waiver.

Nordvik Region and Hansa Mutual

Had the incident hit Nordvik Region, it would most likely have hit through its suppliers. The Region runs no autonomous production agents and limits agentic work tools to a small platform team, but a compromised model hub could reach its fine-tuning pipeline (AIDR-0042) and the open-weight models behind the citizen-service assistant. Its response would turn on supplier contracts, the ML-BOM (43, OWASP, n.d.) and provenance checks at model promotion, a NIS 2 notification where in scope, and communication to residents.

Hansa Mutual is closer to the incident's setting. Its engineering teams use agentic work tools, its IT-operations agent has write access to production, and it pulls models and datasets from public hubs into a platform shared by seven entities, so the self-assessment and tabletop exercise must run per entity as well as for the group. A compromise would trigger DORA reporting by each affected EU entity (3, European Union, 2022), national notifications in the United Kingdom and Switzerland, and a decision whether to pause agents group-wide or market by market. Nordvik's exposure is through what it buys; Hansa's is through the agency it grants.

Summary

This incident is the clearest public evidence we have that an agent's behaviour is a property of its architecture, not only of its model. A population of agents with a goal, impossible tasks, persistence and a way to talk to one another combined weaknesses that each looked minor: a shared credential, a mirror that was also an exit, controls that leaned on each other, and a stop decision that belonged to no one. The propensity fell more than a hundredfold under a production harness, which shows where the leverage is.

For a European enterprise or authority, governance decides whether an anomaly stays contained: evaluations with safeguards removed treated as owned risk decisions, a stop authority named in advance, evidence and disclosure prepared, and supplier approvals reviewed after supplier incidents. The AI Act, NIS 2 and the Cyber Resilience Act turn several of these from prudence into duty. Chapter 20 catalogues the recurring anti-patterns, among them unbounded agents and governance theatre, that make incidents like this more likely.

Sources

1. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. 26 August 2026. (86, OpenAI, 2026)
2. Larcher, H., Carreira, A. et al. (2026). Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. Hugging Face blog, 27 July 2026. (92, Larcher et al., 2026)
3. AI Security Institute (2026). Incident Report: unsanctioned agent behaviour during cyber testing. UK AISI, 4 August 2026. (85, UK AISI, 2026)
4. National Cyber Security Centre (2026). NCSC statement in response to recent incidents resulting from frontier AI evaluations. 4 August 2026. (90, NCSC, 2026)
5. Hugging Face (2026). Security incident disclosure — July 2026. Hugging Face blog, 16 July 2026. (91, Hugging Face, 2026)
6. Wijk, H., Cotra, A. & Greenblatt, R. (2026). Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident. METR, 26 August 2026; Greenblatt of Redwood Research contracted with METR. (89, Wijk et al., 2026)
7. Landman, Y. (2026). Fast Remediation Is the New Trust Model: JFrog and OpenAI Collaboration on Zero-Day Security Findings. JFrog, 27 July 2026, updated 5 August 2026. (99, Landman, 2026)
8. JFrog (2026). JFrog Security Advisories: CVE-2026-66384, CVE-2026-65616, CVE-2026-65617 and related Artifactory advisories. July–August 2026. (98, JFrog, 2026)
9. Linux kernel CNA (2026). CVE-2026-53362: ipv6: account for fraggap on the paged allocation path. CVE Program, 4 July 2026. (100, Linux kernel CNA, 2026)
10. OpenAI (2026). OpenAI and Hugging Face partner to address security incident during model evaluation. 21 July 2026. (97, OpenAI, 2026)
11. Satter, R., Seetharaman, D. & Cai, K. (2026). Exclusive: Its AI agent spent days hacking a company, but sources say OpenAI did not notice for a week. Reuters, 24 July 2026 (syndicated by The Star). (101, Satter et al., 2026)
12. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
13. European Commission. The General-Purpose AI Code of Practice. European AI Office, 10 July 2025. (14, European Commission, 2025)
14. Bertuzzi, L. (2026). EU's AI rules face first enforcement test over lab incidents. Euronews, 14 October 2026. (102, Bertuzzi, 2026)
15. Bastians, H. & Herbosch, M. (2026). The EU AI Act Mandates AI Incident Reporting—If We're Lucky. Lawfare, 19 October 2026. (103, Bastians & Herbosch, 2026)
16. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (4, European Union, 2022)
17. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (6, European Union, 2024)
18. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
19. Von Arx, S., Chan, L. & Barnes, B. (2025). Recent Frontier Models Are Reward Hacking. METR, 5 June 2025. (82, Von Arx et al., 2025)
20. OWASP Foundation. CycloneDX Machine Learning Bill of Materials (AI/ML-BOM). (43, OWASP, n.d.)