大家好，我是安东尼（tuaran.me），一名专注于前端与 AI 工程化的独立开发者。
我在建设 「博主联盟」------连接AI产品方与技术博主的品牌增长平台，帮AI产品精准触达开发者，也帮博主拿到推广资源与成长机会。
同时也在做 「前端下一步」------一个聚焦前端、AI Agent 与大模型的技术情报站，帮你从技术革新焦虑中解脱，得到技术转向判断。
这篇文章，希望对你有所启发。
把 LLM 接到 shell、文件系统和网络上，本质上就是给一个会幻觉的实习生发 root。ZeroClaw 在安全上踩了几个比同类框架更保守的默认值，这一篇把它的安全模型分四层讲清楚。
第 0 层：心智模型------deny by default
这是它和 OpenClaw 风格上最大的区别。
- OpenClaw：默认能 shell、能联网、能读文件，靠"用户记得去关"。
- ZeroClaw ：默认只能做白名单里允许的事。新增一个 Tool 就要在 config 里显式声明"允许、限制条件、参数模式"。
这套思路对运维更友好------审计 config 比审计代码容易；对开发者会"麻烦"一点------加一个新工具要多走一道手续。这个 trade-off ZeroClaw 选了"麻烦但安全"。
第 1 层：路径白名单 / 命令白名单
工具调用前，runtime 会过两道闸：
- 路径白名单 ：文件读写只允许触达预先声明的目录。试图写到
/etc/passwd会直接被拒绝，不用等到 OS 层报错。 - 命令白名单 ：
shell工具只能跑明确允许的可执行文件。curl允许、bash -c不允许，可以这么细。
加一道符号链接逃逸检测 ------避免 ln -s / ./safe_dir 这种典型逃逸技巧。
第 2 层：组件级隔离 + 凭据加密
- Provider 用的 API Key、Channel 的 token，都走加密存储，不会以明文落进配置文件。
- 不同 Tool 之间的"会话上下文"互相隔离：浏览器抓回来的 cookie，不会自动给 shell 工具看。
这一层是给"插件被 prompt injection 利用"留的安全网------即使一个工具被骗了，能漏的范围也是限定的。
第 3 层：OS 级沙箱
这是 ZeroClaw 比一般 Agent 框架走得更远的一层。它在不同平台上挂不同的 OS 沙箱：
| 平台 | 沙箱机制 |
|---|---|
| Linux（5.13+） | Landlock LSM，无需 root |
| Linux（容器/严格模式） | Bubblewrap（unshare/namespaces） |
| macOS | Seatbelt sandbox profile |
| 通用兜底 | Docker 容器化 |
这意味着：哪怕第 1、2 层都没拦住、攻击者真的拿到了一个 shell，他也是在沙箱里------文件系统视图、网络命名空间、能用的系统调用都被收紧过。
第 4 层：审计 / 工具回执
每次工具调用都会落一份加密的"工具回执"（tool receipt）：
- 谁调的（哪个 Channel 的哪条消息触发）
- 调了什么（参数）
- 结果是什么（返回 + 退出码）
- 时间戳 + 链式哈希（前一条 receipt 的 hash 进入下一条）
链式哈希让审计日志不能被悄悄改一行。出了事故复盘时，这是 Agent 类系统里最值钱的证据。
哪些攻击它能挡，哪些挡不住
能挡（或显著降低风险）的
- 工具被 prompt injection 利用去做越界文件操作------路径白名单 + 沙箱兜底
- 攻击者通过 channel 注入指令拿 shell------命令白名单
- 凭据从配置文件被抄走------加密存储
- 事后否认"我没让 Agent 这么做"------审计回执
仍然挡不住的
- 白名单内的工具被滥用 ------你允许它访问
/data，它就有机会泄露/data里的内容。这是设计上的，不是 bug。 - LLM 输出的 SSRF / 数据外发------如果 HTTP 工具的 URL 没做严格 allowlist，模型生成一个内网地址照样会请求。
- 供应链攻击------你引入的第三方 Provider/Channel crate 本身有恶意，沙箱挡不住。
- 配置错误 ------把白名单写成
/、把沙箱关了，怎么设计的安全模型都救不了你。
给生产部署的几条建议
- 不要把 ZeroClaw 用 root 跑------即使有沙箱兜底。
- shell 工具的命令白名单要写到具体路径 ，例如
/usr/bin/curl，而不是curl。 - HTTP 工具的目标域名要有 allowlist，不要让模型自由组装 URL。
- 生产环境关掉浏览器/桌面控制类工具------这类工具沙箱能挡的有限。
- 审计回执要落到外部存储------不要让 Agent 自己有权限改自己的日志。
- Provider/Channel/Tool 的 crate 要锁版本 + 校验 hash，别开自动更新。
一句话总结
ZeroClaw 的安全模型可以概括为：默认拒绝 + 白名单 + 加密凭据 + OS 沙箱 + 链式审计。每一层都有它解决不了的问题，但叠起来，它在"能跑得起 LLM Agent 的框架"里属于第一梯队的保守派。
剩下的，靠你不要把白名单写得太宽。