Agent sandbox

The distinction that matters is between a filter and a boundary. A filter inspects a proposed action and decides whether to allow it; a boundary makes the action impossible regardless of what the program decides. Guardrails, classifiers and approval modes are filters. A container, a virtual machine or an operating-system sandbox with restricted network egress is a boundary.

Why a filter is not a substitute

A filter has to be right about every action, and it is judging text produced by a system that an attacker is actively steering. A boundary has to be right about one thing: what the process can touch. The asymmetry is why the recommendation from every serious prompt-injection researcher ends in the same place — run the agent somewhere it cannot do damage, and stop trying to predict which instruction is hostile.

Where filters fail in a specific way

A control that permits an action and then refuses its reversal is worse than no control, because it converts the agent's own correct response into an obstacle. This has been observed in practice: an automatic approval mode allowed a malicious process to be created and then denied the command intended to terminate it.

The same word, a different thing

In enterprise software the word also names a vendor-provided execution area inside a larger platform, and those are broken regularly — a sandbox escape is a standard vulnerability class. A sandbox is only a boundary while the code enforcing it holds, which is an argument for placing the boundary at the operating system rather than inside the application being defended.

What it does not cover

An assistant used during analysis is not a sandbox and not an evidence source. Material handed to a third-party tool has left the boundary, whatever the tool does with it afterwards.