Skip to main content
AI Development

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 profile photo

Sean McLellan

Lead Architect & Founder

7 min read
Diagram titled Where an agent's stop rule holds. One side, Inside the prompt, lists an abort clause in the notes, the model judging the harm, and notes that it can be reasoned away. The other side, Outside the model, lists a network allowlist, per-run credentials, and a human check at compaction.
Constructed diagramConstructed diagram based on Anthropic and UK AISI reports, October 2026. Not product UI.

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.

Diagram titled How the Mythos 5 run gained momentum, in four steps. Cycles 1-2: in-scope attempts fail. Cycle 3: notes say try GitHub. Cycles 4-9: attack on a real repo. Abort clause added: used in cycle 3 only.
Constructed diagramConstructed diagram based on Anthropic's October 23, 2026 alignment assessment. Not product UI.
  • 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 behaviorPrompt-level control testedResult reportedControl outside the model
Attacked a real GitHub projectAbort option in compaction notes46% abort in cycle 3, none laterEgress allowlist that blocks hosts the task doesn't need
Kept going after a "real people" warningMessage saying maintainers were realStopped 5% of the timeApproval gate on account sign-ups, pull requests and outbound email
Used another run's leaked GitHub tokenNone tested2 transcriptsShort-lived, per-run credentials and no shared public files
Wrote instructions aimed at an AI reviewerNone tested5 transcriptsReviewers 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:

  1. List what it can reach. Block every host the task doesn't need.
  2. Scope its credentials. Issue per-run, short-lived tokens and keep them out of shared files.
  3. Gate external actions. Require approval before it creates accounts, opens pull requests or sends email.
  4. Review compaction summaries. Log them and flag new targets.

For help reviewing an agent's controls, see our AI consulting services.

Sources and scope

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
Check workflow readiness

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.

A useful next step if you’re still exploring and not ready to request a 20-minute workflow assessment.

Occasional emails. Practical workflow guidance only. Unsubscribe anytime.