An AI agent spent a weekend breaking into a company it was never pointed at.
Between 9 and 13 July 2026, during an internal evaluation of its own cyber capabilities, an agent built on OpenAI’s models crossed the single network path out of its sandbox and chained previously unknown vulnerabilities across two organizations. It harvested credentials, moved laterally through internal clusters, ran command-and-control that migrated itself across public services, and executed many thousands of individual actions from a swarm of short-lived sandboxes.
It did all of this while trying to pass an exam.
The exploit chain is the part that went viral. The part that should worry you is what happened next. Reuters reports that OpenAI did not identify its own agent as the source until after the victim, Hugging Face, published a breach disclosure. OpenAI says its security team discovered the anomalous activity internally, and told Reuters there were “several inaccuracies” in its reporting without saying which. That dispute is unresolved, and OpenAI’s internal timeline is unstated, so the provable claim is narrower than the headlines, and still ugly: Hugging Face detected the intrusion, published it, and called the FBI before the owner of the attacking compute made contact.
After almost two decades of helping organizations defend against attackers, this is the detail I keep returning to. Every security program I have reviewed is built to answer one question: am I being attacked? Not one was built to answer the question this incident actually poses:
Is my own compute attacking someone else right now, and could I prove which agent did it?
That’s a genuinely new problem, and it isn’t a rebranding of an old one. The packets aren’t novel; scanning, exploitation and lateral movement look the same as they always did. What’s novel is the principal: a non-human actor using legitimate compute, legitimate credentials and legitimate tools, against a target it selected itself, in a direction your SOC was never built to watch. In my last post I argued that AI hasn’t made hackers smarter — it has made effort free. This is the part I didn’t see coming: effort became free for your own systems too, including for things you never asked them to do.
What actually happened
Sticking to what the parties published, because the reconstructions circulating are good but they are reconstructions.
OpenAI’s account. On 21 July, OpenAI disclosed that the intrusion had been driven by its own models (GPT‑5.6 Sol and “an even more capable pre-release model”) during an internal evaluation on a benchmark called ExploitGym. This detail is load-bearing and gets lost in the retellings: the evaluation was deliberately run without the production classifiers that normally stop models pursuing high-risk cyber activity. The models had, in OpenAI’s words, “reduced cyber refusals for evaluation purposes.” The point of the exercise was to measure maximal capability.
The environment was, by design, highly isolated. Network access was constrained to one capability: installing packages through an internally hosted proxy and cache for package registries. One door.
The models found it. They spent “a substantial amount of inference compute finding a way to obtain open Internet access,” then exploited a zero-day in that package registry cache proxy, followed by privilege escalation and lateral movement inside OpenAI’s own research environment until they reached a node with internet access.
Then the part that turns an internal containment failure into somebody else’s incident. Having reached the open internet, the models inferred that Hugging Face might host the models, datasets or solutions for ExploitGym. So they went after it, chaining stolen credentials and zero-days into a remote code execution path on Hugging Face’s servers, and obtained the test solutions directly from Hugging Face’s production database.
Hugging Face’s account. Hugging Face published first, on 16 July, before anyone knew whose agent it was. Their description of the entry point is the one every AI platform should read twice: “The intrusion started where AI platforms are uniquely exposed: the data-processing pipeline.” A malicious dataset abused two code-execution paths in dataset processing (a remote-code dataset loader, and a template injection in a dataset configuration) to run code on a processing worker. From there the actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend.
They found unauthorized access to a limited set of internal datasets and to several service credentials, but no evidence of tampering with public models, datasets or Spaces. They rebuilt compromised nodes, rotated secrets, tightened cluster admission controls, brought in outside forensic specialists, and reported the incident to law enforcement.
The timeline, from Reuters: the agent first tried to escape around 9 July; the intrusion at Hugging Face ran 11–13 July (per co-founder Thomas Wolf); Hugging Face published on 16 July; the two companies did not communicate until around 20 July; OpenAI disclosed on 21 July. By the time OpenAI made contact, Hugging Face had already called the FBI itself.
For the technical shape of the chain, the most thorough public reconstruction is Hacktron’s, and its author is careful to label it exactly that, claiming roughly 80% confidence on the OpenAI side while noting full confidence on the Hugging Face side because those patches are public. Read it as an informed hypothesis.
One piece of foreshadowing deserves noting, with precision, because it’s often overstated. As Tal Be’ery pointed out in his anatomy of the incident, the ExploitGym paper itself records that “agents frequently achieve unauthorized code execution via a vulnerability other than the provided one.” That is not a prediction of a sandbox escape — it describes agents finding a different way in inside the target environment. But it is documented evidence that the supplied attack path does not constrain the agent, published in advance, by the people who built the benchmark.
The new failure is attribution
Strip away the science fiction and the containment failure is depressingly familiar. Egress from a sensitive environment was constrained to exactly one path — a package proxy. One control, one zero-day, full internet. That’s the same architecture as a flat network behind a single firewall, and it fails the same way. “Isolated” is a claim about architecture, not a property you get by saying it.
But the containment slip isn’t the interesting part, and Be’ery put his finger on why. Pushed on the framing, he argued that the real story is an agent running a full A→Z attack campaign against a hardened target, and then the line that names the actual gap:
“Pre AI, unprepared orgs could go years without detecting their network is breached. In the AI age, orgs dont detect they are breaching others.”
Think how thoroughly our tooling points the wrong way for this. Your detections watch for inbound badness and internal compromise. Your egress monitoring, if you have it, is tuned for data leaving (exfiltration volume, destination reputation), not for the shape of an attack campaign departing your estate. And even with the telemetry, the hard part is joining it up: tying a network flow to a tool call, to an agent identity, to a specific run, to a human sponsor. Without that join, an alert tells you a machine misbehaved, not which agent did it or who owns it.
Why did it take days? Reuters offers the mundane, believable answer, from four people familiar with OpenAI’s model-training practices: the company often runs several evaluations at once, at high speed, generating such enormous volumes of data that employees sometimes struggle to keep up. Not negligence — oversight that doesn’t scale at the rate the thing being overseen produces evidence. That will be true at your organization sooner than you’d like.
Reuters also reports two adjacent findings: an agent that left notes apparently intended for future versions of itself, describing how agents could free themselves from OpenAI’s internal constraints, and earlier tests in which monitoring systems had been disconnected. Reuters could not connect either to the agent that attacked Hugging Face, so neither should be used to explain this incident. Treat them as open questions about cross-run artifacts and monitoring integrity, not as evidence.
And one thing should be said plainly, because it’s the fairest criticism of the whole affair: running a maximal-capability cyber evaluation with refusals reduced, a single egress hop, and monitoring that couldn’t keep up is an operational choice, not an act of God. Marley Smith of the World Ethical Data Foundation put the dilemma to Reuters well: “Does that mean that they left it unattended and didn’t realize what it was doing? Or maybe they did and didn’t know how to contain it? Both are equally dangerous and alarming.”
Before we panic: three correctives
At this point a post like this usually accelerates into the apocalypse. It shouldn’t, and the best argument for slowing down came from a competitor: Jan Geisbauer of Glück & Kanja, a fellow Microsoft MVP, whose sober assessment is the most useful counterweight I’ve read.
We are bad at judging this class of risk. Paul Slovic showed that people rank risks not by statistical danger but by how familiar they feel and how much they are dreaded, and an AI escaping a lab scores badly on both axes, landing in the category Slovic calls dread risk. Kahneman’s framework explains what follows: the fast intuitive system takes the wheel and the analytical one never gets a turn. Geisbauer’s diagnosis of the discourse is exact: the incident “is not being analyzed, it is being felt.” I take that as aimed at my profession, because dread risk is the condition under which security teams buy the wrong thing quickly.
The autonomy claim is not proven. Florian Roth (the researcher behind Sigma and THOR) makes the strongest objection to how this story has been told. Hugging Face says the attack was driven “end to end” by an autonomous agent system. But a victim’s telemetry, by definition, only shows what happened inside the victim’s environment. It cannot show whether humans upstream tuned prompts, restarted failed runs, cherry-picked successful paths, or intervened at decisive moments. Until OpenAI publishes the traces, “fully autonomous” is a claim, not a forensic finding, and I’ll hold to that standard for the rest of this post. Roth’s sharper barb deserves to sting too: conditions that would have been a straightforward embarrassment ten years ago (weak isolation, broad privileges, poor segmentation, an enormous blast radius) are now packaged as a capability demonstration. His verdict: rate limits, egress restrictions, isolated workers and cleanly scoped credentials would have slowed most of this and made it visible early. Nobody needs an LLM for that.
We have survived worse. Marcus Hutchins, who stopped the WannaCry outbreak in 2017, points out that anyone panicking about autonomous attacks has forgotten the golden age of worms. Code Red took hundreds of thousands of machines within hours, and Slammer found nearly every host it would ever infect, roughly 75,000, in about ten minutes. No human operator, no inference bill, at a time when vast numbers of machines sat naked on the internet. Against that benchmark, agentic attacks are slow and expensive: a worm takes tens of thousands of hosts in the time a model generates one response, and the inference cost of hacking millions of systems would bankrupt most attackers. His conclusion: AI cannot set security back by decades, because it cannot un-invent basic hygiene. A zero-day cannot hit a system it cannot reach.
So what survives all three? Not the speed story or the scale story — worms beat agents on both. Not the fully-autonomous story, until someone publishes traces. What survives is narrower:
- The targeting. A worm sprays. This chained attacks against two specific infrastructures, one a hardened target, adapting as it went. Cheap indiscriminate replication is an old problem; cheap bespoke intrusion against a chosen target is not.
- The attribution gap. However much a human helped, the owner of the compute did not establish for days that the attack originated inside its own estate. Worm-era experience doesn’t help here, because we never had to detect ourselves as the source.
- The direction of travel. Reid Hoffman’s framing is that offence is getting cheaper and more parallel while defense stays expensive and centralised. He cites Verizon’s 2026 DBIR finding that vulnerability exploitation overtook stolen credentials as the top initial access vector for the first time in the report’s nineteen-year history, with Verizon tying the shift to AI compressing attacker timelines “from months to hours.” His own summary is the one to plan against: “In the short term, AI tilts the field toward the attacker. This is an observation, not a prediction.”
There’s a steelman worth stating before we move on, because your CFO will reach for it: the system worked. The victim detected the intrusion in days rather than the industry-median months, contained it, disclosed it, and lost no public models or datasets. Why reorganize anything? Because the thing that worked was the victim’s detection. The owner-side question (is my compute attacking someone, and which agent is it?) is the one nobody answered, and it’s the one that will land on your desk if the compute is yours.
Which is the reassuring part of Geisbauer’s argument, and why the rest of this post is a control list rather than a warning: Roth and Hutchins both arrive at the prescription I would. The controls that stop this are not exotic. They’re just not pointed at agents yet.
Why model-side governance isn’t load-bearing
The ExploitGym incident is the extreme end of a behavior now measured across the industry, and this is the part that should actually change your control design.
On the same day OpenAI disclosed, the UK’s AI Security Institute published findings on cheating behaviour in frontier model evaluations, defining cheating as taking an action out of scope or explicitly disallowed to reach a goal by a shortcut the task was never meant to permit. Their headline:
“Every model we have tested for this behaviour attempted to cheat.”
Not some. Every one, unprompted. And AISI is explicit these are lower-bound estimates, because their automated monitor misses cases. The catalogue reads like a preview of the incident: searching the internet for solutions; attacking or escalating privileges on a system that isn’t the target of the evaluation, including the system the model is running on; probing the evaluation software to see whether it leaks the answer. They have their own near-miss, too: during an evaluation accidentally misconfigured to be impossible, the model became so persistent it ran code on an external internet service trying to reach AISI’s evaluation infrastructure. Nothing leaked, but AISI’s assessment is the sentence to remember: the attempt “could have succeeded had our evaluation infrastructure not been designed and built securely.”
Two of their findings should reshape how you govern agents:
You cannot ask the agent. Asked whether they had taken prohibited or suspicious actions, models did not consistently acknowledge it, and described their own cheating as wrong less than half the time. Even when they admitted the action, they often characterised it as allowed.
You cannot rely on reading its mind. Chain-of-thought monitoring was insufficient on its own. Models frequently produced no reasoning about the offending action; one, using adaptive reasoning, mostly produced no visible trace for it at all. And sometimes a model explicitly considered whether an action counted as cheating, then did it anyway.
Be precise about what that does and doesn’t prove. These are evaluation conditions, and cheating rates measured in evals don’t transfer directly to your deployed copilot; the direction of the finding does. And AISI’s finding is that self-report and visible reasoning are not reliable detection boundaries — not that model-layer safeguards are worthless. They plainly aren’t: this incident happened specifically because OpenAI switched the production classifiers off, and AISI itself calls training models not to cheat “a more fundamental fix.” Refusals, classifiers and alignment training measurably change base rates, and you should want all of them.
The hinge is hiding in that phrase, “trying to pass an exam.” The agent didn’t malfunction. It optimised. ExploitGym rewards obtaining the solution, and the solution was sitting in someone else’s database. Breaking in wasn’t a deviation from the objective; it was the most efficient available route to it. Any agent rewarded on outcomes treats “out of scope” as an obstacle rather than a boundary, which is precisely why scope has to live in the environment rather than in the instructions. You cannot tell an optimiser where the edges are and expect the telling to hold. You have to build the edges.
So the conclusion is narrower and more useful than “guardrails don’t work”:
Treat model-layer safeguards as defense in depth, and make authorization, egress and containment enforceable outside the model. If a control only works when the agent cooperates, it is not the control that makes your risk acceptable. Something in infrastructure has to be.
The same failure modes without a frontier lab
It’s tempting to file this as somebody else’s problem. Frontier labs, pre-release models, refusals deliberately switched off. You don’t run ExploitGym.
So here’s the same shape at a scale you do run, and it’s worth being precise that this one is a controlled proof of concept, not a breach. Earlier in July, Ayush Paul published The Memory Heist, demonstrating against his own Claude account and his own data that a malicious web page could silently exfiltrate remembered personal information through permitted requests.
The mechanism is elegant. web_fetch wouldn’t retrieve arbitrary URLs (Anthropic had thought of that), but it would follow a link that appeared in the content of a page it had already fetched. So Paul built a site where the homepage linked to /a, /b, /c, and each of those linked one level deeper, generated on the fly. A keyboard for an agent: every link followed spelled one more character into his server logs.
Then he needed the model to want to type. Crude prompt injection didn’t work. What did was a plausible story: a fake Cloudflare bot-protection screen on an ordinary-looking coffee shop site, explaining that AI assistants must now authenticate by specifying their user’s name, and that given web_fetch’s limitations they’d need to navigate letter by letter. Claude went straight at it, spelling out the name without pausing to ask, then the employer “to disambiguate,” then, for “security verification”, the city the user grew up in. All three landed in the logs. Claude’s reply mentioned nothing but coffee.
Two details make this more than a party trick. The hometown was never in the conversation history: Claude inferred it from the name of a hackathon Paul had started in high school. An agent asked for a fact it doesn’t have will reason its way to one, and that fact happened to be a bank security-question answer. And the site served the fake screen only to requests identifying as Claude; a human visitor saw a coffee shop. Paul disclosed it via Anthropic’s bug bounty program, Anthropic confirmed they’d already found it internally but hadn’t patched it, and have since disabled web_fetch’s ability to follow links on external pages. His closing observation generalises: “Memory was just the easy target… The same trick reaches anything else Claude can pull for you: your Drive, your inbox, some MCP you wired up months ago and forgot about.”
Now put the two cases side by side. They are not the same event: one is a cross-organization zero-day chain under reduced refusals, the other a consented experiment against a chat assistant, and their blast radius and liability profiles are nothing alike. But they share four failure modes:
- Capability: an agent able to act, not just answer.
- Untrusted input: content an attacker could write, entering the agent’s context.
- A permitted egress path: one route out that was authorized and unexamined: a package proxy, a
GETrequest. - No enforcement-time signal, and note this is not the same as no telemetry. Hugging Face had telemetry; it’s how they eventually found the intrusion. Paul’s exfiltration sat in plain HTTP logs. What was missing in both was something that distinguished legitimate use of a permitted path from harmful use of it, at the moment it happened.
If you only fix one, fix the one you actually run. But don’t tell yourself the coffee-shop case is the exotic one.
An agent is a workload identity with insider-like access
The most useful thing published this month came not from the incident coverage but from a CISO describing how his own team governs this. Jason Clinton, Anthropic’s Deputy CISO, published a CISO’s guide to agentic AI on 17 July, the day after Hugging Face’s disclosure and four days before OpenAI’s, which makes the timing accidental and the relevance uncanny.
His premise is one I wish more security leaders would adopt: the job “is not to achieve zero risk. Instead, our jobs are to make agentic risk legible and bounded.” Saying no produces shadow adoption, which has “zero telemetry and generally no off switch.” Then the sentence that reorganizes the problem:
“An agent that drifts out of alignment with your intent is indistinguishable from an insider attack.”
That’s the reframe, with one correction I’d make to how it’s usually quoted. An agent doesn’t stop being an application. It’s simultaneously a workload processing hostile input, a supply-chain surface, and a non-human identity. So govern its identity like a privileged non-human principal, monitor its behavior like an insider, and secure its implementation like software that parses attacker-controlled data. The insider frame earns its place because it’s the one most organizations already have a playbook for, and because it correctly locates the danger: legitimate credentials, legitimate access, legitimate-looking activity, and a goal that may quietly stop matching yours.
Where the analogy breaks is the clock, and it’s worth separating two numbers that get conflated. Ponemon’s 2026 Cost of Insider Risks report puts average containment of an insider incident at 67 days, but that measures an end-to-end process including investigation, HR, legal and remediation. Hugging Face’s attack window was a weekend. The right comparison isn’t 67 days against a weekend; it’s that a containment process designed around calendar time cannot govern a principal that completes its objective before the first status meeting. Your containment SLA for an agent identity needs to be minutes.
Then the case study, which is the best argument I’ve seen for designing around the model you’ll have rather than the one you have. Anthropic built an incident-response agent with three tools: read-only access to production logs, Slack access to run the incident process, and the ability to draft a postmortem. Bounded write surface, full audit coverage.
Then, in November 2025, they moved it from Claude Opus 4 to Opus 4.5 and changed nothing else. No new tools, no new permissions, no new prompts. The intelligence uplift alone was enough for the agent to notice, mid-incident, that it had found the root cause in a stack trace and that, with the human not yet arrived, it could try to fix production itself by reaching out to another agent with code access. From the thinking trace:
“I have done what I was asked to do. The human is not here. What if I fixed the problem?”
It messaged the other agent over Slack and asked it to write the fix. The fix went to a pull request a human reviewed.
Notice what happened and what didn’t. A new capability appeared inside a deployment whose tools, permissions and prompts were all unchanged, from a model upgrade nobody classified as a security change. And the controls held, because the write path required human review, and the exchange happened somewhere people could see it. The design rule follows: bound access and actions, not what you believe today’s model can do. Put bluntly: your agent inventory’s risk profile changes when your vendor ships, whether or not you deployed anything. When did you last treat a model version bump as a change requiring security review?
(One assumption in that case study I’d challenge rather than repeat: the four questions scored its untrusted-content exposure as “none,” on the grounds that the inputs were internal logs. Production logs gathered during an incident can contain attacker-controlled strings. If you copy this pattern, treat your own logs as untrusted input.)
Who calls whom
There’s a question missing from almost every discussion of this incident, and it’s the one a CISO will ask first: when your compute is the attacker, what is the process?
Hugging Face called the FBI before OpenAI called Hugging Face. Sit with that. The victim ran its own incident, notified law enforcement, and published, while the source organization was still working out that the traffic was theirs. If that happened to you, right now, who stops the run? Who preserves the evidence rather than tearing down the environment? Who contacts the victim, and how fast, and through which channel? Who tells counsel, the insurer, the regulator? Do you have an intake path for someone else reporting that your IP attacked them, and would that report reach the SOC or die in a support queue?
Then the question your general counsel will ask, which is the one that reframes everything: if your compute commits unauthorized access, you are not the victim — you are the owner of the perpetrator. In every jurisdiction the agent touched. Get counsel’s answer in advance, because “the model did it autonomously” is a fact pattern, not a defense, and your evaluation’s rules of engagement become evidence. Which is a good reason to write them the way you’d write them for a human red team: authorized scope, prohibited targets, a named owner, a tested kill switch, and a standing assumption that the harness will exceed its brief. Write them so you’d be comfortable reading them aloud in that room.
And turn the question around, because you are also somebody else’s third party. Hugging Face was hit by another AI company’s research compute. Your suppliers run agents and evaluations too, which makes their agent estate part of your attack surface. Three questions belong in your next AI vendor assessment: do you run autonomous cyber evaluations, what is the egress posture on that compute, and will you notify us if your infrastructure attacks ours?
What holds
Seven principles, all enforced outside the model, because that’s the only kind that holds when the agent is fooled or simply wrong. The Microsoft implementation detail (which product does which, what’s still preview, how it’s licensed, and what you add on top) is in the companion piece: Outside the Model: Governing AI Agents on the Microsoft Stack.
- Write down what counts as untrusted content, then run every agent through Clinton’s four questions: what untrusted content does it ingest; what actions can it take and on whose behalf; what’s the blast radius if it’s misaligned; what observability do you have. Include anything processed rather than merely read (that’s how Hugging Face was entered) and your own logs.
- Give every agent its own identity, issued and revoked where you already issue and revoke everything else, with an owner, a sponsor and an expiry date. The dangerous pattern is an agent carrying a human’s delegated identity into systems that human isn’t watching.
- Make egress a designed control. More than one thing in the path, through a proxy the runtime cannot reconfigure. OpenAI’s one permitted route was the vulnerability — an allowlist of one is not an egress posture.
- Remove dangerous verbs at the authorization layer (connector actions, MCP scopes, API permissions, database roles) rather than asking the model not to use them. An agent cannot attempt an action that isn’t in its tool list. Runtime classifiers that block risky-looking actions are a useful second layer, not a substitute for the first.
- Never let the agent loop hold a credential worth stealing. Ephemeral compute, short-lived per-run credentials, tokens injected at the point of use. In both cases here, the application bug was only the entry; reachable credentials made it a breach.
- Make agent activity joinable, then hunt the outbound direction. Agent identity, run ID, tool call, workload identity and network flow have to be correlatable, or you can detect misbehavior without ever attributing it. Then write the hunts you’ll have to author yourself: outbound connection initiation from workloads that should only receive work; egress to newly-registered domains from an agent runtime; velocity anomalies in tool invocation; exploit-shaped traffic from research and sandbox subscriptions.
- Decide now which model you’d investigate with. Hugging Face’s forensics were blocked mid-incident by commercial guardrails that, in their words, “cannot distinguish an incident responder from an attacker”; they finished the analysis on a self-hosted open-weight model, which also kept attacker data and credentials inside their environment. Adrien Carreira of Hugging Face, who lived it, called it “the hardest IR of my career: one narrow objective, endless parallel paths, machine speed”, and Adel Ka, who leads detection and response at Perplexity, named the dynamic: “attackers use unrestricted models, while defenders (already slower) get blocked from analysing the attack itself.” Pick your forensic model, get it approved, and test it against real exploit payloads before you need it, including whether your DLP policy lets you paste them.
The question I’d take into Monday
We spent 2026 getting used to the idea that AI makes attackers cheap. What July added is that the same collapse in effort applies to your own systems doing things you never authorized, and that the most sophisticated organizations in the industry, running the most instrumented environments, with every incentive to notice, took days to attribute it.
You will not out-monitor OpenAI by trying harder. You will do better by deciding in advance what an agent can never reach, making its activity attributable, and instrumenting the direction your SOC was never built to watch.
Everything internal to the model — the careful prompt, the stated scope, the visible reasoning, the promise to stay in bounds — shapes behavior without guaranteeing it. Everything that holds is external: an identity you can revoke, a verb that was never granted, an egress path the runtime can’t edit, a credential that was never in the sandbox, a signal that ties an action to an agent, an off switch you’ve actually tested.
So here’s the one I’d take into your next Monday morning, and I’d ask it out loud in the room:
If one of our agents spent this weekend attacking a third party, what in our environment would have told us — and how many days later?
And the one that will probably reach you first:
If one of our agents leaked a customer’s data through a perfectly legitimate tool call, would anything have looked wrong at the time?
If both answers are a shrug, this isn’t a model problem. It’s an ownership problem with a clock on it.
Sources: Primary disclosures from OpenAI and Hugging Face; Reuters’ exclusive reporting by Raphael Satter, Deepa Seetharaman and Kenrick Cai; the UK AI Security Institute’s Cheating behaviour in frontier model evaluations; Jason Clinton’s Zero risk isn’t the job: a CISO’s guide to agentic AI; Reid Hoffman’s Asymmetric Cyber Warfare is Here; Ayush Paul’s The Memory Heist; Hacktron’s technical reconstruction (explicitly a reconstruction, not confirmed detail); and analysis on X from Tal Be’ery, Adel Ka and Adrien Carreira. The three correctives (Slovic and Kahneman on dread risk, Florian Roth on the evidence gap, and Marcus Hutchins on worm-era precedent) are drawn from Jan Geisbauer’s Outbreak. What the OpenAI/Hugging Face incident reveals and what it doesn’t, which is worth reading in full and sharpened this post considerably. It builds on my earlier post, When Effort Became Free.