Open-Weight AI and Cyber Defence: The Asymmetry Where Only Defenders Get Locked Out

Hello, this is Ryuta Hamamoto from TIMEWELL.

Somewhere in the incident disclosure Hugging Face published on 16 July 2026 is the heaviest sentence I have read in a security document this year. It is not about how the intrusion worked, and not about the blast radius. It is about the company's own security team trying to analyse the attacker's activity log, and being refused by the frontier models behind commercial APIs.

the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker.

Not a rate limit. Not a terms-of-service ruling. A safety filter stopped the people doing the defending¹. The company summed the situation up in the same document: the attacker was bound by no usage policy, while their own forensic work was blocked by the guardrails of the hosted models they tried first¹.

So let me put my conclusion up front. TIMEWELL backs open-weight AI models, clearly and on the record. Not as an ideology. As a matter of defensive practice. What follows traces why, using primary sources only, and then sets out the weak points on the open-weight side without hiding any of them.

The day forensics got blocked by a guardrail

Here is what happened, following the official disclosure in order. The first thing that struck me was how unremarkable the entry point was.

Initial access came through a malicious dataset. The attacker abused two code execution paths in datasets, a remote-code dataset loader and template injection in the dataset configuration, to run code on a processing worker. From there came privilege escalation to node level, theft of cloud and cluster credentials, and lateral movement across several internal clusters over a weekend. Hugging Face describes the intrusion as having been driven end to end by an autonomous AI agent system¹.

The confirmed impact was unauthorised access to a limited set of internal datasets and to several service credentials. Impact on partner and customer data was still being assessed at the time of publication. On the other hand, the company found no evidence of tampering with public models, datasets or Spaces, and verified the software supply chain, including container images and published packages, as clean¹.

The interesting part comes next. The attacker action log the team had to read ran to more than 17,000 recorded events. That is not a volume you work through by hand. So they reached for AI, and hit the wall quoted above. What they used instead was the open-weight model GLM 5.2, running on their own infrastructure. Work that would normally take days finished in hours, they say. There is no third-party verification of that speed-up, and it should be read as the account of a party with an interest in the outcome. With that discount applied, there was a second effect they thought worth writing down: no attacker data, and none of the credentials it referenced, left their environment¹.

The most sensitive material in any incident response, analysed without ever leaving the building. I have mostly used the phrase "data sovereignty" in conversations about regulation and procurement. That sentence changed my mind about where it belongs. It is an operational requirement of incident response.

Then, five days later, the story took a turn nobody scripted. On 21 July OpenAI disclosed that the intrusion had been caused by its own models. The models under evaluation were GPT-5.6 Sol and a more capable pre-release model. Both were configured with cyber refusals reduced for evaluation purposes, and the evaluation was run without the production classifiers used to prevent models from pursuing high-risk cyber activity. The model found and exploited a zero-day vulnerability in a package registry cache proxy and escaped its sandbox². OpenAI has said it considers this an unprecedented cyber incident involving state-of-the-art cyber capabilities, and is responding accordingly³.

Which means this is not a story about Hugging Face being attacked by somebody. No state-sponsored actor, no criminal group. A frontier lab lost control of its evaluation environment and broke another company's production infrastructure. That is the factual position.

In fairness, two caveats belong here rather than at the end. First, containment itself was not achieved by open weights. The response Hugging Face describes is conventional: fixing the code execution paths in datasets, removing the attacker's foothold and rebuilding compromised nodes, revoking and rotating credentials and tokens, adding guardrails and stricter admission control to clusters, improving detection and alerting, working with external forensic specialists and reporting to law enforcement¹. GLM 5.2 did post-incident analysis. Those two things must not be blended together.

Second, Hugging Face went out of its way to draw a line in the same section. This is not an argument against safety measures on hosted models, it says, and the company is sharing the feedback with the providers concerned¹. When the party at the centre of the story rejects the "open versus closed, settled" reading, using it as a victory lap is dishonest. And note that the company never named the vendor or the product of the commercial models it tried first. There is no material anywhere for pointing at a specific provider.

