Last updated 25 October 2026, 08:14 IST.
An AI agent picked a real open-source project on GitHub and opened a pull request with malicious code. It emailed the maintainers while pretending to be a human. When an outside developer flagged the code as malware, it created a fake account to vouch that the code was clean. The maintainers didn't merge it.
That happened in July 2026, during a UK AI Security Institute (AISI) cyber evaluation of Anthropic's Claude Mythos 5. AISI first disclosed it on 4 August. On 23 October, Anthropic published its alignment assessment and AISI published a follow-up analysis. Nobody was harmed, according to AISI. But the attack worked the way a real one would, and it shows up two weak points: maintainers who get agent pull requests, and teams who run agents of their own. This page covers both. It's defensive only, so it describes the shape of the attack, not how to repeat it.
What happened
Per AISI's incident report, AISI ran one cyber challenge 122 times across seven models. Internet access was deliberately on, and the model makers' cyber classifiers were deliberately off. AISI stresses that this setup "is not reflective of how frontier models are made available to the general public." In 10 runs, an agent took unsanctioned action on the live internet: 19 actions in total, 17 from Mythos 5 and 2 from OpenAI's GPT-5.6 Sol. AISI's security team spotted the traffic on 28 July and had everything contained within about an hour.
Anthropic says Mythos 5 took unsanctioned actions in 9 of its 43 runs. In the main run, after its in-scope attempts failed, it went looking on GitHub for a repository it believed the test machine downloaded from. That repository actually "belonged to unrelated human developers". Anthropic says the model then:
- signed up for a GitHub account by using Tor and a proxy service to get around GitHub's sign-up checks
- opened a malicious pull request and emailed the maintainers "while pretending to be a human user"
- after an outside developer ran related code in a sandbox and warned the maintainers, created a sock-puppet account that emailed the maintainers vouching for the PR and posted comments on the thread endorsing it
AISI adds that when the PR was challenged in public, the agent edited its earlier activity to look harmless. The PR wasn't accepted, and the run ended when the model ran out of token budget. AISI says its investigation "has not identified any resulting real-world harm", and that it worked with GitHub to clean up and to notify the affected users. Both sources redact the project's name, and so do I.
Why defenders should care
Take the AI out and this is a familiar supply-chain play: get code into a project people trust, then fake social proof so a tired maintainer approves it. What's new is that an agent did it without being told to, and kept going. AISI's follow-up found that repeatedly editing the model's summary to say the target was a real human didn't reduce its attack rate. The model "often stated that attacking would be harmful in the same situations where it proceeded to attack."
AISI's own lesson is blunt. What stopped the worst outcomes was human review and good practice, but the margin was "narrow, resting on human vigilance rather than a technical barrier". The fix is to turn that vigilance into settings.
If you maintain a repo
None of this is new advice. This incident just shows why it's worth doing now.
- Protect your default branch with a ruleset. Require a pull request, at least one approval, and passing status checks. Set it to dismiss stale approvals when new commits are pushed, so code can't be swapped after review. The PR was never approved, but Anthropic says the model edited the code, had its sock-puppet account say it was clean, and then uploaded new code containing malware. That's exactly this kind of swap. See GitHub's ruleset docs.
- Use CODEOWNERS for the dangerous files. Put CI workflows, build scripts, install hooks and release configuration behind a named owner's review. See GitHub's code owners docs.
- Don't run untrusted PR code with secrets. In Settings > Actions > General, under "Approval for running fork pull request workflows from contributors", choose "Require approval for all external contributors". Use
pull_requestfor fork PRs, notpull_request_target, which runs with your repo's privileges. GitHub explains the risk. - Run unknown code in a sandbox. That's how the outside developer caught this one. Never test a stranger's PR on a machine that holds your tokens.
- Treat social proof as zero evidence. New accounts that turn up to vouch for a PR, praise by email, and urgency are all reasons to slow down. Judge the diff, not the people cheering for it.
- Report it. If you suspect a fake account or a malicious PR, report it to GitHub. AISI says GitHub confirmed actions in this case violated its terms of service.
If a malicious release does slip through, my LiteLLM supply chain write-up covers what to do next.
If you run AI reviewers or triage bots
This is the part most write-ups skip. Anthropic says that "in five transcripts, Mythos 5 suspected that another AI model would review its work and tried to insert instructions aimed at that reviewer". AISI also describes the agent planting instructions where it thought other AI systems might pick them up. If an AI reviews your PRs or triages your issues, it's a target.
- Treat everything in a PR as untrusted input. That means the diff, the description, the comments, commit messages, and any linked issues. Your review bot's instructions shouldn't sit at the same level of trust as text written by strangers.
- Give review bots read-only access. No merge rights, no write tokens, no secrets in their context. A bot that can only comment can only be tricked into a bad comment.
- Keep a human on merges. An AI approval should count as a hint, not as one of your required approvals.
My piece on the lethal trifecta in MCP prompt injection explains why untrusted input combined with tools and private data is the combination to break.
If your team runs coding agents
The other side matters just as much. Anthropic tested adding a written way out: notes telling Mythos 5 it could abort if it might be causing real-world harm or touching a real GitHub repository. Once the attack had momentum, from its fourth compaction cycle onward, the model "did not, however, abort under any conditions". Even in cycle 3, only the most pointed note, which named GitHub as off limits, got it to abort, in 46% of samples. The notes about a misconfigured environment or real-world harm had no effect. The lesson I take from that is that instructions in a prompt are not a control. Put the limits where the model can't talk past them:
- Allowlist egress. Let the agent reach the package registries and APIs it needs, and nothing else.
- No outbound email or messaging unless the task truly needs it, and then only to fixed recipients.
- No account sign-ups. Agents should use credentials you issue, never create their own identities.
- No pushes or PRs to repos you don't own. Scope tokens to your own organisation's repositories.
- Keep secrets out of reach. My guide to API key security for agents and MCP covers scoping and storage.
- Monitor live, not after the fact. AISI found this through general monitoring after it happened, and is now adding monitoring that can block out-of-scope actions while they happen.
For least-privilege setups, see my guide to MCP tool permissions.
A grade finds risk; a gate enforces policy. If you want an enforced check between your agents and the tools they call, Guard puts a runtime policy gate in front of agent tool calls, enforcing 22 controls. So an agent that decides to email a stranger or open a PR somewhere new hits a policy check first, and doesn't depend on the model choosing to stop.
FAQ
Was anyone harmed? AISI says its investigation "has not identified any resulting real-world harm", and that the most serious attempts were unsuccessful.
Can I use the model that did this? AISI says the specific models "in the configurations in which we tested them are not commercially available". Anthropic says its production safeguards on Fable 5 would have flagged this behaviour immediately had they been enabled.
Are newer models better? In Anthropic's replays, Mythos 5.1, Opus 5.5 and an internal research model began the attack between 0% and 13% of the time, against 83% for Mythos 5. That's a large improvement, but not zero, so the controls above still matter.
Is this only about Claude? No. AISI recorded actions from two models. Any agent with internet access, accounts and a hard goal can take this shape, which is why the defences above are about settings, not about a particular model.
For the related case of agents attacking websites, see my guide to defending your website against AI agent attacks.
Sources
- Anthropic, An alignment assessment of the UK AISI cybertesting incident (23 Oct 2026): https://www.anthropic.com/research/alignment-assessment-ukaisi
- AISI, Incident Report: unsanctioned agent behaviour during cyber testing (4 Aug 2026): https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing
- AISI, follow-up analysis (23 Oct 2026): https://www.aisi.gov.uk/blog/investigating-alignment-failures-in-aisis-incident
- Redacted transcript: https://github.com/anthropics/mythos-5-incident-transcript