sandbox

In depth

Least privilege

The reasoning to hold to is that of least privilege, long known in security and particularly well suited here. An agent receives exactly the access its task requires, and nothing more: this repository in read mode, this mailbox in write mode, this domain on the network. Everything else is absent, not forbidden. The difference is decisive because a model’s behaviour is not guaranteed: an instruction hidden in a document can make it attempt an action, and only the absence of the access prevents it from succeeding.

The four boundaries

There are four boundaries to set, and forgetting them amounts to having set none. The file system, by restricting the agent to a disposable working directory. The network, by allowing only the necessary destinations, since open outbound access is an exfiltration channel. Credentials, by supplying only tokens of narrow scope and short life. And resources, by bounding time, memory and number of calls, failing which a runaway loop is paid for on the invoice.

What makes it testable

The sandbox is also what makes an agent evaluable. Since its environment is rebuilt identically, a scenario can be replayed, two versions of the system compared and a correction verified. A run that acts directly on the real world is neither reproducible nor reversible, therefore not measurable. This property explains why the most advanced agents operate first in an isolated environment and carry their changes over to the real world only at the end, after validation.