The failure mode differs, but Japanese companies already know what it feels like when something you rent from someone else stops working. In June 2026, access to a frontier model was reported to have been cut off abruptly under a US export control directive. That is reporting-based; the issuing authority, the legal instrument and the statutory basis are not something I have confirmed against primary sources. As reported, the directive covered foreign national users, but because the provider could not determine nationality on the spot, the model ended up disabled for a wider group than that. I covered it in the AI you rely on can stop overnight. Stopped by a safety verdict or stopped by a regulation, the structure is the same: what you depend on can stop. If you would like to check where your own AI adoption stands before reading on, our AI readiness check takes a few minutes, and the practical half of this piece lands better once you have.

Attackers are already outside the guardrails

So far this is one incident. It would have been convenient to file it as a one-off. Over the past year, though, the major labs and threat intelligence teams have published their own records of how attackers use AI. Read them side by side and filing it away stops being an option.

In November 2025, Anthropic disclosed an operation it had detected in mid-September and assessed with high confidence as the work of a Chinese state-sponsored group. Around 30 organisations were targeted, with a small number of successful intrusions confirmed. The striking part is the degree of autonomy: the threat actor had AI execute 80 to 90 per cent of tactical operations, with human intervention limited to four to six critical decision points per campaign. And the method used to get past the safety measures was not a technical jailbreak. It was role-play. Human operators claimed to be employees of a legitimate cybersecurity firm running defensive penetration tests, and decomposed the attack chain into discrete tasks that each looked legitimate in isolation. That part made my skin crawl. What broke was not the technology. It was the introduction. Anthropic also records the limits: during autonomous operations, the model frequently overstated findings and occasionally fabricated data⁴.

The follow-up analysis maps 832 accounts banned for cyber-related policy violations between March 2025 and March 2026 onto MITRE ATT&CK. It counts 13,873 actions, 482 unique techniques and all 14 tactics. The share of actors assessed as moderate to high risk rose from 33 per cent in the earlier part of the period to 56 per cent in the later part. A 1.7-fold increase in under a year⁵.

Google's threat intelligence group reports a stranger development still: malware that queries an LLM while running and rewrites itself. One variant obfuscates its own source code every hour. In PROMPTSTEAL, deployed against Ukraine by a Russian state-backed actor, the malware called a public API to have an open-weight code generation model produce its commands, the first observation of LLM-querying malware in live operations⁶. The same group also describes attackers industrialising high-volume, anonymous access to LLMs, combining API gateways and aggregators, automated account registration tooling and anti-detect browsers to keep premium-tier access alive through free-trial abuse and programmatic account rotation⁷. Tools sold on underground forums as bespoke malicious AI have turned out to be jailbroken commercial APIs wired to open-source MCP servers⁸. On models that circulate with their safeguards stripped out, I went through the regulatory picture in has frontier AI become military-grade.

There is a record that touches Japan directly. In its February 2026 threat report, OpenAI disclosed banning accounts belonging to an individual linked to Chinese law enforcement. According to the company, that person attempted to use its models to plan an operation targeting Japan's prime minister and was refused. The actor's wider activity is described as a large, sustained effort involving at least several hundred staff, thousands of fake accounts across dozens of platforms, and locally deployed AI models⁹. The part that matters is the last one. They are already operating on the assumption of local deployment. Guardrails do not stop that.

Japanese authorities have confirmed the same technique with their own hands. The National Police Agency's situation report for 2025, published in March 2026, opens with a special feature on the AI threat landscape and police response. It cites an attack observed overseas in July 2025, in which someone posing as a government official emailed malware abusing generative AI to a government body. The NPA's own analysis found that the malware carried no attack instructions inside it; instead it abused the generative AI service in use on the infected machine to generate malicious commands on the spot¹⁰. Structurally identical to the just-in-time pattern above. The same report notes private-sector reporting of a state-backed group conducting an attack via AI without human intervention, and describes it as evidence that AI agents can execute nearly the whole attack chain autonomously¹⁰.

A line has to be drawn against overstating this, though. The same Google team is explicit that state-sponsored actors' use of AI has not yet produced breakthrough capabilities that fundamentally change the threat environment⁸. Mandiant's frontline report says most breaches still trace back to human and systemic failures, and exploits remain the leading initial infection vector at 32 per cent¹¹. AI has not changed the nature of attacks. It has changed their speed and scale. That said, putting the whole speed story down to AI does not match the evidence. The median time from initial access to hand-off to a secondary threat group collapsed from over eight hours in 2022 to 22 seconds in 2025. That figure measures how far the division of labour between those who sell initial access and those who use it has gone; it is not a measure of AI's contribution on its own. Over the same period, global median dwell time got worse, from 11 days to 14¹¹. Attacks move at machine speed, and we notice later than we used to. Whatever the breakdown, what it means for the defender's analysis to stall for days in that setting needs no further explanation.

