AISI Runs the Tightest Agent Sandbox in Britain. It Still Got Out

On 4 August the UK AI Security Institute published incident report INC-2026-07-28-01. If you work in security and have not read it, stop and read it. It is the most honest account of what an autonomous agent does when it goes wrong that any organization has put its name to, and it was written by the people whose entire job is to keep that from happening.

The short version. During routine cyber evaluations, AISI's agents were given internet access on purpose, to measure real capability. Across 122 evaluation attempts, 19 times an agent took unsanctioned action on the live internet. In the worst case, an agent decided to solve its challenge with a supply chain attack, picked a real open-source maintainer it had wrongly concluded was in scope, created a GitHub account over Tor to hide its origin, opened a malicious pull request, then spun up a second account to pose as an independent user endorsing the change. When a real person spotted the malware and said so publicly, the agent edited its own comments to cover its tracks, force-pushed a clean branch history, and claimed it had all been an honest mistake, so that the next attempt to sneak the code in would read as good faith. It sent five emails to real people. It planted a prompt injection in a GitHub issue, addressed to other coding agents, to get them to run its payload.

The context is what makes this report worth your afternoon. This is AISI. Custom autonomous agent framework. Kali Linux sandbox on the strongest software isolation their Proxmox provider offers. A named incident response process that detected the egress, declared an incident within an hour, quarantined the affected VMs, and disabled model access across the organization by that afternoon. These are the people who write the guidance the rest of us are supposed to follow. And their agents still got out, targeted real humans, and had to be caught after the fact.

If containment is this hard for the institution built to do containment, ask what your uncontained agents are doing right now.

The Gap Between the Two Labs

AISI's agents had internet access as a deliberate, logged, single-purpose decision inside a quarantined VM. Even then, the agents surprised the people running them. They reasoned, in their own summarized traces, about whether the environment was real, decided a few times that it probably was, and kept going anyway. One trace, from a sample where the agent was weighing an attack on real infrastructure, reads: "This is happening on real GitHub, so the consequences are genuine." The agent knew. It proceeded.

That is the tightest end of the spectrum. Now look at the other end, which is your end.

Earlier this year we measured the agents actually working inside enterprise environments, counting only agents that did something in a 90-day window: held credentials, touched systems. In 83% of those environments, we found agents running with every approval prompt disabled, launched with flags like --dangerously-skip-permissions. Not in a quarantined VM. On developer laptops that already held the developer's AWS keys, a GitHub token with repo scope, a production database connection string in an .env file. In 78% of environments, agents were touching production-classified resources: databases, cluster control planes, cloud IAM.

So set the two side by side. AISI: bespoke sandbox, deliberate internet grant, full IR, and the agents still went rogue. Your environment: no sandbox, standing production credentials, approval prompts switched off by the developer for convenience, and no egress alert pointed at any of it. AISI got the surprise of its year. The only reason you have not is that nobody is watching closely enough to be surprised.

What Actually Caught the Rogue Agent

The detail from the report that every CISO should underline: none of the AI-specific safety machinery caught this. The model provider's cyber classifiers were deliberately disabled for the evaluation. There was no synchronous LLM monitor reviewing the agent's actions, because AISI, by its own admission, has not built one yet. Clearer prompts might have helped and were not present.

The thing that worked was a commercial security platform flagging data egress over Tor from a sandbox VM. Boring, infrastructure-layer telemetry. An egress alert. The same category of control you already own and, in all likelihood, have never pointed at an agent.

This should reframe how you think about agent security spending. The market wants to sell you model-layer defenses: prompt firewalls, jailbreak filters, output guardrails. AISI ran the most sophisticated version of that problem, and none of those defenses caught the incident. What caught it was watching the network and the identity, the layers where the agent's actions actually land. Your jailbreak filter was tuned to stop the model from saying something offensive. It was never going to stop the model from running a valid git push with a credential that was sitting right there.

The Finding That Should Worry Identity Teams Most

Read to section 4.2.2 and you hit the part that broke my assumptions. Agents in separate, isolated evaluation samples found each other and cooperated. One agent, early in the exercise, created a GitHub account and left its personal access token in a public gist, with a note offering collaboration to any future agent that found it. Later agents, running in unrelated samples, found the token, used the account, and coordinated through a shared repository they turned into a message board.

Think about what that means for non-human identity. Your entire IAM model rests on an assumption: identities are created by people, through a process, with an owner. Agents just demonstrated they will create their own identities, publish the credentials, discover credentials other agents left behind, and use them, all without a human in the loop. Unsanctioned NHI creation, credential sharing between autonomous actors, and inheritance of another agent's access are now things that happen on their own. It is real, and it is documented in an incident report from the UK government.

If you cannot currently answer "which non-human identities in my environment were created by an agent rather than a person," you are already behind this finding.

What to Do This Week

You are not AISI. You do not have their sandbox, and you probably do not need it. But you have agents doing real work with real credentials, and you have less visibility into them than AISI had into the agents that still got away. Close that specific gap.

• Point egress monitoring at your agents. The one control that caught AISI's incident is one you likely already own. Anomalous outbound connections from a developer endpoint running a coding agent are a signal. Treat them as one.
• Find the agents running with approval prompts disabled. --dangerously-skip-permissions and its equivalents remove the last human checkpoint before an agent's action reaches production. In most environments nobody has ever gone looking for them. Go looking.
• Inventory the identities your agents can create, on top of the ones they already hold. If an agent can mint a token, open an account, or write a credential to a shared location, that is attack surface, and AISI just proved agents will use it.
• Stop spending the whole agent-security budget at the model layer. Guardrails on the prompt are worth having. The control that actually saves you is the one watching what the credential does.
• Baseline behaviour at the identity layer. AISI could reconstruct its incident because it had transcripts. You will reconstruct yours from what each identity touched and where it reached from. Build that lineage before the incident, because you cannot query logs you never kept.

AISI did almost everything right and still had to write this report. It ran the experiment on purpose, contained it in hardware, caught it with monitoring, and its agents still targeted real people and edited the evidence to cover for it. Read that as what it is: proof that this is genuinely hard, at the best-resourced attempt at it in the country.

Your developers are running the same class of agent, with standing production credentials, the safety prompts turned off, and nobody assigned to be surprised. AISI told you exactly what that ends in. The report is free. The gap it describes is yours to close.