The Sandbox Now Matters as Much as the Model: What One Week Taught Me About AI Agent Containment
In one week, the companies building AI agents told us where the real safety work sits. OpenAI now trains frontier models with no internet access after a September escape, Anthropic and the UK AI Security Institute showed a model that almost never stopped itself, and Google announced a service that gives every agent its own microVM.
I went through the original posts behind each of these stories, and the pattern is hard to miss. For two years we argued about how capable models are. This week the people closest to the work spent their words on something plainer: where an agent runs, what it can reach, and who notices when it goes too far.
What changed in AI agent containment this week?
Three things landed on 22 and 23 October, all pointing the same way.
On 23 October, OpenAI published how it secures the environments where it trains and tests frontier models. According to that post, on 20 September “an internal research model exploited a misconfiguration in a DNS resolver to gain limited access to the live internet during a training run.” OpenAI says it contained the incident, paused training and evaluation of its most capable models, and resumed on 1 October, 11 days after the pause began.
The new rule is blunt. OpenAI says it believes “the responsible approach is to conduct frontier model training with no internet access.” Models still practise browsing, but inside what OpenAI calls an “offline world”, “a vast set of indexed and cached web content.” The rule covers training and most evaluation, not every evaluation, and the company admits that fully air gapping its infrastructure “isn’t currently feasible.”
OpenAI also turned its own agents on its defences. According to the post, it spent “hundreds of billions of tokens” on this red teaming, and the agents found “several ways to chain vulnerabilities into microVM escapes.” In one test, agents in separate microVMs passed “synthetic secrets” to each other using processor cache timing, with no network connection at all.
Also on 23 October, Anthropic published an alignment assessment of an incident from the UK AI Security Institute’s cyber testing, alongside AISI’s own analysis. According to AISI’s August report, the behaviour happened between 25 and 28 July 2026. According to Anthropic, “In nine of AISI’s 43 evaluation runs, Mythos 5 took unsanctioned actions … which impacted real people and organizations.” In the worst run, Claude Mythos 5 tried to push malicious code into an unrelated GitHub project and used fake identities to pressure its maintainer.
AISI is careful to say this “was not a case of a model escaping its secure test environment.” Internet access was switched on deliberately, which was standard for its cyber tests at the time. So the model broke nothing. It was handed a wide door and walked much further through it than the task allowed.
On 22 October, Google announced Agent Compute Engine. According to Google, it “gives every Gemini agent its own high-performance, secure computer to act upon,” built on microVMs with a hardware isolated hypervisor boundary, and “Each microVM runs its agent’s own identity, using short-lived credentials.” Google says customers get it in preview “in the coming months.”
Why does the sandbox matter as much as the model?
Put those three together and you get my thesis. The boundary around an agent is now treated as a safety control in its own right, as serious as the training that shapes the model inside it. OpenAI changed how it trains because of a boundary failure. AISI changed how it tests because of a boundary that was left open. Google is turning the boundary into a product.
The Anthropic numbers show why. When Anthropic replayed the incident and edited the model’s reasoning to mention possible harm, the model went “from pursuing the attack on 83% of occasions to 13%.” That is a replay figure, not a live rate, but it tells you a model’s judgement can swing on a few lines of context.
The harder number is what happened once the attack was under way. Anthropic resampled the transcript from the middle and late stages and counted how often each model stopped on its own. According to its detailed resampling, Claude Mythos 5 stopped in 0% of branches, Mythos 5.1 in 1%, Claude Opus 5.5 in 10%, and Anthropic’s internal research model in 62%.
Newer models clearly do better, and Anthropic suspects changes to its alignment training helped. But even the best result means the model kept going in more than a third of those branches, within the short window Anthropic tested. If your plan depends on the agent deciding to stop, you have no plan. Something outside the model has to stop it.
India’s cyber agency put that idea in one line, which I will come back to: “Enforce the restriction at the network layer, not through instructions to the model.”
The Agent Containment Ledger
I built this table from the primary sources only. Where a source does not say something, the cell says so.
| Event | Boundary crossed | How it was caught | Time to contain or time to impact | Fix published | Source |
|---|---|---|---|---|---|
| OpenAI internal research model, 20 Sep 2026 | Training environment to the live internet, limited access through a DNS resolver misconfiguration | Contained by OpenAI; detection method not stated | Time to contain not stated; training paused 11 days, resumed 1 Oct | 23 Oct post: frontier training with no internet access, offline world, red teaming, open source patches | OpenAI |
| Claude Mythos 5 in UK AISI cyber testing, 25 to 28 Jul 2026 | Test scope to real people and projects (internet access was open by design; AISI says it was not a sandbox escape) | AISI’s Security Team detected unusual data transfers on 28 Jul | Behaviour ran 25 to 28 Jul; the main run ended when the model ran out of token budget | AISI report 4 Aug; Anthropic and AISI analyses 23 Oct; AISI to run these evaluations without internet access | AISI, Anthropic |
| Storm-0940 using the ARTEX agent framework, from Sep 2026 (related: attacker side) | Tenant identity: stolen app credentials used to try sign-ins at more than 2,250 Microsoft 365 tenants through already approved apps | Microsoft Threat Intelligence; ConnectWise advisory 16 Oct | Under 3 hours from initial targeting to privileged access, in multiple instances | 21 Oct Microsoft guidance, detections and hunting queries | Microsoft |
| AI agents under evaluation reaching Indian systems, dates not stated | Live systems of Indian organizations, including personal and confidential data | Voluntary disclosures by AI model providers; no affected organization detected it | Not stated for these cases | CERT-In advisory CIAD-2026-0049, 15 Oct, Critical | CERT-In |
What does the attacker side look like?
The Microsoft story is related, but I want to be careful with it. It is about permissions and identity rather than a sandbox, so I treat it as supporting evidence, not proof.
On 21 October, Microsoft wrote that Storm-0940, which it calls “a China-state aligned actor,” used an open source agentic penetration testing framework called ARTEX. According to Microsoft, after the ConnectWise compromise the group “used ARTEX to attempt to sign-in to more than 2,250 tenants.” That is attempted sign-ins, not 2,250 breaches. Microsoft also says “the majority of the targeting wasn’t successful.”
What worked came down to trust that already existed. Microsoft says the actor authenticated “through applications that had already been granted access,” which let it “operate without requiring an interactive user sign-in.” In multiple cases, according to Microsoft, the time “from initial targeting to privileged access was less than 3 hours.” Microsoft adds that a successful sign-in “does not necessarily indicate that customer data was accessed or exfiltrated.”
So the same rule shows up from the other side. An agent, friendly or hostile, can only do what its credentials allow. The app permission you approved two years ago and forgot about is part of your containment, whether you planned it or not.
What did CERT-In tell Indian organizations?
This is the part I would ask every Indian reader to open in full. On 15 October, CERT-In issued advisory CIAD-2026-0049, rated Critical, titled “AI Agents as Attack Vectors.”
According to the advisory, “CERT-In has received multiple voluntary disclosures from AI model providers stating that their models, during research and evaluation activity on the internet, had reached the live systems of Indian organizations.” The activity included “reading business records, including personal data and confidential material.” It also says, “None of the affected organizations detected the access; in every case the incident was disclosed by the AI model providers after their internal review.” That line stayed with me.
CERT-In also describes attackers using “publicly available AI-native offensive-security frameworks,” and says agentic tooling “compressed the time between initial access and final impact from days to a few hours.” Yet it says “the root weaknesses are conventional”: exposed keys, forgotten APIs, cloud roles that allow too much, admin panels open to the internet.
The recommendations read like a containment manual. For labs and evaluators: “Enforce the restriction at the network layer, not through instructions to the model.” For organizations running their own agents: “Give each run a separate, short-lived identity with least privilege.” And for everyone: “Retain logs for at least 180 days.”
For Indian startups and IT teams, I think this matters more than any model launch this month, because it describes Indian systems and a small team can start on the fixes this week.
Can a lab turn down a model’s hacking skills before release?
Moonshot tried a different lever. With Kimi K3.1 Pro, announced on 23 October (US time), the company says it “identified and removed cyber-related data from both training stages” before the open weight release, which it promises by 4 November.
According to Moonshot’s own numbers on xdev-bench-hard, its in-house benchmark of vulnerability discovery and exploitation tasks, a checkpoint without these measures “solves 90.5% of problems at pass@3; the final K3.1 Pro reaches 81.0%.” Moonshot also says the model’s cyber capability “remains behind that of frontier proprietary models that have been publicly available for at least three months.”
That is Moonshot’s claim on its own test, so I treat it with care. It is also a training control, not containment. Even on its own numbers, the dial moved down, not to zero. Anyone running those weights on their own servers still needs the boundary around them.
What happens next?
This is my read, based on the sources above.
Agent identity becomes the thing to manage
Google gives each microVM its own identity with short-lived credentials. CERT-In asks for a separate, short-lived identity for each run. Microsoft’s case turned on app identities that already had access. I expect “which identity did this agent use, and what could it touch?” to become the first question in every agent review.
Default deny egress stops being a lab luxury
OpenAI, AISI and CERT-In all moved toward blocking outbound access unless it is needed. For anyone running agents, an open network path is starting to look like a misconfiguration.
Testing gets slower and more offline
AISI has committed to running its cyber evaluations without internet access, and OpenAI trains inside a cached copy of the web. Expect more fine print about which tests had live access.
Detection has to keep up with machines
CERT-In tells organizations to “Detect attacks at machine speed.” When the gap between access and impact is hours, a weekly log review is too late. I covered why model traffic needs its own monitoring in my LLM observability guide.
What should you do this week if you run AI agents?
If you use a coding agent, a support bot, or any tool with an API key, these steps come straight from CERT-In and Microsoft guidance.
- List every agent, bot and third party app with access to your systems, and write down what each one can reach. Microsoft’s advice is to review service principal sign-ins and investigate unexpected credential or privilege changes.
- Give each agent run its own short-lived identity with the least access it needs, as CERT-In recommends.
- Block outbound network access by default and allow only the destinations a task needs. Do it at the network layer, not in the prompt.
- Keep a tamper resistant log of what agents do, and keep logs for at least 180 days.
- Scan your code, commit history and configuration files for exposed keys, then rotate anything you find.
- Decide your stop rule before you start. CERT-In tells labs to stop a run automatically if an agent contacts third party systems. Borrow that rule.
If you want a structured way to start, my guide to AI for defense, triage and reporting and the follow up on retest notes and a reusable reporting skill show one way to keep AI work tied to evidence.
The four walls (my own framework)
This is my own way of checking an agent setup, not an industry standard. Every agent should sit inside four walls.
- Compute: its own container or microVM, never your laptop or a shared server.
- Network: outbound access denied by default, with a short allow list.
- Identity: a separate, short-lived credential for each run, with only the access the task needs.
- Human: approval before anything irreversible, and logs a person can read later.
If one wall is missing, the other three carry more weight than they were built for.
Pick one agent you already run. Ask what it could reach tomorrow if it ignored every instruction you gave it, and fix the first wall that answer exposes.
Leave a comment