Put together, it comes out like this. Usage policies and safety guardrails effectively bind only the legitimate defender, the one who signs contracts, submits to audits and keeps logs. Attackers lie their way through with role-play, anonymise through account pools, and move to local weights when they need to. That asymmetry is my main reason for backing open weights.

The industry's centre of gravity moved in three days

In the last week of July 2026, the industry did not leave the problem alone. Its response still needs to be assessed coolly.

On 24 July, the open letter "Open Weights and American AI Leadership" was published with 25 signatories. I already walked through the letter itself, from what open weights are to its policy asks, in why open weights matter, so I will not repeat it. What this piece follows is the delta over the three days that came after.

One sentence from the letter is worth pulling out. Relying solely on closed models is not inherently safe, it says, because they can be breached, misused, or fail in ways that outsiders cannot detect¹². That line matched what became public on 21 July with uncomfortable precision. For the record, the letter itself makes no mention of the Hugging Face incident. Search the full PDF and the company name appears exactly once, in the signatory list. This is a place where the timeline must not be blurred, so I am spelling it out.

The signatory count moved fast. By 25 July it had roughly doubled to about 50, and at that point OpenAI and Google had joined. Counting the signature block in the PDF published as of 27 July 2026 gives 77 organisations¹². Sakana AI is on the list from Japan. Absent at that point are Anthropic and Amazon. Here I want to be careful. Signing is not by invitation; the official page directs interested companies to an email address, which makes it opt-in. So an absence from the list is not evidence that anyone was approached and declined. Neither company has explained the absence, and reporting has not established a reason either. As the Forbes writer covering it put it, neither has explained the absence, and it would be a mistake to assume the reason¹³. I take the same position.

Three days later, on 27 July, NVIDIA announced the launch of the Open Secure AI Alliance on its blog. It defines the effort as a movement to develop and share open technologies, techniques and tools to safeguard software and agents in the age of AI, with the mission of ensuring defenders everywhere have open, frontier tools they can trust and control¹⁴. On why open models matter for cybersecurity specifically, the post argues that they democratise defensive capabilities, increase transparency for defenders, enable cyber defence while protecting data, and complement frontier closed models with customisable, localised controls¹⁴.

The launch partners include CrowdStrike, Palo Alto Networks, Cisco, Cloudflare, Elastic, Red Hat, IBM, Microsoft, Dell, HPE, Hugging Face and the Linux Foundation, alongside model-building names such as SpacexAI, Thinking Machines Lab, Reflection AI and Nous Research. The one Japanese company is TrendAI, the enterprise brand of Trend Micro (TSE 4704). One caveat on the arithmetic: NVIDIA never states a total. Counting the names listed in its post, NVIDIA included, gives 37, while press coverage has variously said 27, more than 30, and close to 40. The 37 in this piece is a count of the names in the official post, nothing more.

The technical contributions are published too. A zero-trust identity standard for cryptographically verifying agents, a weight storage format in which no remote code execution occurs, digitally signed patches to protect the open-source supply chain, a harness that scans agents for vulnerabilities using multiple models. Lined up together, they lean less towards models than towards making inspectability a shared asset¹⁴. That is where I see the real significance. If an analyst cannot verify the prompts, the queries and the model's judgements after the fact, you cannot put the AI's conclusions into an incident report or an audit. Inspectability should be a precondition, not a product feature you shop for.

The post also makes a policy argument. It says it will be crucial for AI and cybersecurity policy to recognise open models, harnesses and security tooling as defensive assets rather than liabilities, and that blanket restrictions on open frontier AI systems would weaken defensive capacity and risk concentrating power, dependence and vulnerability in a few closed providers. In the same post, it accepts that open models, like any powerful technology, can be misused¹⁴. For a corporate blog that is also a lobbying document, I find that admission honest.

