Agent 最危险的时刻，往往不是它回答错了，而是它在“看起来合理”的下一步里运行了一条范围过大的命令。DeepSeek Harness 提供沙箱和审批接缝，但安全并不会因为界面出现一个权限下拉框就自动成立。
三种模式控制什么
官方沙箱词汇包含 read-only、workspace-write 和 danger-full-access。它们主要约束文件副作用：只读、允许写工作区、放开文件访问。
这里有两个重要边界。第一，文件沙箱不等于完整网络隔离，也不承诺隐藏全部进程。第二，沙箱执行器约束的是同一主机世界里的子进程；如果 Bash 在容器、文件工具却在宿主机，Agent 会处在两个不一致的文件世界。
默认基线怎么设
第一次接入仓库，建议使用 workspace-write + ask：允许在明确工作区内修改，超出边界需要一次性审批。纯审查任务使用 read-only。danger-full-access 只适合隔离环境中范围清楚、可回滚的任务，不应成为团队默认值。
官方权限预设把沙箱模式和审批策略组合为一个选择，但执行仍由各自能力服务负责。自定义组合可能显示为 custom，不要只看 UI 名称，应记录最终两项机制值。
权限升级为什么必须“一次性”
受限命令被拒绝后，工具可以带 sandbox_permissions 和 justification 请求更宽权限。批准只应覆盖这一次重试，不应永久改变后续所有命令。
一个合格的理由应包含：原命令为什么失败、需要访问的具体路径或能力、为什么更窄的权限不够、执行后如何验证。类似“需要权限才能继续”没有审查价值。
不要允许 Agent 通过换命令、复制文件或调用其他工具绕过拒绝。沙箱拒绝是策略信号，不是提示模型寻找漏洞。
Shell 沙箱不是所有工具的沙箱
文件、Web、MCP 和自定义工具可能在进程内执行，它们需要在各自能力接缝实现策略。给 Bash 套上 argv 包装器，无法自动限制一个闭包直接调用 ctx.fs 或向外部 API 发请求。
因此每新增一个插件，都要回答：它能访问哪些服务？是否执行安装脚本？是否联网？是否读取会话和凭据？是否能修改配置？卸载时是否清理资源？
密钥分三层管理
开发者个人实验可以使用 Harness 凭据存储，但团队环境还需要外部 Secret Manager、短期凭据和轮换。不要把 Key 写入 Patch、提示词、Session 日志、CI Artifact 或截图。
模型 Key、代码仓库 Token、部署凭据应分开。一个 Agent 能调用模型，不代表它也应该拥有发布权限。外部写操作最好由独立工具接收窄范围参数，并在服务端校验，而不是向模型暴露通用 Shell Token。
插件供应链基线
固定准确版本和完整性；审查 package.json 安装脚本；优先官方源或内部镜像；记录插件声明的服务依赖；上线前测试加载、禁用、卸载和升级；对本地路径插件保留源码审查记录。
官方仍将项目置于快速演进阶段。v0.1.7-alpha.1 还修复过 Windows 沙箱跨工作区删除问题，这正说明安全结论必须绑定版本和平台，而不是永久信任一个开关。
最终建议
把安全策略写成五层：隔离工作区、最小文件权限、一次性审批、窄范围凭据、独立验收。默认拒绝不可解释的扩权，默认记录工具和审批事实，默认让外部系统验证最终结果。
沙箱的价值不是保证 Agent 永不犯错，而是把一次错误能造成的影响限制在可理解、可恢复的范围内。
继续阅读：Session 事件、日志重建与可观测性。密钥治理可延伸阅读大模型 API Key 安全实践，完整顺序见DeepSeek Harness 专题路线。