如何用 nilbox 沙箱安全运行不信任的 AI Agent？零令牌架构实战详解
运行 AI 编码 Agent（如 OpenClaw、Claude Code、Codex）时，你面临一个两难选择：给它们 API Key 才能工作，但给了之后你基本无法控制这些 Key 被用在哪儿。容器隔离？一个容器逃逸或者 Prompt 注入就能拿到你的全部凭据。nilbox 提出了一个截然不同的方案——零令牌架构（Zero Token Architecture）：API Key 物理上不出宿主机，Agent 在独立的虚拟机里拿到的是占位符字符串，真正的令牌交换在宿主机代理层完成。本文详解如何配置和使用。
问题：为什么容器隔离不够？
Docker 容器共享宿主机内核。这意味着：
/proc、/sys等接口可能暴露主机信息- 挂载的环境变量（
OPENAI_API_KEY等）进程间可见 - 一旦 Agent 被注入恶意指令，Key 可以被直接读取和传出
现实攻击场景：Agent 安装了一个看似无害的 npm 包，该包在 postinstall 脚本中读取环境变量并发送到攻击者服务器。容器内的 Key 对容器内的所有进程可见，这是根本问题。
nilbox 的做法是：把 Agent 真的放到虚拟机里（不是容器），API Key 以占位符形式存在，真实的 Key 只在宿主机内存中，通过 VSOCK 通道按需代理。
nilbox 零令牌架构工作原理
nilbox 的核心设计只有三步：
- Agent 在 VM 内运行——通过 Apple Virtualization.framework（macOS）或 QEMU（Linux/Windows）启动完整的虚拟机
- 环境变量替换——VM 中的
ANTHROPIC_API_KEY被设为ANTHROPIC_API_KEY（一个无意义的字符串），真实的 Key 完全不进入 VM - 宿主机代理拦截——Agent 发往
api.anthropic.com的请求经过 VM 内127.0.0.1:8088代理，宿主机代理层拦截后替换请求头中的占位符为真实 Token，再转发
从 Agent 的角度看，API 调用和直接运行没有区别。但对于攻击者：即使拿到了 VM 的 root 权限，也只能拿到 ANTHROPIC_API_KEY 这个字符串，而非真实的 sk-ant-xxxx。
快速上手
安装 nilbox
从 GitHub Releases 下载对应平台的安装包。目前支持 macOS（Apple Silicon + Intel）、Linux 和 Windows。
从源码构建（需要 Rust 工具链和 Node.js 18+）：
git clone https://github.com/paiml/nilbox.git cd nilbox cd apps/nilbox && npm install && npm run tauri dev
配置凭据
启动桌面应用后，在设置页面配置各 AI 提供商的 API Key：
ANTHROPIC_API_KEY=sk-ant-xxxxxxxx OPENAI_API_KEY=sk-proj-xxxxxxxx GEMINI_API_KEY=AIzaxxxxxxxx GITHUB_TOKEN=ghp_xxxxxxxx
这些 Key 仅存储在宿主机。VM 启动时，nilbox 自动将这些变量映射为占位符注入到 VM 中。
启动 Agent
在 nilbox 界面中点击 “New VM”，选择要运行的 Agent 镜像（内置 OpenClaw、Claude Code CLI、Codex CLI 等模板）。VM 启动后自动建立 VSOCK 通道，Agent 即可像在本地一样工作：
$ echo $ANTHROPIC_API_KEY ANTHROPIC_API_KEY # ← 安全占位符，不是真实 Key $ echo $OPENAI_API_KEY OPENAI_API_KEY # ← 同样的保护
当 Agent 调用 api.anthropic.com 时，nilbox 代理自动注入真实 Token。而如果恶意代码尝试向 attacker.evil.com 发送请求，宿主机代理可以按域名规则拒绝或者只发送占位符。
核心功能详解
域名级访问控制
nilbox 允许配置白名单域名列表。只有白名单内的域名能获得真实 Token 代理，其他域名要么被阻止，要么只发送占位符：
proxy:
trusted_domains:
- api.anthropic.com
- api.openai.com
- api.github.com
rate_limit:
budget_per_provider: 50 # 每日 50 美元上限
多 Provider 支持
配置多组凭据时同样遵循零令牌原则。AWS Bedrock、Google Gemini、GitHub API 等均以相同方式保护：
AWS_ACCESS_KEY_ID=AWS_ACCESS_KEY_ID # 占位 AWS_SECRET_ACCESS_KEY=AWS_SECRET_ACCESS_KEY # 占位
零代码改造
这是最实用的设计——Agent 不需要任何修改。OpenClaw、Claude Code、Codex、Cline 等主流 Agent 开箱即用。环境变量名和结构保持一致，只是值被替换为安全占位符。
适用场景
- 运行不信任的开源 Agent——从 GitHub 拉下来的新 Agent，不想把自己的 Key 交给它
- 多租户隔离——在同一台机器上跑多个 Agent，彼此完全隔离
- 外包/协作场景——让外部开发者的 Agent 在你的基础设施上运行，不需要暴露任何凭据
- 教育/演示环境——给学生或观众演示 AI Agent，无需担心 Key 被滥用
注意事项
- VM 启动需要几秒到几十秒（取决于系统配置），比 Docker 容器慢
- 磁盘占用更大（每个 VM 需要独立的系统镜像）
- 免费版支持同时运行 1 个 VM，高级版支持多个并发实例
- 目前 Agent 镜像模板数量有限，但支持自定义 ISO 镜像
结语
nilbox 用零令牌架构从根源上解决了 AI Agent 的安全问题——API Key 物理上不在 Agent 运行的环境中。对于任何认真对待 AI 安全的团队来说，这比容器级别隔离可靠得多。如果你用 Claude Code、Codex 或 OpenClaw 做日常开发，花半小时配置 nilbox，可以省去后期 Key 泄露的无数麻烦。