最近在做 SkillLite 的本地安全沙箱时，我顺手看了一下 ZeroClaw 的原生沙箱实现，结果发现了几个比较关键的安全设计问题。后面我把问题和修复建议整理成 issue 发给了上游，随后相关方案被实现并合并进主分支。

相关链接：

• Issue: zeroclaw-labs/zeroclaw#4812

• PR: zeroclaw-labs/zeroclaw#4821

背景

我一直在做 SkillLite，一个强调“本地执行 + 安全约束 + 自进化”的 Rust Agent 工程。因为项目里本身就有原生 OS 级沙箱，所以我对 bwrap、seatbelt、firejail、seccomp 这类隔离方案会比较敏感。

也正是在这个过程中，我去看了 ZeroClaw 的 native sandbox 设计，发现它的整体思路其实不错，但在“最后一公里”的安全收口上，还有几个容易被忽略的问题。

我看到的 3 个问题

1. bwrap / firejail 后端缺少 seccomp 等进一步收口

前面已经有 namespace 隔离，但如果没有 seccomp、能力裁剪等机制，攻击面偏大。

这类问题不一定意味着“立刻可利用的逃逸”，但它意味着沙箱的防护深度不够，安全边界没有收紧到应有的程度。

2. 原生后端缺少资源限制

Docker 后端通常会带上 memory / cpu 这类限制，但原生后端如果没有对应的资源控制，就容易被恶意代码打成 DoS。

这个更偏可用性与稳定性风险，不一定直接导致越权，但在生产环境里依然是很现实的问题。

3. 显式指定沙箱后端时，失败后静默回退到 NoopSandbox

这个问题是我最在意的。

因为用户明明指定了某个沙箱后端，结果后端不可用时系统却悄悄降级到无沙箱执行，只打一条日志。

这会造成一种非常危险的“虚假安全感”：

你以为代码在沙箱里跑，实际上它已经在宿主权限下裸跑了。

这不是传统意义上的 RCE 漏洞，但它是一个高风险的安全设计缺陷。

我给出的建议

我在 issue 里给了 3 类建议：

1. 给 bwrap / firejail 增加 seccomp、capability dropping、noroot 等安全收口

2. 给原生后端增加资源限制能力

3. 对显式指定但不可用的 sandbox backend 采用 fail-closed 策略，而不是静默回退到 NoopSandbox

完整 issue 在这里：

zeroclaw-labs/zeroclaw#4812

后续发生了什么

上游随后有人基于这个 issue 提了 PR 来实现相关加固：

zeroclaw-labs/zeroclaw#4821

不过初版 PR 里其实还有一些细节问题，比如：

• 某些 bwrap 参数是否真实存在、是否与 man page 一致

• fail-closed 逻辑在特定路径下是否真的生效

• 环境变量默认值和测试断言是否一致

这些问题我在 PR 讨论里继续指出，后续对方又补了几轮修复，最终才被维护者合并。

所以这次贡献对我来说，完整走了一遍：

• 发现问题

• 定义风险

• 提出方案

• 参与 review

• 推动修正后合并

这件事对 SkillLite 有什么意义

这次事件最大的价值不在于"提出问题"，而是再次印证了SkillLite在沙箱安全领域的正确判断。

通过这个事件，可以确认两个关键点：

第一，SkillLite的沙箱经验有了初步的实战检验

项目实践中积累的经验教训，不仅完善了SkillLite自身的安全体系，还能为其他项目提供切实可行的安全改进方案。

第二，安全能力的核心在于可验证性

空谈安全毫无意义。
只有将安全观点形成具体方案，经过公开讨论、实现验证、代码审查并最终被上游采纳，这样的安全能力才真正具有说服力。我觉得最大的意义不是“给别人提了问题”，而是再次验证了 SkillLite 在沙箱安全这条路上的判断。
现在AI行业的很多项目 sandbox 其实都还是出于初步发展阶段，需要互相验证成长。

最后

这次确实是一组有实际价值的沙箱安全问题，其中包含一个我认为高风险设计缺陷。

对我来说，这也是做 SkillLite 过程中一个很有代表性的时刻：

不是为了写一个看起来很强的 README，而是真正把本地 AI Agent 的安全工程做扎实，并且让这些经验能外溢到生态里。

如果你也在做本地 Agent、MCP、沙箱执行或者 AI 安全相关的事情，欢迎交流。

项目地址：SkillLite