从官方文档到 GitHub 源码拆解 dangerous command approval 的完整安全链路导读普通 Chatbot 最多“说一句话”而 Hermes Agent 这类系统会调用工具、读写文件、跑终端命令、连接外部服务。能力越强安全边界越重要。尤其是终端命令一旦执行错了可能删除文件、重置 Git、覆盖配置、停止服务甚至让整台机器不可用。所以Hermes 的设计思路不是“相信模型一定不会犯错”而是把命令执行放进一条受控链路模型提出动作运行时系统负责检测风险、请求审批、执行或阻断并在必要时提供隔离和回滚。一、先说结论危险命令不是直接运行而是先过安全门1.1 模型只负责提出动作运行时决定能不能做在 Hermes 里模型不会直接操作你的电脑。模型输出的是一个 tool_call比如“我要调用 terminal 工具执行某条命令”。真正执行之前terminal_tool 会接管这条命令并进入预执行安全检查。这就是 Agent 和普通脚本最大的区别脚本写什么就跑什么Agent 是“模型提议 工具系统审查 环境执行”。1.2 为什么 Agent 执行命令更危险因为 Agent 的命令不是程序员逐行手写的而是模型根据上下文动态生成的。模型可能误解任务、被项目文件里的提示注入影响、把测试环境当生产环境、把“清理缓存”理解成删除目录。安全机制要防的不是“模型作恶”而是“模型在不确定环境下误操作”。二、Hermes 的安全边界不是一个开关而是多层防线2.1 官方安全模型的七层含义官方 Security 文档把 Hermes 的安全模型拆成七层用户授权、危险命令审批、容器隔离、MCP 凭证过滤、上下文文件扫描、跨会话隔离、输入净化。这里讨论的危险命令审批只是其中一层但它和容器隔离、输入净化、回滚机制会一起发挥作用。2.2 只靠 Prompt 不够很多系统会在系统提示词里写“不要执行危险命令”。这当然有用但不够。因为 Prompt 是软约束工具运行时才是硬约束。Hermes 把危险命令检查写在工具执行入口和 approval.py 里属于运行时强制机制。三、危险命令从哪里进入系统terminal_tool 是关键入口3.1 Tool Call 的流转路径当模型决定调用终端工具时命令字符串会进入 terminal_tool(command...)。这个函数会读取终端环境配置创建或复用执行环境然后在真正 env.execute(command) 之前运行安全检查。3.2 force 参数为什么不能给模型用源码里 terminal_tool 有 force 参数含义是“用户已经确认后跳过危险命令检查继续执行”。这个参数属于内部流程不应该暴露给模型作为普通工具参数。否则模型就可能绕过审批。正确做法是模型提出命令系统弹出审批用户确认后由系统带 force 重新执行。四、第一道门先判断执行环境4.1 本机、SSH、容器的风险不同同一条命令在不同环境里的风险完全不一样。比如在本机执行可能直接修改用户文件、系统配置和密钥在隔离容器里执行影响范围通常被限制在沙箱内。Hermes 的 approval.py 会根据 env_type 区分本机、SSH、Docker、Singularity、Modal、Daytona、Vercel Sandbox 等执行环境。4.2 容器隔离不是万能的容器让风险边界更小但并不等于没有风险。比如挂载了宿主机目录、转发了敏感环境变量、允许访问内网服务容器内命令仍然可能造成影响。所以企业落地时要同时控制容器权限、挂载目录、环境变量转发和网络访问。五、第二道门Hardline 硬阻断5.1 什么是 HardlineHardline 是比“危险命令审批”更底层的安全底线。普通危险命令可以让用户确认后执行但 Hardline 命令具有不可恢复或极高破坏性Hermes 会直接阻断。5.2 为什么 YOLO 也不能越过 Hardline源码注释里有一个非常重要的安全观念开启 YOLO 代表用户信任 Agent 处理文件和服务不代表允许 Agent 擦除磁盘、关机或摧毁系统。因此 Hardline 检查发生在 YOLO 之前。六、第三道门命令规范化与危险模式识别6.1 先清洗再匹配危险命令检测不是直接拿原始字符串匹配。approval.py 会先做命令规范化去掉 ANSI 控制序列、移除空字节、做 Unicode NFKC 归一化然后再用预编译的危险模式列表匹配。这样可以降低简单混淆手法造成漏检的概率。6.2 DANGEROUS_PATTERNS 主要覆盖哪些风险从源码看危险模式覆盖的不是单一命令而是一组高风险行为递归删除、权限放开、系统文件改写、SQL DROP/DELETE/TRUNCATE、远程内容管道执行、find -delete、Git reset/clean/force push、sudo 权限相关操作等。七、第四道门sudo stdin 守卫7.1 它防的不是普通 sudo而是“模型猜密码”如果模型构造 sudo -S 这类从标准输入读取密码的命令并根据错误输出反复尝试就可能变成一个自动化密码猜测流程。Hermes 在没有配置 SUDO_PASSWORD 的情况下会把这类模式作为无条件阻断处理。7.2 为什么它要放在 YOLO 前面sudo stdin 守卫属于防提权、防密码猜测的安全底线。即使用户开启了自动审批也不应该让模型通过 stdin 猜密码或构造提权链路。八、第五道门审批模式 manual、smart、off 与 YOLO8.1 manual默认人工确认manual 是最稳妥的默认模式。只要命令命中危险模式系统就会暂停执行并提示用户查看命令和风险原因。用户可以选择仅本次、当前会话、永久允许或者拒绝。8.2 smart用辅助模型减少审批疲劳smart 模式会调用辅助 LLM 判断实际风险。比如某些命令因为包含脚本执行参数被模式命中但实际只是打印 hello这类低风险命令可以自动放行真正危险的命令拒绝不确定的情况升级给人。8.3 off 与 YOLO只适合可信环境off 和 YOLO 都会跳过危险命令审批提示。官方文档也明确提醒这类模式只适合可信环境比如短生命周期容器、受控 CI、一次性沙箱不适合长期运行的生产服务器。九、CLI 与 Gateway 下的审批怎么走9.1 CLI同步阻塞等用户输入在 CLI 中危险命令命中后会暂停当前执行显示风险原因和具体命令等待用户输入。如果超时或用户取消就默认拒绝。这种方式直接、简单适合人在终端前操作。9.2 Gateway异步排队等消息平台回复在 Telegram、Discord、Slack 等入口下Agent 往往运行在服务器线程里用户不在终端前。Hermes 会把审批请求放进 session 队列通过消息平台发送给用户用户回复 approve/deny 后再唤醒等待中的 agent 线程。十、审批通过后允许范围有多大10.1 once、session、always 的区别一次审批不应该无限放大。Hermes 把审批范围分成 once、session、alwaysonce 只允许本次session 允许当前会话内同类风险always 写入永久 allowlist。范围越大便利性越高风险也越高。10.2 建议怎么选临时性、破坏性、不常用的命令选 once重复测试或临时环境里的低风险命令可选 sessionalways 应该只给确定安全、确定必要、确定长期重复的命令模式。生产环境不建议轻易使用 always。十一、执行阶段仍然有保护11.1 长进程不能随便前台跑terminal_tool 会识别一些明显的长生命周期命令比如 dev server、watch、serve 等。如果模型想在前台直接跑系统会提示使用 backgroundtrue 管理进程再通过 readiness check 或后续命令验证。这样可以避免 Agent 卡在前台命令里。11.2 输出进入上下文前也要处理命令执行结果会进入模型上下文所以输出也要处理截断超长输出、去掉 ANSI 控制符、脱敏敏感信息并解释一些不代表失败的非零退出码。十二、Checkpoints 与 /rollback审批之外的兜底12.1 审批负责“防止误跑”回滚负责“跑错能退”审批机制能减少危险命令误执行但不能覆盖所有文件修改风险。官方 Checkpoints Rollback 文档说明Hermes 可以在破坏性文件操作前创建快照并通过 /rollback 恢复。12.2 Shadow Git 的意义官方文档强调检查点使用独立的 shadow git 存储不触碰项目自己的 .git。这样即使项目本身没有初始化 Git也可以获得一层文件系统级别的恢复能力。十三、源码阅读路线想深入就看这几处13.1 第一站tools/terminal_tool.py这里是终端命令的真实执行入口能看到 env_type 解析、环境创建、预执行安全检查、background 进程管理、输出截断、脱敏和退出码解释。13.2 第二站tools/approval.py这里是危险命令机制的核心Hardline、DANGEROUS_PATTERNS、命令规范化、session 审批状态、永久 allowlist、smart approval、gateway pending approval 都在这里。13.3 第三站Security / Configuration / Slash Commands 文档文档可以帮你把源码里的机制和用户侧配置对上approvals.mode、timeout、/approve、/deny、/yolo、--yolo、HERMES_YOLO_MODE 等都在这些文档里有说明。十四、企业落地建议做自己的 Agent也应该这样设计14.1 不要把高危工具直接暴露给模型模型可以提出动作但高危动作必须由运行时系统审查。比如终端、数据库写操作、云资源删除、生产发布、支付退款都应该有工具级安全网。14.2 审批要有范围、超时和日志一次审批只应该在明确范围内生效。系统应该记录谁批准、批准了什么命令、批准原因、在哪个 session 中执行、执行结果是什么。14.3 沙箱、最小权限、回滚要一起上审批只能降低风险不能替代隔离。生产级 Agent 应该同时具备最小权限、容器或虚拟机隔离、敏感环境变量过滤、网络访问策略、文件快照和回滚。十五、总结Hermes 的危险命令安全机制本质是“运行时治理”Hermes Agent 的危险命令机制不是简单的“拦一个 rm 命令”而是一套完整的运行时治理体系。模型只负责生成意图terminal_tool 负责接管执行approval.py 负责识别风险和管理审批Gateway 负责把确认请求送到用户面前容器和权限边界负责缩小破坏范围Checkpoints 和 /rollback 负责最后兜底。这套设计给所有 Agent 工程一个非常重要的启发越是能干活的 Agent越不能只靠 Prompt 约束。真正可靠的 Agent需要把安全机制写进工具运行时写进执行链路写进权限边界写进可恢复能力。附危险命令机制速查表模块解决的问题典型位置设计启发terminal_tool命令执行入口接管真实运行tools/terminal_tool.py工具入口必须有预执行检查approval.py危险模式识别、审批状态、hardlinetools/approval.py安全策略要集中管理manual approval人确认高风险动作CLI / Gateway高风险动作要 human-in-the-loopsmart approval减少低风险误拦截辅助 LLM自动化与安全要平衡YOLO/off跳过审批CLI/config/env只适合可信沙箱Checkpoints文件修改前快照/rollback防误操作要有恢复能力