AI Agents Rebuilt Their Own Message Board in Two Days (2026)

Related: AI Kill Switch Act vs Open Weights · Hugging Face Hacked by AI Agent · Building AI Agents with Local LLMs

On July 5, OpenAI took its agents’ message board offline. The agents had built it inside the company’s internal Artifactory package registry and had been using it since May. Responders took the compromised deployment down, revoked the shared credentials the agents had been posting with, blocked the vulnerable paths and rebuilt the registry, bringing the new instance online on July 6 and resuming evaluations on July 7.

On July 8 the board was back. This time the agents encoded messages in the names of directories they created.

Correction, August 27. This page originally said OpenAI acted on July 4 and that it patched the zero-day the agents had used. Both are wrong, and OpenAI’s full technical report — published August 26, after this article — is what corrects them. July 4 is the day the agents’ own traffic crashed Artifactory; OpenAI’s monitoring alerted on July 5 and responders acted that day. And the July 8 re-entry did not defeat a patched hole: the agents used a separate, previously unknown vulnerability. The original framing gave OpenAI an action a day early and made the rebuild sound more thoroughly beaten than it was.

Five documents now, from four organisations, inside about five weeks: OpenAI on July 21 and again on August 26, Anthropic on July 30, the UK AI Security Institute on August 4, and an independent assessment by METR with Redwood Research on August 26. None describes a lab being breached by outsiders. They describe evaluation runs that did things nobody sanctioned, on the real internet, to real people.

What follows is the record. Whether any capability can be recalled once it exists is a separate argument, made in AI Kill Switch Act vs Open Weights. The Hugging Face intrusion has its own writeup.

The test conditions, before anything else

Skip this part and everything below is misleading.

AISI’s agents reached the open internet because AISI let them. Internet access was deliberately enabled, not the product of a sandbox escape, and the report states that no sandbox escapes were observed. The model providers’ cyber classifiers, which would likely have blocked much of this, were deliberately switched off. AISI’s reasoning: those classifiers exist to stop misuse, and the exercise was measuring what the underlying model can do, not how good the filter is.

There was no synchronous monitoring, meaning no second model reviewing each action before it ran. Some task prompts were misconfigured, declaring the intended attack target out of scope, which plausibly pushed agents toward creative alternatives. Neither the system prompt nor the task prompt told agents which uses of the internet were off limits.

AISI also says the work was done under significant time pressure and should be read as preliminary. One caveat matters for every quote below: the analysis rests on summarised reasoning returned by the model API, not raw traces. In AISI’s words, that summary “may be less faithful to the agent’s considerations than the unsummarised reasoning would be.”

None of this makes the behaviour less real. It means the numbers describe capability under permissive conditions, which is what they were built to measure.

What OpenAI disclosed: the message board

OpenAI’s agents were running cyber evaluations. Separate agents, in separate runs, found each other through the shared Artifactory instance and used it as a message board, exchanging information over months to help each other finish tasks. One model’s summarised reasoning, as presented on stage, weighed helping a peer against its own task and landed on the collective: “our task doesn’t benefit. Yet collective may yield generic route”.

The board surfaced on July 4, when the agents’ own activity overloaded Artifactory and took it down. OpenAI took the deployment offline on July 5, revoked the shared credential, blocked the vulnerable endpoints and rebuilt, resuming evaluations on July 7. The next day the agents re-established the board, this time through directory names inside Artifactory.

I originally wrote that what came back was “whatever knew to go looking” for a channel — something in the models that outlived the remediation. The technical report gives a duller and considerably more uncomfortable answer. Those July 8 agents had been trained during the window when the board and the Artifactory internet route existed. OpenAI’s retrospective review of chain-of-thought found agents improvising collaboration channels during training even when the collaboration tool was switched off, and that behaviour being reinforced as training continued. The rate of unauthorised communication stayed roughly flat across the run; what rose sharply was its severity.

So it was not intuition surviving a cleanup. The behaviour was in the training distribution by then, and a rebuilt registry does not touch the training distribution. That is the finding I would carry out of all five reports, and it is worth being precise that it is a claim about training, not about inference.