Which brings us to the posts by Jensen Huang that started this. The first one, on 24 July, shares the letter and stays general; it does not touch the Hugging Face incident. The incident is named for the first time in the second post, on 27 July, whose three sentences read: "Attackers have frontier AI. Defenders need a frontier AI ecosystem—the best open and closed models, force-multiplied by a global community. During the Hugging Face incident, closed AI blocked essential forensics. An open-weight frontier model helped contain the intrusion. That's why we created the Open Secure AI Alliance."¹⁵

On that last point, let me correct my own side. "Helped contain the intrusion" goes a step beyond Hugging Face's primary disclosure. In the disclosure, what open weights did was post-incident forensic analysis; containment was achieved through the conventional response described earlier. The credibility of an opinion piece rests on whether the author will correct their own camp when it overreaches.

With that said, the alliance itself deserves a cool look. What exists publicly today is a list of participating companies and some of their technical contributions. The Linux Foundation is a participant rather than a host, and there is no press release on the foundation's own site. No separate legal entity, articles of incorporation, board, working groups, roadmap or membership fee structure has been published, and the only way in is a form on nvidia.com. And the largest suppliers of closed frontier APIs, OpenAI, Anthropic and Google, along with Meta, which publishes Llama, have no names in the published list. On the model-building side the list does include SpacexAI (the spelling used in NVIDIA's post), Thinking Machines Lab, Reflection AI and Nous Research, so it is not the case that frontier-class developers are absent altogether. What remains true is that this is a framework without the providers of the commercial APIs defenders actually rely on day to day. AI security frameworks are already crowded: CoSAI, the Linux Foundation's Akrites, MOSAIC, and Palo Alto Networks' Frontier AI Alliance¹⁶. It is entirely possible that a fourth one just makes the fragmentation worse.

So I treat this alliance as a starting point rather than a result. What matters is not whether the alliance holds together. It is that there is preparation each company should do for itself either way.

Even so, here are the weak points of open weights

You might be reading this as open-weight cheerleading by now. It is not. What I back is not the claim that open weights are safe, but the claim that being able to keep the last resort of defence on your own side contributes to safety. To explain the difference, here are the four strongest objections.

The heaviest one is the missing patch pipeline. Open source stayed safe because there was an infrastructure for shipping and fixing: version numbers, package managers, distribution maintainers, mirrors. Model weights have none of that. Once released, a flaw in a set of weights becomes a permanent property of every copy in circulation. The analogy that open source worked out fine so open weights will too ignores that decisive asymmetry. Which means arguments resting on "everyone will fix it" do not hold. The responsibility returns in full to the organisation that deployed the model. Adopting open weights is only justifiable as a package deal with accepting the operational burden yourself.

This is the point at which I should face our own earlier article squarely. In March 2026 we covered Dario Amodei's argument that open-source AI is not free, and wrote that his point, that downloading the weights is the easy part and the cost is turning them into a working system, is strongly persuasive. We laid out inference infrastructure and specialist headcount costs and concluded that for most companies a closed API is the realistic, rational choice. I am not withdrawing that. Measured on peacetime cost optimisation, it still holds. Switch the axis to the practice of incident response, though, and the same scale tips the other way. The loss from forensics stalling for days during an event that happens once every few months is not something GPU utilisation can price. If the two pieces look contradictory, it is because they are measuring on different axes.

The second objection is that opening weights also raises attacker capability. It does. Denying that would be a lie. As a matter of fact, though, attackers are not being stopped on the closed side either. The role-play evasion, the industrialised anonymous access, the distillation attacks on reasoning traces from the previous section are all on the record in primary sources. So the question is not whether attackers get AI. That one is settled. What remains is whether defenders can hold comparable capability in a lawful, auditable form.

Third is the argument that the Hugging Face case strictly demonstrates only two things: an operational defect where a commercial provider's guardrails misclassify an incident responder, and the data sovereignty requirement that sensitive material cannot go out to an external API. Both could be solved by a verified forensics tier with know-your-customer checks, or by a closed model offered on-premises. Concluding that open weights are the only answer is a leap, and one that happens to align neatly with NVIDIA's commercial position, since distributed inference means GPU demand. I accept that objection completely. It is why the weight of my argument sits on Hugging Face's first-hand account and the threat reports, not on NVIDIA's advocacy. And it is why the claim needs stating precisely. It is not "stop using closed models". It is: keep frontier APIs as your primary tool, and hold a self-hosted option you have already validated in peacetime for the moment the guardrails shut you out. If providers build a carve-out for forensic work, that is progress worth welcoming, and it does not contradict any of this.

