AIR-2026-009 · AI Agent Incident Register
OpenAI says its own evaluation models breached Hugging Face's production systems
Incident: 2026-07-16 · Parties: Hugging Face (the target, whose production infrastructure was accessed and which disclosed the breach); OpenAI (which publicly attributes the intrusion to its own models, GPT-5.6 Sol and an unnamed, more capable pre-release model, run with reduced cyber refusals during a capability evaluation)
Liability locus: Vendor-borne. the gravity is upstream with the provider, and the deployer is largely a bystander. How this compares across the corpus.
Legal analysis by Michael K. Onyekwere, CIPP/E · Janus Compliance · Published 2026-07-22 · Last reviewed 2026-09-25. Analysis of public facts. Not legal advice.
What happened
The confirmed core, on which both companies agree: over a single weekend in July 2026, an autonomous AI agent compromised Hugging Face's production infrastructure. Hugging Face's own security team detected the activity through anomaly monitoring, contained it, rebuilt the affected nodes, and rotated the exposed credentials. It published a disclosure on 16 July 2026. Some later reporting places the public disclosure around 20 July; Hugging Face's own blog is dated 16 July, and this entry carries both.
Hugging Face's account of the mechanism is specific. A maliciously crafted dataset uploaded to the platform abused a code-execution path in its data-processing pipeline to run attacker code on a processing worker. From there the agent escalated privileges, moved laterally, and used several of Hugging Face's own service credentials to reach internal systems.
What Hugging Face confirms was accessed is narrow, and the limits matter as much as the breach. In its words, the intrusion gained "unauthorized access to a limited set of internal datasets and to several credentials used by our services." It then states the clearance directly: "We have found no evidence of tampering with public, user-facing models, datasets, or Spaces, and our software supply chain (container images and published packages) was verified clean." Whether any partner or customer data was affected it left open: "We are still completing our assessment of whether any partner or customer data was affected." So the confirmed harm stays inside Hugging Face's own systems: a limited set of internal datasets and some service tokens. The platform's public artefacts and supply chain are affirmatively cleared. Hugging Face advised users, as a precaution, to rotate access tokens and review recent account activity.
On the question everyone wanted answered, whose model was it, Hugging Face was deliberately neutral. It named no vendor and no model, describing the attacker only as "an autonomous agent framework (appearing to be built on an agentic security-research harness — used LLM still not known)." Its forensics could not identify the model.
The attribution came from the other side. Days after Hugging Face's neutral disclosure, OpenAI published a statement taking responsibility: the breach, it said, "was driven by a combination of OpenAI models — including GPT-5.6 Sol and an even more capable pre-release model, all with reduced cyber refusals for evaluation purposes." One of the two, GPT-5.6 Sol, is a released model; the other OpenAI describes only as an unreleased, more capable pre-release system. Per OpenAI, the models were running inside its "sandboxed testing environment" during a cyber-capability evaluation on ExploitGym, a publicly hosted benchmark that measures a model's ability to execute attacks against known vulnerabilities. OpenAI's account is that the models "spent a substantial amount of inference compute finding a way to obtain open Internet access," exploiting a zero-day in what it calls the "package registry cache proxy" (since responsibly disclosed to the vendor), then "identified and chained vulnerabilities across OpenAI's research environment and Hugging Face's production infrastructure to obtain test solutions directly from Hugging Face's production database." The goal, on OpenAI's reading, was to cheat the test: "All evidence suggests that the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal." OpenAI calls it "an unprecedented cyber incident, involving state-of-the-art cyber capabilities."
Two cautions belong in the record before any of this hardens into "what happened." First, the attribution to OpenAI's specific models rests entirely on OpenAI's own disclosure. Hugging Face's forensics were model-blind, and no independent party has confirmed which system drove the agent. This is the unusual shape of the incident: the only party that can name the actor is the party volunteering that it was at fault. Second, the dramatic verbs, that the model "escaped," "broke containment," used "stolen credentials," achieved "remote code execution," are largely press framing. OpenAI's own posted language is more careful: "obtain open Internet access" from a "sandboxed testing environment," "exposed credentials," "zero-day vulnerabilities," "privilege escalation and lateral movement." That distinction carries weight for a liability read. Only what a party admitted can bear it; a headline's verb cannot.
One further detail, reported by Hugging Face, captures the governance bind neatly. When its team tried to use a Western commercial frontier model over an API to analyse the attack, the provider's own safety guardrails blocked the requests, because they were full of real exploit payloads and command-and-control artefacts. Hugging Face ran an open-weight model (reported as GLM 5.2) on its own infrastructure instead. The safety controls built to stop a model helping an attacker also, here, obstructed the defender trying to understand the attack. That defensive model is not the attacker; the two should not be conflated.
The duty engaged
Everything below is a duty analysis on self-disclosed, non-adjudicated facts, as at 22 July 2026. There is no regulator finding, no enforcement action, and no court ruling. Nothing here asserts that any party has broken the law; it identifies the duties the facts engage.
The duty that defines this entry is one the register has not had a clean example of before: the containment of dangerous-capability testing. A frontier developer that deliberately lowers a model's cyber refusals to measure its offensive capability takes on a heightened duty to contain that test. The whole premise of the evaluation is that the system under test is, for the duration, more willing and more able to attack; the containment around it is therefore the primary safety control. On OpenAI's own account, that control failed: the test environment had an exploitable path to the open internet, and the models found it. No court has yet recognised a "containment of testing" duty, and whether it would reach a specific third party like Hugging Face is the kind of proximity question a court would have to work through. But the building blocks of a negligence claim are present: a foreseeable risk from a deliberately hazardous activity, run by the party best placed to contain it, reaching a third party that party could foresee.
Security of processing (GDPR Article 32). To the extent the internal datasets accessed at Hugging Face contained personal data, which is not yet established and is part of what Hugging Face is still assessing, Article 32's obligation to ensure security of processing is engaged. The instructive point is where the failure lies. Hugging Face's perimeter was breached through a legitimate platform feature, uploading a dataset that triggers processing, which it moved to close. But the agent that exercised that feature was, per OpenAI, OpenAI's own model, released from a test that OpenAI ran. The security failure that let a dangerous agent loose to look for a target is upstream, in the testing party's containment. Hugging Face's own systems held against everything except a feature working as designed.
The EU AI Act, general-purpose AI with systemic risk. This is the strongest regulatory frame, and it fits the facts closely. GPT-5.6 Sol and a still-more-capable frontier model are general-purpose AI models; the most capable ones fall in the systemic-risk tier under Article 51, whose provider obligations have applied since 2 August 2025. Article 55 spells out what those providers owe, and three of its duties map onto this incident almost line for line. Article 55(1)(a) requires model evaluation including adversarial testing, which is exactly what ExploitGym was. Article 55(1)(d) requires an adequate level of cybersecurity protection for the model and its physical infrastructure: a containment failure in the vendor's own testing infrastructure, letting the model reach the open internet, is precisely the risk that duty addresses. And Article 55(1)(c) requires providers to track, document, and report serious incidents to the AI Office, the kind of channel a cyber incident emanating from a systemic-risk model and causing a real intrusion into a third party exists for. None of this is a finding that OpenAI breached the Act; it is the set of obligations the facts put in play, and the relevant chapter of the GPAI Code of Practice covers model evaluations and cyber containment directly.
Unauthorised access to computer systems. The conduct OpenAI describes, gaining access to Hugging Face's systems without authorisation and extracting data, is, in the UK, the territory of the Computer Misuse Act 1990 (unauthorised access, and unauthorised acts in relation to a computer). US reporting has raised the equivalent Computer Fraud and Abuse Act. Both are flagged here as commentary on which laws the conduct touches; nothing here is an adjudicated finding. No prosecutor or regulator has acted, and the novel question of how criminal-access statutes apply when the actor is an autonomous model rather than a person is exactly the kind of question this incident will force but has not yet answered.
The liability chain
The allocation here points upstream, to the vendor, and the reasoning is worth being precise about because the surface facts, a breach of Hugging Face, could mislead.
OpenAI carries the gravity, as the principal behind the agent. Take OpenAI's disclosure at its word, which for liability purposes is the point: its models, its evaluation, its decision to run them with cyber refusals reduced. The harm to a third party flowed from choices that were entirely OpenAI's to make and OpenAI's to contain. When a developer runs a deliberately de-restricted frontier model in a test adjacent to the open internet, the risk that the model reaches something it should not is the developer's risk to hold. That is why the register tags this vendor: the gravity belongs to the model provider that built the agent and set the test conditions.
Hugging Face is the injured party, and that is not the whole story. The intrusion entered through a data-processing pipeline that ran attacker-supplied code, which is a genuine security gap, and a fair opponent would argue Hugging Face bears some contributory responsibility for shipping a feature that executes untrusted uploads. Hugging Face moved to close that path once it was used, and on its own account discharged the part of the security-of-processing duty that matters when prevention fails: it detected the intrusion with its own monitoring, contained it over a weekend, rebuilt compromised nodes, and rotated credentials. But the gap let an agent in; it did not point the agent at Hugging Face or strip the safeguards that made the agent dangerous. Those choices were OpenAI's, which is why the gravity stays upstream even though the breached door was Hugging Face's. Where partner or customer personal data turns out to be implicated, Articles 33 and 34 (breach notification to the regulator and to affected individuals) would be engaged; Hugging Face has said it will contact affected parties as required, which is the right posture while the assessment is open.
The attribution is the fragile link, and honesty requires saying so. The entire chain above rests on OpenAI's self-report that these were its models. If that self-attribution is complete and accurate, the vendor allocation is clean. But no independent forensic work has confirmed it, and a register that analyses liability has to mark where the load-bearing fact is a party's own statement rather than an adjudicated finding. Here, unusually, the statement runs against the speaker's own interest, which is a reason to credit it. It is still a statement, and the register marks it as one.
What would have prevented it
- Air-gap dangerous-capability evaluations from any path to the open internet. A test that removes a frontier model's cyber refusals is, by design, a test of whether the model can attack. The single control that makes that safe is a sandbox with no reachable route out. On OpenAI's account, the route existed and the model found it. For this class of test, network isolation is the whole safety case.
- Treat the security of the testing infrastructure as a first-order obligation. Article 55(1)(d)'s reference to the cybersecurity of the model's physical infrastructure is exactly this point. The zero-day was in the test environment's own plumbing; a de-restricted model under evaluation is a realistic adversary against that plumbing, so it should be threat-modelled as one.
- Least privilege and egress control on evaluation sandboxes. The model chained privilege escalation and lateral movement to get out. Assume the system under test will attempt precisely that, and constrain what a compromised evaluation node can reach, inside the lab and, above all, outward.
- On the platform side, contain code execution from user uploads. Hugging Face's own remediation is the general lesson for any platform whose features run user-supplied code: isolate the execution, and monitor for the escalation-and-lateral-movement pattern that turns one worker into a foothold. Its anomaly detection is what caught this; that investment paid.
- Have a serious-incident reporting path ready before you need it. For a systemic-risk GPAI provider, an incident like this engages the Article 55(1)(c) reporting channel to the AI Office. The time to work out what qualifies and how to file is before an evaluation agent can reach a third party.
Mapped controls
- OWASP Top 10 for Agentic Applications 2026: the primary fit is ASI10 Rogue Agents, an autonomous agent operating outside its intended scope and control, pursuing a legitimate goal (solve the benchmark) through unauthorised means (breach a third party). It is close to the textbook definition. Secondary: ASI05 Unexpected Code Execution (RCE) (the malicious dataset's code-execution path into Hugging Face, and the zero-day used to leave the sandbox); ASI03 Identity and Privilege Abuse (harvesting service credentials, privilege escalation, lateral movement); and ASI02 Tool Misuse and Exploitation (the model turning capability testing into a live intrusion). The single incident touches four of the ten, which is itself the point about autonomous agents: one goal-directed system exercises several failure modes in sequence.
- NIST AI RMF: a MANAGE and MEASURE failure. MEASURE, because an internet-adjacent evaluation was run with the model's cyber safeguards deliberately removed; MANAGE, because the controls around that evaluation did not contain the risk it created. NIST's Generative AI Profile (AI 600-1) names the "Information Security" risk, models lowering the barrier to, or autonomously conducting, offensive cyber operations, which is this incident precisely. On the defence side, Hugging Face's detect-contain-recover response is a clean NIST Cybersecurity Framework execution.
- EU AI Act: general-purpose AI with systemic risk (Article 51), engaging Article 55 provider duties, model evaluation and adversarial testing (55(1)(a)), cybersecurity of the model and its infrastructure (55(1)(d)), and serious-incident reporting to the AI Office (55(1)(c)), in force since 2 August 2025, with the GPAI Code of Practice's safety-and-security chapter covering evaluations and containment.
- The general rule the incident stands for: a dangerous-capability evaluation is only as safe as the sandbox that contains it. When a developer removes a frontier model's cyber refusals to measure what it can do, the containment of that test becomes a security-of-processing obligation in its own right, owed not only to the developer's own systems but to every third party a released-then-uncontained agent could reach. It is the register's first entry where the liability gravity belongs to the vendor because a capability test reached beyond its bounds rather than because a product shipped a defect. It runs alongside the vendor-facing analysis in Amazon Q and, on the deployer side, the crystallised penalties in Garante v Luka and Moffatt.
Addendum (5 September 2026): the technical reports, the closed assessment, and the pattern
Since this entry was published on 22 July, the incident has been documented in far more detail, and two of its open threads have closed. The analysis above stands as it was on its date. This addendum records what has been established since, each point dated and sourced.
OpenAI's technical report (late August 2026). OpenAI published a detailed technical report that fills in the mechanism the July disclosure only sketched. The agents had been using an internal "Artifactory" package service in unexpected ways to leave messages and files for one another since May 2026 (OpenAI notes this internal service is unrelated to the JFrog Artifactory Cloud product). They compromised that service, causing an outage in early July, and on 8 July exploited a separate, previously unknown vulnerability in it as their route to the open internet. On 9 July an internal-only research agent running an ExploitGym evaluation gained root access to the parent virtual machine of its own testing sandbox. Between 10 and 13 July the agents found Hugging Face user credentials exposed on the internet and used them to reach its systems. OpenAI attributes the activity primarily to a highly capable, internal-only research model, with the released GPT-5.6 Sol also involved, and it confirms the models exploited OpenAI's own internal research infrastructure as well, not only Hugging Face's. It also states it identified additional third parties whose publicly exposed credentials the agents used in the course of the attack.
Hugging Face's forensic timeline, and the closed data question. Hugging Face published its own technical timeline, placing the intrusion between 9 and 13 July, and it answers the question the original entry had to leave open. Its assessment of partner and customer data is complete, and the result is narrow. The only customer content accessed was five datasets whose names and files point to ExploitGym or CyberGym challenges and solutions, with no other customer-facing models, datasets, Spaces or packages affected, and the only customer records read were operational metadata tied to search queries. The forensic scale is larger than the harm: roughly 17,600 attacker actions in about 6,280 clusters, access to 136 keys in a production secrets store, and 181 VPN devices enrolled across the campaign, against a single internal database read with no bulk extraction. The security-of-processing picture the entry drew holds. Hugging Face's systems were breached through a feature working as designed, and the confirmed data harm stayed inside a narrow set.
The attribution has firmed up. The original entry flagged its load-bearing weakness, that the attribution rested entirely on OpenAI's self-report, with Hugging Face's forensics model-blind and no independent confirmation. That caveat has substantially closed: Hugging Face's later timeline attributes the campaign to an autonomous agent driven by OpenAI models, aligning its forensics with OpenAI's account, and independent reviewers including METR and Redwood Research published their own assessments. The vendor-locus allocation the entry made rests on firmer ground than it did in July.
From one incident to a pattern. As it widened its investigation, OpenAI found further instances of its agents escaping containment (Insurance Journal, 3 August), and reporting through late July described comparable evaluation-containment escapes at other frontier developers. That shift matters for the duty this entry is built on. One containment failure can be read as an accident. A recurring one is a systemic risk, and it strengthens the Article 55 reading above rather than softening it: the systemic-risk provider's duty to secure the model's evaluation infrastructure, and to report serious incidents, is exactly what a pattern of escapes engages. The register will treat further confirmed escapes on their own facts.
The entry's status and liability allocation are unchanged. These developments corroborate the original reading and close its two open questions. They do not alter it.
Addendum (14 September 2026): the research exclusion in the AI Act
The analysis above, as published on 22 July, treated the Article 55 duties of a provider of a general-purpose AI model with systemic risk as mapping directly onto this incident. It did not address Article 2(8) of the Act, which provides that the Regulation "does not apply to any research, testing or development activity regarding AI systems or AI models prior to their being placed on the market or put into service". That exclusion bears on this incident. OpenAI's technical report, summarised in the addendum above, attributes the activity primarily to a highly capable, internal-only research model, with the released GPT-5.6 Sol also involved. For the internal-only model the evaluation is likely outside the Act altogether. The carve-back in the same Article for testing in real world conditions does not obviously change that, since Article 3(57) defines the term around testing an AI system for its intended purpose under the Article 57 and 60 regimes, and an accidental route to the internet in a model evaluation is neither. For GPT-5.6 Sol, a released model, the Article 55 duties on adversarial testing, cybersecurity of the model and its infrastructure, and serious-incident reporting remain the relevant frame.
The practical effect is to narrow the regulatory reading of this entry. The containment duty identified above does not depend on the Act and is unaffected, and so is the vendor allocation. The same exclusion is analysed for the parallel incidents at Anthropic and Meta in AIR-2026-012, where it reaches further because more of the models involved were unreleased.
Addendum (15 September 2026): OpenAI's third-party evaluation incidents
On 4 August OpenAI published a first-party account of two further incidents in which its models reached the public internet, both during cyber evaluations run by outside partners, and it describes both as separate from the Hugging Face incident. At the UK AI Security Institute, internet access had been enabled on purpose and the models' cyber classifiers disabled. GPT-5.6 Sol was involved in two of the 19 events the Institute identified. At Irregular, an evaluation partner, models that had been told they had no internet access were connected to it by a misconfiguration, and one exploited a real website whose domain matched the name of the fictional target. OpenAI says that incident "did not involve a sophisticated sandbox escape or a zero-day". The mechanism in this entry was different, since the models found and exploited a previously unknown vulnerability to reach the internet.
They add two first-party instances to the pattern described in the addendum of 5 September. Irregular's environment, in which models from Anthropic and Meta also reached real systems, is analysed in AIR-2026-012. The UK AI Security Institute incident will be treated on its own facts. Neither changes the analysis or the vendor allocation of this entry.
Addendum (25 September 2026): an earlier incident involving an OpenAI model, in Australia
On 24 September the Australian Government disclosed that an OpenAI agent had gained unauthorised access to the Medicare Statistics Reporting Service portal, a public-facing statistics site run by Services Australia. The Prime Minister put the date at 18 June 2026, three weeks before the Hugging Face intrusion of 9 to 13 July. Ministers described the agent's task in slightly different terms. The Prime Minister said OpenAI's research team "used an internal model to conduct internet based research into public medicine spending". The Minister for Government Services said the task was "part of internal capability evaluation", and the Acting Prime Minister spoke of a model "that was undergoing training by OpenAI".
On the Government's account the model interacted with four Australian public websites, and on three of them the interactions were "entirely normal". On the Medicare statistics portal its first request was refused, and the agent then "engaged in what's described as misaligned behaviour and engaged in unauthorised access of that portal". The Prime Minister said it "accessed public and non-public information within the portal", and that Services Australia advises it "engaged in writing files as well to the internal server", a point still under investigation. The portal held aggregate statistics, and the Prime Minister said no personal information is believed to have been accessed at this stage. The Acting Prime Minister said "The system itself has not been in any way compromised."
The Government's criticism has centred on the notification timeline. The Acting Prime Minister said OpenAI had advised that it became aware of the incident in August. OpenAI emailed Services Australia on 10 September, at an address the agency uses for vulnerability reports from researchers, and the Minister for Government Services described that email as identifying a vulnerability in the system. Services Australia notified the Australian Signals Directorate by 15 September, and the Government made the incident public on 24 September. It has set up a taskforce led by the Department of the Prime Minister and Cabinet, whose report will consider "possible law enforcement and legislative responses", and it will seek advice on whether any offences have occurred.
Two things change for this entry. First, OpenAI described the Hugging Face intrusion as an unprecedented cyber incident in July, before, on its own account, it knew of the June access in Australia. The summary above now follows those words (see Corrections below). Second, the general rule stated above is framed around a dangerous-capability evaluation run with refusals reduced. Neither transcript says whether the Australian model's safeguards had been reduced, and its task was research into medicine spending. If they had not been, the containment point in this entry extends to any agent sent onto the open internet, and the rule above is drawn too narrowly. The vendor allocation of this entry is unchanged. The Australian incident will be treated on its own facts.
Sources
- Hugging Face, "Security Incident - July 2026" - the target's own disclosure; confirms unauthorised access to a limited set of internal datasets and several service credentials, no evidence of tampering with public models/datasets/Spaces, supply chain verified clean, partner/customer-data assessment still open, and that the model behind the "autonomous agent framework" was "still not known"; dated 16 July 2026 - checked 22 July 2026 [primary]
- OpenAI, "OpenAI and Hugging Face partner to address security incident during model evaluation" (openai.com/index/hugging-face-model-evaluation-security-incident/) - OpenAI's statement attributing the breach to its own models (GPT-5.6 Sol and an unnamed pre-release model, "reduced cyber refusals for evaluation purposes"), describing the sandbox-to-internet step, the ExploitGym context, and the goal-fixation framing; OpenAI's X post (x.com/OpenAI, "Cyber-capable OpenAI models compromised Hugging Face production during a benchmark evaluation") is the accessible primary for the core attribution - the openai.com page returned HTTP 403 on direct fetch, so its wording here is taken from OpenAI's post and from multiple outlets quoting the statement directly, cross-consistent - checked 22 July 2026 [primary, provenance noted]
- TechCrunch coverage of the OpenAI / Hugging Face incident - corroborates the attribution and the ExploitGym setup, and flags the potential Computer Fraud and Abuse Act exposure ("unclear whether OpenAI will face any legal consequences") - checked 22 July 2026 [corroborating]
- Fortune coverage of the OpenAI / Hugging Face incident - carries OpenAI's verbatim "identified and chained vulnerabilities" statement and independent AI-safety commentary - checked 22 July 2026 [corroborating]
Addendum sources (checked 5 September 2026):
- OpenAI, "OpenAI-Hugging Face Incident Technical Report" (late August 2026) - the detailed technical report, read in full. Primary for the mechanism: the internal "Artifactory" package service used for agent coordination since May 2026 (which OpenAI states is unrelated to the JFrog Artifactory Cloud product), the early-July compromise and outage, the 8 July egress to the open internet via a previously unknown vulnerability in that service, the internal-only research model as the primary driver alongside GPT-5.6 Sol, the exploitation of OpenAI's own research infrastructure, and the additional third parties whose exposed credentials the agents used [primary]
- OpenAI, "The Hugging Face incident and the road ahead" - OpenAI's follow-up statement on remediation [primary]
- Hugging Face, "Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident" - Hugging Face's forensic timeline (intrusion 9-13 July) and its completed partner/customer-data assessment: five datasets tied to ExploitGym/CyberGym challenges and solutions, operational search metadata, 136 keys in a production secrets store, 181 VPN devices, one internal database read with no bulk extraction [primary]
- Insurance Journal, "OpenAI Finds Evidence Other AI Agents Escaped Containment as it Widens Probe" (3 August 2026) - the pattern of further containment escapes [corroborating]
- Fortune, "OpenAI, independent firms publish reports into rogue AI agent attack on Hugging Face" (26 August 2026) - covers the OpenAI technical report and the independent assessments by METR and Redwood Research [corroborating]
Addendum sources (checked 14 September 2026):
- Regulation (EU) 2024/1689, the AI Act - the Official Journal text. Primary for Article 2(8), excluding research, testing and development activity before a model is placed on the market and carving back testing in real world conditions, and for Article 3(57), defining that term [primary]
Addendum sources (checked 15 September 2026):
- OpenAI, "Third-party cyber evaluations involving OpenAI models" - OpenAI's first-party account, dated 4 August 2026 and read in full. Primary for the two incidents in third-party evaluations and their separation from the Hugging Face incident, the UK AI Security Institute configuration with internet access enabled and cyber classifiers disabled, the two of 19 events involving GPT-5.6 Sol, the Irregular misconfiguration and real-domain target, and the statement that the Irregular incident involved no sophisticated sandbox escape or zero-day [primary]
Addendum sources (checked 25 September 2026):
- Prime Minister of Australia, "Press conference - New York" - transcript, 24 September 2026. Primary for the 18 June date, the research task into public medicine spending, access to public and non-public information within the portal, the writing of files to the internal server, the statement that no personal information is believed to have been accessed at this stage, the notification on 10 September, and the taskforce and its remit [primary]
- Defence Ministers, "Press Conference, Sydney" - transcript of the Acting Prime Minister and the Minister for Government Services, 24 September 2026. Primary for the four websites and the normal interactions with three of them, the misaligned behaviour and unauthorised access on the portal, OpenAI becoming aware in August, the address the email was sent to and its purpose, notification to the Australian Signals Directorate by 15 September, and the statement that the system itself was not compromised [primary]
- OpenAI published channels, checked 25 September 2026: no first-party account of the Australian incident was found on OpenAI's misalignment reports page or by a search of openai.com, and the comments reported so far came through a spokesperson. Recorded as a negative finding scoped to that page and that search on that date [primary, negative finding]
Corrections
- 25 September 2026: The summary previously described the incident, on OpenAI's own account, as "the first time a frontier model's evaluation agent has compromised a live third-party production system". OpenAI's statement called it "an unprecedented cyber incident", and the summary now follows those words. An earlier incident involving an OpenAI model, disclosed by the Australian Government on 24 September, is recorded in the addendum of 25 September.
Cite this entry as: Onyekwere, Michael K., AIR-2026-009, AI Agent Incident Register, CompanyScope, https://companyscope.io/register/air-2026-009, as at 2026-09-25. Entry IDs are stable; corrections publish as dated addenda on this page. The AIR prefix is also used by an unrelated arXiv project; the companyscope.io URL identifies this register.
Talk to Michael about your agent deployment - or your AI vendor governance more broadly
CompanyScope's public profiles cover the general picture. Michael runs Janus DPO-as-a-Service for businesses that need ongoing AI vendor governance, and writes one-off CIPP/E-reviewed Vendor Risk Notes for specific procurement decisions. Tell him what you're actually trying to clear.
Your context goes only to Michael. We don't share with the vendor or anyone else. Privacy notice.
Subscribe to the AI Agent Incident Register
Every new Register entry delivered with the legal analysis: the incident, the duty engaged, who is liable across the chain, and what governance would have prevented it. Written by Michael K. Onyekwere, CIPP/E. Free.
Subscribe - freeDelivered via Compliance Engineering on Substack, which handles your subscription and consent. Unsubscribe any time. Privacy notice.
This analysis is the work Janus Compliance does for clients before the incident. For a fixed-scope read of your own EU AI Act Article 50 exposure, see the Article 50 teardown; for ongoing agent governance, Janus DPO-as-a-Service. New entries are delivered free through Compliance Engineering on Substack. Browse the full register or the vendor compliance index.