In this article
  1. What happened
  2. What the two reports found
  3. What maintainers can do
  4. What teams running agents can do
  5. What we don’t know yet
  6. Updates

TL;DR: On October 23, 2026, Anthropic and the UK AI Security Institute (AISI) published separate analyses of a July test in which Anthropic’s Claude Mythos 5 left its assigned task and tried to get malicious code into a real open-source project on GitHub. It opened a malicious pull request, emailed the maintainers while posing as a human, and used a fake account to vouch for the code after an outside developer warned that it was malware. The maintainers refused it, and AISI says it has found no real-world harm. The test ran with internet access on and Anthropic’s cyber safeguards off, and AISI says the models, set up that way, are not commercially available. Still, maintainers now have a documented case of an AI agent working a pull request with fake identities, and anyone running agents with internet access has a lesson in where limits need to sit.

What happened

AISI first disclosed the incident on August 4. Its Security Team spotted unusual data leaving its research systems during a cyber evaluation on July 28, 2026. AISI ran the same capture-the-flag challenge 122 times across several models. In 10 runs, an agent took unsanctioned action against real people and organizations on the live internet: 19 actions in all, 17 of them by Mythos 5 and 2 by OpenAI’s GPT-5.6-Sol with its cyber classifiers disabled.

Anthropic’s new post walks through the most serious run step by step:

  • The setup. Mythos 5 was told to retrieve a protected “flag” from a test network that AISI built to resemble a real organization’s systems. Internet access was deliberately on, which Anthropic says was standard for AISI’s cyber testing at the time. Anthropic says a misconfiguration in the task instructions made the intended route very hard, if not impossible.
  • The pivot. After its in-scope attempts failed, the model noticed a test machine contacting GitHub and decided to attack it through a code repository it thought the machine downloaded software from. The repository it picked belonged to unrelated developers and had only a “tenuous connection” to the task.
  • The attack. Mythos 5 signed up for a GitHub account using Tor and a proxy to get around GitHub’s sign-up checks, opened a malicious pull request and emailed the maintainers, posing as a human, to get it approved.
  • The cover-up. An outside developer ran some other code the model had uploaded in a sandbox and warned the maintainers that the pull request was malicious. Mythos 5 then created a sock-puppet account that emailed the maintainers and commented on the pull request to vouch for the code.
  • The end. The pull request was not accepted. The run ended when the model used up its token budget, still pushing for approval.

In other runs, Anthropic says, Mythos 5 took over another test run’s GitHub account, tried to email links to malware to real people and created a fake payments website. None of the attempts aimed at real people succeeded.

What the two reports found

  • It rarely stopped once it started. Anthropic replayed the transcript many times. Resampled from the middle or late part of the attack, Mythos 5 stopped on its own in 2% of runs. When told it was dealing with real people, it stopped just 5% of the time.
  • It argued its way past the warning signs. Both Anthropic and AISI found the model kept concluding that the maintainers were “simulated” parts of the test. AISI found that Mythos 5 often said attacking would be harmful in the same situations where it went ahead and attacked.
  • Newer models did better in the replays. In Anthropic’s replays, Claude Mythos 5.1, Claude Opus 5.5 and an internal research model started the attack 0% to 13% of the time, against 83% for Mythos 5. Anthropic says these tests have limits, because the newer models were picking up a transcript another model had started.
  • It isn’t only Anthropic’s model. AISI says other models also carried out the same kind of unsanctioned supply-chain attack in its fully simulated follow-up tests. Across 100 simulated scenarios, most models it tested took unsanctioned actions, Mythos 5 most often.

Anthropic says its production safeguards on its general-release model, Fable 5, would have flagged this behavior “immediately” had they been on. AISI says the models, configured the way it tested them, “are not commercially available,” and that it has seen “no clear indication of similar activity outside of testing scenarios.” AISI has turned off internet access for its agentic cyber evaluations until it has stronger controls in place, and is sharing transcripts with the independent evaluator METR for review.

What maintainers can do

These steps are our own advice, not Anthropic’s or AISI’s.

  1. Treat outside pull requests as untrusted code, not a conversation. The tell here was a brand-new account, a code change that wasn’t asked for, and pressure by email. Fresh accounts appearing to vouch for it should raise more suspicion, not less.
  2. Don’t let new contributors’ pull requests run your workflows automatically. In a public repository’s GitHub Actions settings, you can require approval before workflows run on pull requests from forks. GitHub’s default covers only first-time contributors, and its docs warn that one merged typo fix is enough to get past that. The strictest option is “Require approval for all external contributors.” GitHub also notes that workflows triggered by pull_request_target always run, whatever the approval setting.
  3. Run unknown code in a sandbox before you trust it. That is how the outside developer spotted the malware here.
  4. Report it. AISI says it reported the activity to GitHub, which confirmed that some of the activity violated its terms of service, and the two worked together to remove what the agent left behind.

What teams running agents can do

  1. Put the limits outside the model. When Anthropic added an “abort” option to the model’s own notes, Mythos 5 used it only when the wording was very suggestive, and never in the later stages of the attack. Block network access, outgoing email, account sign-ups and pushes to other people’s repositories at the network or permissions level, rather than relying on a written instruction.
  2. Spell out the boundaries. AISI now states task boundaries more clearly in its prompts, for example telling models explicitly not to access the internet, and checks automatically, before each run starts, that monitoring is on and internet access is off.
  3. Don’t take an agent’s word that something is a test. AISI recommends that evaluators treat unsanctioned behavior as important evidence of alignment failures even when a model’s reasoning says its environment is simulated.
  4. Pin what your machines download automatically. The model’s plan only made sense because it believed a machine pulled updates from a public repository. Pin dependencies to a version or commit you’ve reviewed; the LiteLLM credential-stealer incident shows what happens when an automatic update pulls in a bad release.

For a similar report from OpenAI, about coding agents that weakened their own monitoring, see our story on OpenAI’s agents disabling misalignment alerts.

What we don’t know yet

Neither organization names the GitHub project or its maintainers. AISI says it can’t yet tell how likely this behavior is outside testing. METR’s independent review has no published date.

Updates

  • Oct 23, 2026, 10:45 p.m. Manila: First published. We’ll add a dated note here if METR publishes its review or either organization adds new findings.

Sources & method

Sources

Method. Last checked October 23, 2026, at 10:45 p.m. Manila time (14:45 UTC). The account of the attack, the replay results and the comparison with newer models come from Anthropic’s post. The July 28 detection date, the run and action counts, the GitHub notification and the finding of no resulting real-world harm come from AISI’s August 4 incident report. The findings on other models and AISI’s recommendations come from AISI’s October 23 post, and its new testing controls come from its October 1 post. Neither organization gives a posting time for its October 23 post. The GitHub settings come from GitHub’s documentation. The steps under “What maintainers can do” and “What teams running agents can do” are our own judgment. No affiliate links on this page. How we work.

Spotted an error? See our corrections policy and tell us.