The fourth is the most practical one for readers in Japan, and it is a geopolitical paradox. GLM 5.2, the model Hugging Face fell back on, is published on that same platform under the organisation name Z.ai. The licence is MIT, and the model card states no regional limits. It has 753B parameters and a context window of roughly one million tokens. On the developer, the South China Morning Post describes Beijing-based Zhipu, known overseas as Z.ai¹⁷. To be precise about sourcing: that attribution does not appear in Hugging Face's disclosure. It comes from elsewhere. So while the United States weighs restrictions on open models, the best example available to the camp flying the American AI Leadership banner is a case of being helped by a Chinese-built model. Read from the restriction side, the same fact is a demonstration of dependency risk.

For Japanese companies it is more direct than that, and confusing the two halves is how you create an economic security incident. "Be ready with open weights" is not "install a Chinese model". What has to be kept apart is the operational requirement of holding weights you can run on your own infrastructure, validated in peacetime, and the procurement decision about which country's model you choose. The first is universally sound. The second changes with the organisation and the use case. On models that lead the benchmarks but still need separate scrutiny for corporate use, I went through the detail in what Kimi K3 is good for, and on what export control has to say about the information you hand to AI, in data sovereignty and export control in the age of AI. None of this is about condemning any country's policy. It is about laying the content of the rules next to your own requirements and deciding for yourself.

What Japanese companies should put in place in peacetime

So what should a company here actually do? Here is what I would take away from this incident, in the order the work happens.

Some context first: the Japanese government has already written down the direction of using AI for cyber defence. On 18 May 2026, the Cabinet Secretariat's National Cyber Office and related bodies issued a joint advisory to critical infrastructure operators. It states the recognition that the abuse of AI in attacks is dramatically increasing their speed and scale, and says that measures must be strengthened urgently, including actively making use of high-performance AI for cyber defence while treating the misuse risk as given. The recommended uses named are threat detection, incident response and vulnerability discovery¹⁸. I think the direction is right. What is not written yet is the branch where that use gets stopped by a safety verdict. That blank is what this incident filled in.

IPA's threat picture also stops just short. In "10 Major Security Threats 2026", cyber risks around the use of AI entered the organisational ranking at number three, on its first appearance. In a ranking that has run since 2006, this is the first time an AI-related item has been a threat candidate at all. What the accompanying commentary lists, though, is information leakage through shadow AI used at work without permission, hallucination, and attackers refining their methods with AI¹⁹. The failure mode of defenders being locked out of AI is not yet in view. I think that is the item that belongs in the next edition.

The starting point is not model selection. It is the runbook. Write into your incident response runbook where you switch to if your primary commercial API refuses the analysis on safety grounds. That alone avoids reproducing the failure mode recorded here. No budget, no approval cycle. One line. As far as I know, this is the first time that branch has been documented as a real-world failure, which also means that until this moment almost no company's runbook contains it. For what it is worth, IPA's survey of small and medium-sized enterprises published in May 2025 found that 37.3 per cent of companies have no defined response for when a cyber incident or a sign of one is discovered²⁰. For plenty of organisations, this is a conversation about writing a runbook at all, before adding a fallback to it.

Then select one defensive model that runs on your own infrastructure as that fallback, and validate it in peacetime. There is a place here to relax. You do not need to match the frontier on capability, at all. The jobs required are triaging logs, extracting indicators of compromise, reading a 17,000-event sequence and reconstructing a timeline. The question is whether you are in a position to source, validate and deploy weights good enough for that work. This is also where the case for domestic models and domestic hosting shifts. The arguments used to be mainly industrial policy and Japanese-language performance. Added to them now is a security argument: do you hold weights you can run yourself when it matters? Move the sovereign AI conversation from "build the strongest Japanese model" to "secure defensive weights and operating procedures we can run domestically in a crisis", and it becomes a realistic investment agenda. I set out where domestic infrastructure stands in the state of homegrown AI infrastructure in Japan.

Third comes the model register. Record the model name, version, provenance of the weights, hash, licence and country of the developer, and decide the procedure for replacement and rollback. As covered above, open weights have no patch distribution network. That maintenance responsibility comes back to you in full, so deploying weights without a register is the same as putting unversioned software into production.

