CC Safety Net 与操作系统级沙箱的对比

大多数编码智能体 CLI 现在都内置或支持提供文件系统和网络隔离的操作系统级沙箱。沙箱提供的是广泛的隔离：它限制进程可以接触的对象，但不知道命令的含义。CC Safety Net 提供的是语义化、有界的拦截：它读取受支持工具调用的含义，并在破坏性操作运行前阻止它们，无论操作指向何处。两者防御不同的威胁。一起使用可提供最完整的保护。

​

操作系统沙箱的工作方式

各平台的沙箱实现不同，但大多数实现使用相同的操作系统基础机制，即 macOS Seatbelt 和 Linux bubblewrap，并采用相同的默认策略：允许广泛读取，只允许向当前工作目录和临时目录写入，并限制或默认关闭网络访问。每个实现还会分开两个控制项：沙箱本身是限制可接触对象的技术边界，审批策略决定智能体必须在何时请求许可。

​

不同的保护层

​

编码智能体沙箱的限制

沙箱限制你可以向何处写入，但不理解边界内的操作是否具有破坏性。下列命令都会被沙箱允许：它们在当前工作目录内写入、读取沙箱允许的文件，或访问允许的远程端点。 从操作系统的角度看，这些命令完全合法：它们向允许的路径写入或读取沙箱允许的文件，不接触网络（push 除外），并且正常完成。沙箱没有 Git 历史、未提交更改、stash 条目或凭证文件的概念。CC Safety Net 理解这些语义，并据此阻止命令。 同样的差异也适用于命令代理。代你运行命令的工具对两个保护层来说都像一个不透明的可执行文件。但在你用 cc-safety-net rule wrapper add <command> 声明该工具后，CC Safety Net 会查看其中可见的子命令，并应用相同规则。沙箱完全不检查子命令，只限制整个进程树可以接触的对象。

​

何时更适合使用沙箱

如果你主要关注以下威胁，沙箱是正确的工具：

• 提示注入攻击：通过限制出站网络域来降低数据外泄风险
• 恶意依赖项：限制不可信软件包的文件系统写入和网络访问
• 不可信代码执行：操作系统级隔离从根本上强于命令文本分析
• 网络控制：CC Safety Net 完全不提供网络保护

如果你运行来自不可信来源的代码，或担心受损依赖项连接攻击者控制的服务器，沙箱才是处理这些威胁的保护层。

​

CC Safety Net 无法提供帮助的范围

CC Safety Net 解释受支持的工具调用，但不隔离进程。下列限制需要隔离，而不是语义分析：

• 通过网络外泄数据。 运行时评估不发出网络请求，管线也不检查出站流量。域 allowlist 是沙箱的工作。
• 读取已识别集合之外的内容。 敏感路径保护覆盖一个有界模式集，包括 .env 及其变体、SSH 密钥、云凭证存储、编码 CLI 凭证文件以及你配置的 deny path，并覆盖受支持的 command、path、search 和 patch 形式。完整目录见机密保护参考。它不是通用读取边界，因此无法保护未识别文件中的凭证。沙箱可以限制所有读取，而不必知道哪些文件重要。
• 隐藏在二进制文件内的行为。 some-tool --task destructive-cleanup 在命令文本中看似无害。即使将代理配置为透明包装器，如果它改写子命令而不是执行可见子命令，也无法展开它。
• 完整的文件系统执行。 拒绝会停止工具调用，但不执行权限控制。当你需要完整保护而不是尽力拦截时，请使用可信写入代理、操作系统权限或沙箱。

这些正是沙箱隔离功能的用途。因此，两种工具互为补充，而不是替代关系。完整的残余限制列表见已知限制。

​

将沙箱与 CC Safety Net 一起使用

沙箱通过在操作系统级限制智能体可以执行的操作来处理未知威胁。CC Safety Net 通过在命令执行前拦截命令来处理已知破坏性模式。两者结合可覆盖各自单独使用时留下的缺口。