Jailbox:把整个开发环境装进无法访问私网的 Linux VM

# Jailbox / KVM Sandbox:把整个开发环境装进"无法访问私网"的 Linux VM

## 一、Karam Atli 在 2026 年 9 月发布的网络隔离 KVM 方案

2026 年 9 月,Karam Atli 发布一篇技术深度文章 "Jailbox: Network-Restricted, Hardened Linux VMs for AI Agents and Untrusted Code"(HN 5pts,内容极深)。

核心观点:

> "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."

中文:在供应链攻击和越来越强的 AI 编程 Agent 之间,你已经在用自己的权限跑你从没读过的代码。与其沙箱化单个工具,不如把整个开发环境(editor + agents + 容器)放进一个 KVM VM——VM 能上互联网,但不能访问 host / LAN / 任何私网地址****。

## 二、文章论证的三个攻击面

Karam Atli 把"为什么需要这层 sandbox"拆成三个攻击面:

### 攻击面一:供应链攻击

> "In 2016, unpublishing an 11-line npm package 'broke the internet'... 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..."

中文:2016 年 unpublish 一个 11 行 npm 包"破坏互联网";LiteLLM 一次被攻陷的 release 一日 300 万下载,exfiltrate 云和 CI/CD 凭据;Hades 活动在二十几个 PyPI 包埋启动时执行代码;debug / chalk 等 16 个 npm 包被集体攻陷……

判断:你的依赖有自己的依赖,攻击者只需要占据链条里任何一个位置。

### 攻击面二:AI Agent

> "AI agents 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."

中文:AI Agent 经常处理不可信输入:源文件 / README / issue 评论 / 抓取的网页 / 刚跑完的命令输出。任何一项都可能携带 prompt injection,误导 Agent 偷 SSH key、泄漏环境变量、跑破坏性命令。

判断:Agent 的危险不是"模型本身",是 Agent 自动调用工具的权限 + 处理的不可信输入 = 主动攻击面。

### 攻击面三:开发工具本身

> "VS Code illustrates why not. It's an embedded browser (Electron) at heart, rendering content from untrusted repos: README previews, notebook cells, extension panels."

中文:VS Code 揭示了问题。它本质是嵌入式浏览器(Electron),渲染不可信仓库的内容:README 预览、notebook 单元格、扩展面板。

North Korea 的 Contagious Interview 行动:VS Code 打开一个假面试 repo,`.vscode/settings.json` 自动跑恶意任务——开发者打开 repo 那一瞬间被攻陷。

GlassWorm:第一个自我传播的 VS Code 扩展蠕虫,偷 marketplace 和 GitHub 凭据,用它们继续感染其他扩展。

## 三、Karam Atli 推荐的防御层次:defense in depth

文章推荐的方案分三层:

``` Host (credentials, your files) └── 终端/浏览器/编辑器 UI │ └── Sandbox VM (硬件虚拟化) └── editors + 扩展 + AI Agents + MCP servers + 开发工具 │ └── Container (kernel namespaces) └── 不可信代码 +依赖 ```

关键设计:

- Sandbox VM 可以访问互联网,不能访问 host / LAN / 私网(10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.0/8、169.254.0.0/16、100.64.0.0/10) - Host → VM 允许(SSH / HTTP / HTTPS 调试) - VM → Internet 允许(包下载、git remote、Agent API) - VM → Host / LAN / 私网 拒绝 - 这条策略需要 NAT + stateful firewall,不能光用 `--network none`

## 四、为什么选 KVM 而不是 bubblewrap / Firecracker / Docker Sandbox

文章细致对比了 5 种方案:

| 方案 | 优点 | 缺点 | |---|---|---| | bubblewrap / gVisor | 轻量、namespace | 仍然依赖 host kernel(或重写 syscalls),无法完全隔离 | | Firecracker | VM 级别隔离,125ms 启动,适合 ephemeral workloads | 为短暂 swarms 设计,不适合"长期工作站" | | libkrun / Kata | 容器 + microVM | 每个容器单独 microVM,不是"一个边界包整个环境" | | Docker Sandboxes | 思路接近(microVM 包 Agent) | 闭源,无法审计或加固;单 session 而非持久环境;agent 有 passwordless sudo | | hosted(E2B / Modal / Codespaces) | 强隔离 | 代码凭据上 vendor,按量计费 | | plain KVM VM | boring、公开云都在用、经过最充分实战测试;硬件强制隔离;near-native 性能 | 启动比 container 慢,RAM 多 |

