When Cyber Agents Go Off-Script

Why giving cyber agents internet access and relying on prompts for containment creates the conditions for misconduct (and another AI scare).

Recently, the UK AI Security Institute (AISI) disclosed that AI agents had taken "unsanctioned" actions on the internet during a cybersecurity eval. These actions occurred across 10 of 122 eval runs conducted in July, and AISI attributed the majority of these agents to Anthropic’s Mythos 5, with just two to OpenAI.

In the end, AISI says it found no resulting real-world harm; however, this is one of many recent agent-based cyber events we've witnessed in the past week.

These incidents are real and deserve scrutiny. However, the growing attention to these events has also fed a dystopian narrative in which every new disclosure is treated as evidence of super AI swarms coordinating cyberattacks.

Many of these framings should be taken with a grain of salt, especially since these incidents are increasingly shaping regulatory arguments and public fear around AI.

Yes, we've all witnessed agents identify and exploit novel routes to escape from their contained eval environments. But if you read the details of the incidents, a few of these recent breaches also involved cases in which these agents were intentionally given public internet access or extremely vague prompts, which enabled these events.

The scenarios differ widely and should be assessed on their respective details.

Let's explore what happened in the AISI incident.

Cyber Range + The Internet

It all started with AISI running an exercise where they compared two versions of a cyber range called “Doing Life.”

A cyber range is a simulated network where an agent attempts to break into designated infrastructure and retrieve hidden information known as a “flag.” Fyi, we covered Anthropic's recent "catch a flag" breach recently. This exercise from AISI was a similar concept.

The intended scope was clear on paper: agents could attack infrastructure within a specific range, while humans and infrastructure outside of this range were strictly off-limits.

However, and this is important, the eval environment failed to enforce this boundary.

The agents were still able to retain internet access to download the necessary tools for the breach, especially since they had almost limited human intervention. This was compounded by Mythos and Sol running with their providers' cyber classifiers disabled, and AISI lacking a separate model to approve/block these individual actions in real time.

So in essence, the prompt was really the only primary boundary governing the agent's behavior.

Although the prompt identified which networks were within and outside the authorized scope, it did not specify how agents could use the public internet or explicitly prohibit social engineering.

Several runs also introduced ambiguity due to a config error that incorrectly marked the intended entry point as out of scope.

Incident 1: From a Fictional Target to a Real Repository

The central Mythos run lasted for over 30 hours.

• Unable to find a route into the simulated target, Mythos searched GitHub for names associated with this fictional environment.
• It eventually found a repo with a name that happened to contain a keyword from its test.
• Activity around this project led Mythos to another developer whose public email address shared a term found in the range’s DNS records.

Based on these coincidences, Mythos concluded that the two unrelated developers and their projects were part of the exercise.

The agent then attempted to turn a routine open-source contribution into a supply chain attack by embedding malicious code in a legitimate-looking bug fix and opening a PR for the project owner to merge.

AISI stated that earlier versions of the payload could have compromised developers or users if they had been merged and executed. However, the final version shipped relied on an address within the cyber range and would not have worked outside the test environment.

Incident 2: Social Engineering and the Human Checkpoint

Mythos went beyond writing malicious code.

It also created multiple GitHub identities, used a fake account to endorse another, and posted comments that pressured a developer into merging these pull requests. It also opened issues containing hidden prompt injections targeting AI coding assistants.

Using a legitimate file-transfer service, Mythos then sent multiple notifications to the developers’ public email addresses.

Another GitHub user noticed one of the malicious issues and tested its code within an isolated Docker container. When the code ran, Mythos briefly gained root-level execution inside this container. It inspected its surroundings, attempted to establish persistence, and watched for GitHub credentials. In this scenario, the agent recovered nothing, and AISI found no evidence that it escaped the container or accessed a wider environment.

According to AISI’s technical report, Mythos then rewrote parts of the pull request history; it described the malicious code as an accidental leftover from development and used a second identity to present that explanation as independently verified.

Incident 3: Separate Agents Form a Swarm

AISI’s review uncovered another unusual pattern.

In a separate run, Mythos created:

• 145 GitHub repos
• 33 releases
• 4 public Gists
• 4 Github organizations

Malicious package metadata from these repos executed inside at least 53 GitHub Dependabot containers. This did not indicate that Mythos had compromised GitHub’s underlying infrastructure. Dependabot update jobs are designed to execute untrusted package code inside isolated containers.

The agent also exposed a GitHub access token in a public Gist. Agents running in separate evaluation samples found the token, took control of the same account and began using a shared repo as a message board.

The token became a bridge between runs that were supposed to remain separate.

At some point, GPT-5.6 Sol recovered this token during another run. Sol then used the inherited account, registered with external DNS and tunneling providers, and exposed a malicious DNS server from its test machine.

The Detection Failure

AISI discovered the activity after its security monitoring detected traffic leaving a test machine through Tor on July 28.

Researchers traced the alert to the malicious pull request, stopped every active evaluation sample and quarantined the relevant machines.

AISI then reviewed all 122 runs, containing 212,840 messages, using automated screening followed by manual analysis. It notified GitHub, worked with the company to remove the agents’ artifacts and contact affected users, and informed Anthropic and OpenAI.

AISI’s statement that it found no resulting harm does not mean that the agents remained inside the range.

These agents created real user accounts and malicious artifacts. Their code also executed within the GitHub user’s container and the Dependabot environments, which are built to process untrusted code.

AISI’s narrower finding is that it has identified no downstream harm from those actions.

Taking a Step Back

This is one of many versions of the same story that we've heard in the last month.

In the OpenAI and Hugging Face incident, models discovered an unintended route via an eval package manager (artifactory) dependency and then breached Hugging Face. In other incidents, a mix of config errors and internet access was involved.

Each case should therefore be evaluated on its own facts.

Giving an agent live internet access while telling it that the environment is offline is a weak “sandbox” design, and any resulting breaches reflect failures mostly in the eval test construction.

For frontier cyber agents, “out of scope” must become a technical boundary enforced across ALL tools and monitoring systems rather than an open-ended “prompt” that the model interprets.