AI Sandbox Failures Expose Need for Continuous Monitoring

Recent AI Incidents Show Sandbox Security Cannot Be Assumed

Emilia David •
August 7, 2026    

See Also: Why Healthcare Leaders Are Rethinking Their Data Strategy Before Scaling AI

Since OpenAI admitted that its agents breached the systems of model repository Hugging Face in July, Anthropic and Meta said their models also attempted to access third-party systems while in a testing environment not meant to have internet access. Kimi K3 from Chinese lab Moonshot AI also escaped its sandbox (see: Kimi K3 Bypasses Cyber Test With Answer From GitHub).

But sandboxes themselves are not the problem. The containment failures point to a mindset and design problem as much as a technical one.

Sandboxes are meant to keep potentially dangerous code away from real production environments. Keeping risks contained allows engineers to push the limits of powerful models and agents meant to automate workflows.

Heather Ceylan, CISO at Box, said the incidents illustrate that frontier model labs can’t take sandbox containment as a given – for each test, they must monitor containment layer controls and ensure those controls are tailored to the risk and the capacities of the agent being probed on the inside.

“These incidents caused security teams to shift their thinking, and I hope engineering teams too, to treat the agent as an adversary,” Ceylan said.

She added treating highly capable models and agents less like products and more as a threat contributes to a mindset that tightens monitoring and the need for shared responsibility.

Not all recent AI model breaches involve a rogue model escaping a sandbox. OpenAI’s GPT-5.6 Sol models did leave their isolated testing environment to hack Hugging Face’s systems, but the incidents involving Anthropic and Meta models were cases of misconfiguration.

Anthropic and Meta both worked with an outside evaluation company called Irregular. Frontier models from both companies were supposed to be undertaken without internet access. But, a mistake in the testing environment allowed the models to connect to the outside world.

Jose Lejin, a member of the technical staff at Salesforce, said in an email that agent and model evaluation could learn more from the security industry when designing test environments.

“The solution to this problem lies in taking a lesson from the security world, where isolation would be defined by a specific threat model and guarantee,” he said.

Lejin said a good start would be verifying if containment assumptions hold, much like how security teams do before deploying new code. Before a run, check for real network isolation, block connectivity to internal services, remove any API keys and other credentials, have a known and versioned baseline. And a kill switch.

No matter how much a team verifies an environment during a test, it’s still likely that a highly motivated and extremely capable AI model will try everything it can to complete tasks it’s instructed to do.

Sai Molige, senior manager of threat hunting at Forescout, said sandboxes should be viewed as a continuously verified security boundary.

“A sandbox is only as strong as its weakest integration; organizations should continuously test,” he said.

Continuous monitoring highlight’s a common thread among the AI sandbox escapes, said Box’s Ceylan. In many cases, evaluators did not see the agents acting out until it was too late.

“How do we not only just log this stuff to keep an audit trail, but how do we actively monitor an alert so we know that something bad happened to these agents? I think a lot of enterprises are still behind where they would want to be on this,” she said.

Enterprises and some frontier labs have already started using AI agents to help monitor their systems and evaluations. Ideally, these agents are meant to alert human researchers if there is a rogue agent. Ceylan noted that monitoring agents do have benefits. Still, for the foreseeable future, enterprises will be better off combining agents and humans to monitor AI systems.