Vocabulary

Why a Sandbox Is Necessary but Not Sufficient

Isolation is one of the oldest and most reliable ideas in security. Put the risky thing in a box, restrict what the box can reach, and whatever goes wrong stays contained. For AI agents, this usually means a test environment with no internet access, a limited toolset, or a strict network boundary.

It is a genuinely strong first layer. The problem is not that isolation is a bad idea. The problem is that isolation is a single boundary, and a single boundary has exactly one job: hold.

If it holds, everything downstream is fine by default, because nothing downstream was built to catch a failure that was not supposed to happen. If it does not hold, even briefly, there is often no second layer positioned to notice, because the architecture assumed the first layer would not need one.

This is not a hypothetical concern. Agents doing capability research or red-teaming are often given deliberately more latitude inside their sandbox, since understanding what a model can actually do sometimes requires reducing the restrictions that would mask the result. That is a reasonable research tradeoff. It also means the isolation boundary becomes the only thing standing between an experiment and a production system.

A sandbox answers “can this stay contained.” It does not answer “should this specific action be allowed to happen.” Those are different questions, and a mature architecture needs both answered, not just one.