核心判断:Plain KVM 是"强边界 + 无新依赖"的最优解——你不需要学新技术,不需要信任新厂商,只需要给 KVM 一个严格 egress 防火墙。

## 五、网络策略为什么是"the awkward middle ground"

文章直白点出:

> "The useful policy is the awkward middle ground. The extremes are cheap (--network none is one flag, and full access is the default), but 'internet yes, private addresses no' requires NAT plus a stateful firewall in the path."

中文:有用策略是尴尬的中间地带。两个极端都很容易(--network none 一个 flag,完全开放是默认),但"互联网可用 + 私网不可用"需要 NAT + stateful firewall 在路径上。

这是关键洞察:大多数 sandbox 工具给你两个选项(全开 / 全闭),真正安全的"中间选项"需要工程投入。Docker Sandboxes 有这个选项但用起来太复杂(per-domain allowlist + 阻断 raw TCP/UDP),所以大家都被推到默认全开。

## 六、作者自己做了 stress test

Karam Atli 给一个 AI Agent root 权限在 sandbox VM 里,让它尝试逃逸。Agent 没能成功。

这是文章最强的一手证据:不是理论设计,是实测过 Agent 试图突破。

## 七、跟之前讨论的所有 sandbox 是什么关系

把 Jailbox 放进我们之前的 sandbox 全景:

| 方案 | 边界层 | 关注点 | |---|---|---| | bubblewrap(Seahaven) | Process namespace | 个人 Agent 文件视野 | | Firecracker(microVM) | VM 级别 | 多租户 + ephemeral | | Muse Secure VM | VM + 加密 | 个人 Agent 隐私 | | Isle | Application 层 | 应用进程恢复 | | OpenAI Agents API | Hosted sandbox | 远程 + 不需要本地资源 | | Jailbox / KVM sandbox | VM + 严格 egress firewall | 整个开发环境隔离 |

Jailbox 的独特之处是它给整个工作站隔离(editor + agents + containers + MCP servers),不是只隔离 Agent 一个进程。这意味着开发者自己也在 sandbox 里**,开发环境跟 host 完全断开。

## 八、对企业的现实启示

短期(立刻):

- 重新评估你的开发环境隔离——如果你的工程师在 host 上跑 Agent + VS Code + 各种 toolchain,整个工作站都在暴露 - 关注 network-restricted VM 设计——不是 sandbox,而是"internet-only VM" - 关注 Karam Atli 的 `kvm-sandbox` 工具(GitHub: ertug/kvm-sandbox)——一个命令创建完整 sandbox

中期(3-6 个月):

- 把"开发工作站隔离"纳入企业 IT 安全规范——不只是 Agent,整个开发环境要能配置为"internet-only VM" - 关注 egress firewall 工程——NAT + stateful firewall + per-VM routing 是核心基础设施 - 评估开发工具自身的攻击面——VS Code / JetBrains / Cursor / Claude Code 都在 sandbox VM 内运行更安全

长期(1 年+):

- "AI 时代的开发工作站"会出现新标准——VM + 严格 egress + 自动镜像管理 + GPU passthrough + 跨设备同步 - Linux VM + libvirt + nftables 的组合会成为开源开发者的事实标准——比 macOS / Windows sandbox 更可控 - "agent 在 sandbox VM 内 + VM 不能访问 host"会成为 AI Agent 安全的工业基线——不是 nice-to-have,是 must-have

## 九、回到题目:Jailbox / Network-Restricted VM 真正改变了什么

Karam Atli 的方案揭示了一个长期被 AI Agent 安全讨论忽视的事实:Agent 安全不只是 sandbox Agent,而是 sandbox 整个开发环境。

之前我们讨论的所有 sandbox 都是针对 Agent 一个进程/一个 session,但 Karam Atli 揭示的是:Agent 只是一个 entry point——编辑器、扩展、MCP server、容器、所有开发工具都是潜在攻击面。只隔离 Agent 不够,要隔离整个开发工作站。

更重要的是 Karam Atli 的核心洞察:Agent 在自己 sandbox 内能跑得多安全,取决于 sandbox 之外的"整个工作站"有多安全。如果 host 有 SSH key、LAN 有打印机、VPN 有内部系统,Agent 跑得多认真 sandbox 也救不了——因为攻击向量根本不在 Agent 进程里。

2026 年下半年,企业 IT 必须把"开发工作站 = 网络隔离 VM"作为 AI Agent 时代的新基线。这不是一个产品决策,是安全范式的转变。

Jailbox / KVM Sandbox 不是答案的全部,但是答案的必要部分。