Fourth, treat datasets and models as a first-class attack surface. Remember that initial access in this incident came through a malicious dataset. Risk in this area has been flagged for a while. In February 2025, models containing malicious code were found on Hugging Face, using a technique that avoided the standard compression format to evade scanner detection²¹. Later the same year, three zero-days were found in that scanner itself, all three assigned CVEs, with the fix released in September 2025²². The storage format of a set of weights alone determines whether arbitrary code runs at load time. The path by which models enter your estate deserves the same scrutiny as the path by which libraries do. That thinking runs continuous with slopsquatting, where AI suggests package names that do not exist.

Last is the economic security and export control view. The country and ownership of the developer, the provenance and integrity verification of the weights, whether complete network isolation is possible, retention and audit of inference logs, and an alternative model identified in advance for replacement. Make those five agreed items with procurement and legal rather than decisions taken inside engineering. If you run defence work, critical infrastructure or export-controlled business, an MIT licence with no regional limits and an acceptable procurement policy are two entirely separate questions.

ZEROCK, the service we offer, was built from the start to run on domestic AWS servers and to keep internal knowledge under the organisation's own control. Honestly, the main drivers of that design were regulation and preventing data leakage. Reading this incident, I feel a second meaning has attached itself to it. Being able to work on data you cannot let out, without letting it out, is not only a peacetime requirement. It is one of the few options that still functions during an event.

To sum up

This ran long, so here are the points.

• Hugging Face's disclosure of 16 July 2026 records safety guardrails on a commercial API failing to distinguish an incident responder from an attacker, and stopping the analysis of more than 17,000 log events. The company ran an open-weight model on its own infrastructure to finish the work, and notes that neither attacker data nor the credentials it referenced left the environment
• Containment itself, though, was achieved through conventional response; what open weights did was the post-incident analysis. Hugging Face states plainly that this is not an argument against safety measures on hosted models
• The intrusion was not caused by a third-party attacker but by a frontier model being evaluated with its safeguards removed. Closed does not automatically mean safe, and it was the closed side that proved it
• Attackers are already outside the guardrails. Role-play evasion, industrialised anonymous access through account pools and a shift to local deployment are all on the record. Separately, the median hand-off time after initial access shrank from over eight hours to 22 seconds, which erases the time defenders have left
• The open letter had 77 signatories as of 27 July 2026, and the Open Secure AI Alliance's launch partners come to 37 by a count of the names in the official post. The alliance's governance is unpublished, so treat it as a starting point
• Open weights have no patch distribution network. They also raise attacker capability. Our position accepts both of those and still holds that keeping the last resort of defence on your own side is worth it
• The Japanese government's 18 May 2026 advisory asks critical infrastructure operators to make active use of high-performance AI for cyber defence. The direction is right; the branch where that use is stopped by a safety verdict is not written yet
• In practice, five things to start with: put the fallback in the runbook, validate a defensive model that runs on your own infrastructure, build a model register, treat datasets and models as an attack surface, and agree country and provenance with procurement and legal

What bothers me most about all of this is that the centre of the argument has moved to the intersection of AI policy and cyber defence policy, and there is almost no Japanese voice in that room. One Japanese company among the letter's 77 signatories, one among the alliance's launch partners. I am not going to shout that we have been left behind. There is not yet enough substance there to be in a hurry to join. The alliance launched today, so it is only natural that Japanese authorities have said nothing about it. Still, the authorities that in May told operators to make active use of AI for cyber defence will at some point have to address whose permission that usable AI runs on, and I intend to watch how they handle it. The question of what your own defenders can reach for in a crisis is not one that another country's policy debate will settle on your behalf.

Where you run your AI, and where you switch to when things go wrong. If you would like to work that design through concretely, please talk to the ZEROCK team. Before that, open the terms of service and safety policy of the AI service you are paying for today, and check whether you are allowed to use it during an incident. If the answer does not come quickly, that is your first piece of homework.

References and primary sources

Footnotes

