超越权限提示：用 sandboxing 让 Claude Code 更安全

导读

本文讨论为什么 permission prompts 不是 Claude Code 安全的终点，并介绍 sandboxing 如何用系统边界限制文件、网络和凭据访问，减少 prompt injection 后果。

说明：本文按 Agent Learning 的中文阅读页格式，对原文结构与关键技术细节做逐节中文转述与解读；为避免整篇镜像转载，正文保留原文章节脉络、关键数字和术语，但不做逐字复刻。

核心观点

• permission prompt 能提醒用户，但不能替代技术隔离。
• 用户长期批准会产生疲劳，攻击也可能诱导模型请求危险操作。
• sandboxing 把风险从“每次判断”转移到“默认边界”。
• 文件系统隔离可限制 agent 读取和修改的路径范围。
• 网络隔离可减少凭据外传、恶意下载和未授权请求。
• 凭据不应暴露给 Claude 生成代码运行的环境。
• 安全设计应结合 prompt injection 检测、tool policy 和可审计日志。
• 自主性越高，越需要结构性隔离而不是更多弹窗。

正文

原文主线

本文讨论为什么 permission prompts 不是 Claude Code 安全的终点，并介绍 sandboxing 如何用系统边界限制文件、网络和凭据访问，减少 prompt injection 后果。

permission prompts 的局限

Claude Code 需要执行命令、读写文件、调用工具。permission prompts 可以让用户确认高风险动作，但它依赖人类持续判断。如果每几分钟都弹出确认，用户会疲劳；如果 prompt injection 说服模型提出看似合理的请求，人类也可能误批。

因此，安全不能只靠问用户。更稳的策略是把环境默认限制在安全边界内，让低风险动作顺畅进行，高风险能力从结构上不可达或需要明确授权。

sandboxing 的作用

sandboxing 通过文件系统、网络、进程、资源和凭据隔离，把 agent 的行动空间限制在任务需要的范围内。即使模型被恶意内容影响，攻击者也更难读取敏感文件、外传 token 或修改不相关资源。

文件系统隔离可以让 agent 只访问当前 repo 或临时工作区。网络隔离可以默认禁止外联，只允许必要域名。资源限制可以防止无限进程和消耗攻击。

凭据和工具边界

最关键的原则是：凭据不要进入 Claude 生成代码可读取的环境。Git、MCP、云服务等凭据可以通过 proxy、vault 或资源绑定方式使用，让 agent 能完成操作，却拿不到原始 secret。

工具也应带 policy。某些工具只读，某些工具可写但需要确认，某些工具只能在 sandbox 内部运行。权限边界越清楚，prompt prompt injection 的后果越小。

安全与体验

更强隔离不是为了让 agent 更受限，而是为了让它更自主。低风险操作如果被 sandbox 包住，就可以减少 permission prompt；用户把注意力留给真正重要的决定。

安全体验的目标是少打扰但更可信：默认安全边界、清晰升级路径、可审计日志和发生异常时的解释。

深度解读

这篇主题的价值在于，它把 agent 安全从 UI 交互问题拉回系统边界问题。permission prompt 是最后一道人类判断，但不能成为唯一防线。随着 coding agents 更自主，用户不可能审查每个命令的所有后果。sandboxing 的意义，是把可犯错空间缩小，让模型即便被诱导也只能在有限范围内行动。好的安全设计不是不断喊停，而是让安全成为默认环境。

落地启示

• 用 sandbox 默认限制文件和网络范围。
• 把凭据放在 vault、proxy 或资源绑定层，而不是放进可读环境变量。
• 为低风险读操作减少打扰，为高风险写操作保留确认。
• 保留审计日志，支持事后追踪。
• 把 prompt injection 检测与系统隔离结合使用。