Jailbox: Network-Restricted, Hardened Linux VMs for AI Agents and Untrusted Code · Ertuğ Karamatlı
↓Skip to main content
Table of Contents
TL;DR: Between supply chain attacks and increasingly capable AI coding agents, you’re already running code you’ve never read, with your own privileges. Instead of sandboxing individual tools, put the whole development environment (editor, agents, containers, and all) inside a plain KVM VM that can reach the internet but has no route to the host, the LAN, or any other private address. The companion tool kvm-jailbox creates a hardened sandbox VM with one command and verifies the network boundary actually holds. To stress-test that claim, I gave an AI agent root inside one and told it to break out; it couldn’t.
Introduction #<br>Building software today is an exercise in trust: the packages you depend on, the AI agents you delegate to, and the tools you build with. Each has quietly become an attack vector of its own. The next few sections walk through all three, then make the case for containing them behind a hard boundary.
Supply chain attacks #<br>In 2016, unpublishing an 11-line npm package “broke the internet”. left-pad was a dependency countless projects relied on without realizing it, and its removal broke builds at Facebook, PayPal, Netflix, and Spotify. That wasn’t an attack, just an author deleting his own code. But it exposed the same fragility a supply chain attack exploits: how much trust we place in code we’ve never looked at, pulled from people we’ve never met.
Over the last few years, we’ve seen a significant rise in supply chain attacks that specifically target software developers. A sampling: a compromised release of LiteLLM (3M downloads a day) that exfiltrated cloud and CI/CD credentials, the Hades campaign that booby-trapped two dozen PyPI packages to run at interpreter startup, the mass compromise of debug, chalk, and 16 other npm packages, a backdoor in Axios (100M+ weekly downloads), and npm waves that harvested enterprise developer credentials.
Your dependencies have their own dependencies, so package managers like pip and npm quietly leave you with hundreds of them across long chains. An attacker’s foothold can appear anywhere in that chain: a hijacked maintainer account, a compromised build, a package name you mistype. All it takes is one malicious package, and your machine gets compromised.
AI agents #<br>The growing capability and reach of AI coding agents amplify the risk. In early 2026, Anthropic previewed Mythos, a model so capable of finding and exploiting software vulnerabilities that Anthropic restricted access to a small group of vetted security partners. The safeguarded public release that followed, Fable 5, was suspended within days under a US government export directive, over concerns it could be misused for cyberattacks (later restored). The whole episode captures this post’s premise: the capability that makes an agent useful makes it dangerous. A tool that can autonomously hunt down zero-days is the last thing you want running with your privileges on your host. The more capable these agents get, the more a hard isolation boundary matters.
Tools like Claude Code, Codex, and Antigravity typically run with the same privileges you do. They can read any file, execute shell commands, and make network requests on your behalf. They also routinely process untrusted input: source files, READMEs, issue comments, web pages they fetch, and the output of commands they just ran. Any of these can carry a prompt injection that misleads the agent into exfiltrating SSH keys, leaking environment variables, or running destructive commands. And the MCP ecosystem is another source of supply chain compromise: each MCP server is essentially a dependency installed from a registry and running with the agent’s full privileges.
The threat surface is no longer just what a malicious package can do on your machine. It now includes what an agent can be tricked into doing with the access you’ve already granted it. Some agents ship their own sandbox modes, and they are worth enabling, but they only cover the agent’s own processes and are easy to turn off for convenience. For work on an untrusted repository, Claude Code’s docs steer you past the built-in sandbox to a dedicated VM (the approach this post develops).
Development tools #<br>Are the development tools themselves secure? VS Code illustrates why not. It’s an embedded browser (Electron) at heart, rendering content from untrusted repos: README previews, notebook cells, extension panels. On top of that, every extension runs with your privileges. One click on a malicious repository in github.dev was enough for a hidden script to install a bundled extension and steal a GitHub token.
Workspace files in a repo, like .vscode/settings.json or tasks.json, can be malicious too. North Korea’s Contagious...