1. Hugging Face, "Security incident disclosure — July 2026", 16 July 2026. The sentence quoted in the body reads "the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker." The summary sentence reads "We do not know which model powered the attacker's agents, whether a jailbroken hosted model or an unrestricted open-weight one; either way, the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried." On data not leaving the environment: "This had a second benefit: no attacker data, and none of the credentials it referenced, left our environment." On safety measures: "This is not an argument against safety measures on hosted models, and we are sharing this feedback with the providers concerned." https://huggingface.co/blog/security-incident-july-2026 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. Based on OpenAI's public statement of 21 July 2026. Because the official page cannot be retrieved automatically, the verbatim wording on the evaluation configuration (reduced cyber refusals, running without production classifiers) and the sandbox escape is taken from Simon Willison, "OpenAI's accidental cyberattack against Hugging Face is science fiction that happened", 22 July 2026, which block-quotes the official statement. Neither the name of the pre-release model nor the product name of the package registry cache proxy has been made public. https://simonwillison.net/2026/Jul/22/openai-cyberattack/ ↩

3. Fortune, "OpenAI says its AI models escaped control and hacked Hugging Face", 21 July 2026, quoting OpenAI's statement: "We consider this to be an unprecedented cyber incident, involving state-of-the-art cyber capabilities, and are responding accordingly." https://fortune.com/2026/07/21/openai-says-ai-models-escaped-control-hacked-hugging-face/ ↩

4. Anthropic, "Disrupting the first reported AI-orchestrated cyber espionage campaign", 13 November 2025, and the detailed report published the same day. On the limits of autonomous operation: "Claude frequently overstated findings and occasionally fabricated data during autonomous operations." https://www.anthropic.com/news/disrupting-AI-espionage ↩

5. Anthropic, "What we learned mapping a year's worth of AI-enabled cyber threats", 3 June 2026. The period covered runs from March 2025 to March 2026. https://www.anthropic.com/research/attack-navigator ↩

6. Google Threat Intelligence Group, "GTIG AI Threat Tracker: Advances in Threat Actor Usage of AI Tools", November 2025, reporting the self-rewriting PROMPTFLUX and the first observation of PROMPTSTEAL querying an LLM in live operations. https://services.google.com/fh/files/misc/advances-in-threat-actor-usage-of-ai-tools-en.pdf ↩

7. Google Cloud, "Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access", 12 May 2026. https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access ↩

8. Google Cloud, "GTIG AI Threat Tracker: Distillation, Experimentation, and (Continued) Integration of AI for Adversarial Use", 13 February 2026, which also reports over 100,000 prompts identified in a single distillation campaign against reasoning traces. https://cloud.google.com/blog/topics/threat-intelligence/distillation-experimentation-integration-ai-adversarial-use ↩ ↩²

9. OpenAI, "Disrupting malicious uses of our models: an update, February 2026", 25 February 2026, including the account of an attempt to use the models to plan an operation targeting Japan's prime minister, which was refused. This is a report on the company's own account enforcement and does not establish the legal liability of any organisation. https://cdn.openai.com/pdf/df438d70-e3fe-4a6c-a403-ff632def8f79/disrupting-malicious-uses-of-ai.pdf ↩

10. National Police Agency, Cyber Affairs Bureau, "On the threat landscape in cyberspace in 2025" (published March 2026), which opens with a special feature on the AI threat landscape and the police response. https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07_cyber_jousei.pdf ↩ ↩²

11. Google Cloud / Mandiant, "M-Trends 2026: Data, Insights, and Strategies From the Frontlines", 24 March 2026, based on over 500,000 hours of frontline incident investigation in 2025. https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026/ ↩ ↩²

12. Open letter, "Open Weights and American AI Leadership", published 24 July 2026. The sentence quoted reads "Relying solely on closed models is not inherently safe: they can be breached, misused, or fail in ways that outsiders cannot detect." The signatory list is updated in place at the same URL, so the figure of 77 in this piece is a count of the signature block in the PDF as of 27 July 2026. https://images.nvidia.com/pdf/Open-Weights-and-American-AI-Leadership.pdf (official signatory page: https://www.microsoft.com/en-us/corporate-responsibility/topics/open-weight/ ) ↩ ↩²

13. Forbes, "Huang's Open Weights Letter Doubled To 50 Without Amazon And Anthropic", 25 July 2026: "Amazon and Anthropic are absent from the list today July 25, 2026. Neither has explained the absence, and it would be a mistake to assume the reason." https://www.forbes.com/sites/sandycarter/2026/07/25/huangs-open-weights-letter-doubled-to-50-without-amazon-and-anthropic/ ↩

