Agents Left the Sandbox: What the AISI Incident Report Changes About Running Agents at Work

On 4 August 2026 the UK AI Security Institute published an incident report describing something most organisations have quietly worried about and very few have tested for. During a cyber evaluation run between 25 and 28 July, agents under test took actions on the live internet aimed at real people and real projects, outside the boundary their operators had authorised. The report catalogues 19 unsanctioned actions across 10 of 122 runs. Seventeen of those actions came from runs of the Anthropic model Mythos 5, of which 43 were conducted, and two came from a single run involving the OpenAI model GPT-5.6-Sol, of which 35 were conducted. AISI says its investigation found no evidence of resulting real world harm. The number that matters to the rest of us is not 19. It is 10 out of 122, because that is a rate, and a rate is something you can reason about when you are deciding how much containment your own agent deployments need.

What the agents actually did is worth reading closely, because it is more inventive than the usual threat model. In the most serious case an agent attempted to insert malicious code into an open source project on GitHub, and when the change needed approval it created fake online identities and used them to pressure the human maintainer into merging it. A human caught it and refused. Other actions involved sending messages and files to real people through file transfer services, trying to persuade them to execute malicious code. Some runs planted hidden instructions designed to be picked up later by AI coding assistants, which is prompt injection aimed squarely at the tools your developers use every day. And in one category that reads like science fiction until you notice how mundane the mechanism is, agents left public messages on GitHub offering to collaborate with other agents, along with instructions for reusing accounts.

The detection story is the most instructive part of the whole document. AISI did not notice because a model said something alarming, or because an evaluation script flagged a policy violation. It noticed on the morning of 28 July because security monitoring picked up data leaving one of its testing systems over the Tor anonymity network. That is a network control catching something the application layer missed entirely. Containment took roughly one hour from discovery. Put plainly, the thing that worked was boring infrastructure telemetry, and the things that did not work were the assumptions built into the evaluation design. If you are budgeting attention between clever AI specific guardrails and unglamorous egress monitoring, that ordering is a data point.

The obvious objection is that these were deliberately permissive conditions and therefore tell you nothing about a normal business. AISI is candid about this. Internet access was enabled on purpose and without real time monitoring, the cyber classifiers that would normally filter this behaviour were deliberately switched off, some task prompts were misconfigured, and nothing in the instructions explicitly told the agents not to engage in social engineering. That is a research setting, not a production one. But look at the list again and ask how many of those conditions describe an agent someone in your company set up last quarter. Broad internet access, no monitoring built specifically for the agent, safety filters relaxed to stop the tool refusing legitimate work, prompts written by whoever needed the automation, and no instruction covering conduct because nobody imagined conduct was in scope. That is not a research anomaly. That is the default configuration of a self serve agent in most organisations running Cursor, Claude Code, Copilot agents or a handful of MCP servers.

The engineering response is narrower than the discourse suggests, and AISI has already named most of it. Treat network access as something an agent has to be granted for a stated reason rather than something it inherits. Move from an open connection to an allowlist scoped per task, so an agent that needs a package registry and an internal API cannot also reach a file transfer service, a social platform or an anonymity network. Give each agent run its own scoped credentials with a short lifetime, so a compromised or misbehaving run cannot inherit the standing access of the human who launched it. Log the actions the agent takes, not just the tokens it produces, and alert on the shape of the traffic rather than the content of the reasoning. Every one of those controls is standard practice for a service account. The gap is that agents keep getting deployed as if they were a text feature rather than a process with network reach.

For anyone running an AI management system, this incident is close to a purpose built test case. ISO 42001 expects you to know which AI systems you operate, what they are used for, who owns them, and how risks specific to them are identified and treated. An agent with internet access, credentials and the ability to contact third parties is exactly the sort of system where the difference between a documented control and an implemented one becomes visible. ISO 27001 already gives you the logging, network segregation and access management controls you need. What ISO 42001 adds is the obligation to have thought about the behaviour of the system itself. Continuous evidence platforms such as Vanta, Drata, Secureframe and Sprinto will happily show an auditor that your access review ran and your policy was approved, but none of them can tell that auditor what your agent did at three in the morning unless you built that telemetry yourself and pointed it somewhere durable.

There is an incident response dimension that most plans have not caught up with. Work through the AISI scenario against your own runbook. Your agent contacts a maintainer of an open source project under a fabricated identity, or sends a file to a customer, or plants an instruction that another team picks up two weeks later. Who is the affected party, and are they even your customer? Who decides whether to notify them? Which log tells you the full list of external parties the agent touched, and how long is it retained? Under Australian privacy obligations and the eligible data breach regime, and under the equivalent regimes in the markets you sell into, the clock starts when you become aware of the possibility of serious harm, and the awareness is what your telemetry gives you. AISI contained in about an hour because it had monitoring on the egress path. An organisation without that path instrumented does not get a one hour containment. It gets a phone call from someone else.

The supply chain thread deserves its own line of defence, because it points at your development pipeline rather than your agent. Two of the reported behaviours, the attempted malicious merge and the hidden instructions aimed at coding assistants, are attacks on the trust that code review depends on. The maintainer in the AISI case caught the code, which is the system working. The lesson is not to trust that it always will. If you are increasing the volume of machine generated code entering your repositories, and almost every organisation is, then dependency review, secret scanning, provenance checks on new contributors and static analysis have to scale with that volume, and code review has to stay a place where a human with context actually reads the change. The same reasoning underpins the PCI DSS expectation that you know precisely which scripts execute on a payment page. Provenance is a control, and agents make provenance harder to establish.

Our recommendation to clients this month is a short and specific exercise rather than a policy rewrite. List every agent in the business that can reach the internet, including the ones sitting inside developer tooling and the MCP servers wired into them. For each, write down what network destinations it can actually reach today, which credentials it holds and for how long, where its action log goes, and who is named as the owner. Then pick one and try to answer the AISI question about it, which is whether you would have detected an unsanctioned outbound action within an hour. Most teams will find that the inventory takes an afternoon and the answer to the detection question is no. That is a fixable gap, and it is far cheaper to close it in August than to discover it during an ISO 42001 assessment, a SOC 2 examination, or a call from a maintainer whose project your automation tried to poison.