The first time I let an AI agent loose on my PC, I sat and watched it type commands faster than I could read them. It installed packages, moved files, and edited configs on the same Windows install that holds my tax documents, my photo library, and a decade of work. The experiment ended the day it ran a cleanup command in a folder I never pointed it at. Nothing important was lost, but the lesson stuck: an agent runs with my permissions, and my permissions can do damage.
While not using agents is not an option, I wanted to stop trusting them with my real machine. It turns out Windows already ships with a disposable PC hidden inside it, a cage that builds itself in seconds and burns down the moment I close the window.
Giving the agent a throwaway PC
A clean Windows desktop that deletes itself when you close it
An AI agent with shell access can do anything I can do, and so can an installer I grabbed from a forum post. Antivirus won’t flag an agent that deletes the wrong folder, because nothing about that action looks like malware. There are other ways to run suspicious programs safely on Windows, but most of them mean setting up and maintaining a full virtual machine.
The solution was to run the agents in a sandbox, specifically Windows Sandbox. It’s a fresh Windows desktop that runs on top of Microsoft’s hypervisor with its own kernel, walled off from the host. When I close the window, everything inside the sandbox, including every file, install, and registry change, is destroyed. The next launch starts from a clean slate.
More importantly, compared to a VM, a sandbox boots in seconds and takes around 500MB of disk space once installed, because it reuses the host’s own Windows files instead of storing a second copy of the operating system. You can enable Windows Sandbox from the Features dialog, and it only takes a few changes and often a restart to start using it.
Windows Sandbox is only available on the Pro, Enterprise, and Education editions. If you’re on Windows Home, you’ll need a Windows Sandbox alternative instead.
Creating a .wsb file and locking folders to read-only
One small text file decides what the agent can see and touch
Out of the box, the sandbox is a blank desktop with internet access. That’s fine for poking at an installer, but for AI agents I wanted stricter rules, and Windows Sandbox reads those rules from a plain text file with a .wsb extension. Mine looks like this:
Disable
Disable
Enable
C:UsersTashreefProjects
C:UsersWDAGUtilityAccountDesktopProjects
true
Here’s what each of the lines is doing: Networking set to Disable cuts the sandbox off from the internet, so nothing inside can phone home or pull down something worse. ClipboardRedirection set to Disable stops anything from riding the shared clipboard between the sandbox and my desktop. ProtectedClient adds an extra AppContainer boundary around the sandbox process itself, which is a safety net in case something ever climbs the first one.
The MappedFolder block shows a folder from my real PC inside the sandbox, and with ReadOnly set to true, the agent can read my project files but can’t change a single one. If you’re wondering about that odd path, WDAGUtilityAccount is the built-in user account every sandbox session runs under, so mapped folders land on its desktop.
If you’re on Windows 11 24H2 or later, there’s also a wsb command-line tool that can script all of this: start launches a sandbox from a config file, list shows running sessions, exec runs a command inside, share maps a folder on the fly, and connect, ip, and stop handle the rest. Just be careful with wsb share –allow-write. This flag hands the sandbox write access to a real folder, and you should only use it when you mean it.
What it won’t protect?
The fine print that keeps the cage honest
The biggest gotcha is in the mapped folder feature. If you map a folder with write access enabled, anything the sandbox changes in it stays changed on your real PC after the session is destroyed.
Networking is the second trap. It’s on by default, so a sandbox launched from the plain Start menu shortcut, rather than a locked-down .wsb file, has full internet access.
There are other smaller limits worth knowing. The GUI runs one sandbox at a time. The wsb exec command can’t capture output, so you only get an exit code back, not what the command printed. Nothing survives between sessions, and the window itself can be fussy about sizing.
And some jobs are simply the wrong shape for a throwaway machine. Anything long-running, anything you want to keep, or anything that needs several machines talking to each other belongs in a real VM, Docker, or LXC, which are built for environments that stick around.
Sandboxing AI agent on my PC
Windows Sandbox favors work that’s short, risky, and repeatable, which is exactly what an AI agent session is. For instance, my setup is a handful of .wsb files on my desktop with network off, clipboard off, and the projects folder mapped and set to read-only. The agent gets a whole PC to mess up, and I get to close the window when I am done with it. Losing everything at close, which sounds like a weakness, is also the whole point of a sandbox.