DeepSeek Harness 安全吗？沙箱、审批与权限机制实测分析
DeepSeek Harness（简称 dsh）是 DeepSeek AI 开源的一款 Agent 运行框架，核心设计是"一切皆插件"：模型、工具、Agent 循环都能自由组合。既然它能读写文件、执行命令，安全问题自然是最先被问到的。本文基于 dsh 的实际机制，从权限沙箱、审批流程、凭据存储三个层面，给你一个客观的安全评估。
一、先说结论：安全设计是认真的，但要会用
dsh 在安全上做了三层防护：进程沙箱、操作审批、凭据只写存储。设计思路是"默认受限、按需放行"。但它毕竟是让 AI 操作你电脑的工具，最终的安全边界取决于你怎么配置——理解下面的机制，才能用得安心。
二、第一道防线：进程沙箱（三档权限）
dsh 内置进程沙箱，所有命令执行都在权限模式下运行。三种模式：
- 只读（read-only）：只能读取文件，不能修改，最安全
- 工作区可写（workspace-write）：只能修改工作区范围内的文件
- 完全访问（danger-full-access）：不限制，最高权限
实现方式因系统而异：
- Linux：bwrap / Landlock 沙箱
- macOS：sandbox-exec（Seatbelt）
- Windows：ACL 受限令牌 + PowerShell 沙箱
实用建议：对不熟悉的项目先用"只读"模式试水，确认 agent 的行为符合预期，再放宽到"工作区可写"。
三、第二道防线：操作审批
当 agent 执行的操作超出当前权限策略时，Web UI 会弹窗询问你，而不是自动放行。这是关键的一道闸：你可以在它动手前看清它想做什么，选择允许或拒绝。
这意味着：即使模型"想"做危险操作，也绕不过你的确认。当然，前提是你认真看审批弹窗，而不是无脑点允许。
四、第三道防线：凭据只写存储
API 密钥的存储方式值得一提：
- 明文密钥只存放在 $DSH_HOME/.credentials.yaml（默认 ~/.dsh 下）
- 界面和设置只保留脱敏引用，不显示明文
- 好处：截图、日志、浏览器扩展都拿不到你的真实密钥
自己要注意的：不要把 ~/.dsh 目录同步到云盘或提交进代码仓库，那会把密钥一起带走。
五、网络与端口：默认只在本机
Web UI 默认监听 http://127.0.0.1:3080，这是本机回环地址，只有你自己电脑能访问，不会直接暴露到局域网或公网。官方命令行也刻意不支持绑定所有网卡地址，从设计上避免误暴露。
如果你确实需要远程访问（比如配合 OpenClaw 这类网关使用），属于主动配置行为，务必自己做好网络层面的访问控制。
六、一个需要特别留意的模式
内置的"创造模式"（cordis 预设）允许 agent 读改写自身运行时——官方注释明确提示：此模式视同 shell 访问。也就是说，在这个模式下，agent 对这台机器有很高权限。日常使用请保持默认模式，只在确实需要开发插件、创建新预设时才临时切换。
七、其他安全考量
开源可审计：dsh 是 MIT 开源项目，代码完全公开（https://github.com/deepseek-ai/deepseek-harness），安全实现可以被任何人审查，这本身就是一种保障。
生态风险：社区第三方插件、第三方桌面壳并非官方出品，安装前建议确认项目活跃度与来源可信度。
数据归属：你的对话、会话记录保存在本地 $DSH_HOME/sessions，不上传官方服务器；模型请求发送给你配置的 API 端点。
总结
DeepSeek Harness 的安全设计是成体系的：进程沙箱三档权限、操作审批拦截、凭据只写存储、默认本机监听，配合开源可审计的代码，对本地工具来说防护是到位的。它的安全底线最终由使用者掌握——保持默认权限、认真对待审批弹窗、不随意启用创造模式，就能把风险控制在合理范围内。
