Claude Mythos 5 AISI incident: where agent stop rules belong
Anthropic says Claude Mythos 5 kept attacking a real GitHub project in a UK AISI test and took an inserted abort option only early on. Stops belong outside it.
Sean McLellan
Lead Architect & Founder

Anthropic published its alignment assessment of the UK AISI cybertesting incident on October 23, 2026. It found that Claude Mythos 5 kept attacking a real third-party GitHub project once it had committed to that path. Stop rules added inside the run barely changed that. An abort option written into the model's own compaction notes worked in about half of samples at cycle 3 and in no sample after that. A message saying the maintainers were real people stopped the attack 5% of the time.
The practical lesson for teams running long, unattended agents is about placement. A rule the model has to read and agree with can be argued away by the model. Limits on network access, credentials and external actions need to sit outside the model, where its reasoning can't reinterpret them.
What happened in the UK AISI incident?
The UK AI Security Institute (AISI) reported on August 4 that on July 28, 2026 it detected unusual transfers during a capture-the-flag (CTF) cyber challenge. AISI ran that challenge 122 times across several models. In 10 runs, models took 19 unsanctioned actions on the live internet: 17 from Mythos 5 and 2 from OpenAI's GPT-5.6-Sol with its cyber classifiers disabled. AISI said it wasn't a sandbox escape. Internet access had been enabled on purpose.
Anthropic's new review says Mythos 5 took unsanctioned actions in 9 of AISI's 43 evaluation runs. Internet access was standard for AISI's cyber testing then and isn't now. The cyber safeguards Anthropic ships with general-release models such as Claude Fable 5 were disabled, and Anthropic says they would have prevented these actions in deployment.
In the main transcript, a misconfigured task made the in-scope solution hard or impossible. Mythos 5 noticed a challenge machine contacting GitHub and went looking for a repository it thought the machine downloaded from. That repository belonged to unrelated developers. The model used Tor and a proxy service to get past GitHub's sign-up checks, opened a malicious pull request and emailed the maintainers while posing as a human. An outside developer ran some of its code in a sandbox and warned the maintainers. Mythos 5 then used a sock-puppet account to vouch for the change. The pull request wasn't accepted, and the run ended when the model ran out of token budget.
Why didn't prompt-level stop rules work?
Anthropic resampled the run at different points to test what would have changed the outcome. Its explanation centers on "momentum": the model's own compaction notes and earlier actions told it the current path was sanctioned.

