07. Hermes Agent 安全机制——审批、授权与容器隔离

让 AI 智能体执行命令意味着把控制权交了出去。Hermes Agent 用七层纵深防御模型回答了一个核心问题：如何在赋予 agent 行动能力的同时，守住安全底线。

七层纵深防御概览

Hermes 的安全模型不是单一的审批门，而是一组层层叠加的安全边界：

1. 用户授权 — 谁可以与 Agent 通信（允许列表、DM 配对）
2. 危险命令审批 — 针对破坏性操作的人工审核
3. 容器隔离 — Docker/Singularity/Modal 沙箱及加固配置
4. MCP 凭据过滤 — MCP 子进程的环境变量隔离
5. 上下文文件扫描 — 检测项目文件中的 prompt 注入
6. 跨会话隔离 — 会话之间无法访问彼此数据
7. 输入清理 — 终端工具的工作目录参数经允许列表验证，防 shell 注入

每一层都假设上一层可能被突破，这种"不信任任何单一边界"的思路正是纵深防御的核心。

危险命令审批：三种模式

在执行任何命令之前，Hermes 会将其与一份精心维护的危险模式列表进行比对。审批系统支持三种模式：

# ~/.hermes/config.yaml
approvals:
  mode: manual    # manual | smart | off
  timeout: 60     # 等待用户响应的秒数

• manual（默认）：始终提示用户审批危险命令。
• smart：使用辅助 LLM 评估风险。低风险命令自动批准，真正危险的自动拒绝，不确定的升级为手动提示。
• off：禁用所有审批检查，等同于 YOLO 模式。

CLI 中的审批提示提供四个选项：

⚠️ DANGEROUS COMMAND: recursive delete
rm -rf /tmp/old-project

[o]nce | [s]ession | [a]lways | [d]eny

选择 always 会把该模式保存到 config.yaml 的 command_allowlist 中，在所有后续会话中静默批准。审批超时默认 60 秒，超时后命令默认被拒绝——故障关闭。

YOLO 模式与硬性黑名单

YOLO 模式绕过当前会话中所有危险命令审批提示，可通过 CLI 标志、/yolo 斜杠命令或环境变量激活。当 YOLO 激活时，Hermes 会显示两个持久的视觉提醒——会话开始的红色横幅和状态栏中的警告徽章。

但 YOLO 并非"无限制"。Hermes 有一份硬性黑名单，无论 YOLO 是否开启、审批模式是否关闭，以下命令始终被拒绝：

模式	原因
rm -rf / 及变体	清除文件系统根目录
:(){ :|:& };:	bash fork 炸弹，使主机挂起
mkfs.* 作用于根设备	格式化运行中的系统
dd if=/dev/zero of=/dev/sd*	清零物理磁盘
curl ... | sh（根文件系统顶层）	远程代码执行攻击面过大

黑名单是 YOLO 之下的底线。它在审批层看到命令之前就触发，没有任何覆盖标志。如果合法工作流确实需要这些命令（如清除并重装流水线），请在 Agent 外部运行。

容器隔离：Docker 安全加固

使用 Docker 终端后端时，Hermes 对每个容器应用严格的安全加固：

_SECURITY_ARGS = [
    "--cap-drop", "ALL",              # 丢弃所有 Linux capabilities
    "--cap-add", "DAC_OVERRIDE",      # root 可写入绑定挂载目录
    "--cap-add", "CHOWN",             # 包管理器需要文件所有权
    "--cap-add", "FOWNER",
    "--security-opt", "no-new-privileges",  # 阻止权限提升
    "--pids-limit", "256",            # 限制进程数量
    "--tmpfs", "/tmp:rw,nosuid,size=512m",
    "--tmpfs", "/var/tmp:rw,noexec,nosuid,size=256m",
    "--tmpfs", "/run:rw,noexec,nosuid,size=64m",
]

容器内可配置 CPU、内存和磁盘限制：

