​Your AI Agent Sandbox May Not Be As Safe As It Sounds

Claude Mandy is Field CTO at Edera. A former CISO and Gartner analyst, he was most recently chief evangelist at Zscaler.

Few words in AI security get used as often as, or are used to reassure as much as, “sandbox.” Security teams hear a promise when they hear this word: If the agent goes wrong, whether an attacker steers it or it drifts off task, the damage stays in the box. Many products using this word can’t keep that promise.

When OpenAI disclosed in July that models under evaluation had escaped their sandbox and breached Hugging Face, there was no outside attacker. The models were chasing benchmark answers, and their route out was a package-install proxy.

In sandbox environments, containment must mean limiting reach and preventing breakout.

What A Sandbox Actually Promises

A sandbox is a strictly isolated environment where code runs without affecting the broader system. Malware analysts detonate suspicious files in them, and browsers isolate each web page so hostile scripts can’t reach your files. The boundary is the product.

The word also has a softer meaning: any non-production environment. Low consequence isn’t isolated; those environments often reach real networks and data. Many AI agent platforms isolate at the runtime layer, but permissive defaults like open network access leave customers closer to the second meaning unless they lock things down.

Why Containers Fail The CISO’s Sandbox Test

Most early adopters I work with started with agents in standard containers on shared clusters. Namespaces and control groups can separate each container’s view, but every container on the node shares the host’s kernel. That kernel is the real boundary, and runc flaws such as CVE-2019-5736 and CVE-2024-21626 have let code cross it. Hardening such as seccomp depends on the kernel policing itself.