Agent sandboxing

Agent sandboxing is the practice of running an AI agent inside an enforced boundary that limits its filesystem, network, credential, and side-effect access, so that a mistaken, hallucinated, or hijacked action stays contained instead of reaching the wider system.

How it works

A sandbox wraps the agent's execution in a boundary enforced below the model, by the operating system or a container, so the limits hold regardless of what the agent decided to do. It bounds four things: the filesystem, restricting which paths the agent can read and write; the network, routing traffic through an allowlist to limit which destinations the agent can reach; credentials, keeping secrets out of the agent's reach or injecting them through a proxy the agent never sees; and side effects, blocking actions that would let the agent change its own limits. The boundary is distinct from two things it is often confused with: a permission scope is the grant of which tools and data the agent may use, and a runtime gate is the check that allows or denies a specific action, while the sandbox is the lower-level boundary the operating system enforces on the resource paths it mediates, which still holds when a grant was too broad or a gate was passed. Because it sits below the agent's reasoning, a sandbox can contain an action that reaches outside its boundary, including one the agent was tricked into by injected content, though an action the boundary already allows still runs. The cost is that a boundary tight enough to be safe also blocks legitimate work, so the work is tuning what the agent genuinely needs against what it is able to reach.

Why it matters

An agent that only writes text is low-stakes, but an agent that runs commands, edits files, and calls tools can cause real damage from a single wrong step, and the more autonomous the run the less a human is watching each action. Sandboxing is what makes that autonomy survivable, because it backs the agent's probabilistic judgment with a boundary that is not, at least for the paths that boundary covers, so the question shifts from whether the agent will behave to what it can reach if it does not. This matters especially under prompt injection, where the agent can be turned against its task by content it merely read, because a sandbox contains the hijacked action whether the bad instruction came from a bug or an attacker. The honest limit is that a sandbox bounds reach, not intent, since inside its boundary the agent can still do the wrong allowed thing, so isolation is one layer beside permission scope, runtime gates, and review rather than a substitute for them. A sandbox is also only as good as its configuration, and the common failures are quiet ones, an over-broad mount or an open network path, that leave the boundary looking present while the blast radius stays wide.

In practice

An agent runs in continuous integration with permission to edit code and run the test suite. It is sandboxed so it can write only inside the checkout, reach only the package registry it needs, and never read the credentials sitting elsewhere on the machine. When a step goes wrong, whether from a reasoning error or an instruction injected through a dependency it pulled, the damage is bounded to the working copy rather than the surrounding system, because the agent never held the access the worse outcome would require. The boundary did the work that watching the agent could not, since no one was reviewing each command in an unattended run.

Practical considerations

The four dimensions fail independently, so a sandbox that locks the filesystem but leaves network egress open still lets an agent send data out, and credentials left readable in a default location undercut the rest of the boundary. Network is the subtle one: allowing a single broad destination can reopen an exfiltration path the filesystem limits were meant to close, and an allowlist that filters by hostname without inspecting encrypted traffic can be circumvented. Where a sandbox sits depends on the run, since a local developer session, an unattended job in continuous integration, and a hosted execution environment each carry a different threat model and a different tightness. A credential proxy is the durable pattern for secrets, because an agent that never holds a credential cannot leak one even if it is compromised. Escape hatches deserve scrutiny, since a setting that lets a failed command retry outside the sandbox quietly turns the boundary off at the moment it was most needed. The discipline is to grant the narrowest reach the task genuinely needs and to verify the boundary by what the agent cannot do, not by trusting that the configuration looks right.

Defined by Ready Solutions AI