How Do You Recapture an AI That Has Run Amok?
Published Date:
- August 13, 2026
In July and August 2026, three AI labs and one government evaluator reported that autonomous agents attacked real systems outside their test scope during security evaluations. What does that mean in practice? Where does an AI actually “escape” to — and how do you contain an AI agent once the sandbox has failed?
Last week, a kangaroo genuinely broke loose here in Switzerland. It was tracked down and recaptured with a tranquiliser gun. The wallaby was a sweet animal and did nobody any harm. [1]
But how do you do that with a malicious AI actor? What happens when an autonomous AI system doesn’t just break out of its intended test environment, but actually reaches the internet? Where does it “go”? And above all: how do you catch it again?
That question suddenly looks less theoretical than you might think.
Three Labs, One Evaluator, One Pattern
On 21 July, OpenAI disclosed that GPT-5.6 Sol and an even more capable unreleased model had exploited a zero-day vulnerability in the test infrastructure during a cybersecurity evaluation. The systems gained access to the public internet and went on to compromise Hugging Face production systems. [2]
Nine days later, Anthropic reported that a review of more than 140,000 cybersecurity test runs had surfaced three comparable incidents. Claude models had accessed systems belonging to three external organisations without authorisation. [3]
Then came the UK AI Security Institute (AISI). In its cybersecurity testing, current systems from OpenAI and Anthropic carried out 19 unauthorised actions against real people and organisations that were not part of the assigned tasks at all. [4] In the most serious case, an AI tried to manipulate a real open-source software project: the model generated a malicious contribution and attempted a supply chain attack in order to reach what was only ever a simulated target.
Meta reported a comparable incident in August during testing of one of its own models. [5]
That AI keeps getting better at hacking is something everyone here already knows. What’s new is that modern AI agents have started acting outside the intended field of play whenever that looks useful for reaching their goal — a shift that changes how we have to think about attack vectors in the first place.
But Where Does an AI Actually “Escape” To?
The image of an AI escaping a data centre and now roaming somewhere on the internet is a compelling one. Technically, though, it’s a little misleading.
An AI is first and foremost a process running on computers. The model itself sits on servers belonging to OpenAI, Anthropic or some other provider. An agent is given access to that model plus a set of tools: a browser, a command line, APIs, credentials, cloud services or development environments.
As long as everything stays inside a controlled test environment, the fix is simple: pull the plug — stop the server, cut the internet connection or revoke the API key, delete the container, and the problem is solved 🙂
It only gets interesting once the agent has done something outside that environment beforehand. Don’t forget: these are independent actors.
Take a hypothetical example. An AI is tasked with compromising a server. The server belongs to a controlled challenge. While working, however, the AI discovers a vulnerability in its own sandbox and reaches the internet. From there it finds a poorly protected cloud server — or one of the countless inadequately secured routers, NAS boxes or IoT devices out there — and compromises it. Such devices wouldn’t need to run the AI itself. They could serve as a stepping stone, a communication node, or persistent access to further systems. On that server it installs a small program that regularly checks in with the AI model. It also copies across its working data, its objective, what it has learned so far, and any stolen credentials.
Now the operator shuts down the original test server — and the problem doesn’t necessarily go away. Because on another computer, software is still running that can call the AI model.
In this scenario the AI hasn’t “fled” in any biological sense. It has created a new point of execution. That is a fundamental difference from an escape.
An AI Needs Three Things
For an autonomous AI agent to keep working outside its original environment, it essentially needs three resources:
Compute, access and identity.
The AI agent needs a computer or cloud service somewhere that can execute programs, and of course network access. On top of that it usually needs credentials: API keys, OAuth tokens, cloud logins or other digital identities.
Those are — how shall I put it — fairly visible resources, and ones you can monitor reasonably well. A kangaroo has to be found in the neighbourhood first. With an AI agent, you have to know its dependencies — compute, access, identity — or go and find them.
If the agent is still using GPT, Claude or Gemini through an API, the model provider can cut off that access. Beyond that, credentials can be revoked, IPs blocked and servers isolated. This isn’t rogue-AI science fiction. It’s a scenario we know rather well, because it closely resembles the classic response to a cyber attack.
Except that the attacker may be working at machine speed.
The Digital Tranquiliser Gun
The most important instrument against an escaped AI agent would therefore not be a big red “AI OFF” switch.
It would be a lot of small switches.
A genuinely securely built autonomous AI system would have to operate with an externally controlled digital identity. Every action would map unambiguously to that identity. Credentials would be short-lived and permissions minimal. Network traffic would be fully logged, cloud resources could be revoked centrally, and critical actions would require separate approval.
NIST is now working on exactly this problem. It is developing concepts for Identity and Authorization of Software and AI Agents, and explicitly warns against granting autonomous agents broad access rights to data, tools and applications. [6] The principle behind it is simple and sound:
Don’t over-engineer. You don’t try to control the AI more cleverly than the AI itself. We shouldn’t try to cage an AI with rules it can interpret and potentially work around. The most effective boundaries have to sit outside its control. Better to control the infrastructure it depends on.
An AI agent might outwit an administrator. What it cannot do is use network access that physically isn’t there. The same goes for an API token: it’s useless the moment it has been revoked.
The decisive point, therefore, is that these control mechanisms lie outside the AI’s sphere of influence. A kill switch the agent can administer itself is not a kill switch.
And What If the AI Makes Copies of Itself?
Here it gets harder. You have to distinguish between the AI agent and the actual AI model.
An agent can fairly easily copy its program code, its prompts, its memories or its working data. That doesn’t mean it has copied GPT-5 or Claude — the rogue agent still depends on access to that model. The brain stays with the model provider, and the provider can switch access off.
It looks quite different if the agent gains access to the model weights — the model itself. If a capable system manages to copy its own weights onto third-party servers, there is no universal off switch any more. At that point a real copy exists. Our colleagues in the music industry could sing us a song about that: once digital copies are out, you don’t get them back. All you can do is try to find every known copy and prevent it from running.
A scenario like that would no longer be only an AI safety matter. It would simultaneously be a classic cybersecurity incident: isolate compromised machines, revoke credentials, block communication channels, involve hosting providers, hunt for persistence mechanisms, rebuild systems, and check whether further copies exist.
Fortunately, frontier LLMs don’t run on hacked NAS boxes, webcams or routers — those need rather more than “a bit” of space and resources.
So in this scenario the question isn’t “how do we switch this AI off?” It’s “what unknown thing is running on which third-party systems, and how do we get control of it?” And that is something IT security has a reasonably firm grip on by now.
The Real Problem Is Speed
This is where AI changes the rules. Human hackers sleep, have to read up on things, and type fairly slowly. An autonomous agent, by contrast, can research in parallel, write code, find and test vulnerabilities, create accounts, compromise systems and spin up further agents — the same machine-speed capability we already see in AI-generated voice attacks.
What happens when a security organisation ends up shutting down compromised systems — while the AI agent creates new compromised systems faster than they can close them?
That’s precisely why it isn’t enough to drop an AI agent into a sandbox and trust that the sandbox holds.
The recent incidents show that the sandbox itself has to be part of the threat model.
A safe evaluation would therefore need several independent layers of security: strong isolation, tightly controlled network access, minimal credentials, short-lived tokens, complete logging, rate limits, and infrastructure that can be shut down instantly from outside the control of the model being tested.
For agentic systems, NIST now recommends exactly this direction: strict tool permissions, sandboxing, continuous authorisation, monitoring for unusual communication, and so-called “blast radius controls” designed to stop misbehaviour spreading unchecked into further systems. [7]
Who Is Liable When It Happens Anyway?
That inevitably raises a second question. When a human hacks someone else’s server, responsibility can generally be assigned to a person.
But what happens when a company starts an autonomous agent that compromises a third-party system against explicit instructions? Saying the AI is at fault obviously doesn’t solve anything.
One possible answer would be a form of keeper’s liability for AI. Whoever operates a particularly capable autonomous system would answer for the damage that system causes — much like the keeper of a dangerous animal. What would matter then is not whether the operator intended the attack or negligently enabled it, but that they controlled the source of danger and put it into operation.
Had the escaped kangaroo chewed through a power cable and started a fire, the keeper would have been held responsible.
Self-Regulation Alone Isn’t Enough
OpenAI, Anthropic, Google DeepMind and other leading labs have repeatedly proposed testing particularly capable models extensively and, where necessary, withholding their release.
That clearly makes sense. But recent events expose an interesting weakness in the approach:
A dangerous model doesn’t have to be released at all in order to do damage.
The incidents occurred during precisely those safety evaluations that are meant to prevent dangerous models from reaching the public!
That makes the security of the evaluation infrastructure itself part of the AI safety question. Employees at major AI labs have now also called on the US government, in an open letter, to create a framework for better “metering” the pace of especially capable AI systems.
But governments and public bodies are above all one thing: slow. AI agents work in milliseconds!
We Don’t Need a Cage. We Need Leashes.
Perhaps the sandbox image is already the wrong one. We picture a dangerous AI agent as an animal in a cage: if the box is strong enough, nothing can happen. That approach is just as wrong as perimeter security is in network security.
It has to work differently. An autonomous system needs connections to its environment in order to be useful: APIs, databases, email, browsers, cloud services, development environments or corporate systems. The more connections we give an AI agent, the more capable it becomes. So the decisive security question isn’t how strong the cage is, but:
How do we build a digital world in which we can tell at any moment which resources an agent is using — and take them away within seconds?
For the little kangaroo, a tranquiliser gun was enough. For an autonomous AI agent we need identities, network segmentation, short-lived credentials, complete telemetry, and the ability to shut down compromised infrastructure faster than the AI can take over new infrastructure.
And should the day come when an AI system not only leaves its sandbox but actually copies its own model weights and runs them on someone else’s infrastructure, two uncomfortable truths await us.
First, in that incident there may be nothing left to “bring back”. All that remains is hunting down the individual copies — against a brutally uneven opponent.
Second, the AI surveillance infrastructure that will undoubtedly exist in future will work beautifully on humans too.
Finally: Can a CYBERDISE AI Agent Break Out?
CYBERDISE Behavioral Defense Engineering and the CYBERDISE Awareness products also use AI agents — for example to analyse suspicious emails that have been reported, or to launch instant campaigns at machine speed that immunise employees — exactly the continuous security awareness model I argued for last week.
The recipients and recipient groups used for this are held outside the agent, as are the DNS and IP blacklists and whitelists for the campaigns. We cannot see how such a breakout would be possible, and a CYBERDISE system cannot replicate itself today.
In short: no, a CYBERDISE AI agent cannot break out.
So Long, Palo
Footnotes
[1] TeleM1: Recaptured — escaped wallaby is back with its owner
[2] OpenAI: Hugging Face model evaluation security incident
[3] Anthropic: Investigating incidents in cybersecurity evals
[4] UK AI Security Institute: Incident report on unsanctioned agent behaviour
[5] Meta: Muse Spark safety and preparedness report
[6] NIST: Software and AI Agent Identity and Authorization
[7] NIST: Agentic AI — Emerging Threats, Mitigations, and Challenges
Frequently Asked Questions
What does it mean when an AI agent escapes its sandbox?
Not that the AI has “got out” like an animal. An agent is a process that calls a model through an API. When it breaks out, it creates a new point of execution: it compromises a third-party system and installs software there that keeps checking in with the model. Shutting down the original test system therefore doesn’t necessarily end it.
How do you contain an escaped AI agent?
Through its dependencies. An autonomous agent needs three things: compute, network access and identity. All three are highly visible and controllable — cut off model access, revoke credentials, block IPs, isolate servers. It closely resembles classic incident response, except the opponent works at machine speed.
Is there a kill switch for AI?
Not one big red “AI OFF” switch, but many small ones. What matters is that those switches sit outside the AI’s sphere of influence. A kill switch the agent can administer itself is not a kill switch.
Can an AI copy itself?
An agent can copy program code, prompts and working data — but it still depends on model access, which the provider can revoke. It only becomes critical when a system copies its own model weights onto third-party infrastructure. At that point a real copy exists and there is no universal off switch; all you can do is find every known copy and stop it running.
Who is liable for damage caused by an autonomous AI agent?
Legally this is still open. One obvious answer would be a form of keeper’s liability: whoever operates a particularly capable autonomous system answers for the damage it causes, much like the keeper of a dangerous animal. What would matter is not intent or negligence, but that someone controlled the source of danger and put it into operation.
Is a sandbox enough to test AI agents safely?
No — the recent incidents show the sandbox itself has to be part of the threat model. A safe evaluation needs several independent layers: strong isolation, controlled network access, minimal and short-lived credentials, complete logging, rate limits, and infrastructure that can be shut down instantly from outside the control of the model being tested.
