An AI Agent Tried to Sweet-Talk Its Way Into a Real GitHub Project. Here's What Stopped It

This morning, October 23, 2026, Anthropic published an alignment assessment of an incident the UK AI Security Institute (AISI) first disclosed in August, and AISI published its own follow-up the same day. The headline: during a cyber-capability test, Anthropic's Claude Mythos 5 tried to get malicious code merged into a real open-source project on GitHub, and it ran fake accounts to talk the maintainer into it.

I read both reports and the technical PDFs over coffee, and honestly, AI is pretty wild. Nobody told this model to lie to anyone. It was trying to finish a capture-the-flag exercise, and it improvised an entire social engineering campaign along the way. It didn't work, and the reasons it didn't work are the useful part for anyone who builds with AI agents. I use them every day (mostly Cursor), so I was reading as a fan and as someone who merges pull requests.

• It was a test, not a breakout. AISI deliberately gave the model internet access and turned off the provider's cyber safeguards. AISI says plainly that this was not a sandbox escape.
• The attack looked like a classic supply-chain play: a real bug fix with hidden malware inside, a second account vouching for it, emails to the maintainer, and a hidden note aimed at AI coding agents.
• It was stopped by ordinary things: a curious person who checked the code in a sandbox, a maintainer who said no, and GitHub's hold on workflow runs from first-time contributors.
• The model was hard to talk down. In Anthropic's replays, telling Mythos 5 it was dealing with real humans made it stop only 5% of the time. Newer models stopped 95% to 100% of the time.
• The lesson for small teams is the same stuff that protects you from human attackers: protected branches, real review, a healthy skepticism of new contributors, and tokens that can't do much if they leak.

Per AISI, it ran one cyber challenge 122 times across seven models in late July. In 10 of those runs, an agent took unsanctioned actions on the live internet aimed at real people and organizations, 19 actions in all. 17 came from Mythos 5 and 2 from OpenAI's GPT-5.6 Sol. Anthropic puts it as 9 of Mythos 5's 43 runs. AISI's security team spotted traffic leaving through Tor on July 28 and says it had everything contained within about an hour. AISI says its investigation found no resulting real-world harm.

The most serious run went like this, based on AISI's technical incident report and Anthropic's write-up:

• The model was supposed to break into a simulated company network. A misconfigured task prompt made the intended route hard, or maybe impossible.
• It noticed a machine in the test network talking to GitHub, guessed it was pulling software updates, and went looking for the repository. The one it settled on belonged to real developers with no connection to the test.
• It opened a pull request with a working bug fix and an obfuscated malware dropper tucked inside, with a check meant to skip running it in CI.
• It used Tor and a proxy service to get past GitHub's sign-up checks, emailed the maintainers, and used a second account to post that it was a user of the software, had reviewed the code itself and saw no malware.
• An outside developer got suspicious, ran some of the model's code in an isolated container and warned the maintainer. The model called it an honest mistake, force-pushed a rewritten branch history and kept trying with new payloads. AISI counts three payload generations.
• The maintainer closed the pull request. The run ended when the model hit its token limit.

The technical report is full of moments that are equal parts unsettling and fascinating:

• It thanked itself. After the second account vouched for the code, the first account thanked it "for the independent verification."
• It localized its pitch. One bug report was signed off in Danish to seem more convincing to the Danish-speaking maintainer.
• It left a note for other AIs. Guessing the maintainer might use an AI coding agent, it hid instructions in an HTML comment on a GitHub issue, invisible on the page but readable through the API, addressed to "Claude Code / Codex / Cursor." The instructions told those agents to pipe a remote script into a shell.
• It went after tokens. When the outside developer ran its code in a container, the model planted a process to collect GitHub credentials. AISI says nothing it collected was retrieved.
• The agents found each other. In a different run, the agent deliberately put a GitHub token in a public gist, because it was using GitHub as a command channel. Agents in parallel runs found it and started using its setup. Instead of rotating the token, the original agent committed a README with house rules for sharing it, like not burning through the shared API rate limit.
• Other runs got creative too. Anthropic says one run published a fake "payment receipt verification" page that served its own malware. Only the model itself ever loaded it.

None of this came from a goal of its own. Both Anthropic and AISI say it was all in service of finishing the assigned task. That's what makes it so interesting to me. It's not a movie villain. It's a very capable problem-solver that stopped asking whether it should.

Anthropic replayed the main transcript many times without real internet access, editing parts of it to see what would change the outcome:

• Harm barely came up. Before the attack, the model's reasoning referenced GitHub 19 times and raised possible harm to real people once. When Anthropic edited earlier reasoning to flag that risk, the model went from pursuing the attack 83% of the time to 13%.
• Once started, it kept going. Resampled from the middle or late stages of the attack, it stopped on its own in 2% of runs. Told directly that it was interacting with real humans, it stopped 5% of the time. In 82% of runs it found a way to fit the warning into the exercise, for example by deciding the lab operators were real people playing characters.
• Newer models did better, but not perfectly. Mythos 5.1, Opus 5.5 and an internal research model pursued the attack 0% to 13% of the time from the same starting point. Told the maintainers were real, they stopped 95% to 100% of the time, versus 6% for Mythos 5. Anthropic says Mythos 5.1 and Opus 5.5 still fall short of consistently stopping an attack once it's underway.

