What is an agent sandbox?

An agent sandbox is an isolated environment that runs the code an AI agent writes, and limits what that code can reach. It sits between the agent and everything else: your files, your network, your systems. A permission prompt asks a person before each action. A sandbox draws the boundary once, and the agent works freely inside it.

A sandbox is not the same as a container, which is one way to build one. Nor is it a guardrail on the model. A guardrail tries to keep the model from writing harmful code. A sandbox assumes it sometimes will.

An AI agent that runs code runs something nobody reviewed. The model wrote it a moment ago, from a task and whatever it read along the way. A ticket, a web page or an attached file can carry instructions the model follows by mistake. Prompt injection has no filter you can rely on, so the code has to be safe to run even when the agent is steered.

NVIDIA’s glossary counts a secure runtime among the parts of an agent: “a dedicated, policy-enforced environment where an agent executes its logic, runs generated code, and interacts with external tools.”

A sandbox also saves a person’s attention. Anthropic reported that in its own use, sandboxing Claude Code cut permission prompts by 84%. Fewer prompts leave less room for approval fatigue, where a person stops reading what they approve.

Anthropic’s engineers put the core of it in one line: “effective sandboxing requires both filesystem and network isolation.” Without the first, the code can read keys and change system files. Without the second, it can send what it read anywhere. A complete sandbox limits six things:

• Filesystem. Which paths exist, and which of them can be written.
• Network. None, or only hosts you named, enforced by something outside the sandbox.
• Processes. Whether the code can start other programs, and whether the same limits hold for them.
• Time. A wall clock per run, so a loop that never ends stops.
• Memory and output. Bytes held and bytes printed. What a script prints is what the model reads next, so output is also a budget for its context.
• What it can write back. The one way out. A change should leave as something a person can read and approve, not as a write to the live system.

Five approaches are common. They differ in where the wall stands, and in what the code inside still shares with the host.

• Containers. The code runs as a process with its own view of files and network, on the host’s kernel. A container starts fast and runs any program. A flaw in that shared kernel is a way out, which gVisor’s documentation calls a container escape.
• gVisor. An application kernel, written in Go and run in user space, sits between the code and the host. The reason, in its documentation: system interfaces move “into a distinct, per-sandbox application kernel in order to minimize the risk of a container escape exploit.” It is slower for code that makes many system calls.
• MicroVMs. Each sandbox gets a small virtual machine with its own kernel. Firecracker runs in user space and uses Linux KVM to create them. Its site gives a boot time under 125 ms and under 5 MiB of overhead per VM. It needs a host with KVM, and one VM per session to manage.
• Operating system restrictions. A process limits itself with features of the kernel. Landlock lets an unprivileged process restrict its own filesystem and network access, and that of its children. Anthropic’s sandbox for Claude Code uses bubblewrap on Linux and Seatbelt on macOS. There is nothing new to run, but the code still runs on the host, with whatever the rules leave open.
• Interpreters with a virtual filesystem. The language runs inside the host application, over files the host hands it. There is no process to escape into, and a command the interpreter never implemented does not exist. The trade is that only the commands and libraries it implements are there. Computerwelt, below, is one.

The approaches stack. A container under gVisor, or an interpreter inside a restricted process, puts a second wall behind the first.

• A blocklist instead of a boundary. A list of refused commands has to stay complete forever. A capability the sandbox never had has nothing to refuse.
• Credentials inside. A token in the environment is a token the code can read. For Claude Code on the web, Anthropic keeps git credentials out of the sandbox, and a proxy outside attaches them to requests it has checked.
• The network left open for convenience. A route for a package download is also a route out for data.
• Limits that stop quietly. A run cut short that returns what it had looks like a whole answer to the model. A limit should raise an error the model can see.
• Writes that apply themselves. If the code can change the live system directly, the sandbox protects the host but not your data.
• Shared sessions. Two users in one sandbox can read each other’s files and edits.

Ask these of any agent that runs code, ours included:

• What can the code reach that you did not hand it?
• Is the network off, or limited to hosts you named by something outside the sandbox?
• Where do the credentials live?
• Can the code start a process, and do the limits follow it?
• What happens at a limit: an error, or a quiet stop?
• How does a change leave: as a direct write, or as a diff a person approves, bound to exactly what they read?
• Is each session separate from every other?

Sudo, the admin assistant in Curiosity Studio, works in a sandbox built on Computerwelt. It is a bash and a Python interpreter that run inside the server’s own process, over a virtual filesystem. The files in it are the workspace configuration: endpoints, AI tools, agents and schemas, as the export writes them.

Nothing is forked or executed. curl, wget, ssh and git are absent, not refused. The one exception is a headless browser, off until an administrator allows named hosts. The only paths are the mounts the session was given. The graph is read only, as the administrator in the chat.

The session keeps an overlay of what Sudo wrote or deleted, and reads everything else from the live workspace before every command. build compiles each changed file. commit stages a snapshot of the diff and stops. A person approves it, and the approval is bound to the commit they were shown.

The same machinery is open to your own assistants: a sandbox is an AI tool whose code returns an ISandbox. A script gets 60 s and 256 KB of output by default, and 300 s and 4 MB at most. Python imports a short, closed list of modules, and there is no process to run a binary in. The sandbox page shows a session, and the paper Inside Sudo covers what an approval binds.