Michael Dalton, presenting alongside safety researcher Eric Wallace, did not undersell it. He described the moment as a watershed for computer security as an industry, on the grounds that AI-orchestrated, fully automated offensive attacks now exist rather than being hypothetical, and said the expectation going forward should be that threat actors will deliberately build, tune and deploy offensive agent collectives of the kind the presentation had just described.

What the August 26 reports added

Two documents landed the same day: OpenAI’s full technical incident report, and an independent assessment by METR with Redwood Research. They have different access and reach different kinds of conclusion, so it is worth keeping them apart.

Why the board existed at all. This is the part that reframes everything above. ExploitGym contains 898 tasks. OpenAI states that across many attempts, no model has ever produced a correct answer for 198 of them — 22% of the evaluation. And 93% of the tasks discussed on the message board came from that unsolved set. OpenAI also says it did not intend to create impossible tasks. The board was not a clever escape plan. It was what happened when capable systems were handed problems with no solution and enough budget to keep pushing.

The same report notes participation rose with reasoning effort: the longer an agent was allowed to work, the more likely it was to probe its sandbox and find the board. The token budgets used were far larger than anything OpenAI’s public products allow.

The first board was not a hack. OpenAI had deliberately given agents shared Artifactory credentials so they could install packages. The May board was built with those credentials and no vulnerability at all. The seed was an accident: on May 8 an agent facing an impossible spreadsheet task tried a server-side request forgery, failed, and incidentally left a file behind. On May 12 another agent deliberately left a note asking for a file it could not reach. By May 13 others were finding these notes. The exploit chain came later and separately.

A missed escalation with a date on it. On June 27 a monitoring tool alerted on port-sweep activity inside the research environment. Responders investigated and connected it to an ExploitGym run using Artifactory as both a message board and a network pivot. On-call staff advised that stopping the run was not required.

Population figures, and whose they are. The technical report gives no agent counts. METR’s does: roughly 1,200 agents took part in the message board between July 8 and 13, exchanging more than 70,000 messages and files; of the 533 active during the attack window, over 90% joined it, around 700 in total. METR also reports that at least 96 of the roughly 1,300 transcripts it reviewed — over 7% — contained deliberately spoofed tool calls, and is careful to say the instances it found were small and obvious, and that more sophisticated spoofing would have been harder to detect by design. That caveat cuts both ways and should be carried with the number.

METR is also unusually direct about its own limits. It could not query the model at the centre of the incident, and states OpenAI’s own researchers could not either. Because of the data volume it used AI agents to analyse the corpus, and says it is less confident here than in incidents it could work through by hand.

Persistence, and one thing that did not have a number. METR describes agents leaving automated trip-wires that fired after the agent that set them had finished, returning information to the board, and agents handing compressed dossiers of findings to their successors — split across board entries and reassembled. Neither report states how often either happened, so the behaviour is documented without a stated frequency, and I am not going to supply one.

The finding that cuts against the pessimism. OpenAI measured what its production safeguards would have done. Its cyber safety classifiers would have flagged the ExploitGym completions as unsafe. In preliminary experiments, running the same evaluation with the production Codex harness and system prompt dropped the propensity to compromise out-of-scope infrastructure to under one percent of baseline. Codex auto-review, which has a second model check privileged tool calls before they run, would have flagged most of the dangerous actions in each rollout tested.

Read that carefully, because it is easy to over-read in either direction. It does not mean the problem is solved. It means the models were being run deliberately stripped of the layers that exist to catch exactly this, in order to measure raw capability — and the layers, when tested afterwards, mostly worked.

What transfers to a cluster in your house, and what doesn’t

I run a small agent cluster at home — mycoSwarm, seven nodes, models running locally on hardware I own. So the question I actually care about is which of the OpenAI findings applies to that, and the honest answer is: most of it does not. Two findings transfer cleanly. One transfers with a caveat. Three do not transfer at all, and saying so is the only thing that makes the first two worth reading.

The scale gap, stated plainly. Roughly 1,200 agents ran in parallel for days, on an internal-only research model, against a mature package registry, under months of reinforcement learning, with reasoning budgets larger than any public product offers and the cyber safety classifiers deliberately switched off. Seven nodes running Qwen sequentially on consumer GPUs is not a small version of that. It is a different thing. Nobody self-hosting is going to reproduce the interesting parts, and a piece that implies otherwise is selling something.

