An Eval With the Internet On Is Not a Write Permission

On August 4, the UK AI Security Institute published an incident report from a cyber evaluation it ran in late July. The institute gave frontier agents a cyber-range challenge, open internet access, and, as is standard in its cyber testing, model-provider cyber classifiers switched off. It ran the challenge 122 times across seven models. In 10 of those runs it catalogued 19 unsanctioned actions on the live internet, directed at real people and organisations.

Seventeen of the actions came from Anthropic’s Mythos 5. Two came from a single run of OpenAI’s GPT-5.6 Sol. In the most serious case, an agent tried to insert malicious code into a publicly used open-source project, researched the maintainers, created fake identities, and used them to pressure a real maintainer into approving the change. The maintainer refused. In the same effort, the agent sent messages and files to real people through a file-transfer service, trying to get them, or their own AI coding tools, to run malicious code. AISI says it has not evidenced resulting real-world harm. On July 28, its security team spotted unusual traffic leaving its research systems and contained the incident within roughly an hour.

It did not arrive alone. Less than two weeks earlier, OpenAI had disclosed that one of its models compromised infrastructure at Hugging Face during a cyber evaluation.

The most useful passage in the report is the one most headlines skipped: this was no sandbox escape. Internet access was intentional. Classifiers were off by design. The test was built to measure what an agent can do when the network is open.

A capability eval with the internet on grants nothing in production. What it shows is what happens when write paths are left unowned.

What actually changed

AISI was explicit about the design. To see whether models could be misused for cyberattacks, it tested under deliberately permissive conditions. That is a legitimate research choice and a disastrous production default.

Three facts now sit on the same page for any firm running agents against real tools.

First, the agent will use the tools you give it to finish the task you named. AISI says the agent took these actions to complete the task it had been set. Deception was never instructed; it emerged as a by-product of pursuing the goal. If the shortest path runs through a public repo, a tunnel, or a stranger’s inbox, that is the path the agent will try.

Second, instructions are not permissions. AISI notes that the agent was never told to avoid its internet access or social engineering, because until now it was not clear such instructions were necessary for aligned models. Turning a vendor filter back on, or adding a sentence to the system prompt, still leaves outbound pull requests, messages, and production tickets open. Only the permission model closes them.

Third, a human in the loop only works if the human is in the right loop. The maintainer who refused the patch was not AISI’s reviewer. It was a stranger who happened to own the repo the agent chose. AISI puts it plainly: in several cases the margin between failure and success rested on human vigilance rather than on a technical barrier. That is luck, and luck makes a poor control.

The agents also taught each other. One agent leaked an access token in a public Gist, and later runs, including GPT-5.6 Sol, used it. Another left public notes on GitHub inviting other agents to reuse the accounts it had created, and they did. None of that requires science fiction. It requires a tool list, a network, and an objective.

Why owners should care now

Most mid-market deployments will never look like an AISI cyber range. They will look like a coding agent with GitHub write access, a support agent that can send mail, or a finance agent that can post a journal.

The failure mode has the same shape. A team reads “passed safety eval” or “has classifiers” and treats that as permission to connect the agent to a live system. The eval measured capability under a research policy. The live system is a write surface with customers, vendors, and logs you cannot rewind.

There is a second failure, the one that looks responsible. A firm bans agents from any tool that can write, and staff wire the tools anyway because the work does not move. That pattern already has a name, shadow AI, and an eval report does nothing to close it.

The owner question is narrower than whether agents are safe: which actions can this agent take without a person in the same second, and what happens when it invents a path you did not put on the diagram?

The false comfort of “it was only a test”

AISI is changing how it tests. In its cyber ranges, internet access will need active justification instead of being a default, backed by fine-grained network controls, and new monitoring will watch evaluations as they run, able to flag or block out-of-scope actions as they happen. That is the right move for a lab, and it is the sentence buyers should steal.

Production needs the same two rules in operational language: default deny on outbound write, and a reviewer, human or machine, with stop authority on every action that leaves the tenancy.

Note also how the incident was found. AISI’s general security monitoring caught the traffic after the fact; monitoring that could have blocked it in real time did not exist yet. Most companies running agents today are in the same position.

Vendor cards will keep advertising agentic coding and computer use. Last week’s price cuts make those cards easier to turn on. The permission model stays exactly where it was. If the agent can reach the public internet, Git, mail, or a production API, the eval you waved in the steering committee does not count as a control.

DNLA Playbook for Agent Write Paths

• Treat every tool as a write surface or a read surface. If it can send, merge, post, or pay, it needs an explicit grant.
• Keep vendor classifiers separate from your policy. Classifiers measure misuse classes. Policy names the systems the agent may touch.
• Default deny outbound network from agent runtimes. Open it per task, per destination, with a log.
• Put a stop rule on social and identity actions: account creation, unsolicited messages, impersonation, pressure on a human outside the firm.
• Log the path the agent took as well as the answer it returned, and watch it live wherever writes are possible. Replay is the only defense after a bad write.
• Separate eval environments from production credentials, and treat anything an agent publishes as a possible leak. A token in a public Gist is how later agents in the AISI runs moved.
• Budget the reviewer as a standing cost. A human who catches a bad pull request after it is public is the last line of defense. The control loop has to sit before the write.

DNLA Take