Beyond Permission Prompts: Making Claude Code More Secure and Autonomous
原标题: Beyond Permission Prompts: Making Claude Code More Secure and Autonomous 中文标题: 超越权限弹窗：让 Claude Code 更安全且更自主的沙盒化方案 作者: David Dworken, Oliver Weller-Davies 等 | 发布日期: 2025年10月20日 原文链接: https://www.anthropic.com/engineering/claude-code-sandboxing
一句话摘要
Anthropic 为 Claude Code 引入操作系统级沙盒机制，通过文件系统隔离和网络隔离双重防线，在将权限提示减少84%的同时大幅增强安全性，从根本上解决了"审批疲劳"与安全性之间的矛盾。
完整核心内容翻译
一、问题挑战
Claude Code 在你身边编写、测试和调试代码，它可以浏览你的代码库、编辑多个文件并运行命令来验证自己的工作。授予如此广泛的访问权限带来了显著的安全风险，尤其是提示注入攻击（prompt injection）的威胁。
传统的基于权限的模型制造了大量摩擦："不断点击'批准'会拖慢开发周期，并导致'审批疲劳'。"用户在授权决策中可能变得漫不经心，这反而悖论式地降低了安全性。当第十次审批弹窗出现时，用户已经不再真正审查内容，只是机械地点击通过。
二、沙盒化架构
核心理念： 沙盒创建了预定义的边界，在边界内 Claude 可以更自由地工作，而不是为每个操作逐一请求权限。
两个关键组件
文件系统隔离： 限制 Claude 只能访问特定目录，防止被提示注入攻破的实例修改敏感的系统文件。例如，Claude 可以自由读写项目目录 /home/user/project/，但无法触及 ~/.ssh/、~/.aws/ 或系统配置文件。
网络隔离： 限制连接仅限于已批准的服务器，阻断凭据外泄或恶意软件下载的路径。即使攻击者通过提示注入控制了 Claude 的行为，也无法将窃取的数据发送到外部服务器。
文章强调："有效的沙盒化需要同时具备文件系统隔离和网络隔离。"任何一层的缺失都会留下可被利用的攻击面。
三、实现细节
沙盒化 Bash 工具
新的运行时（以Beta研究预览版提供）允许定义智能体可以访问哪些目录和网络主机。它构建在操作系统级原语之上：
- Linux： 使用
bubblewrap容器化工具 - macOS： 使用
seatbelt安全沙盒框架
这种方法覆盖了直接交互以及所有派生的脚本和子进程。这意味着即使 Claude 运行一个 Shell 脚本，该脚本又启动了另一个进程，所有这些进程都在沙盒约束之内——不存在通过子进程"逃逸"的可能。
Claude Code 网页版
基于云的执行为每个会话提供独立的沙盒环境。关键设计：敏感凭据（如 git 凭据或签名密钥）永远不会出现在 Claude Code 的沙盒内部。
一个定制代理处理 git 交互，使用范围受限的凭据进行认证，并在传输到 GitHub 之前验证操作。这种架构确保了即使沙盒完全被攻破，攻击者也无法获得用户的真实凭据。
四、如何开始使用
用户可以在 Claude Code 中运行 /sandbox 命令并查阅文档进行配置。沙盒化代码已经开源，供更广泛的社区采用和审查。
技术要点
- OS级沙盒而非应用级隔离： 使用 Linux bubblewrap 和 macOS seatbelt 等操作系统原语实施限制，确保即使应用层被绕过，安全约束仍然有效。
- 双重隔离缺一不可： 文件系统隔离防止本地破坏，网络隔离防止数据外泄，两者必须同时实施才能构成有效防线。
- 凭据与执行环境分离： 在云端版本中，git凭据等敏感信息通过代理层间接使用，永远不进入沙盒内部，即使沙盒被完全攻破也不会泄露凭据。
- 子进程继承沙盒约束： 覆盖所有派生进程，杜绝通过生成子进程来逃逸沙盒限制的攻击路径。
- 84%的权限提示减少： 在安全性不降反升的前提下，大幅减少了对用户的干扰，解决了"审批疲劳"问题。
深度解读
本文揭示了AI工具安全设计中一个深刻的悖论：更多的安全提示并不等于更高的安全性。 当权限弹窗过于频繁时，人类审批者会进入"自动驾驶"模式——习惯性地点击"批准"而不真正审查内容。这与网络安全领域经典的"警报疲劳"问题如出一辙。
Anthropic 的解决思路代表了安全范式的转变：从"逐次请求许可"到"预设安全边界内自由行动"。 这类似于企业IT中的"零信任"与"边界安全"之间的辩证关系——不是信任或不信任每个操作，而是定义一个安全的操作空间。
从技术架构角度看，选择OS级原语（bubblewrap/seatbelt）而非应用级隔离是一个关键决策。应用级沙盒（如JavaScript的VM2）历史上多次被发现逃逸漏洞，因为它们在同一安全层级上运行。而OS级隔离将安全边界下移到内核层面，攻击者需要同时突破应用层和内核层才能逃逸——这大幅提高了攻击成本。
凭据代理模式特别值得注意。传统做法是将凭据注入执行环境（如环境变量），但在AI智能体场景中这极其危险——一个成功的提示注入攻击可以让智能体读取环境变量并外泄凭据。Anthropic 的代理模式将凭据隔离在沙盒之外，智能体只能通过受控的代理层使用凭据的"功能"而非凭据本身——这是**能力安全（capability security）**原则的优雅应用。
开源沙盒代码的决策也值得关注——这不仅增加了透明度，还允许社区进行安全审计和改进，符合"安全不依赖隐蔽性"的原则。
延伸思考
- 沙盒模型能否扩展到多智能体协作场景？当多个智能体需要共享文件但不应访问彼此的凭据时，如何设计隔离策略？
- 随着智能体能力增强，"安全边界"如何动态调整？是否可能实现根据任务风险等级自动扩缩沙盒权限？
- 提示注入攻击与沙盒防御之间是否会形成"军备竞赛"？未来的攻击是否会尝试社会工程方式诱导用户扩大沙盒权限？
- 沙盒化方案如何与其他安全层（如内容审核、输出过滤）组合使用，形成纵深防御体系？
本文为 Anthropic 官方工程博客文章的深度中文解读。