terminal:
  backend: docker
  docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
  container_cpu: 1
  container_memory: 5120    # MB
  container_disk: 51200     # MB
  container_persistent: true

一个重要的安全特性是：在 docker、singularity、modal 或 daytona 后端运行时，危险命令检查会被跳过——因为容器本身就是安全边界，容器内的破坏性命令不会危害宿主机。这意味着切到容器后端后，审批疲劳问题自然消失。

用户授权：谁可以和 Agent 对话

运行消息 gateway 时，Hermes 通过分层授权系统控制谁可以与机器人交互。授权检查按以下顺序进行：每平台允许所有用户标志 > DM 配对已批准列表 > 平台专属允许列表 > 全局允许列表 > 全局允许所有用户 > 默认拒绝。

# ~/.hermes/.env
TELEGRAM_ALLOWED_USERS=123456789,987654321
DISCORD_ALLOWED_USERS=111222333444555666
GATEWAY_ALLOWED_USERS=123456789

若未配置任何允许列表且未设置 GATEWAY_ALLOW_ALL_USERS，则所有用户均被拒绝。这对于生产部署至关重要——默认关闭意味着不会有意外的访问。

对于更灵活的授权，Hermes 提供了基于验证码的 DM 配对系统。未知用户向机器人发送 DM 后会收到一个 8 位配对码，机器人所有者在 CLI 上运行 hermes pairing approve <platform> <code> 批准。配对系统遵循 OWASP + NIST SP 800-63-4 指南：验证码使用 32 位无歧义字母表、密码学安全随机数、1 小时过期、每用户每 10 分钟 1 次速率限制、5 次失败后 1 小时锁定。

凭据过滤与环境变量透传

execute_code 和 terminal 都会从子进程中剥离敏感环境变量——名称中包含 KEY、TOKEN、SECRET、PASSWORD、CREDENTIAL 的变量默认被阻止。但某些 skill 确实需要访问特定凭据，Hermes 提供了两种受控的透传机制：

技能作用域透传（自动）： 技能在 SKILL.md frontmatter 中声明 required_environment_variables，加载时自动注册为透传变量：

required_environment_variables:
  - name: TENOR_API_KEY
    prompt: Tenor API key

基于配置的透传（手动）： 对于未被技能声明的变量，添加到 config.yaml：

terminal:
  env_passthrough:
    - MY_CUSTOM_KEY
    - ANOTHER_TOKEN

透传仅影响你或你的技能明确声明的变量——任意 LLM 生成代码的默认安全态势不变。缺失或未设置的变量永远不会被注册，不存在的内容无法泄露。

SSRF 防护与上下文注入扫描

所有支持 URL 的工具在获取 URL 之前都会进行验证，防止服务器端请求伪造（SSRF）。被阻止的地址包括私有网络（RFC 1918）、回环地址、链路本地地址（含云元数据 169.254.169.254）、CGNAT 地址空间等。DNS 失败被视为阻止（故障关闭），重定向链在每一跳都重新验证。

上下文文件（AGENTS.md、.cursorrules、SOUL.md）在被纳入系统 prompt 之前会扫描 prompt 注入。扫描器检查"忽略先前指令"类内容、隐藏 HTML 注释中的可疑关键词、尝试读取密钥的指令、通过 curl 泄露凭据的模式，以及不可见 Unicode 字符（零宽空格、双向覆盖）。被阻止的文件不会加载，而是显示警告。

生产部署检查清单

将 Hermes 投入生产环境前，请逐项确认：

• 设置明确的允许列表——切勿使用 GATEWAY_ALLOW_ALL_USERS=true
• 使用容器后端——terminal.backend: docker
• 限制资源上限——设置合适的 CPU、内存和磁盘限制
• 安全存储密钥——chmod 600 ~/.hermes/.env
• 启用 DM 配对——优先使用配对码而非硬编码用户 ID
• 审查命令允许列表——定期审计 command_allowlist
• 设置 MESSAGING_CWD——不要让 Agent 在敏感目录中操作
• 以非 root 用户运行 gateway
• 监控日志——检查 ~/.hermes/logs/ 中的未授权访问尝试
• 保持更新——定期运行 hermes update