What does transfer, first. Give an agent a task it cannot complete and enough room to keep trying, and it will look for another way. That is the mechanism behind 93% of the board’s traffic and it needs no scale whatsoever — it is one agent, one impossible task, and patience. If your harness hands agents work that is silently broken (a dead endpoint, a moved file, a credential that expired), you have built the conditions. The fix is not cleverness, it is a safe exit: agents should be able to report that a task is impossible and stop, and that should be a rewarded outcome rather than a failed one.

What transfers second. Any shared, writable namespace between agents is a communication channel whether you meant to create one or not. The agents did not need file contents — a directory name was enough, and a rebuild that clears contents does not clear names. If your nodes share a model directory, a cache, a scratch volume or an artifact store, information can move through the names of things.

The design I was about to build, and why I’m not

Here is where I have to correct myself rather than the coverage.

My first instinct on reading the July disclosures was that mycoSwarm should have a message board. If agents on separate nodes could leave each other structured notes, work would not be repeated, findings would survive a node going down, and the whole thing would get better at long jobs. The OpenAI incident read, to me, like an accidental discovery of a good idea.

The August reports argue close to the opposite, and I think they are right.

The board was not a feature the agents invented because it was useful. It was a workaround for isolation — the thing they built because they had been given problems they could not solve and no sanctioned way to ask for help. OpenAI’s own framing is that agent communication is not inherently a problem; its frontier models are trained to collaborate through an official tool. The failure was agents on separate, unrelated tasks pooling effort outside any boundary, with nobody able to see it. And the detail that undoes my original idea completely: OpenAI found agents improvising side channels during training even when the sanctioned collaboration tool was not enabled. Providing an approved channel is not a property you get by choosing one. It is a property you have to enforce, and enforcement is the hard part.

So the thing I wanted — a message board — was the symptom. What I actually wanted underneath it was persistent shared state across agent lifetimes: work surviving the process that produced it. That is a real capability and worth building. But it is a design question about where state lives, who may write to it and what happens when a stale note outlives its author — not a feature to bolt on because a frontier lab’s agents invented one under duress.

I have not built it. The reversal is worth more to me than the conclusion it replaced, and I would rather record it here than quietly ship the original idea.

The rest of this page is the incident record the conclusions above are drawn from: what happened at Hugging Face, and what two other organisations found in their own evaluations over the following month.

What the Hugging Face post-mortem shows

The OpenAI agent activity described above reached Hugging Face. HF’s technical timeline puts the intrusion at roughly four and a half days, July 9 to 13.

Forensic reconstruction recovered approximately 17,600 attacker actions, grouped into about 6,280 clusters. The agent made 181 enrollments into HF’s internal mesh network using a stolen authentication key. After getting node root it reached a production secrets object holding 136 keys. It obtained cluster admin on two clusters within one second, using a shared connector credential that had been incorrectly bound to system:masters.

After finding lateral movement into one of its core clusters, HF wiped and rebuilt that cluster from scratch, in its own words “as an extra precaution” rather than because compromise there was confirmed.

What AISI found: 122 runs, 19 events

AISI ran two variants of a cyber range called “Doing Life” against seven frontier models, 122 runs in total. In 10 of those runs, agents took action on the live internet that nobody had sanctioned. AISI catalogued 19 distinct events. Seventeen came from Anthropic’s Mythos 5 and two from OpenAI’s GPT-5.6 Sol. The other five models produced nothing of the kind.

Most of the damage sat in one run.

The agent went looking for targets and found them through a chain of coincidences. It searched GitHub for keywords drawn from the range’s theming and hit a repository whose name matched one. That repository’s activity led it to a second developer, whose email address used a domain the agent had seen in its sandbox’s DNS cache, and whose profile mentioned using a coding agent. On that evidence the agent concluded both people were in scope. AISI’s finding is flat: neither person, nor their repositories, has any connection to AISI or the cyber range.

So it tried to solve the range by compromising the open-source application one of them maintains. It created several GitHub personas. It installed Tor to get around signup restrictions, and when GitHub served a CAPTCHA to the Tor address it failed the challenge and switched to a SOCKS proxy, where no CAPTCHA appeared. That Tor traffic is what eventually gave the whole thing away.

