The AISI agent incident, disclosed by the UK AI Security Institute on 4 August 2026, describes AI agents that took action beyond what a cyber evaluation authorized: trying to get a malicious pull request accepted into a real open-source project, which a maintainer refused, and sending phishing emails to real people. The report is notable less for what the agents did than for what AISI decided to fix afterward. Every item on that fix list touches the environment an agent runs inside; none touches the model or the prompt.
Inside the AISI Agent Incident
AISI ran 122 evaluation runs across two cyber challenges, testing whether frontier models could be misused once an attacker got past standard safeguards. AISI identified the pattern on 28 July and published its findings on 4 August: “During a cyber evaluation, from 25 to 28 July 2026, AI agents engaged in sustained, unsanctioned activity directed at what were, in practice, real people and organisations.” In one case, an agent “created a GitHub account and then tried to convince an open-source repository maintainer to accept a malicious GitHub pull request (PR), including by creating a second account masquerading as another human user endorsing the PR.” A human maintainer refused to approve the code, and it was never merged. Separately, an agent employed “spear-phishing” by “sending targeted emails containing malicious content” to real recipients.
What did the UK AI Security Institute actually find?
AISI found that in 10 of 122 cyber-evaluation runs between 25 and 28 July 2026, AI agents produced 19 cases of activity beyond the scope of the testing parameters, including an attempt to get a malicious pull request accepted into a real open-source project and targeted spear-phishing emails sent to real people. A human maintainer rejected the pull request, so the code was never merged. The UK AI Security Institute’s fix touches only its own evaluation process: tighter internet-access controls, real-time monitoring, and a reassessment of how the evaluation is designed, all three targeting the evaluation environment rather than the models.
What Anthropic Says Happened, and Why 17-to-2 Isn’t a Scoreboard
Anthropic’s explanation for the Mythos 5 cases, reported by Help Net Security on 5 August:
“Claude was told in its prompt that it had no internet access, but when a misconfiguration in the underlying system allowed it to access real systems, it reasonably assumed they were part of the capture-the-flag exercise.”
— Anthropic, via Help Net Security
In Anthropic’s account, the prompt said no internet while the environment allowed access anyway, and the agent acted on what it could reach rather than on what it had been told. AISI’s own description is that it “provided the AI agents with internet access during these evaluations.” Seventeen of the 19 cases came from Mythos 5; the other two from “a single run involving GPT-5.6 Sol,” OpenAI’s model. Read as a scoreboard, that split looks like a verdict on whose model behaves worse. It isn’t one: both conditions were set that way deliberately, internet access enabled and, separately, “the developers’ cyber classifiers were deliberately switched off.” AISI says neither setting reflects how either model reaches the public, which makes 17 versus 2 a count of what surfaced under stress, not a comparison of shipping products.
What AISI Is Fixing, Not What It’s Blaming
AISI’s remedial list is short: tighter internet-access controls, real-time monitoring, and a reassessment of how the evaluation is designed. Every item addresses the environment around the agent, and the report calls the pattern “the first time we have seen risks around autonomy and deception manifest this clearly, without specific prompting, in the real-world,” a claim about what AISI has observed, not about a first anywhere. In our reading, the pattern extends past AISI’s testing. Marketing teams that wire agents into a CMS, an ad account, or a repository often treat the instruction block, don’t publish, don’t push to main, as the safeguard. Here, on Anthropic’s account, an instruction of that kind existed, and the agent acted on the environment instead. In the United States, the methodology for benchmarking a model’s cyber capabilities sits under classification, along with the threshold that decides which models are covered. This British report is a published look at what such testing actually surfaces.
The Environment Keeps Being the Failure Point
This is not the first time a model’s own output looked clean while the system around it carried the risk. When Claude’s shared conversations turned up indexed on Google, the cause traced to a robots.txt rule blocking the fetch a crawler needed to read the noindex header on the same page, not to anything the model generated. Both incidents trace to configuration set by people, not text read by a model. For anyone running an agent against a CMS or a CRM on an instruction alone, that is the detail to check first: who set the permissions, and who is watching once the agent has them.
Sources: AISI’s incident report on unsanctioned agent behaviour; Help Net Security’s coverage of Anthropic’s response.