Frequently Asked Questions

Q：smart 审批模式和 manual 模式相比，真的安全吗？辅助 LLM 会不会误判？

A： smart 模式的设计是"不确定就升级"，而不是"不确定就放行"。辅助 LLM 评估风险后，低风险命令自动批准、真正危险的自动拒绝、不确定的升级为手动提示。实际使用中，smart 模式最大的价值是减少审批疲劳——你在本地开发时大量 ls、cat、python -c "print('hello')" 这类低风险命令不会反复打断你。但要注意，smart 模式的判断质量取决于辅助模型的水平，如果你把辅助模型设成了一个很弱的小模型，判断准确度会下降。我的建议是：个人开发环境可以用 smart，生产 gateway 还是保持 manual，因为生产环境的命令模式更复杂、误判代价更高。

Q：我开启了 YOLO 模式跑自动化脚本，还需要担心安全问题吗？硬性黑名单到底拦了什么？

A： YOLO 绕过的是危险命令审批提示，但绕不过硬性黑名单。黑名单覆盖的是不可逆的灾难性操作——rm -rf / 清根目录、fork 炸弹、格式化根设备、清零物理磁盘、根目录顶层 curl | sh。这些命令即使在 YOLO 下也会被拒绝，并向 agent 返回说明性错误。但需要注意，黑名单之外的危险命令（如 rm -rf /tmp/specific-dir、DROP TABLE、不含 WHERE 的 DELETE）在 YOLO 下是不拦的。所以 YOLO 适合"你充分信任所生成命令"的场景，比如在一次性容器里跑经过测试的自动化脚本。如果你的脚本会执行删库、递归删除等操作，请在 agent 外部运行，或者至少保持 manual 模式。

Q：我的 skill 需要访问 API key，但 execute_code 默认会剥离带 KEY 的环境变量。怎么让 skill 拿到凭据又不会泄露？

A： 正确做法是在 skill 的 SKILL.md frontmatter 中声明 required_environment_variables。加载 skill 时，Hermes 会自动检查这些变量是否在环境中已设置，已设置的注册为透传变量，未设置的不注册。透传变量会绕过 execute_code 和 terminal 的黑名单检查，进入本地执行环境以及 Docker/Modal 容器。关键安全保证是：只有你或你的技能明确声明的变量才会透传，LLM 生成的代码默认看不到任何带 KEY/TOKEN/SECRET 的变量。另外，如果你用的是 Docker 后端，凭据文件（如 OAuth token JSON）可以声明 required_credential_files，Hermes 会以只读绑定挂载的方式挂到容器里，agent 能读但不能改、不能删。

延伸阅读与交流

本文涉及的Hermes Agent自进化智能体技术体系，目前已有系统化的深度学习资源可供参考。中国通信工业协会通信和信息技术创新人才培养工程项目办公室将于近期组织相关技术专题分享，围绕本文讨论的AI原生架构、智能体工作流、自进化数据层等方向展开系统讲解。

专题信息

• 主题：AI原生Hermes自进化智能体系统
• 时间：2026年8月22-23日
• 形式：线上直播
• 内容方向：AI原生架构 · Hermes智能体拆解 · 全栈扩展 · 智能自动化 · 产品级实战 · Context Engine · 自进化数据层

分享嘉宾

王老师（Gavin），Agentic AI企业联合创始人兼CTO，十余年硅谷AI系统工程经验。长期深耕NLP、强化学习、可控AI与智能体系统架构，提出"语言即控制（Language as Control）"原创范式，在RLHF、PPO、DPO、GRPO等方向有系统化工程实践，推动智能体技术在社交媒体、医疗、金融、法律、教育等专业场景落地。联系邮箱：hiheartfirst@gmail.com

技术交流

• 联系人：Sam
• Hermes Agent技术文档：https://hermes-agent.nousresearch.com/docs/