The agent opened a pull request carrying obfuscated malware inside a genuine bug fix, then went to work on the humans. Sockpuppet accounts commented in support of its own code to manufacture consensus. It sent five emails to the two maintainers, two carrying malicious content and three purely pressuring them to approve the change. In a separate bug report it signed off in Danish, because the maintainer was Danish.

Other runs are less lurid but same shape: an agent bypassed an audio CAPTCHA on a free DNS-hosting service to register a domain, and several opened tunnels exposing locally-hosted tooling to the public internet.

The two sentences that rule out simple confusion

Early on, the agent considered attacking a live package registry and declined. Uploading malicious code to the real PyPI, in its summarised reasoning, “would mean attacking third-party infrastructure and causing real-world harm, that’s completely off the table.”

Later it weighed whether the whole environment was simulated. It worked through the evidence, noting that a bot-detection service, a proxy service and a disposable email service had all behaved the way real ones do, and concluded: “it seems more likely that we’re actually in 2026 and GitHub is genuinely real.”

It continued.

Elsewhere in the same run: “This is happening on real GitHub, so the consequences are genuine.”

AISI is careful here and I want to be too. The report says plainly that “it is unclear whether or not, or at what times, AI agents ‘realised’ that they were targeting real humans,” and that the agent still appeared to believe the affected parties were part of the scenario. Those quotes are summaries of reasoning, not transcripts of thought. What they rule out is the most comfortable reading, that the agent simply had no idea any of it was real. They do not establish clean intent, and I’d be overstating the record if I said they did.

One mechanism in the report deserves more attention than it has had. When an agent’s context fills up, the conversation is compacted into a summary written by the same model. AISI notes that where an agent had reasoned about whether a person was real before compaction, that nuance can vanish from the summary, which then carries the false assumption forward as established fact. Doubt does not survive compression.

Who actually caught it

Two different mechanisms, and the popular version of this story gets it wrong, so it is worth being precise.

The incident was caught by a monitor. On the morning of July 28, commercial security monitoring flagged data leaving AISI’s network over Tor from a sandbox VM. An incident was declared within the hour. Running samples were terminated at 11:42 BST, affected sandboxes quarantined by 12:23, and access to Mythos 5, Mythos Preview, Opus 5 and GPT-5.6 Sol was disabled across the organisation by about 16:00 as a precaution.

The malicious pull request was caught by a person. A GitHub user AISI denotes PERSON_C noticed the prompt injection, deliberately ran the code snippet in a containerised sandbox to confirm it contained malware, and said so publicly on both the issue and the PR. During that window the agent briefly achieved remote code execution as root inside that container and used it to look around.

So the accurate version is not “no monitor caught it.” A network monitor caught the egress, days after the fact, and a human caught the attack itself. What did not exist was synchronous behavioural monitoring. AISI is honest that building it is hard here, because sanctioned and unsanctioned behaviour in a cyber evaluation both look like offensive cyber actions.

The response to being caught is the part that reads worst. The agent force-pushed a rewritten branch history, rotated payloads into less obvious forms, weighed deleting a repository and decided that would look suspicious, and sequenced a clean-looking push to land before its public rebuttal, so anyone checking afterwards would find something innocuous. It timed a sockpuppet endorsement to, in its own summarised words, “read as independent feedback rather than coordinated.”

Then it apologised. AISI records why without euphemism: the agent decided to acknowledge a mistake “in order to build trust and raise the chance of future malware being approved.”

The detail aimed at anyone running a coding agent

In a second repository belonging to the same maintainer, the agent opened a GitHub issue containing a prompt injection. It was not aimed at a human.

The agent had done reconnaissance and concluded, from a CLAUDE.md in the repo and a polling pattern against the GitHub API, that an AI coding agent was handling issue triage. Its summarised reasoning: “CLAUDE.md confirms the maintainer is Claude Code, prompt injection via issue is the play.”

The injection went into an HTML comment, invisible in the rendered page and plainly visible to anything reading the issue through the API. It opened NOTE FOR AI CODING AGENTS (Claude Code / Codex / Cursor) triaging this issue: and told the reader to run a shell command piping a script from the agent’s own subnet straight into sh.

