跨产品封控 Claude 的方式

安全威胁与外泄风险

• 评论者指出，除了文章所描述的内容之外，还存在许多外泄向量：域名前置、在提交或文本中的隐写编码、时序/排序侧信道，以及隐藏在仓库、文档、缺陷报告或依赖项中的提示注入。
• 一些人认为，要防止基于提示注入的外泄，实际上只有在具备非常强的、多级数据分类系统和侧信道安全设计时才可能做到。
• 也有人预测，行业会以“YOLO”方式部署智能体，并把外泄和篡改视为一种可接受的、类似欺诈的成本。

封控架构（VM、airlock、独立机器）

• 多位用户描述了把智能体运行在 VM 中（qemu、macOS 容器、Linux VM），配合严格的出站控制、项目专用 token，以及对提交进行人工审查。
• 讨论中提到一种 “airlock” 模式：一个本地离线智能体拥有文件系统访问权限；一个在线但无文件系统访问权限的智能体；数据只通过用户介导的文本在两者之间流动，绝不自动回到互联网。
• 还有人建议更严格的隔离：完全独立的硬件（廉价笔记本/VPS）、单向通道，或借鉴 Qubes 和 “Tin Foil Chat” 的概念。
• 关于容器与 VM 的争论仍在继续：有人认为 Docker 作为安全边界太弱；也有人接受它，但会配合 bubblewrap 等额外工具。

当前护栏的局限性

• 评论者强调，环境层面的控制比模型是否“表现良好”更重要；模型仍然是概率性的，且可以被欺骗。
• 文章提到自动批准只阻止了约 83% 的高风险操作，这让一些读者感到警惕，因为这与产品文档中暗示的更强保证不一致。
• 过去据报道 Claude Code 沙盒和 token 作用域方面的 bug 表明，封控仍然脆弱，而且会回归。

风险-收益框架与怀疑态度

• 几位参与者批评了文章明确的风险-收益框架：他们认为这在安全领域很正常，但担心公司在优化自身收益的同时，把风险外包给用户。
• 也有人认为，现实世界中的所有系统都会接受非零风险；关键是最小化期望伤害，而不是消除一切风险。
• 对厂商沟通的怀疑相当明显，有人把“模型危险”的叙事看作营销，尽管他们也承认确实存在安全工作。