Hermes Agent 安全架构：审批、沙箱、回滚与凭据隔离
内容提要
本文介绍Hermes Agent安全架构，强调安全不能仅靠提示模型谨慎，而需多层防护：网关鉴权、工具作用域、命令审批、文件保护与回滚、沙箱隔离及凭据出站代理。各层针对不同威胁，如陌生用户、危险命令、误删文件、代码影响宿主及凭据泄露，无人值守场景需Fail-Closed策略。
延伸解读
安全分层：各司其职，不可互相替代
文章强调安全不能依赖单一机制，而是多层防线协同。审批、沙箱、回滚和凭据代理分别针对不同威胁：审批判断命令是否危险，沙箱限制影响范围，回滚处理误操作，凭据代理控制敏感信息泄露。这些层不能互相替代，例如Checkpoint能恢复文件但不能阻止命令执行，容器限制影响范围但不判断业务操作是否合理。理解每层的职责边界，才能正确配置安全策略。
无人值守场景的Fail-Closed策略
在Cron、单次查询等无人值守场景中，没有人类确认通道，因此Hermes为headless场景单独定义审批策略。当权限回调超时、失去Session Lease或无法证明恢复所有权时，系统更倾向于拒绝或中断，确保安全。而观察日志等非关键Hook可以Fail-Open，避免可观测性插件拖垮主流程。这种区分体现了安全与可用性的平衡。
凭据隔离：从环境过滤到出站代理
文章指出，MCP子进程和生成代码只能拿到过滤后的环境，而Iron Proxy可让沙箱只持有映射Token，在受控出站处替换真实凭据并执行Host/CIDR规则。这解决了凭据进入子进程或出站请求的风险。但需注意，这些机制不能补救已经写进Prompt的秘密，因此开发者仍需避免在提示中硬编码敏感信息。
Q&A
Hermes Agent 的安全架构包含哪些主要层次？
Hermes Agent 的安全架构包含多层防护：网关鉴权（平台 Allowlist 与 DM Pairing）、工具作用域（会话工具集与托管作用域）、命令审批（Hardline Blocklist、用户 Deny、Smart/Manual Approval）、文件保护与回滚（保护路径、Safe Root、Shadow Git Checkpoint）、沙箱隔离（本地/SSH/Docker/Modal 等后端）以及凭据出站代理（环境过滤、Secret Source、Egress Proxy）。
Hermes Agent 如何防止模型执行危险命令？
Hermes Agent 通过多层机制防止危险命令：Hardline Blocklist 包含不可恢复命令的黑名单，用户自定义 Deny 规则优先于普通审批，Smart Approval 在低风险、拒绝和人工确认之间路由，Manual Approval 则要求人工确认。这些机制在命令执行前进行拦截，但并非操作系统级沙箱。
Hermes Agent 的文件保护与回滚机制是如何工作的？
Hermes Agent 提供保护路径和可选的 HERMES_WRITE_SAFE_ROOT 来限制文件写入范围。启用 Shadow Git Checkpoint 后，在写文件或破坏性命令前，会将目录快照到 ~/.hermes/checkpoints/store/ 的共享对象库，不触碰真实项目的 .git。默认关闭，启用后每目录每 Turn 最多一份快照，用于事后恢复，但不决定操作是否允许。
Hermes Agent 如何隔离生成代码对宿主机的影响？
Hermes Agent 通过环境后端（Environment Backend）实现隔离，支持本地、SSH、Docker、Modal 等。对于不信任的代码，应选择 Docker 或 Modal 等隔离环境，并正确配置挂载和资源限制，以限制代码对宿主机的影响。终端命令以相应后端的 OS 权限运行，因此隔离效果取决于后端配置。
Hermes Agent 如何防止凭据泄露给子进程或出站请求？
Hermes Agent 通过环境过滤、Secret Source、MCP 隔离和 Egress Proxy 来防止凭据泄露。MCP 子进程和生成代码只获得过滤后的环境变量；Iron Proxy（Egress Proxy）让沙箱只持有映射 Token，在受控出站处替换真实凭据，并执行 Host/CIDR 规则。但无法补救已经写进 Prompt 的秘密。
为什么无人值守场景需要 Fail-Closed 策略？
无人值守场景（如 Cron、单次查询、Kanban Worker）没有可靠的人类确认通道，因此 Hermes 为 headless 场景单独定义审批策略。当权限回调超时、失去 Session Lease 或无法证明恢复所有权时，更倾向于拒绝或中断，即 Fail-Closed。而观察日志和非关键 Hook 可以 Fail-Open，避免可观测性插件拖垮主流程。
