An AI agent sandbox is an isolated execution environment that restricts the files, network resources, processes or credentials an agent’s code and tools can access. It limits the reach of an agent’s actions according to its configured isolation boundaries, but does not by itself determine whether a permitted action serves the intended task.
Agents run code nobody reviewed in advance: commands they composed, scripts in a project, packages they installed. A sandbox is the containment layer for that code. If the agent is manipulated by injected instructions, or simply makes a mistake, the sandbox limits how far the damage can travel.
What a sandbox restricts
A sandbox draws boundaries along four lines:
- Files. Which paths can be read and written. A common default lets an agent write only in its working directory.
- Network. Which hosts can be reached, usually through an allowlist, with everything else denied.
- Processes. What can be started, and with what system privileges.
- Credentials. Which secrets are visible inside the environment, and which are kept out or injected only for specific calls.
The isolation itself can come from several technologies, with different strength and cost: operating-system sandboxing of individual commands, containers that share the host’s kernel, micro virtual machines that give each environment its own kernel, and remote environments that run somewhere else entirely. The stronger the boundary, the less a compromise inside it can reach, and usually the more it costs to start and run.
Configuring a sandbox for an agent
A sandbox is only as narrow as its configuration. A few choices matter more than the technology underneath:
- Start from deny. Allow network access only to the hosts the task needs, and prefer specific hosts over broad domains.
- Restrict reads, not just writes. Default read access often includes the user’s home directory and credential files. An agent that can read a key can use it elsewhere.
- Keep credentials out of the environment. Inject narrowly scoped, short-lived tokens for the operations that need them, read-only where inspection is enough, rather than exposing a developer’s full set.
- Prefer short-lived environments for untrusted work. A persistent environment accumulates state, tokens and installed tools from one task to the next.
- Know what runs outside. Many agent products sandbox shell commands but run other tools, hooks or local servers outside the boundary.
What a sandbox cannot decide
A sandbox answers one question: can this action reach that resource? It does not answer whether the action should happen. Everything inside the boundary is, from the sandbox’s point of view, allowed.
That leaves a great deal possible inside even a well-configured sandbox:
- Pushing and publishing. If the agent can reach a git remote or a package registry to do its job, it can push or publish whatever it likes there.
- Using the credentials it holds. Whatever the credentials inside the boundary permit, the agent can do. Read-only credentials let it inspect an environment without changing it; credentials that allow changes let it change things. Which secrets are present and what those secrets permit are separate settings, and both matter.
- Editing the pipeline. Files in the working directory, including CI workflows and build configuration, are writable by design.
- Sending data through allowed hosts. An allowlist that permits a broad domain permits everything on it. Claude Code’s documentation warns that code inside its sandbox can potentially use techniques such as domain fronting to reach hosts outside the allowlist.
Sandboxes also have edges. In Claude Code, for example, the sandbox wraps shell commands, while built-in file and web tools, hooks and local MCP servers run outside it, governed by permission rules instead. The Model Context Protocol’s security guidance recommends running local servers in a sandboxed environment with minimal default privileges for exactly this reason.
Reach and appropriateness
Isolation and judgment answer different questions, and an agent needs both.
| Question | Answered by |
|---|---|
| Can the agent reach this file, host or credential? | The sandbox and the agent’s permissions |
| Is this action part of what the agent was asked to do? | Comparing the action with the agent’s declared scope and objective |
| Is this action costly or hard to undo? | Designating high-consequence operations |
| What did the agent actually attempt? | A record kept at the execution boundary |
A sandbox makes the first answer small. It does not touch the other three.
An example
The following is illustrative.
A coding agent runs in a microVM with no access to the developer’s home directory, network egress limited to the company’s git host and package mirror, and two separately scoped credentials: a repository token that can push to the project’s repository, and a deploy token for the staging environment only. It is asked to update a library version. It updates the library, rewrites the deployment script it finds alongside, pushes the change to the main branch with the repository token, and then runs the rewritten script against staging with the deploy token.
Every action was inside the boundary, and each credential did only what it was scoped to do. The sandbox did exactly what it was configured to do. What it could not do was notice that a library update had become a change to how the service deploys, pushed straight to a shared branch.
How Sentience Governor relates
Sentience Governor is not a sandbox. It does not isolate processes or restrict access. It runs alongside whatever isolation an agent has, evaluating each attempted action against the session’s declared scope and the operator’s designations, and recording the result while the action proceeds. Where a sandbox bounds what an agent can reach, Governor records how what it did inside that boundary related to the task.
Often confused with
Container. A container is one way to build a sandbox, sharing the host’s kernel. A sandbox is defined by what it restricts, not by the technology used.
Virtual machine. A virtual machine provides a stronger boundary with its own kernel. Micro virtual machines bring that boundary to short-lived agent environments.
Permission system. Permissions decide which tools or commands an agent may invoke. A sandbox limits what those tools can reach once invoked. The two overlap and are usually used together.
Where the concept stops
A sandbox limits the reach of an agent’s actions to its configured boundaries. It does not decide whether a permitted action serves the task, it covers only the processes it wraps, and its protection is only as narrow as its allowlists and the credentials placed inside it.