Hermes Agent 安全架构：审批、沙箱、回滚与凭据隔离

前言：Agent 真正能写文件、执行终端、连接远端服务之后，“提示模型小心一点”就不再是安全设计。Hermes 把身份、工具作用域、命令审批、文件恢复、运行环境和凭据出站拆成多层边界。本文按威胁类型重新梳理这些机制，也说明每一层解决不了什么。

系列导航：这组文章按“总览 → 入口 → 运行时 → 扩展 → 状态 → 协作 → 安全”的顺序展开；第一次阅读可以从总览开始，带着具体问题也可以直接跳到专题。

Gateway 把入口复杂性挡在会话之外

消息网关使用 PlatformRegistry 管理平台适配器。一个 PlatformEntry 会描述适配器工厂、依赖探测、配置校验、授权字段、消息长度、独立投递能力和平台提示。

平台 SDK 往往很重，所以 Registry 支持 deferred loader：普通 CLI 启动时不需要把所有消息平台 SDK 都导入，只有实际查询或启动某个平台时才加载对应插件。这是插件架构直接服务冷启动性能的例子。

入站事件最终变成统一的 SessionSource，包含 platform、chat、user、thread、scope 和 profile 等信息。网关据此鉴权、生成稳定 session key、恢复会话、解析模型与工具集，再构造或复用 AIAgent。

网关按会话缓存 Agent，这不只是为了少跑一次构造函数，更是为了保留冻结的 Prompt、工具快照和会话状态。当然缓存也会制造新问题：数据库历史可能被别的进程改了，session id 可能切换，旧 Agent 可能对应已经结束的会话。因此源码里能看到大量缓存失效和重新基线逻辑。

安全不是一句“请谨慎”

flowchart TD
    Input[用户 / 外部平台输入] --> Auth[平台 Allowlist 与 DM Pairing]
    Auth --> Agent[智能体循环
Agent Loop]
    Agent --> Scope[会话工具集与托管作用域
Session Toolset + Managed Scope]
    Scope --> SideEffect{准备产生副作用}
    SideEffect --> Policy[Hardline Blocklist / 用户 Deny / Hook]
    Policy --> Approval[Smart 或 Manual Approval]
    Approval --> WriteGuard[文件保护路径 + 可选 Safe Root]
    WriteGuard --> Checkpoint[可选 Shadow Git Checkpoint]
    Checkpoint --> Backend[本地 / SSH / Docker / 沙箱后端
Local / SSH / Docker / Sandbox Backend]
    Backend --> Secrets[最小化环境与凭据显式映射]
    Secrets --> Egress[可选 Egress Proxy：域名策略 + 出站凭据替换]
    Egress --> External[文件系统 / 进程 / 网络]

这些层不能互相替代。tools/approval.py 的不可恢复命令 Blocklist 位于 YOLO 之下，用户自定义 Deny 也先于普通审批；Smart Approval 只是在低风险、拒绝和人工确认之间路由，不是操作系统隔离。write_file / patch 还有保护路径与可选 HERMES_WRITE_SAFE_ROOT，但终端仍以相应 Backend 的 OS 权限运行，所以真正不信任代码时要选 Docker、Modal 等隔离环境。

Checkpoint 又是另一类能力：它在写文件或破坏性命令前，把目录快照到 ~/.hermes/checkpoints/store/ 的共享 Shadow Git 对象库，真实项目的 .git 不会被碰；默认是关闭的，启用后每目录每 Turn 最多一份快照。它解决“做错后如何恢复”，并不决定“这次能不能做”。Secrets 与 Egress 则解决凭据暴露面：MCP 子进程和生成代码拿到过滤后的环境，Iron Proxy 可让沙箱只持有映射 Token，在受控出站处再替换真实凭据并执行 Host/CIDR 规则。把审批、恢复、隔离和凭据代理混成一个“安全开关”，会误读这套架构。

先按威胁类型选防线

要防什么	主要机制	它不负责什么
陌生用户驱动 Agent	平台 Allowlist、DM Pairing、Backend Auth	不判断具体命令是否危险
模型误执行危险命令	Hardline Blocklist、用户 Deny、Smart / Manual Approval	不是对抗恶意进程的 OS Sandbox
文件写错或误删	保护路径、Safe Root、可选 Checkpoint / Rollback	不能替代 Git 分支与备份
生成代码影响宿主机	Docker、Modal、SSH 等 Environment Backend	需要正确配置挂载和资源限制
凭据进入子进程或出站请求	环境过滤、Secret Source、MCP 隔离、Egress Proxy	不能补救已经写进 Prompt 的秘密

这也是为什么文章不把安全归结为“有没有审批弹窗”。审批、恢复、隔离和凭据代理分别覆盖不同失败模式：Checkpoint 可以撤回写错的文件，却不会阻止命令执行；容器限制影响范围，却不判断业务操作是否应该发生；Egress Proxy 控制真实凭据和出站目标，也不会替代平台身份认证。

无人值守路径为什么更需要 Fail-Closed

交互式 CLI 可以停下来问用户，Cron、单次查询、Kanban Worker 和某些 ACP Host 却没有可靠的人类确认通道。Hermes 因此为 headless 场景单独定义审批策略；权限回调超时、失去 Session Lease、无法证明恢复所有权等正确性边界更倾向于拒绝或中断。观察日志和非关键 Hook 则可以 Fail-Open，避免一个可观测性插件拖垮主流程。