In plain terms
Children can build and wreck whatever they like in a sandbox, and the garden stays intact. An agent's sandbox is a sealed workspace with its own files, its own machine and limited or no network. Whatever the agent does there, by mistake or because it was tricked, stays there.
Why it matters
A sandbox is what makes it reasonable to let an agent run code and work unattended. It turns the question “can we trust the model?” into “what can this box reach?”, which is a question IT can answer and audit. The more autonomy you grant, the more the box matters.
Example
A data-analysis agent receives a spreadsheet and writes Python to analyse it. The code runs in a disposable container with the file, no access to the company network and no internet. When the session ends, the container is destroyed.
Most often confused with
Sandbox vs. Guardrails
Guardrails inspect content and can be fooled by content. A sandbox does not inspect anything: it removes the capability. A guardrail tries to stop the agent from sending data out; a sandbox with no network makes sending impossible. Strong systems use both.
Under the hood
Isolation is applied at several levels: file system (a scratch directory or container image, with read-only mounts for inputs), network (none, or an egress proxy with a domain allowlist), process (containers, gVisor-style kernels or microVMs such as Firecracker) and credentials (short-lived, narrowly scoped tokens, never the user's own). Design choices include what persists between sessions, how files get in and out, and resource limits. Usability drives the trade-off: every permission prompt removed by a sandbox is autonomy gained, and every hole opened for convenience is risk regained.