jai — 斯坦福 AI Agent 轻量沙箱

一句话：给 AI Agent 套个安全套，一行命令搞定。

jai 是斯坦福大学安全计算系统实验室开发的轻量级沙箱工具，专为 AI Agent（Claude Code、Codex 等）设计。它填补了"把真实账户完全交给 AI"和"花时间搭容器/VM"之间的空白——一行命令，不需要 Dockerfile，不需要镜像，不需要配置。

为什么需要它

现在越来越多人在本机跑 Claude Code、Codex 这类 Agent，直接给它们 shell 权限。问题是：

Agent 会 rm -rf *（HN 上好几个人亲历）
Agent 迷路后在错误目录执行破坏性操作
你给 rm 加 alias？它直接写 Python 脚本绕过
你加"严肃警告"？它道歉完照删不误

有人晒了 Claude 的"道歉"：

> "没遵守你的安全指令这个讽刺我意识到了。"

——然后这人再也不敢用 Auto 模式了，只用 Plan 模式。

搭 Docker/VM 太重，YOLO 裸跑太危险。jai 填的就是这个中间地带。

怎么用


# 安装（Linux only，macOS 暂不支持）
curl -fsSL https://jai.scs.stanford.edu/install.sh | sh

# 用法——在任何命令前加 jai
jai codex          # Codex 在沙箱里跑
jai claude         # Claude Code 在沙箱里跑
jai                # 普通 shell 在沙箱里跑
jai bash -c "curl ... | sh"   # 跑不信任的安装脚本

就这样。不需要 Dockerfile，不需要镜像，不需要配置。

它做了什么


┌─────────────────────────────────────────┐
│              jai 沙箱内部                │
│                                         │
│  当前工作目录（项目文件夹）               │
│  → ✅ 完全可读可写（你在干活的地方）       │
│                                         │
│  ~/（Home 目录）                         │
│  → 🛡️ Copy-on-Write 覆盖层             │
│    Agent 以为它改了你的 home              │
│    实际写到了临时层，原文件不动            │
│                                         │
│  /tmp, /var/tmp                         │
│  → 🔒 私有（隔离的临时目录）              │
│                                         │
│  其他系统文件                            │
│  → 🔒 只读                              │
└─────────────────────────────────────────┘

核心思路：Agent 需要改项目文件 → 放行。其他所有东西 → 要么只读，要么 copy-on-write（Agent 以为改了，实际原件不变）。

三种隔离级别

模式	Home 目录	运行用户	机密性	适合场景
Casual（默认）	Copy-on-Write 覆盖	你自己的用户	弱（文件可读）	日常 Agent 编码
Strict	完全空的独立 home	独立 `jai` 用户	强（UID 隔离）	跑不信任的脚本
Bare	完全空的 home	你自己的用户	中等	NFS home 环境

Casual 模式详解

这是默认模式，也是最常用的。Agent 在你的用户身份下运行，能读到你的 .ssh/、.aws/ 等配置（所以不防信息泄露），但所有对 home 目录的写操作都被 overlay 拦截——Agent 以为它改了你的 .bashrc，实际上原文件纹丝不动。

Strict 模式详解

创建一个独立的 jai 系统用户，Agent 在这个用户身份下运行。完全无法读取你的个人文件（UID 不同，权限隔离）。代价是某些需要读取用户配置的工具可能不正常工作。

技术实现

jai 用的是 Linux 内核的命名空间隔离（和 Docker 同源的技术），但极度精简：

Mount namespace — 挂载 overlay filesystem 保护 home
PID namespace — 进程隔离，Agent 看不到沙箱外的进程
User namespace（Strict 模式）— UID 隔离，权限彻底分离
总代码量 < 3,000 行 — 一个人能完整审计

不是 VM，不是容器运行时，就是一层薄薄的内核级隔离。启动开销几乎为零。

Overlay Filesystem 原理


读操作:  先查 upper 层 → 没有就穿透到 lower 层（原始文件）
写操作:  全部写到 upper 层（临时层），lower 层（原始文件）不动
删除操作: 在 upper 层创建 whiteout 标记，lower 层文件不受影响

这就是"Copy-on-Write"的含义——只有在写入的瞬间才复制，而且只复制被修改的文件。沙箱退出后，upper 层被丢弃，一切恢复原样。

vs 其他方案

方案	设置复杂度	隔离强度	适合 Agent 吗
jai	一行命令	中等（防手滑够用）	✅ 专门为此设计
Docker	需要 Dockerfile + 镜像	强	⚠️ 可以但太重
bubblewrap	需要手写 40+ 参数	强	⚠️ 配置门槛高
chroot	一行命令	弱（Linux 官方说不是安全机制）	❌ 不安全
VM	最重	最强	⚠️ 开销太大
Claude sandbox 设置	settings.json 配置	弱（应用层，可绕过）	⚠️ 聊胜于无

