There's a conversation developers keep having right now, and it's the same conversation in three different disguises.

"How do I run this AI agent without it nuking my repo?" "How do I try this MCP server without handing a stranger's code my shell?" "How do I check out this random GitHub project without installing half of it into my laptop?"

Three questions, one answer. All three are untrusted code running as you, on your machine, with your files and your tokens. That's the same trust class. It deserves the same response: a local sandbox you can install in one click.

Not a cloud API you pipe prompts into. Not a closed-source "trust us" runtime. A sandbox whose boundary is on disk, whose source is on GitHub, and whose kill switch is a window you close.

And as far as we can tell, nothing of that exact shape existed until now. nilbox is — to our knowledge — the first cross-platform GUI sandbox for AI agents, MCP servers, and untrusted apps: one installer for Windows, one for macOS, one for Linux, the same VM and the same boundary inside each. The source lives in the open at github, so the boundary is something you can read rather than something you have to take on faith.

TL;DR

• Agents, MCP servers, and unknown apps collapse to one problem: untrusted code running on your host as you.
• Cloud sandboxes don't fit desktop workflows; closed-source sandboxes don't fit the trust model you're trying to establish in the first place.
• The right shape is local + one-click: VM-grade isolation on your own machine, no round-trip to somebody else's cluster, with a readable source you can audit if you want to.
• nilbox ships that — to our knowledge, the first cross-platform GUI sandbox of this kind shipping real installers on Windows, macOS, and Linux. Debian-based VM, Zero Token boundary so the real API key never enters the sandbox, default-deny egress. Source is up at github.com/rednakta/nilbox for transparency.

Three workloads, one threat model

Stop thinking of these as three separate problems. They're one problem with three surfaces.

AI agents. The agent reads a web page, decides what to execute, and runs it. The "decision" is a language model's token stream. That means every external input — a README, a PDF, an HTML page, the output of a tool call — is a potential instruction. Prompt injection is not a rare exploit; it's how untrusted text is supposed to work against a model that was trained on "helpfully follow instructions." The agent is one injected sentence away from cat ~/.ssh/id_rsa or curl -X POST with your secrets.

MCP servers. MCP is great. It's also a protocol for letting an agent call code somebody else wrote and you didn't read. Two independent risks compound here:

1. The MCP server itself is a binary you just ran. If it's hostile, it's already inside your agent's trust boundary the moment you start it.
2. The responses an MCP server returns are text the agent will treat as tool output — and often, downstream, as context for the next model call. A malicious response is a prompt injection carrier with extra steps.

So MCP isn't a safer category than agents. It's an amplifier: more third-party code paths, more injection surfaces, more tokens in play.

Unknown apps. The oldest version of the problem. The curl | bash install for a CLI you want to evaluate. The GitHub repo a coworker forwarded. The binary in a Slack DM. The npm package whose name you half-remember. You want to try it without installing it — without writing it into your PATH, your dotfiles, your keychain, your browser session.

The threat shape is the same across all three. Untrusted code, your credentials, your network, your home directory. Same trust class, same answer.

:::warning[The framing trap]
It's tempting to build three different answers — a coding-agent sandbox, an MCP runner, a try-before-you-install jail. Don't. That's three half-finished security boundaries you have to keep in sync forever. One sandbox that all three run inside is less to maintain and less to get wrong.
:::

Why local matters

The "local" word is doing real work in the sentence above. Drop it and the sandbox stops being the right tool for desktop AI workloads — for reasons that have less to do with security and more to do with how a developer's environment actually works.

The dev environment is the work. Your editor, your terminal, your services on localhost, your shell aliases, your git checkout, the node_modules you spent eleven minutes resolving — that's what the agent should be touching. Cloud sandboxes ask you to ship a snapshot somewhere else, run the agent there, and reconcile the result back. A local sandbox just runs alongside you. The agent reads the repo you're already reading, edits the files you can see in your editor, and its work shows up as git diff lines you can review before they leave your branch.

Portability. A laptop is the developer's actual environment, full stop. The plane, the cafe, the captive-portal hotel wifi, the corporate VPN that won't let HTTPS out to certain hosts, the off-network box you log into from a different country — wherever the laptop goes, the work goes. A local sandbox goes with it. A cloud sandbox needs network reachability, an active account, and someone else's uptime.