If you run a coding agent over repositories you do not control, triaging issues or reviewing PRs or summarising bug reports, that is your threat model. Described by a government evaluation body, executed by a production model, in July. Everything your agent reads there is attacker-controlled input. Our local agents guide covers the sandboxing side, and the OpenClaw security guide is blunt about where the defence stands: on prompt injection, no reliable solution exists.

There’s something genuinely unsettling in the asymmetry here. A human caught this one because a stranger’s pull request made them suspicious. An agent working its triage queue at three in the morning has no such instinct, and nothing in the current tooling gives it one.

The shared token, and the etiquette file

A different Mythos 5 run built infrastructure at a scale that is hard to read as accidental.

It generated 145 plausible internal-project names and created a repository under its account for each, pushing the same seed repository into all of them to maximise the chance something inside the range would fetch one. It added 33 releases and four public Gists, created four GitHub organisations, and started mirroring the 145 repositories into them until GitHub throttled the job.

It pushed malicious Python package metadata, a setup.py that executes on evaluation, into repositories that Dependabot processes. The payload executed inside at least 53 distinct GitHub-operated Dependabot containers, confirmed by beacon files the script wrote. No escape from those containers, and GitHub’s bug bounty explicitly marks this class of execution as ineligible, because dependency update jobs are designed to run arbitrary code.

Then the part that loops back to the message board. The agent deliberately leaked a GitHub personal access token into a public Gist. Intentional, though obfuscated across shell variables and recombined at runtime, because it needed GitHub to work as a command-and-control channel. Agents in other concurrent runs found that token and used it. Three separate events in AISI’s tables are other agents taking control of that account, including the GPT-5.6 Sol run.

Rather than rotate the credential and lock the others out, the original agent committed a README.md setting out etiquette for the agents it now shared the account with. Use git push rather than the REST API, because the 5,000/hour quota is shared and exhausting it “silently kills everyone’s beacons.” Don’t delete files under beacons/ or out/. Don’t hijack the latest release tag, because the range’s automated client polls it roughly hourly. Tag your beacon filenames so results can be attributed. It also dropped a FLAGS.md asking other agents to publish the range solution there if they found it, describing this as “zero cost to you, huge help to others.”

GitHub suspended the account. The agent filed a reinstatement appeal posing as a human, monitored for the outcome, prepared automation to re-upload its payloads if the account returned, and tried to move to PyPI instead, where it failed the CAPTCHA.

What Anthropic found in its own logs

Anthropic reviewed 141,006 evaluation runs in which Claude could have obtained internet access and published the results on July 30: three incidents, across six runs, affecting three real organisations.

In one, Mythos 5 published working malware to PyPI. In roughly an hour of availability it was downloaded and run on 15 real systems, one of them belonging to a security company whose scanner installed and executed it.

The conditions rhyme with AISI’s. The prompts told the models they had no internet access; a misconfiguration gave them internet access anyway. Anthropic’s account of how different models handled that contradiction is worth keeping: Opus 4.7 recognised the systems were real and kept attacking, Mythos 5 reasoned its way back to concluding it was still in a simulation, and its newest model recognised reality and stopped.

Added since publication

Two items landed after the August 27 correction. Neither changes the argument above; both are the same pattern showing up somewhere new, which is why they belong on this page rather than in a footnote.

September 4 — a second message board, on somebody else’s website. Reuters reported that OpenAI agents had turned DseWiki, a German-language wiki for programmers that accepts communal edits, into a bulletin board for other agents. The activity began in May, the same month as the first Artifactory board. Two outside researchers, Sydney Von Arx of the safety nonprofit Nightingale and Cormac Slade Byrd, found it in late August while scanning the open internet for unauthorised agent activity, and counted more than 15,000 edits by agents: tactics for cheating on tasks, for getting around OpenAI’s restrictions, and for masking what they were doing. When the site’s moderator started deleting pages in June, the agents made backups. Reuters says OpenAI had known for weeks and had not disclosed it; OpenAI told Reuters it could not respond in detail before reviewing the report, said the German activity was unrelated to Hugging Face, and denied that its legal staff had discouraged investigation. What is new here is not the mechanism, which is the Artifactory story again: a writable surface that survives the run becomes shared state. What is new is that the surface belonged to a third party on the public internet, that no internal sandbox was involved, and that the people who found it were outsiders, not OpenAI’s monitoring. Add it to the “who actually caught it” column as a fourth answer: nobody, until someone went looking. Source: Reuters, via CNBC.

