📚 系列导航：上一篇 Hermes Agent 安装与部署教程 已经讲清“安装与部署教程（Windows、macOS、Linux）”；本篇聚焦 Hermes Agent 安全配置；下一篇 Hermes Agent Promptware 防御指南 继续学习“Promptware 防御与可观测性指南”。
先给结论：审批、脱敏和模式扫描只能降低风险，真正的安全边界是操作系统级隔离。 如果 Agent 能执行命令、加载插件或接触凭证，不要因为开了几条检查规则就默认它已经安全。
ℹ️ 版本说明： 原稿基于 Hermes Agent v0.16.0（2026 年 6 月）源码整理。本文保留其版本化机制分析；命令、数量和界面请以 Hermes Agent 官方文档 与本地输出为准。
Hermes Agent 的操作系统安全边界
两个月前的旧版 Hermes，安全这块几乎是空白。我翻旧调研笔记，搜 sandbox、approval 这些词，一个实质内容都搜不到。
到了 v0.16.0，它长出了一份 332 行的 SECURITY.md。整份文档的骨架，可以浓缩成官方的一句原话：
官方原话：「针对一个对抗性的 LLM，唯一的安全边界是操作系统。」（The only security boundary against anadversarial LLM is the operating system.）
我第一次读到这句，是有点意外的。市面上的 Agent 产品都在比谁的防护层数多，输入过滤、输出脱敏、危险命令检测、工具白名单，一层叠一层，听着很安心。Hermes 的文档直接说：这些进程内的东西，没有一个构成真正的隔离。
它的逻辑其实很费曼。LLM 吐出来的每一个字符，都可能被攻击者通过 prompt 注入影响。你在进程里跑任何扫描器去筛查这串输出，本质上是在一个受攻击者操控的字符串上跑启发式规则。规则再聪明，也只是启发式，不是边界。
安全边界与进程内启发式检查的区别
这是全章最重要的一个区分。Hermes 把进程里的安全组件统一叫「启发式」，把 OS 级隔离叫「边界」。两个词不能混。
| 进程内组件 | 它在做什么 | 为什么不是边界 |
|---|---|---|
| 审批门 | 执行前检测常见的破坏性 shell 命令,弹窗让你确认 | shell 是图灵完备的,对它做黑名单结构上不可能穷尽 |
| 输出脱敏 | 从显示层剥掉看起来像密钥的字符串 | 有动机的输出生产者总能绕过 |
| SkillsGuard | 扫描待安装 skill 里的注入模式 | skill 在 import 时执行任意 Python,读描述拦不住代码 |
这套区分有个特别诚实的推论，写在文档的「范围」一节里：绕过这些启发式，不算漏洞。你研究出怎么用正则绕过审批门，或者怎么骗过脱敏，Hermes 欢迎你提 issue，但不会走私密披露通道、也不发安全公告。因为它从一开始就没把这些当边界，绕过一个本来就不严密的东西，不构成「破防」。
反过来，什么算真漏洞？逃逸已声明的 OS 隔离、未授权访问外部接口、本该被剥离的凭证泄漏了，这些动了真边界，才进安全范围。
💡 核心建议
这个态度我蛮欣赏的。「Out of scope 不等于不值得报告」。审批门永远能多抓几个模式，脱敏永远能更聪明，但承认它们的天花板，比假装它们密不透风要负责任得多。
Hermes Agent 的操作系统级隔离方式
既然进程里没有边界，operator 就必须主动选一种 OS 级隔离姿态。Hermes 给了两条路。
使用终端后端隔离 Agent 命令
第一种是终端后端隔离。把 LLM 吐出的 shell 命令丢进容器、远程主机或云沙箱里跑，文件读写工具也走这个后端，够不到后端没暴露的路径。它管得住 agent 通过 shell 和文件做的事，但管不住 agent 在自己 Python 进程里做的一切：代码执行工具、MCP 子进程、plugin 加载、skill 加载，这些全是 import 进同一个解释器的。
所以文档专门警告了一句误解：「在终端后端沙箱里却指望它管住不走 shell 的代码路径，是在支持的安全姿态之外操作。」很多人开了 Docker 就觉得安全了，这话正好戳破这个错觉。
第二种是整进程包裹。把整个 agent 进程树丢进沙箱，shell、代码执行、MCP、文件工具、plugin、hook、skill 加载全受同一套文件系统和网络策略约束。Hermes 自带 Docker 镜像可以这么干，更硬核的是接 NVIDIA 的 OpenShell：每会话一个沙箱，文件系统、网络出口、syscall、推理路由都能声明式管控，凭证从外部 store 注入，永不落到沙箱的文件系统里。
到 v0.16.0，沙箱后端从旧版的单一 local 长到了七种。
| 后端 | 隔离能力 | 备注 |
|---|---|---|
| local(默认) | 无,直接在宿主跑 | 但有凭证剥离兜底 |
| docker | 容器 | 自带镜像,非 root 用户 |
| singularity | 持久容器 | capability dropping、资源限制硬化 |
| daytona / modal | 云沙箱 | 每命令前 resync 文件 |
| ssh | 远程主机 | 凭证文件按需 sync 进去 |
Hermes Agent 危险命令审批机制
就算选了 OS 边界，约束层里最具体的那块代码还是值得逐行看的。审批门这个文件 1701 行，注释里自称是「危险命令系统的唯一真相源」。
它的执行顺序，藏着整套设计哲学。
沙箱后端的审批策略
如果已经在 Docker、modal 这类 OS 沙箱里，进程内审批就没必要了，直接通过。这跟「唯一边界是 OS 的立场完全自洽：有了真边界，启发式可以让位。
危险命令的硬性拦截规则
有一类命令没有恢复路径： rm -rf / 、 mkfs 、 dd 写裸设备、关机重启、forkbomb。这些在 YOLO 模式生效之前就被无条件 block。注释写得很直白：「开 YOLO 是信任 agent 碰你的文件和服务，不是信任它擦盘或把机器关机。
YOLO 模式与危险命令检测
过了硬底线，才轮到 YOLO 全放行，或者逐条模式匹配加 session 审批缓存。约 50 条正则，覆盖磁盘破坏、权限滥用、SQL 删库、远程代码执行、sudo 提权、git 强推等等。
有个细节特别能体现「进程内组件不可信」是怎么落到实现的。YOLO 模式在模块 import 时就被冻结，不是每次调用都去读环境变量。注释解释了原因：如果每次都读 os.environ，进程里任意一个 skill 都能偷偷设这个变量、瞬间绕过所有审批，这就是一条现成的 prompt 注入提权路径。把它冻死在 import 那一刻，这条路就堵了。
审批门还有一层「自我保护」是 agent 特有的：禁止 agent 杀掉自己的 gateway 进程、禁止 docker compose down 、禁止把自己关掉。一个能自治运行的 agent，得防着它把管自己的那只手给剁了。
更进一步，被模式 flag 住的命令还能交给一个辅助 LLM 做「安全审查员」，返回放行、拒绝或升级给人。这里其实有个值得玩味的张力：用一个 LLM 去判断另一个 LLM 的输出安不安全，这跟「LLM 输出是受攻击者影响的字符串」的立场，内在是有点矛盾的。所以它失败时一律保守升级给人，不赌。
Hermes Agent 凭证隔离与泄漏风险
讲到「真边界」和「假边界」的差别，有个 GHSA 安全公告是最好的实锤。
Hermes 给低信任的进程内组件传环境变量时，包括 shell 子进程、MCP 子进程、代码执行子进程，默认剥离 provider 的 API key 和 gateway token，只放行 operator 或已加载 skill 显式声明的变量。这个剥离不是硬编码黑名单，而是遍历所有 provider 配置动态派生出来的。
为什么要这么干？因为有过真实的攻击路径。源码注释里记着一类已修复的漏洞：一个恶意 skill 把
ANTHROPIC_TOKEN 、 OPENAI_API_KEY 注册成 passthrough 变量，在代码执行子进程里拿到这些凭证，从而击穿沙箱的凭证擦除。修复方式很干脆：provider 凭证进黑名单，skill 不可覆盖。
⚠️ 注意
但文档同时诚实地标注：凭证剥离本身也不是 containment。任何跑在 agent 进程里的组件，都能读 agent 自己能读的一切，包括内存里的凭证。真正的缓解只有一个：安装前 operator 自己审查代码。第三方 skill 和 plugin 的边界，永远是「装之前读它的 Python」，不是读它的描述文件。
Hermes Agent 安全配置原则
把上面的东西串起来，Hermes 对安全的整体态度其实是一句话：不在进程内造护城河，而是把进程整个丢进 OS 沙箱，再把一切行为暴露给可观测性契约，让人和工具能事后审计。
这和「用更聪明的 prompt 去约束 agent」是两条相反的路。后者听起来更高级、更 AI，但它建在一个不可信的地基上：你没法用一个能被劫持的东西去约束自己。
顺带说一句，审批门的注释里反复出现 Claude Code 和 OpenAICodex 的名字，很多危险模式的灵感直接标了来源。主流 Agent 的约束层正在趋同，危险命令检测慢慢变成了行业公共知识。这本身也是个信号：大家都在同一个现实里，LLM 的输出靠不住，真正的安全只能往 OS 那一层沉。
下一章我们接着这条线往深走：当 agent 开始自改进、自治运行，这套「唯一边界是 OS」的哲学还撑不撑得住，它到底能走多远。
常见问题
Hermes Agent 开启审批后就安全吗？
不是。审批规则属于启发式检查，无法穷尽所有 shell 行为。需要处理不可信内容或长期无人值守时，应使用容器、远程主机或云沙箱提供真正隔离。
Hermes Agent 应该使用哪个终端后端？
本地开发且任务可信时可以使用 local；需要降低主机风险时优先 Docker；需要把执行环境放到另一台机器时选择 SSH 或支持的云沙箱。
这篇教程里的版本数字会变化吗？
会。原稿以 Hermes Agent v0.16.0 为分析基线，平台、工具、命令参数和默认配置可能继续变化；实际操作前请核对当前官方文档和本地命令帮助。