Ownership of side-effects. When a local agent writes a file, the file is on your disk. When it edits a config, you git diff it before committing. When the experiment goes nowhere, you git stash and walk away. No remote session to clean up, no detached state on a server, no sync conflict between a cloud copy and a local copy. The agent's work is just work in your repo, treated like work you'd have done yourself.

The cloud-sandbox category has its place — hosted code interpreters, backend agent platforms, anything where the sandbox is part of a product you're shipping. That's not this post. This post is about the sandbox you need, sitting between your laptop and the things you don't trust yet.

(A small aside on the source side of things: nilbox's boundary proxy, VM image, and store manifest are all in a public GitHub repo. Not as a marketing pitch, just as transparency — if you're going to trust a security boundary, being able to read it beats taking someone's word for it.)

What a "good enough" local sandbox has to do

Four things. If any of them is missing, the sandbox is incomplete.

1. Kernel-level isolation. Not just namespaces. A container escape is a host compromise, and LLM output is the exact kind of untrusted code that historically finds those bugs. VM-grade (hypervisor, microVM, whatever you want to call it) is the minimum.
2. Token leak prevention. The real API key must not enter the sandbox. If it does, prompt injection and malicious packages both win — the kernel boundary doesn't protect a credential the process is authorized to read.
3. Default-deny egress. The sandbox should reach the LLM provider you actually use and not much else. An agent that can POST anywhere on the internet is one tool call away from exfiltration, regardless of how isolated the process itself is.
4. Covers all three workloads. Agent loops, MCP servers, and ad-hoc unknown apps have to run in the same environment, under the same boundary. If MCP servers require their own isolation mechanism, you'll skip it.

A fifth, softer requirement: one-click install on the OS you actually use. Security tools nobody runs are not security tools. If installing the sandbox is a multi-evening adventure in WSL, Docker daemons, or hypervisor kernel modules, your teammates will just run the agent on the host and hope. Hope is not a threat model.

How nilbox implements it

nilbox is built exactly for this shape: a local sandbox for agents, MCP servers, and unknown apps, with the source kept open in the same repo.

The sandbox itself is a Debian-based VM called Linux for nilbox. One-click install on macOS, Windows, and Linux — no WSL gymnastics, no Docker daemon, no "please enable virtualization in your BIOS" side-quest. The desktop app handles hypervisor setup, disk provisioning, and the shell handoff. When the window is open, the sandbox is running; when it's closed, it isn't.

To our knowledge this is the first sandbox of this shape that ships a real desktop GUI on all three platforms rather than an API or a CLI. Docker has a desktop app but isn't kernel-isolated; VMware and VirtualBox are cross-platform but not purpose-built for agents; cloud sandbox APIs are purpose-built but neither local nor GUI. Source is up at github.com/rednakta/nilbox if you'd rather read the boundary than take our word for it.

Zero Token Architecture is the second layer. The agent inside the sandbox never sees the real API key. You hand it a placeholder — literally OPEN_API_TOKEN=OPEN_API_TOKEN — and a boundary proxy substitutes the real token outside the sandbox, right before the outbound call leaves your machine:

If the sandbox leaks its environment — prompt injection, a malicious dependency, a curious env tool call — what escapes is a string that equals its own variable name. You can't call an LLM with it, you can't charge anybody's account with it, you can't even prove which vendor it was for. The full argument lives in the Zero Token Architecture write-up.

MCP servers run inside the same sandbox as the agent. That's the whole point of picking a single boundary — MCP isn't a separate trust domain, it's more code in the already-untrusted pile. When the agent talks to the MCP server, both are inside Linux for nilbox; when either talks to the outside world, both hit the same boundary proxy and the same egress policy.

Unknown apps work the same way. Install the app into the sandbox via the store or a shell session. Try it, poke it, let it install things in its own home directory. If it turns out to be hostile, the blast radius is a Debian VM on a disk image you can delete. Your host ~/.ssh, your keychain, your browser cookies — never in scope.

That's the full picture: one VM, one boundary, three workloads.

If you're wondering how these four break down in more detail, the sandbox comparison post walks through each category and where it holds up.

The verdict

One sandbox. Three workloads. Local, so it fits your desktop workflow and your file tree. Default-secure, so the agent inside doesn't have the real API key, can't POST to arbitrary hosts, and can't reach out of the VM into your home directory. The source sits on GitHub if you ever want to verify any of that for yourself.

If you've been running agents, MCP servers, or sketchy binaries directly on your host because the "real" solution felt like too much setup — this is the setup. It's a window you open on your laptop.

• github.com/rednakta/nilbox