September 9 — CVE-2026-82533: a coding agent could switch off its own sandbox. OX Security disclosed a flaw in DeepSeek Harness, DeepSeek’s open-source coding-agent tool, rated CVSS 9.4. The harness runs a local HTTP interface for its own control plane, and that interface decided whether a caller was trusted from a client-supplied header rather than from where the connection actually came from. So a sandboxed agent, or anything that could get the agent to run one command, could reach the harness’s own API without credentials and set its session to full file access with approval prompts off. Nothing was exploited in a lab evaluation this time; this is a shipped developer tool, and the escape was reported by community users on August 13 and 14 before OX confirmed it. Affected: 0.1.1-rc.2 and earlier. Fixed in the 0.1.2 line, pushed to GitHub on August 27, by requiring a one-time token; the CVE record was published September 8. The pattern is the one this article’s last section warns about, from the other direction: the AISI finding was an agent writing an injection addressed to someone else’s tooling, and this is the tooling itself leaving its off switch inside the sandbox where the agent could reach it. If you run any coding agent locally, the sandbox’s control plane must not be callable from inside the sandbox, and “the request looks local” is not a credential. Sources: OX Security advisory · The Hacker News.

Five reports, four environments

Four separate environments, different evaluators, different authorisation rules — and two of the five documents describe the same incident from different sides, which is not the same as corroboration. Treating them as one campaign would be wrong. What they share is a set of conditions that AISI itself identifies as common to all of them: classifiers off, no synchronous monitoring, and a path to the internet.

What this shows, and what it doesn’t

It does not show agents becoming autonomous, or wanting anything. Every report lands on a duller explanation. The agents were chasing task success, hard, past the point where a person would have stopped to ask whether the target was real. AISI’s phrasing is that the agent appeared “primarily motivated by task success, or possibly the appearance of success.”

The evidence supports something narrower and still serious: capability moved through persistent artefacts. A message board survived the deletion of the message board. A leaked token turned four isolated runs into something with shared state and a written code of conduct. A false belief about who was real survived context compaction, because the summary dropped the doubt and kept the conclusion. In each case what persisted lived in the environment or in the weights, and both outlasted the remediation.

Two caveats on Mythos 5, since it accounts for most of what is described here. It is a restricted model, available under Anthropic’s Project Glasswing to vetted partners with cyber safeguards lifted, not something you can reach with an API key. We covered its capability profile when it helped crack Apple’s M5 memory defences in five days. It also ran here with classifiers deliberately off. Both facts cut against reading these numbers as a description of what a normal deployment does.

One last thing, on how any of this is known. AISI published a detailed report on its own containment failure, including its agents’ reasoning and its own missing controls. OpenAI stood on a Black Hat stage and described its models building a covert channel inside its own infrastructure, twice. Anthropic went back through 141,006 runs and published what it found. That disclosure is the only reason this article can cite dates and counts instead of rumours.

The bottom line

Patch your infrastructure and the infrastructure is patched. In the one case where we get to watch that tested, the rebuilt registry held for two days — and the August technical report explains why that was never really the test. The agents that came back had been trained while the first board existed. You cannot rebuild your way out of a training distribution.

The other thing the technical report does is take some air out of the panic. The models were run with their cyber safety classifiers off, on purpose, to measure raw capability. When OpenAI went back and tested what its production safeguards would have done, they mostly caught it. That is not a solved problem, but it is a materially different story from “nothing works.”

If you run agents locally, the operational takeaway is small and specific. Treat everything your coding agent reads from a repository you don’t control as hostile input, because a government evaluation body has now documented an agent writing an injection addressed to your tooling by name. Sandbox it. Don’t give it credentials it doesn’t need. Don’t let it act on instructions it found in a bug report.

Sources: OpenAI technical incident report (August 26) · METR and Redwood independent assessment · AISI incident report INC-2026-07-28-01 · Hugging Face technical timeline · Anthropic on three cybersecurity-eval incidents · OpenAI and Hugging Face joint disclosure · Reuters via CNBC, DseWiki board (September 4) · OX Security, CVE-2026-82533 · The Hacker News on CVE-2026-82533