When working with software, AI agents, or files downloaded from the internet, one of the most common fears is breaking something on your system, getting infected with malware, or leaking sensitive data almost without realizing it. You don't have to be paranoid: a single failed execution can delete a database, ruin a deployment, or introduce a bug into your system.
The good news is that today you have several ways to create an isolated environment where you can test things without risking damage , and many of them are integrated into the operating system itself or into platforms designed for code agents. We call this "sandboxing": running code inside a kind of controlled bubble, so that even if something goes wrong or is malicious, the damage is contained.
What is manual sandboxing without additional software?
In security and development, talking about a sandbox means precisely defining what a program or agent can access while running . It's not just "running it somewhere else," but defining clear boundaries: what files it can see, what processes it can launch, whether it has network access, what credentials it can use, how long that environment lasts, and what happens to its state when it terminates.
The phrase "manual" and "without additional software" is misleading. In many cases, you can rely on features already included in your operating system or your own development platform , such as Windows Sandbox, Linux primitives (Landlock, seccomp), or macOS mechanisms. You don't need to install a complete virtualization suite, but you do need to learn how to activate and manage these built-in mechanisms so they act as a barrier between the code you want to test and your actual machine.
Why do code agents need isolated environments?
Modern coding agents are no longer simple chat-like assistants that suggest code snippets: they are runtime environments coupled to a language model . They can read your repository, edit files, execute terminal commands, install packages, build containers , communicate with external APIs, and even open browser sessions.
Platforms like Claude Code, some of LangChain's "Deep Agents," and specific sandboxes distributed by Docker and other tools explicitly describe how these agents operate on real file systems, launch threads, and delegate tasks to specialized sub-agents . In other words, they're quite similar to a junior developer with access to your tools… only automated and very fast.
In this context, the main security question shifts from "Does it respond correctly to the prompt?" to "What is its scope when it makes a mistake, is misaligned, or has been tampered with?" If a model can, for example, run pytest, install npm packages, manage branches, or inspect a compilation failure, it is just a few steps away from touching deployment scripts, modifying Git hooks, or exfiltrating secrets to a remote service.
The easy answer is often to require human approval for every command. That helps, but it has a recurring problem: approval fatigue . In environments where engineers launch many agents or workflows in parallel, the sheer volume of requests means that almost everything ends up being approved without careful reading. When more than 90% of permission requests are automatically approved, that mechanism ceases to be a true security control and becomes pure ceremony.
That's why sandboxes matter so much: they don't make the model infallible or fix instruction injection , but they do reduce the "burst radius" of its errors. If the AI ​​messes up or someone manages to hijack its instructions, the damage is confined within the isolated environment instead of spreading directly to your production system or your laptop.
Main limitations of a code agent sandbox
A serious sandbox for coding agents relies on several types of boundaries, not just "another directory" or "another container." Each covers a different aspect of risk, and understanding them is essential for effective manual sandboxing with your existing resources.
File system boundary
The first step is to decide which directory tree the agent can see and modify . In a properly set up sandbox, the agent should only be able to read and write to the workspace or volumes you explicitly mount for it. The rest of the system (user home directory, system paths, other projects) should be kept out of its reach.
Agent frameworks and sandbox platforms make this very clear: the sandbox is the barrier that prevents access to host files beyond what is shared . In microVM-based models, the rule is even stricter: only the directory you mount (often with read-write access) crosses the boundary between the virtual machine and the host. Everything else remains inaccessible unless you open it.
Process boundary and kernel
The second key limitation is what the agent sees at the process and kernel levels. If, within the isolated environment, it installs services, starts containers, or launches threads , all these actions must remain encapsulated, without sharing processes or a bare kernel with the host.
Many robust sandbox implementations rely on microVMs or lightweight virtual machines with their own Linux kernel, reinforced with seccomp, cgroups, namespaces, and jail techniques. Others use layers like gVisor or Kata Containers to interpose a virtualization or emulation layer between the isolated process and the node's kernel. The basic idea: if someone exploits something inside, the jump to the host is much more difficult than in a simple shared-kernel container.
Network boundary
Code agents are often very "network-hungry": they want to install dependencies, consult documentation, call LLM APIs, access remote repositories, or even browse the web. Without a clear policy, an "isolated" environment can end up being a fantastic data exfiltration tunnel.
Therefore, more and more platforms are implementing a default denial policy for outgoing traffic : HTTP/HTTPS are blocked except in certain cases, TCP/UDP/ICMP are restricted, and, very importantly, access to private ranges and local addresses is prohibited. Communication is only permitted with hosts or domains explicitly included on an allowlist, and often through a proxy controlled by the host.
Credentials limit
It's of little use to have the agent locked down if, inside its cage, it can read your API keys, deployment tokens, or database secrets. The modern design of many sandboxes involves never injecting raw secrets into the isolated environment , but instead having a proxy on the host add the credentials to the headers of the HTTP requests that the sandbox wants to send.
With this approach, the process within the sandbox uses the credentials but never sees them . This greatly reduces the impact of a potential agent hijacking. However, the moment you store a key in a file or environment variable within the sandbox, that advantage disappears: the model can then read it directly, and any instruction injection can instruct it to filter it.
Life cycle boundary and state
Finally, there's the time constraint: what is preserved and what is destroyed when the environment stops . Agents are not point-in-time processes: they read, compile, debug, open multiple hypotheses, abandon some, resume others… This requires a runtime that manages state intelligently: fast startup, suspension, snapshots, branching, and safe deletion.
Some platforms offer in-memory snapshots, pools of pre-warmed environments, and branching functions from a specific state (for example, an already authenticated browser or a partially resolved dependency graph). This makes all the difference between a usable agent—one that can iterate interactively—and an agent that takes ages to repeat the same setup over and over again.
Sandboxing implementations on macOS, Linux, and Windows
Beyond commercial products, many teams have chosen to leverage existing isolation primitives in operating systems to build their own code agent sandboxes, without needing to add heavier layers. The key is understanding what each platform brings to the table.
Sandboxing on macOS: Seatbelt and dynamic profiles
On macOS, several models have been evaluated: App Sandbox, containers, virtual machines, and Seatbelt. The first options have significant drawbacks for a development environment: App Sandbox requires signing every binary that the agent could execute and inherits the trust of the signature, which opens up vectors of abuse if the agent itself generates or modifies binaries; containers are limited to the Linux ecosystem; traditional VMs add significant boot latency and memory consumption.
The practical alternative has been to rely on Seatbelt, accessible via sandbox-exec . Although Apple has marked it as obsolete for years, it is still used by critical applications like Chrome . It allows commands to be executed under a sandbox profile that restricts the behavior of the entire descendant process tree.
This profile defines permissions with great granularity: it can filter specific syscalls and read or write operations on specific files and directories , using a unique policy language. Some implementations generate this policy dynamically at runtime, combining workspace configuration, administrator policies, and user ignore files, so that the agent has room to maneuver without accessing potentially dangerous areas.
Sandboxing on Linux: Landlock and seccomp
Linux offers both more flexibility and more work: the kernel exposes primitives like Landlock and seccomp , but it is the responsibility of the user space to combine them into a coherent and manageable sandbox.
Instead of relying solely on external projects, some teams choose to use seccomp directly to block system calls deemed dangerous and Landlock to restrict filesystem access. A common approach involves mounting the user's workspace on a filesystem overlay and replacing files marked as ignored with special copies protected by Landlock , so that the isolated process cannot read or modify anything you want to hide.
The slowest part of this approach is usually locating and remounting all those files, since Linux doesn't offer an easy way to find the full path of a file within a seccomp-bpf filter . Even so, the result is a fairly refined sandbox: the agent can work with its project tree while the prohibited paths are, de facto, excluded from its environment.
Sandboxing on Windows: relying on WSL2
On Windows, the story is different. Creating a general-purpose native sandbox is much more complicated because many existing isolation primitives are designed for browsers or other very specific software , and don't mesh well with versatile development tools.
A practical solution is to run a Linux sandbox within WSL2 . This way, you reuse Linux's isolation tools (Landlock, seccomp, namespaces, etc.) on a virtualized base that isolates the development session from the Windows host. In parallel, there is ongoing work with Microsoft to expose new primitives that will eventually allow for more native sandboxing for development tools.
Windows Sandbox: an isolated space integrated into the system
For those using Windows 10 or 11 Pro, Enterprise, or Education editions, there's a particularly interesting tool: Windows Sandbox . It's a lightweight virtual machine integrated into the system itself that allows you to run untrusted applications or suspicious files in a disposable environment.
The idea is simple: opening Windows Sandbox starts a temporary, clean Windows desktop, just like a fresh installation . Everything you copy or install within it—programs, documents, scripts—exists only in that instance. If you close the window, the environment is destroyed: software, files, and system state are discarded, and the next time you open Windows, you'll start from scratch.
Key features of Windows Sandbox
This feature comes with several very useful properties for manual sandboxing without relying on third-party tools:
- Part of WindowsEverything you need is already included in the compatible editions (Pro, Enterprise, Education). You don't have to download images or maintain external virtual machines.
- Disposable and pristineEach run is as clean as a fresh Windows installation. Nothing you do inside is saved to your device once you close the environment.
- Safe by designIt relies on hardware-supported virtualization (Hyper-V) to isolate the sandbox kernel from the host kernel. It uses the Microsoft hypervisor to keep the two worlds separate.
- Efficient: the startup is fast, in a matter of seconds, with intelligent memory management and virtual GPU support, using fewer resources than a traditional VM.
Technically, it behaves like a small, disposable Windows virtual machine , perfectly valid for testing installers, visiting dubious websites, or opening email attachments that you don't trust to run on your real system.
Practical scenarios for using Windows Sandbox
There are several typical scenarios where Windows Sandbox shines as a simple manual sandboxing solution:
- Try unknown softwareWhen you download an application or executable from the internet and you are not sure of its origin, you can first install it within Windows Sandbox and see how it behaves without risk to your computer.
- Safer web browsing: for Visiting potentially dangerous websites, malware or phishing sitesYou can open your browser inside the sandbox. If something goes wrong, simply closing the window will remove any trace.
- Opening untrusted attachments and filesIf you receive a suspicious attachment or a ZIP file that doesn't inspire confidence, you copy it to the sandbox, open it there, and once reviewed, decide if it's worth extracting anything to your real system.
- Demonstrations and specific tool testsIt's perfect for creating software demos, testing preview versions, extensions, or add-ons without cluttering your main installation.
- Maintain multiple separate development environmentsYou can create separate, isolated spaces for each language stack or version, for example a sandbox for each version of Python and its dependenciesso that the experiments don't interfere with your stable environment.
Requirements and licenses for using Windows Sandbox
Not everyone can use Windows Sandbox, but it's already available in many professional environments. To enable it on your computer, you need:
- Compatible Windows EditionWindows 10/11 Pro, Enterprise, Pro Education/SE or Education. The Home edition is not supported.
- Virtualization supportIt is essential to have the virtualization functions in the BIOS/UEFI (Intel VT-x, AMD-V or equivalent).
- Minimum resources: at least 4 GB of RAM (although 8 GB is recommended), 1 GB of free disk space —preferably SSD— and a minimum of 2 CPU cores (ideally 4 with hyperthreading).
- updated operating systemStarting with certain builds (for example, Windows 10 build 18305 and later, and modern builds of Windows 11). On ARM64, compatibility arrived with more recent builds.
Regarding licensing, the Pro, Enterprise, and Education editions include the right to use Windows Sandbox without needing to pay for additional virtualization software licenses. Simply activate it and you're good to go.
How to activate Windows Sandbox without extra tools
To get it up and running, you don't need anything outside the system itself:
- Open the Start menu and look for the option "Turn Windows features on or off".
- In the list of features, mark Windows Sandbox and confirm.
- Restart your computer when prompted.
- After restarting, search for "Windows Sandbox" in the Start menu and run it.
If you prefer a more technical approach, you can also enable it using PowerShell with the command `Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online` , provided you have administrator privileges. Once enabled, the sandbox will always be available whenever you need that secure "second machine".
Configuration and customization files
Windows Sandbox supports simple configuration files that allow you to customize certain environment parameters : for example, mounting host folders as read-only or read-write, disabling the network, running scripts at startup, etc. These files are available starting with specific builds of Windows 10 and 11.
In practice, this capability helps you create sandbox "recipes": one configuration with network disabled to open malware , another with a project folder mounted in read-only mode to review files, or a configuration geared towards software testing with certain tools pre-installed in the base image.
How to teach AI agents to use the sandbox correctly
A sandbox is only truly effective if the code agent itself understands the environment it is operating in and knows when it can operate freely and when it needs to request further permissions or human assistance.
To achieve this, many platforms have had to thoroughly revise the infrastructure that describes the tools to the model. For example, updating shell tool descriptions to clearly explain:
- What restrictions does the sandbox impose? (access to the file system, git, network).
- How can the agent request an upgrade of permits when something fails due to a lack of privileges.
- Which types of commands are most likely to be blocked?
These changes don't always work perfectly the first time: they usually require extensive manual testing of real deployment flows , analyzing where the model's expectations break down, and adjusting prompts and instructions. By measuring behavior with and without a sandbox in internal benchmarks, failure patterns are identified, such as agents that repeatedly execute the same command that the sandbox blocks instead of understanding that they need to request additional permissions or modify their strategy.
A practical improvement is to display the specific reason for the sandbox-imposed block in the tool's results and even explicitly suggest that the agent request elevated privileges when appropriate. This small hint drastically reduces blind retries and improves recovery from sandbox-related errors, both in offline testing and production.
To ensure that sandboxing doesn't degrade the user experience, many companies have opted for a phased rollout , gathering internal and external feedback before enabling it by default. The data is usually clear: a significant fraction of requests (for example, around a third) end up being executed within the sandbox on compatible platforms, with notable reductions in both the time spent requesting approval and manual review.
Isolation models and real-world safety lessons
In practice, there is no single "perfect sandbox." There are important differences between a shared kernel container, a gVisor-type sandbox, a microVM, and a full VM . This distinction matters when we talk about allowing the agent to run Docker, install arbitrary packages, or even launch complex browsers and threads.
Historical security incidents underscore the importance of choosing well: vulnerabilities such as CVE-2019-5736 or CVE-2024-21626 , which allowed jumping from the container to the host or manipulating system binaries, demonstrate that when your limit of trust is a container runtime on the host kernel, a severe bug can bring down the entire barrier.
This becomes even more problematic with coding agents because they often execute untrusted compilation code, build images, install unaudited dependencies , and generally handle highly heterogeneous inputs. Furthermore, the pressure to "give them more power" is strong: if they cannot run certain tools, they often fail to complete their tasks.
Therefore, many modern agent sandbox designs tend to reinforce the boundary using microVMs or lightweight VMs , even at the cost of slightly increased complexity. This reduces direct dependency on the host kernel and provides an additional layer of isolation against container escapes. In multi-tenant environments or large-scale execution of untrusted code, gVisor or Kata Container occupy a middle ground, trading compatibility for greater isolation.
Human approvals, political approvals, and sandboxes: how to fit it all together
One recurring pattern is that perennial permission requests don't scale well . In demo mode, it's fine for the agent to request permission before accessing a file. However, in production, with semi-autonomous workflows and numerous small actions, the "click OK for everything" model becomes a sieve.
The more mature approach combines several layers:
- Strong sandbox to protect the host and delimit the execution environment.
- Restrictive network policy to control which endpoints the agent can talk to.
- Credential management via proxyso that the model uses them without seeing them.
- Versioned configurations at the project level (permissions, hooks, external servers) so that teams have a single source of truth in the repository.
- Read-only subagents for exploration and planning, leaving the writing actions to more controlled instances.
- Human approval reserved for truly delicate actions: publishing packages, infrastructure changes, rotating secrets, or pushing to critical branches.
Furthermore, it's important to consider the control surface you give the agent through your own configuration files, plugins, and skills. Guides from providers like OpenAI clearly warn that exposing open catalogs of capabilities or allowing anyone to define powerful instructions within the repository can lead to data leaks or destructive actions if an attacker manages to inject malicious instructions into README files, issues, documentation, or sample files.
In a sound design, the sandbox isn't seen as a magic trick that fixes security overnight, but rather as another boundary within an architecture that includes policies, independent verification, careful secret management, and configuration reviews . Thus, even assuming that one day the agent reads and obeys malicious instructions, the system is designed to limit the impact: no direct access to keys, no open network, and no ability to surreptitiously modify scripts that you then run on your real machine.
Ultimately, setting up a good manual sandbox without relying on extra software comes down to maximizing the capabilities of macOS, Linux, and Windows —Seatbelt, Landlock, and seccomp profiles, Windows Sandbox, and WSL2—combined with clear network rules, credentials, and environment lifecycle management. Add to that trained agents who understand these restrictions, reasonable policies, and some discipline regarding what they're allowed to access in your workspace, and you can test risky code, tools, and files with much greater peace of mind, knowing that if something goes wrong, the problem will stay within the sandbox and won't compromise your system or critical data. Share this information so more users can learn about it.