How do you sandbox an AI agent that runs shell commands?

Run an agent's shell commands inside a disposable, isolated environment that holds no real credentials, has a narrow filesystem and network, caps resources, and is thrown away after the task. Assume the model will sometimes run something unintended, whether through error or hostile input, and limit the damage in advance.

Why is a shell different from other tools?

Most tools do one narrow thing. A shell can do anything the user account can. OWASP calls the underlying problem excessive agency: a model given more functionality or permissions than its task needs. If text the agent reads can steer its commands, as with prompt injection from a web page or an issue comment, the shell turns text into actions on your machine.

So the question is not whether the agent is well behaved. It is what the worst command can reach.

Which isolation layers exist?

Containers use kernel features. Docker's security documentation describes namespaces, which stop processes seeing others, control groups, which limit resource use, and a restricted default set of Linux capabilities. It also warns that the Docker daemon needs root unless you opt into rootless mode, and that only trusted users should control it. Never mount the Docker socket into an agent environment.

A syscall filter such as seccomp restricts which system calls a process may make, based on call numbers, per the Linux manual page. It narrows the attack surface without a separate kernel.

gVisor takes a third approach. Its documentation says it implements a Linux like kernel in userspace, written in Go, and provides an OCI runtime called runsc, so sandboxed containers use their own application kernel and reduce the risk of container escape. It is distinct from both a syscall filter and a virtual machine in the everyday sense.

A virtual machine or microVM per task gives the strongest boundary of the options here, at higher cost. Pick by the risk of the task.

What should the environment contain?

Only what the task needs. A copy of the code, not the whole disk. No cloud credentials, SSH keys or tokens, or a short lived credential scoped to one action. A read only root filesystem with a scratch directory. Network off by default, with an allow list for package mirrors if installs are needed. CPU, memory, process and time limits.

A constructed example

An agent fixing a failing test reads an issue comment that says to run a command fetching a script from a remote address. In an unsandboxed setup, that runs on a developer laptop with cloud credentials in the environment. In a sandbox with no network and no secrets, the fetch fails, the agent reports the error, and the log shows the attempt for a human to review.

What to do

1. Run agent commands in a disposable container, gVisor sandbox or microVM, never on a developer host.
2. Keep credentials out. If one is needed, issue a short lived, narrowly scoped one for that task.
3. Mount code read only where possible and give a scratch space for writes.
4. Deny network by default and allow named destinations only.
5. Drop capabilities, use a seccomp profile, run as a non-root user, and never mount the container runtime socket.
6. Set CPU, memory, process count and wall clock limits.
7. Destroy the environment after the task, and keep logs of commands and outputs outside it.
8. Require a human step for anything that leaves the sandbox: pushes, deployments, messages.

Safeguard's MCP Guardrail and guardrails let you control which tools an agent can reach, and its policies and gates add checks before changes land. Neither replaces isolation of the process itself.

Quick check

Sources

• Docker, Docker Engine security
• gVisor documentation
• Linux manual page, seccomp(2)
• OWASP GenAI, LLM06 Excessive Agency

Last reviewed: 18 October 2026.