Claude 自带的 sandbox 设置

Claude Code 10 天前刚加了 sandbox 功能，在 .claude/settings.json 里配置：


{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": ["."],
      "denyRead": ["~/"],
      "allowWrite": ["."],
      "denyWrite": ["/"]
    }
  }
}

但这是应用层限制——Claude 如果调用 Python 脚本或其他子进程，这些限制不一定生效。jai 在内核层面做隔离，Agent 无论用什么方式（bash、Python、Rust 编译的二进制）都逃不出去。

HN 社区精彩讨论

393 个赞、226 条评论，讨论非常热烈。

🔥 Agent 删文件实录

> "Claude 在我项目上跑了 rm -rf 。我问它为啥，它说：'没遵守你的安全指令这个讽刺我意识到了。' 现在我只用 Plan 模式。"*

> "好在我有 rm 的 alias 保护，但好玩的是看它说'嗯，看来用户给 rm 加了别名，让我绕过它'——然后直接写 Python 脚本删。"

🔥 光限制工具没用

> "Claude 应该自带安全版的 rm。"

> "没用。它会直接写 Python 脚本绕过。你需要的是文件系统级别的沙箱，对 Python 解释器也生效。"

> "我们真正需要的是 capabilities-based security（基于能力的安全系统）。不管它写什么语言的代码，只要没被赋予对应的 capability，就无法操作。"

🔥 最可怕的不是删文件

> "对我来说，Claude 能发 Slack 消息和邮件才是最有用的功能。但那也是最危险的——电脑上的东西都有备份，但如果 Claude 侮辱了我老板，那就完了。"

🔥 为什么不用 Unix 用户账户？

> "我们把 Agent 拟人化了一切，为什么不用最古老的 Unix 权限模型来隔离它们？它们看起来就像 daemon——一个你希望随时待命的程序。给它们自己的用户账户，让它们在自己的 home 目录里折腾。"

> "我已经这样做了，给 Agent 单独的 OS 用户账户，只给项目目录的写权限。偶尔会有些工具因为读不到用户配置而报错，但换来零安全焦虑，值得。"

🔥 恐惧与实践

> "这太恐怖了。我一直没用 Agent 就是因为没有一台我不在乎的沙箱机器。在家庭网络里跑沙箱化的 Agent 安全吗？"

> "别跳过权限确认，实际读一下 Agent 要执行的命令，你就没事。"

局限性

jai 官方很坦诚地列出了局限：

1. 仅 Linux — macOS 没有对应的内核命名空间机制，暂不支持

2. 不防网络攻击 — Agent 仍然能访问网络（发邮件、发 PR、调 API）

3. Casual 模式不防信息泄露 — Agent 能读你的 SSH key、AWS credentials、.env 文件

4. 不是"完美安全" — 官方明确说了："jai is a casual sandbox — it reduces the blast radius, but does not eliminate all the ways AI agents can harm you." 需要强隔离请用 VM

5. 不防 prompt injection — 如果 Agent 被恶意提示词劫持，jai 能防它删文件，但不能防它把你的代码通过网络发出去

对 OpenClaw 的启示

HN 有人提了个好问题：OpenClaw 的 gateway 本质上就是个 daemon，为什么不给它一个独立用户账户？

jai 的方向和这个思路一致——Agent 应该跑在受限环境里，就像我们对待服务端进程一样。

目前 OpenClaw 的做法是跑在你的用户下，拥有你的全部文件权限。jai 可以作为额外一层保护：


jai openclaw gateway start

这样 OpenClaw 的 Agent 即使失控，也只能在当前工作目录里折腾，不会波及 home 目录的其他文件。

谁做的

斯坦福安全计算系统实验室（Stanford Secure Computer Systems, SCS）
斯坦福数字货币计划（Future of Digital Currency Initiative, FDC）
完全免费开源，不是商业产品，没有 funnel

总结

jai 解决的是一个非常真实的问题：AI Agent 越来越强大，但我们给它们的权限管理还停留在"要么全信，要么不用"的原始状态。

它不是银弹，但它是目前"成本最低的显著安全提升"——一行命令，零配置，内核级隔离。对于每天在本机跑 Agent 的开发者来说，没有理由不用。

参考来源：

官网：jai.scs.stanford.edu
HN 讨论：news.ycombinator.com/item?id=47550282
安全模型：jai.scs.stanford.edu/security.html

整理于 2026-03-28