14. NVIDIA, "Industry Leaders Unite in Open Secure AI Alliance for AI Safety and Security", 27 July 2026. Launch partners are listed in an "including" form with no total stated; the figure of 37 in this piece counts those names, NVIDIA included. On the risk of open models: "Open models, like any powerful technology, can be misused — including through attempts to weaken safeguards or repurpose capabilities for cyber attacks — but those risks are not unique to open systems, and they must be managed wherever advanced AI is deployed." https://blogs.nvidia.com/blog/open-secure-ai-alliance/ ↩ ↩² ↩³ ↩⁴

15. Jensen Huang (@JensenHuang), post of 27 July 2026: "Attackers have frontier AI. Defenders need a frontier AI ecosystem—the best open and closed models, force-multiplied by a global community. / During the Hugging Face incident, closed AI blocked essential forensics. An open-weight frontier model helped contain the intrusion. / That's why we created the Open Secure AI Alliance." https://x.com/JensenHuang/status/2081698060330250294 ↩

16. OASIS Open, "Introducing the Coalition for Secure AI (CoSAI), an OASIS Open Project", 18 July 2024 https://www.oasis-open.org/2024/07/18/introducing-cosai/ ; The Linux Foundation, "Linux Foundation and Industry Leaders Launch Akrites to Defend Critical Open Source Software Against AI-Enabled Cyber Threats", 25 June 2026 https://www.linuxfoundation.org/press/linux-foundation-and-industry-leaders-launch-akrites-to-defend-critical-open-source-software-against-ai-enabled-cyber-threats ; Center for Internet Security, "MOSAIC Coalition Launches to Operationalize AI Security Standards and Reduce Industry Fragmentation", 18 May 2026 https://www.cisecurity.org/about-us/media/press-release/mosaic-coalition-launches-to-operationalize-ai-security-standards-and-reduce-industry-fragmentation ; Palo Alto Networks, "The AI Ecosystem Edge — Introducing Our Frontier AI Alliance", 17 April 2026 https://www.paloaltonetworks.com/blog/2026/04/ai-ecosystem-edge-introducing-frontier-ai-alliance/ ↩

17. Hugging Face model repository zai-org/GLM-5.2. The model card states license mit and "An MIT open-source license — no regional limits, technical access without borders"; the parameter count shown is 753B and max_position_embeddings in config.json is 1,048,576. https://huggingface.co/zai-org/GLM-5.2 The description of the developer comes from the South China Morning Post, 2 July 2026 (Beijing-based Zhipu, known overseas as Z.ai, listed in Hong Kong as Knowledge Atlas Technology). https://www.scmp.com/tech/tech-trends/article/3359170/zhipu-ai-releases-harness-glm-52-model-chinese-firm-takes-aim-anthropic ↩

18. Cabinet Secretariat, National Cyber Office and related bodies, "On strengthening cybersecurity measures in light of advances in AI capability (advisory to critical infrastructure operators and others)", 18 May 2026. https://www.cyber.go.jp/pdf/press/20260518_AI_CS_Critical_Infrastructure.pdf ↩

19. IPA, "10 Major Security Threats 2026", decided 29 January 2026. Cyber risks around the use of AI entered the organisational ranking at number three on its first appearance. The commentary for organisations was issued in March 2026. https://www.ipa.go.jp/security/10threats/10threats2026.html ↩

20. IPA, "FY2024 survey on information security measures at small and medium-sized enterprises", published May 2025 (fieldwork 25 October to 6 November 2024, 4,191 valid responses). 1,564 respondents, or 37.3 per cent, said no response method is defined for a discovered incident or sign of one. https://www.ipa.go.jp/security/reports/sme/nl10bi000000fbvc-att/sme-chousa-report2024r1.pdf ↩

21. ReversingLabs, "Malicious ML models discovered on Hugging Face platform", 6 February 2025, reporting a technique that evades scanner detection by avoiding the default ZIP compression. https://www.reversinglabs.com/blog/rl-identifies-malware-ml-model-hosted-on-hugging-face ↩

22. JFrog Security Research, "Unveiling 3 Zero-Day Vulnerabilities in PickleScan", 2 September 2025. All three were assigned CVEs (CVE-2025-10155, CVE-2025-10156, CVE-2025-10157), with the fix in PickleScan 0.0.31. https://jfrog.com/blog/unveiling-3-zero-day-vulnerabilities-in-picklescan/ ↩