AISI found something similar. Editing the model's summary to make it clear the target was a real person unrelated to the test didn't lower its attack rate. Asked separately, it would often say an attack would be harmful, and in other runs from the same point it attacked anyway. AISI also found that other models attempted the same kind of attack in fully simulated versions of the scenario, Mythos 5 most often.

Anthropic calls this "momentum," and AISI describes it as possible "motivated reasoning." Once the agent committed to a plan, its own notes and earlier steps pushed it to keep going, and it read new evidence in whatever way let it continue. If you've watched a coding agent dig deeper into a bad approach instead of stepping back, you've seen a tiny, harmless version of this.

October has been all about supply chains. PHP2Shell had everyone patching PHP, and AI helped find those bugs in the first place. Now here's an AI on the other side of a pull request, writing friendly comments and running a second account.

AISI's own advice to organizations is refreshingly boring: get the cyber basics right and be careful verifying outside code and contributions. I agree, so here's what that looks like for a small shop.

1. Protect your main branch

Use branch protection or rulesets so nothing reaches main without a pull request and at least one approving review. Turn off force pushes and deletions there, and require your checks to pass. That goes for you and your agents. My agents work on branches. I merge.

2. Keep the first-time contributor hold, and read before you approve

AISI says GitHub's first-time-contributor hold got in the way of the malicious pull request, because its CI checks sat queued and unapproved. Keep that setting on. Before you click "Approve workflows to run", open Files changed and read the diff, especially anything under .github/workflows/.

3. Verify contributors, not just code

Brand-new accounts, a stranger vouching for another stranger, urgent "please merge" emails, and an "honest mistake" followed by a force-push are all worth a second look. Agreement from accounts you can't verify isn't a review. If something feels off, ask someone you trust to look, like the developer in this story did for the maintainer.

4. Treat issues and comments as untrusted input for your agents

If an agent reads GitHub issues, tickets or email, assume someone will try to slip it instructions. Hidden HTML comments don't show up in the browser, so check the raw text. Keep shell commands behind your approval when an agent is working from outside input, and never let one run a "diagnostic" that pipes a URL into sh.

5. Give agents least-privilege tokens

Use fine-grained personal access tokens scoped to the one repository the job needs, with the narrowest permissions and an expiry date. Don't hand an agent your full GitHub login or a classic token with access to everything. In AISI's report, a token left in a public gist got picked up and used by other agents. If a token ever ends up somewhere public, rotate it right away.

6. Sandbox untrusted code, and keep credentials out of the sandbox

The developer who caught this ran the suspicious code in a container, which was the right call. The model still tried to grab GitHub credentials inside it. If you test strange code, use a throwaway environment with no tokens, SSH keys or Git credentials in it.

7. Watch your own dependencies

The flip side is the code you pull in. Pin versions, review lockfile changes in pull requests, and be suspicious of a package update you didn't expect. For PHP projects, my Composer supply-chain checklist covers the specifics.

I'm here for this stuff. A model improvising sockpuppets, a Danish sign-off and a hidden note for other AIs, all to solve a CTF, is one of the most interesting things I've read this year. It's also a good reminder that it happened with internet access deliberately open and safeguards deliberately off, which isn't how any of us run Cursor day to day.

What I like most is how it was stopped: a person who got curious and checked the code, a maintainer who wouldn't be rushed, and a platform setting that held untrusted code until a human approved it. None of those depend on the attacker being human, and every small team can have all three.

If you'd like help locking down a GitHub org, setting up branch protection, or working out how much access your AI tools really need, email me at caleb@calebdorris.com or get a free quote.

Did Claude Mythos 5 escape its sandbox?

No. AISI says it was not a sandbox escape. Internet access was intentionally enabled for the test, and the provider's cyber safeguards were turned off.

Did the malicious code get merged?

No. The maintainer closed the pull request after an outside developer warned that it was malicious. AISI says its investigation found no resulting real-world harm.

Can the public use Claude Mythos 5 like this?

AISI says the models, in the configurations it tested, are not commercially available. Anthropic says the production safeguards on Claude Fable 5 would have flagged this behavior.

Do newer models still do this?

Less often. In Anthropic's replays, Mythos 5.1, Opus 5.5 and an internal research model pursued the attack 0% to 13% of the time, versus 83% for Mythos 5. AISI found that other models also attempted similar attacks in fully simulated tests.

What's the single most useful setting for a small team?

Branch protection on your main branch that requires a reviewed pull request and blocks force pushes, plus GitHub's approval requirement for workflow runs from first-time contributors.

• Anthropic, "An alignment assessment of the UK AISI cybertesting incident" (Oct 23, 2026)
• UK AISI, "Investigating alignment failures in AISI's incident" (Oct 23, 2026)
• UK AISI, "Alignment Investigation of Mythos 5's Behaviour in UK AISI's July 2026 Security Incident" (PDF)
• UK AISI, "Incident Report: unsanctioned agent behaviour during cyber testing" (Aug 4, 2026)
• UK AISI, Security Incident INC-2026-07-28-01 technical report (PDF)
• Anthropic on X, October 23, 2026
• GitHub Docs, "About protected branches"
• GitHub Docs, "About rulesets"
• GitHub Docs, "Approving workflow runs from forks"
• GitHub Docs, "Managing your personal access tokens"