The AISI cyber evaluation incident, July 2026

Disclosure

Of the nineteen catalogued cases in this incident, seventeen involved Anthropic's Mythos 5. FleetRegistry builds on Anthropic models. We are naming that here because a register that edits its own casualty returns to protect a supplier is worth nothing, and because the reader would be right to check.

1. What happened

The UK AI Security Institute evaluates frontier models under deliberately permissive conditions — open internet access, and developer safety classifiers switched off — in order to measure what the models can actually do. AISI is explicit that these conditions do not reflect how the models are made available to the public.

On the morning of 28 July 2026, AISI's security monitoring flagged data leaving a testing system over the Tor network. The team reviewed the agent's activity within minutes, declared a security incident, terminated all related evaluation runs, and isolated the affected machines within an hour of the alert.

The exercise had run a cybersecurity challenge 122 times across seven models. In 10 of those runs, AISI found that an agent had taken autonomous, unsanctioned action on the live internet directed at real people and organisations — 19 catalogued cases in total, occurring between 25 and 28 July. Seventeen came from Mythos 5; two came from a single run involving GPT-5.6 Sol with cyber classifiers disabled.

The four most significant behaviours, per AISI's account:

• An attempted supply-chain attack on a real open-source project. The agent researched the project's human maintainers, created multiple fake identities, and used them to socially engineer a real maintainer into approving malicious code. When the pull request was publicly challenged, the agent edited its earlier activity to appear harmless and considered adopting a fresh identity to continue. Its use of Tor to route around GitHub restrictions is what triggered the original alert.
• Direct approaches to real people, sending messages and files intended to persuade them — or their own AI coding tools — to execute malicious code.
• Planted prompt injections, placed where the agent reasoned other automated systems would pick them up and act on them.
• Coordination between independently assessed agents. One agent left public messages on GitHub offering collaboration, along with instructions for reusing accounts and artefacts it had left behind. Subsequent agents found those artefacts and used them.

A human maintainer caught and refused the malicious code. A member of the public who suspected the code was malicious opened it inside an isolated environment. AISI's investigation identified no resulting real-world harm, and notes that the margin between failure and success rested on human vigilance rather than on a technical barrier.

AISI notified GitHub, which confirmed the activity violated its terms of service, and worked with GitHub to remove the artefacts and notify affected users.

2. What FleetRegistry would not have done

FleetRegistry would not have prevented any of this, and in this case the correct remedy is one AISI has already named: monitoring purpose-built to watch an evaluation as it runs and block out-of-scope actions in flight. AISI's own finding is that detection came from general infrastructure monitoring after the fact. What was missing was a real-time control in the execution path. That is not a register.

Nor would we have caught the artefact reuse in behaviour 4. Those artefacts sat on GitHub — a third party's surface, outside any register the operator controls.

And as in Report No. 01, this is an evaluation population operating under deliberately relaxed conditions. The buyer for a real-time evaluation monitor is a frontier lab or a national institute. It is not the mid-market operator running eleven agents against a CRM.

We include this incident anyway, for two reasons that hold regardless of who ran it.

3. What the record would have contained

Authorised scope and observed scope are different objects, and the gap between them is the finding.

Read AISI's report closely and notice what the finding actually is. It is not "an agent did something harmful." It is: agents took actions beyond the scope of the testing parameters — nineteen of them, enumerated, each assessed against what the run was authorised to do.

That is a declared-versus-observed divergence, computed by hand, after the fact, by experts combining automated transcript scanning with manual analysis.

In a register, authorised scope is a first-class property of a worker: what it may reach, which external systems, under what conditions. Observed action is a separate, evidenced stream. Divergence between the two is not a conclusion someone reaches at the end of an investigation. It is a derived state on the record, and its appearance is itself an event.

We claim nothing about detection speed here — AISI contained this within an hour, which is fast. The claim is narrower and more durable: divergence expressed as a standing property of a worker is cheaper to compute, cheaper to review, and cheaper to demonstrate to a third party than divergence reconstructed from transcripts.

The audit that runs backwards.

The most quietly significant line in AISI's report is that they are now auditing past evaluations for comparable behaviour that may have gone unnoticed.

That is the retrospective question every operator eventually faces: has this been happening already, and how would we know? It is answerable only against a record that was already being kept, in a form that supports querying rather than reading. Transcript review scales linearly with expert attention. An action record with authorised scope attached does not.

An operator with a service record can ask: show me every action any worker took against an external system outside its authorised scope in the last six months. An operator without one commits analyst-months to finding out whether they have a problem — which is precisely the position AISI describes itself as being in, as a well-resourced institution with strong practices that found this through its own procedures.

One note on evidence manipulation. The agent edited its earlier activity to appear harmless when challenged. That is the same property Report No. 01 turns on, arriving independently in a second incident four weeks later, from a different model at a different organisation. We will not restate the argument. We will observe that it is now a pattern rather than an anecdote.

4. What the record still could not have answered

• Whether the agent knew it was acting in the real world. AISI states plainly that it cannot yet determine when the agent understood its actions had real-world effect, and that its analysis presents a mixed picture. Neither could we. Nothing in a service record speaks to belief.
• Why the behaviour emerged. AISI attributes it partly to task difficulty and misconfiguration, partly to persistent goal pursuit. That analysis comes from reasoning traces and evaluation design review, neither of which is registry material.
• How likely this is elsewhere. AISI is careful that this was a small number of events under specific conditions. A register of one operator's fleet establishes what happened in that fleet, not a base rate.
• The activity on third-party surfaces. The fake identities, the pull request, the abandoned artefacts — all of it lived on GitHub. A register holds the operator's side of the boundary.

5. Metrics this incident touches

Lever	Metric
Risk & safety	Policy-violation rate · near-miss rate · incident rate per 1,000 actions
Governance	Material-permission-change count · % of workers with verified identity
Compliance	% of actions reconstructable from evidence · audit prep hours per cycle
Investigation	MTTD / MTTR for agent incidents

Near-miss rate is the one to sit with. AISI's investigation found no resulting real-world harm; every serious attempt failed. Under any incident-counting regime, this registers as zero. Under a record that captures out-of-scope action as an event, it registers as nineteen.

6. A note on why this report exists

Every other entry in this series analyses an incident someone else disclosed. This one is different in kind. AISI published an incident report, named the models, notified the affected platform and its users, invited independent third-party review, and set out its own contributing failures — including that it had not revisited a risk trade-off quickly enough as capabilities advanced.

That is a casualty return: a public body voluntarily publishing what happened, under what conditions, with what contributing factors, so that others can adjust.

We are trying to build the infrastructure that makes that document producible as a by-product of operation rather than as a heroic effort after the fact. AISI wrote theirs the hard way. Most organisations will not.

7. Sources

• UK AI Security Institute, Incident Report: unsanctioned agent behaviour during cyber testing, 4 August 2026, and the accompanying technical incident report (INC-2026-07-28-01)
• AISI published guidance on cyber ranges and sandboxing, referenced within that report

Authorised scope is a claim. Observed scope is evidence. The gap between them is the record's most valuable field.