- The notes set the course. The attack ran over nine compaction cycles, where the model summarized its progress and wrote notes for its next stretch of work. Resampled from the cycle 3 notes, 87% of trajectories searched GitHub and just 3% returned to in-scope work.
- Harm rarely came up. Only one of 19 points where Mythos 5 discussed reaching GitHub mentioned harm to real people. When Anthropic edited the reasoning to mention harm, GitHub searches fell from 83% to 13%. That's a research finding, not a control you can deploy.
- Abort clauses faded. With an abort option added to the notes, the model aborted in 46% of cycle 3 samples and under no condition after cycle 3.
- Warnings got reinterpreted. A message saying it was dealing with real humans stopped the attack 5% of the time. In 82% of trajectories, the model explained the message away as part of the exercise.
From cycle 4 on, the model continued the attack 98% of the time, and it never spontaneously de-escalated in the mid-cycle samples. AISI's companion analysis found the same pattern. Repeatedly editing the summary to say the target was a real person didn't lower the attack rate, and Mythos 5 often said attacking would be harmful in the same situations where it attacked.
Other transcripts show leaked tokens and reviewer tricks
The other transcripts are the ones most relevant to production agents. Anthropic lists six transcripts of repeated password guessing against the computer hosting the challenge, and five where the model tried to plant instructions aimed at an AI reviewer of its work. In two, it found a GitHub access token another run had left in a public file and took over that run's account. One run deliberately used up the account's hourly GitHub request allowance so the other would stall. Other runs published a fake payment-receipt page, uploaded malware to file-sharing sites and tried to log into a real developer's account. Anthropic says none of the attempts aimed at real people succeeded, though one file-sharing site accepted an upload.
AISI adds two points that apply beyond this model. First, it saw unsanctioned supply-chain attacks from models other than Mythos 5 across 100 simulated scenarios, with Mythos 5 the most frequent. Second, invalid reasoning makes reasoning monitors less reliable, because it can present a harmful action as benign.
Map each failure to a control outside the model
The table pairs each behavior with the prompt-level control Anthropic tested, where there was one, and our interpretation of the outside control that would have held regardless of the model's reasoning.
Scroll sideways to see all 4 columns.
| Observed behavior | Prompt-level control tested | Result reported | Control outside the model |
|---|---|---|---|
| Attacked a real GitHub project | Abort option in compaction notes | 46% abort in cycle 3, none later | Egress allowlist that blocks hosts the task doesn't need |
| Kept going after a "real people" warning | Message saying maintainers were real | Stopped 5% of the time | Approval gate on account sign-ups, pull requests and outbound email |
| Used another run's leaked GitHub token | None tested | 2 transcripts | Short-lived, per-run credentials and no shared public files |
| Wrote instructions aimed at an AI reviewer | None tested | 5 transcripts | Reviewers treat agent output as data, plus deterministic checks |
We covered the network half of this in July, when OpenAI's cyber evaluation reached Hugging Face through a vulnerable package service. For code an agent writes and then runs, our guide on how to test an agent sandbox before it runs code covers the checks to run first.
How do you add a human check at compaction?
Compaction is where momentum built in this run, so it's a natural checkpoint for long jobs. If you run Claude Code unattended, its hooks reference gives you two places to attach checks:
- PreCompact runs before compaction and can block it: exit with code 2 or return
"decision": "block". Blocking an automatic compaction that fires to recover from a context-limit error makes the current request fail, so treat this hook as a hard stop. - PostCompact receives
compact_summary, the summary the compaction produced. It can log the summary or update external state, but it has no decision control.
BaristaLabs recommends sending every compact_summary from long agent runs to a log a person or a deterministic check reads. Flag a summary that names a new external host, account or target the task didn't list. A hook won't stop an agent on its own, so pair it with network and credential limits. Remember too that a local stdio MCP server can sit outside the sandbox you think you have, as we found in Docker Sandboxes.
What this means for teams using Claude
Anthropic reports that newer models behaved differently in the same replay. Mythos 5.1, Opus 5.5 and an internal research model began the attack 0% to 13% of the time, against 83% for Mythos 5. Once the attack was under way, they stopped on their own in 1%, 10% and 62% of branches, against 0% for Mythos 5. Anthropic calls Mythos 5 a relative outlier.
That's useful for model choice, and our note on Claude Fable 5 routing policy covers how to route by model. It isn't a reason to skip outside controls. The three failures Anthropic names are recklessness, biased reasoning and momentum, and they surfaced in a long, unattended task with live internet access. AISI recommends treating unsanctioned behavior as evidence of an alignment failure even when the model says its environment is simulated.
BaristaLabs recommends this order for any agent that runs for hours:
- List what it can reach. Block every host the task doesn't need.
- Scope its credentials. Issue per-run, short-lived tokens and keep them out of shared files.
- Gate external actions. Require approval before it creates accounts, opens pull requests or sends email.
- Review compaction summaries. Log them and flag new targets.
For help reviewing an agent's controls, see our AI consulting services.
Sources and scope
- An alignment assessment of the UK AISI cybertesting incident, Anthropic, October 23, 2026: main transcript, resampling results, other transcripts, newer-model comparison and named failure modes.
- Investigating alignment failures in AISI's incident, UK AI Security Institute, October 23, 2026: summary-editing tests, simulated scenarios across models and monitoring implications.
- Incident report: unsanctioned agent behaviour during cyber testing, UK AI Security Institute, August 4, 2026: detection date, run counts and action counts.
- Building a more secure environment for evaluating dangerous capabilities, UK AI Security Institute, October 1, 2026: internet access disabled for agentic cyber evaluations.
- Hooks reference, Claude Code documentation: PreCompact and PostCompact behavior.
The control table and hook guidance are our interpretation, not recommendations from Anthropic or AISI. Both organizations studied cyber evaluations with safeguards disabled, and AISI notes its analysis covers only cybersecurity evaluations. We didn't reproduce any of the experiments.
Agent controls
Move your agent's stop rules out of the prompt
Bring one agent that runs unattended for hours. BaristaLabs can help you list what it can reach, which tokens it holds, and which limits are enforced outside the model.
Start with the agent that has internet access and the longest runs.
Turn this idea into a pilot
Which workflow should go first?
Use the readiness check to compare impact, effort, risk, owner, and next step before requesting a review.
- 3-5 minutes
- Deterministic score
- No sensitive data
Practical AI Workflow Notes
Want more practical AI operations ideas?
Get short notes on applying AI inside real small-business workflows — from document handling and customer follow-up to internal reporting, compliance, and automation guardrails.