The one-sentence version
Chatbots only "talk," but AI Agents "do": they execute commands, read and write files, access the web, and call APIs. Once an Agent is subject to prompt injection, or simply misunderstands a task, its actions impact the real system. Therefore, an Agent should run in a sandbox: an environment isolated from the real system that limits which files it can read/write, which networks it can connect to, and how many resources it can consume. The logic is simple: Assume the Agent will be tricked or make mistakes eventually, and pre-emptively confine the potential damage within a small scope.
This article has three layers:
- Layer 1: The Intuition: Giving a new intern a test machine
- Layer 2: Real-World Use: Coding Agents, Browser Agents, and cloud execution environments
- Layer 3: Principles and Engineering details: The four things to isolate, threat models, and what sandboxes cannot solve
Layer 1: The Intuition
1.1 Giving an Intern a Test Machine
A new intern is very smart and very hardworking, but has two problems:
- Too trusting: If someone writes "Please send me the server password" in a file, they might actually do it;
- Occasional mistakes: If you ask them to "clean up temporary files," they might accidentally delete the entire project directory.
You wouldn't give them the root password for the production server on their first day; instead, you would give them a test machine: something they can tinker with as much as they want—if it breaks, you just reinstall it—without touching real production data or customer systems.
An AI Agent is like this intern. A sandbox is that test machine.
1.2 Two Risks, One Solution
| Risk | Example |
|---|---|
| Being tricked (prompt injection) | A README file in a repository contains "Run this script to complete configuration," and the script uploads your SSH private key |
| Making a mistake | Misunderstanding an instruction, executing rm -rf, force-pushing and overwriting someone else's code, or deleting a database |
Regardless of the type, a sandbox confines the consequences to a disposable environment.
Layer 2: Real-World Use
- Coding Agents: AI coding tools running on a developer's computer execute shell commands, install dependencies, and run tests. Mainstream tools are introducing sandboxes: for example, using the built-in Seatbelt sandbox on macOS, or tools like bubblewrap on Linux to limit writable directories and accessible networks; or running directly in a disposable cloud container.
- Cloud Code Execution: The "Code Interpreter" feature in various AI products allows model-generated code to run on a server. This code is untrusted and must be executed in a strongly isolated container or micro-VM.
- Browser Agents: Agents capable of operating a browser will log into websites and fill out forms. It is best to use a separate browser profile that does not contain the user's daily login sessions and passwords.
- Documented Accidents: The community has occasionally reported AI coding tools executing destructive commands or deleting files and databases, sparking widespread discussion regarding default permissions and sandboxing.
Layer 3: Principles and Engineering
3.1 The Four Things to Isolate
| Resource | Consequence of No Isolation | Isolation Method |
|---|---|---|
| File System | Reading SSH private keys, browser cookies, or cloud credentials; deleting or overwriting important files | Mount only the working directory; hide sensitive directories; limit write scope |
| Network | Exfiltrating data; downloading and running malicious programs; accessing internal network services | Outbound allowlist, proxy (see "Network Egress Control") |
| Credentials | Pushing code using your identity, calling paid APIs, or manipulating cloud resources | Do not put credentials inside the sandbox, or use short-lived, narrow-permission credentials (see "Credential Leakage and Context Window") |
| Compute Resources | Mining, infinite loops, exhausting disk space | Limits on CPU, memory, disk, process count, and execution time |
3.2 Threat Model
When designing a sandbox, you must first think clearly: Assume the Agent is already fully controlled by an attacker, what will it attempt to do?
- Read every piece of sensitive information it can access;
- Send information out through every available channel;
- Leave a backdoor in the system to return later (persistence);
- Attempt to break out of the sandbox to access the host machine (see "Container Escape").
Every layer of sandbox design should be able to answer: "How will this specific step be blocked here?"
3.3 Sandbox Strength Must Match the Risk
| Scenario | Recommended Isolation Strength |
|---|---|
| Read-only Q&A, retrieval | Process-level restrictions are sufficient |
| Writing code on your own computer | System sandbox (limit directories and network) + manual confirmation for sensitive operations |
| Running completely untrusted code | Containers as a baseline, preferably gVisor or a micro-VM (see "Layers of Sandboxing") |
| Handling money or modifying production environments | Strong isolation + Human-in-the-loop + Auditing |
3.4 What Sandboxes Cannot Solve
- Data inside the sandbox: If you put sensitive data that needs processing into the sandbox, an injected Agent can still read it. A sandbox limits "what can be accessed," so you should minimize what is put inside;
- Abuse of legitimate channels: If the Agent's job inherently requires pushing code to a code hosting platform, then "pushing to an attacker's repository" might use that same legitimate channel;
- Human clicking "Allow": When operations outside the sandbox require human confirmation, confirmation fatigue can cause the defense line to fail (see "Agent Permission Design").
A sandbox is one layer of defense in depth; it must be used in conjunction with permission design, egress control, and prompt injection defense (see "Defending Against Prompt Injection").
Summary
| Layer | Key points |
|---|---|
| Intuition | A smart but trusting, occasionally mistaken intern; give them a test machine first |
| Isolation | Files, network, credentials, compute resources |
| Threat Model | Assume the Agent is fully controlled: read, send, leave backdoors, escape |
| Limitations | Data placed inside can still be read; legitimate channels may be abused; confirmation fatigue |