安全

Hermes Agent 采用纵深防御的安全模型设计。本页涵盖每一个安全边界——从命令审批到容器隔离再到消息平台上的用户授权。

概述

安全模型包含七个层级：

用户授权（user authorization）——谁可以与 agent 对话（白名单、DM 配对）
危险命令审批（dangerous command approval）——破坏性操作需要人工介入
容器隔离（container isolation）——带有加固设置的 Docker/Singularity/Modal 沙箱
MCP 凭据过滤（MCP credential filtering）——MCP 子进程的环境变量隔离
上下文文件扫描（context file scanning）——项目文件中的提示注入检测
跨会话隔离（cross-session isolation）——会话无法访问彼此的数据或状态；定时任务存储路径针对路径遍历攻击进行了加固
输入清理（input sanitization）——终端工具后端的工作目录参数会根据白名单进行验证，防止 shell 注入

危险命令审批

在执行任何命令之前，Hermes 会将其与精心筛选的危险模式列表进行比对。如果匹配，用户必须显式批准。

审批模式

审批系统支持三种模式，通过 ~/.hermes/config.yaml 中的 approvals.mode 配置：

approvals:
  mode: manual    # manual | smart | off
  timeout: 60     # 等待用户响应的秒数（默认：60）

模式	行为
manual（手动）（默认）	始终提示用户批准危险命令
smart（智能）	使用辅助 LLM 评估风险。低风险命令（例如 `python -c "print('hello')"`）自动批准。真正危险的命令自动拒绝。不确定的情况升级为手动提示。
off（关闭）	禁用所有审批检查——等同于使用 `--yolo` 运行。所有命令执行无需提示。

:::warning 将 approvals.mode 设置为 off 会禁用所有安全提示。仅在受信任的环境（CI/CD、容器等）中使用。 :::

YOLO 模式

YOLO 模式绕过当前会话中所有危险命令审批提示。可以通过三种方式激活：

CLI 标志：使用 hermes --yolo 或 hermes chat --yolo 启动会话
斜杠命令：在会话中输入 /yolo 切换开关
环境变量：设置 HERMES_YOLO_MODE=1

/yolo 命令是一个开关——每次使用会打开或关闭该模式：

> /yolo
  ⚡ YOLO mode ON — all commands auto-approved. Use with caution.

> /yolo
  ⚠ YOLO mode OFF — dangerous commands will require approval.

YOLO 模式在 CLI 和网关会话中均可使用。在内部，它会设置 HERMES_YOLO_MODE 环境变量，在每次执行命令前进行检查。

当 YOLO 激活时，Hermes 会显示两个持久的视觉提醒，让你很难忘记审批提示已被绕过：

当 YOLO 已激活时，会话启动时显示一条红色横幅：⚠ YOLO mode — all approval prompts bypassed。YOLO 关闭时隐藏，保持默认横幅整洁。
状态栏中显示 ⚠ YOLO 片段，在所有宽度层级下均可见，并在你切换 YOLO 模式时实时更新（富文本渲染器和纯文本回退均支持）。

:::danger YOLO 模式会禁用会话中所有危险命令安全检查——但不包括硬性黑名单（见下文）。仅在你完全信任所生成的命令时使用（例如，在可丢弃环境中的经过充分测试的自动化脚本）。 :::

对于破坏性的会话斜杠命令（/clear、/new / /reset、/undo、/exit --delete），CLI 也会在执行前提示确认。参见斜杠命令 —— 破坏性命令的确认提示。

硬性黑名单（始终生效的底线）

有些命令的破坏性太大——不可逆的文件系统擦除、fork 炸弹、直接块设备写入——以至于 Hermes 无论如何都拒绝执行，无论：

--yolo / /yolo 已打开
approvals.mode: off
定时任务在无头（headless）approve 模式下运行
用户显式点击”始终允许”

黑名单是 --yolo 之下的底线。它在审批层甚至看到命令之前触发，并且没有覆盖标志。当前涵盖的模式（并非详尽无遗；与 tools/approval.py::UNRECOVERABLE_BLOCKLIST 保持同步）：

模式	为何是硬性规则
`rm -rf /` 及明显变体	擦除文件系统根目录
`rm -rf --no-preserve-root /`	显式的”是的，我就是要删根目录”变体
`:(){ :\|:& };:`（bash fork 炸弹）	使主机卡死直至重启
在已挂载的根设备上执行 `mkfs.*`	格式化正在运行的系统
`dd if=/dev/zero of=/dev/sd*`	将物理磁盘归零
在根文件系统顶层将不受信任的 URL 通过管道传给 `sh`	远程代码执行攻击向量过于广泛，无法批准

如果你触发了黑名单，工具调用会向 agent 返回一个解释性错误，且不会执行任何操作。如果合法工作流需要其中一个命令（例如，你是擦除并重装管道的操作员），请在 agent 之外运行它。

审批超时

当出现危险命令提示时，用户有一个可配置的时间来响应。如果在超时时间内没有响应，命令默认被拒绝（故障安全关闭）。

在 ~/.hermes/config.yaml 中配置超时：

approvals:
  timeout: 60  # 秒（默认：60）

什么会触发审批

以下模式会触发审批提示（定义在 tools/approval.py 中）：

模式	描述
`rm -r` / `rm --recursive`	递归删除
`rm ... /`	在根路径下删除
`chmod 777/666` / `o+w` / `a+w`	全局/其他用户可写权限
`chmod --recursive` 带不安全权限	递归全局/其他用户可写（长标志）
`chown -R root` / `chown --recursive root`	递归将所有者改为 root
`mkfs`	格式化文件系统
`dd if=`	磁盘复制
`> /dev/sd`	写入块设备
`DROP TABLE/DATABASE`	SQL DROP
`DELETE FROM`（无 WHERE）	无 WHERE 条件的 SQL DELETE
`TRUNCATE TABLE`	SQL TRUNCATE
`> /etc/`	覆盖系统配置
`systemctl stop/restart/disable/mask`	停止/重启/禁用系统服务
`kill -9 -1`	杀死所有进程
`pkill -9`	强制杀死进程
Fork 炸弹模式	Fork 炸弹
`bash -c` / `sh -c` / `zsh -c` / `ksh -c`	通过 `-c` 标志执行 shell 命令（包括 `-lc` 等组合标志）
`python -e` / `perl -e` / `ruby -e` / `node -c`	通过 `-e`/`-c` 标志执行脚本
`curl ... \| sh` / `wget ... \| sh`	将远程内容通过管道传给 shell
`bash <(curl ...)` / `sh <(wget ...)`	通过进程替换执行远程脚本
`tee` 到 `/etc/`、`~/.ssh/`、`~/.hermes/.env`	通过 tee 覆盖敏感文件
`>` / `>>` 到 `/etc/`、`~/.ssh/`、`~/.hermes/.env`	通过重定向覆盖敏感文件
`xargs rm`	xargs 与 rm 组合
`find -exec rm` / `find -delete`	带破坏性操作的 find
`cp`/`mv`/`install` 到 `/etc/`	复制/移动文件到系统配置
`sed -i` / `sed --in-place` 在 `/etc/` 上	就地编辑系统配置
`pkill`/`killall` hermes/gateway	防止自我终止
`gateway run` 带 `&`/`disown`/`nohup`/`setsid`	防止在服务管理器之外启动网关

:::info 容器绕过：当在 docker、singularity、modal、daytona 或 vercel_sandbox 后端运行时，危险命令检查被跳过，因为容器本身就是安全边界。容器内的破坏性命令不会危害宿主机。 :::

审批流程（CLI）

在交互式 CLI 中，危险命令会显示内联审批提示：

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

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

      Choice [o/s/a/D]:

四个选项：

once（一次）——允许这次执行
session（会话）——允许此模式在本次会话的剩余时间内使用
always（始终）——添加到永久白名单（保存到 config.yaml）
deny（拒绝）（默认）——阻止该命令

审批流程（网关/消息平台）

在消息平台上，agent 将危险命令详情发送到聊天中，并等待用户回复：

回复 yes、y、approve、ok 或 go 以批准
回复 no、n、deny 或 cancel 以拒绝

运行网关时，会自动设置 HERMES_EXEC_ASK=1 环境变量。

永久白名单

以”始终”方式批准的命令会保存到 ~/.hermes/config.yaml：

# 永久允许的危险命令模式
command_allowlist:
  - rm
  - systemctl

这些模式在启动时加载，并在所有未来会话中静默批准。

:::tip 使用 hermes config edit 查看或从永久白名单中移除模式。 :::

用户授权（网关）

当运行消息网关时，Hermes 通过分层授权系统控制谁可以与机器人交互。

授权检查顺序

_is_user_authorized() 方法按以下顺序检查：

平台级别的允许所有标志（例如 DISCORD_ALLOW_ALL_USERS=true）
DM 配对批准列表（通过配对码批准的用户）
平台特定白名单（例如 TELEGRAM_ALLOWED_USERS=12345,67890）
全局白名单（GATEWAY_ALLOWED_USERS=12345,67890）
全局允许所有（GATEWAY_ALLOW_ALL_USERS=true）
默认：拒绝

平台白名单

在 ~/.hermes/.env 中以逗号分隔的值设置允许的用户 ID：

# 平台特定白名单
TELEGRAM_ALLOWED_USERS=123456789,987654321
DISCORD_ALLOWED_USERS=111222333444555666
WHATSAPP_ALLOWED_USERS=15551234567
SLACK_ALLOWED_USERS=U01ABC123
 
# 跨平台白名单（所有平台都会检查）
GATEWAY_ALLOWED_USERS=123456789
 
# 按平台允许所有（谨慎使用）
DISCORD_ALLOW_ALL_USERS=true
 
# 全局允许所有（极其谨慎地使用）
GATEWAY_ALLOW_ALL_USERS=true

:::warning 如果没有配置白名单且未设置 GATEWAY_ALLOW_ALL_USERS，则所有用户都被拒绝。网关在启动时会记录一条警告：

No user allowlists configured. All unauthorized users will be denied.
Set GATEWAY_ALLOW_ALL_USERS=true in ~/.hermes/.env to allow open access,
or configure platform allowlists (e.g., TELEGRAM_ALLOWED_USERS=your_id).

:::

DM 配对系统

为了实现更灵活的授权，Hermes 包含一个基于代码的配对系统。无需预先提供用户 ID，未知用户会收到一个一次性配对码，机器人所有者通过 CLI 批准该配对码。

工作原理：

未知用户向机器人发送一条 DM
机器人回复一个 8 字符的配对码
机器人所有者在 CLI 上运行 hermes pairing approve <platform> <code>
该用户在该平台上被永久批准

在 ~/.hermes/config.yaml 中控制如何处理未授权的直接消息：

unauthorized_dm_behavior: pair
 
whatsapp:
  unauthorized_dm_behavior: ignore

pair 是默认值。未授权的 DM 会收到配对码回复。
ignore 静默丢弃未授权的 DM。
平台部分会覆盖全局默认值，因此你可以在 Telegram 上保持配对，同时保持 WhatsApp 静默。

安全特性（基于 OWASP + NIST SP 800-63-4 指南）：

特性	详情
码格式	从 32 字符无歧义字母表中取 8 字符（无 0/O/1/I）
随机性	加密安全（`secrets.choice()`）
码有效期	1 小时过期
速率限制	每用户每 10 分钟 1 次请求
待处理限制	每个平台最多 3 个待处理码
锁定	5 次失败的批准尝试 → 锁定 1 小时
文件安全	所有配对数据文件设置 `chmod 0600`
日志记录	码永远不会记录到标准输出

配对 CLI 命令：

# 列出待处理和已批准的用户
hermes pairing list
 
# 批准一个配对码
hermes pairing approve telegram ABC12DEF
 
# 撤销用户的访问权限
hermes pairing revoke telegram 123456789
 
# 清除所有待处理的码
hermes pairing clear-pending

存储： 配对数据存储在 ~/.hermes/pairing/ 中，每个平台一个 JSON 文件：

{platform}-pending.json — 待处理的配对请求
{platform}-approved.json — 已批准的用户
_rate_limits.json — 速率限制和锁定跟踪

容器隔离

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

Docker 安全标志

每个容器使用以下标志运行（定义在 tools/environments/docker.py 中）：

_SECURITY_ARGS = [
    "--cap-drop", "ALL",                          # 删除所有 Linux 能力
    "--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",         # 大小受限的 /tmp
    "--tmpfs", "/var/tmp:rw,noexec,nosuid,size=256m",  # 禁止执行的 /var/tmp
    "--tmpfs", "/run:rw,noexec,nosuid,size=64m",   # 禁止执行的 /run
]

资源限制

容器资源可在 ~/.hermes/config.yaml 中配置：

terminal:
  backend: docker
  docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
  docker_forward_env: []  # 显式白名单；空值保持密钥不出现在容器中
  container_cpu: 1        # CPU 核心数
  container_memory: 5120  # MB（默认 5GB）
  container_disk: 51200   # MB（默认 50GB，需要 XFS 上的 overlay2）
  container_persistent: true  # 跨会话持久化文件系统

文件系统持久化

持久模式（container_persistent: true）：从 ~/.hermes/sandboxes/docker/<task_id>/ 绑定挂载 /workspace 和 /root
临时模式（container_persistent: false）：工作空间使用 tmpfs——所有内容在清理时丢失

:::tip 对于生产网关部署，使用 docker、modal、daytona 或 vercel_sandbox 后端将 agent 命令与宿主机系统隔离。这完全消除了危险命令审批的需求。 :::

:::warning 如果你将名称添加到 terminal.docker_forward_env 中，这些变量会被有意注入到容器中以供终端命令使用。这对于任务特定凭据（如 GITHUB_TOKEN）很有用，但也意味着容器中运行的代码可以读取并泄露它们。 :::

终端后端安全性比较

后端	隔离性	危险命令检查	最适合
local	无——在宿主机上运行	✅ 是	开发、受信任的用户
ssh	远程机器	✅ 是	在独立服务器上运行
docker	容器	❌ 跳过（容器即边界）	生产网关
singularity	容器	❌ 跳过	HPC 环境
modal	云沙箱	❌ 跳过	可扩展的云隔离
daytona	云沙箱	❌ 跳过	持久的云工作空间
vercel_sandbox	云微 VM	❌ 跳过	带快照持久化的云执行

环境变量透传 {#environment-variable-passthrough}

execute_code 和 terminal 都会从子进程中剥离敏感的环境变量，以防止 LLM 生成的代码泄露凭据。但是，声明了 required_environment_variables 的技能需要合法地访问这些变量。

工作原理

两种机制允许特定变量通过沙箱过滤器：

1. 技能作用域透传（自动）

当加载一个技能（通过 skill_view 或 /skill 命令）并声明了 required_environment_variables 时，环境中实际已设置的变量会自动注册为透传。缺失的变量（仍处于需要设置状态）不会被注册。

# 在技能的 SKILL.md 的 frontmatter 中
required_environment_variables:
  - name: TENOR_API_KEY
    prompt: Tenor API key
    help: 从 https://developers.google.com/tenor 获取密钥

加载此技能后，TENOR_API_KEY 会透传到 execute_code、terminal（本地）以及远程后端（Docker、Modal）——无需手动配置。

:::info Docker 和 Modal 在 v0.5.1 之前，Docker 的 forward_env 是与技能透传独立的系统。现在它们已合并——技能声明的环境变量会自动转发到 Docker 容器和 Modal 沙箱中，无需手动添加到 docker_forward_env。 :::

2. 基于配置的透传（手动）

对于未由任何技能声明的环境变量，请将其添加到 config.yaml 的 terminal.env_passthrough 中：

terminal:
  env_passthrough:
    - MY_CUSTOM_KEY
    - ANOTHER_TOKEN

凭据文件透传（OAuth 令牌等） {#credential-file-passthrough}

某些技能需要在沙箱中使用文件（不仅仅是环境变量）——例如，Google Workspace 将 OAuth 令牌存储为活动配置集 HERMES_HOME 下的 google_token.json。技能在 frontmatter 中声明这些文件：

required_credential_files:
  - path: google_token.json
    description: Google OAuth2 令牌（由设置脚本创建）
  - path: google_client_secret.json
    description: Google OAuth2 客户端凭据

加载后，Hermes 检查这些文件是否存在于活动配置集的 HERMES_HOME 中，并注册它们以供挂载：

Docker：只读绑定挂载（-v host:container:ro）
Modal：在沙箱创建时挂载 + 每条命令前同步（处理会话中的 OAuth 设置）
Local：无需操作（文件已可访问）

你也可以在 config.yaml 中手动列出凭据文件：

terminal:
  credential_files:
    - google_token.json
    - my_custom_oauth_token.json

路径相对于 ~/.hermes/。文件挂载到容器内的 /root/.hermes/。

每个沙箱的过滤内容

沙箱	默认过滤	透传覆盖
execute_code	阻止名称中包含 `KEY`、`TOKEN`、`SECRET`、`PASSWORD`、`CREDENTIAL`、`PASSWD`、`AUTH` 的变量；仅允许安全前缀变量通过	✅ 透传变量同时绕过两项检查
terminal（本地）	阻止显式的 Hermes 基础设施变量（提供商密钥、网关令牌、工具 API 密钥）	✅ 透传变量绕过黑名单
terminal（Docker）	默认无宿主机环境变量	✅ 透传变量 + `docker_forward_env` 通过 `-e` 转发
terminal（Modal）	默认无宿主机环境/文件	✅ 凭据文件已挂载；环境变量透传通过同步
MCP	阻止除安全系统变量 + 显式配置的 `env` 之外的所有内容	❌ 不受透传影响（改用 MCP `env` 配置）

安全注意事项

透传仅影响你或你的技能显式声明的变量——对于任意的 LLM 生成代码，默认安全姿态不变
凭据文件以只读方式挂载到 Docker 容器中
Skills Guard 在安装前扫描技能内容中的可疑环境变量访问模式
缺失/未设置的变量永远不会被注册（你无法泄露不存在的东西）
Hermes 基础设施密钥（提供商 API 密钥、网关令牌）绝不应添加到 env_passthrough 中——它们有专用的机制

MCP 凭据处理

MCP（Model Context Protocol，模型上下文协议）服务器子进程接收过滤后的环境，以防止意外凭据泄露。

安全环境变量

只有以下变量会从宿主机透传到 MCP stdio 子进程：

PATH, HOME, USER, LANG, LC_ALL, TERM, SHELL, TMPDIR

以及任何 XDG_* 变量。所有其他环境变量（API 密钥、令牌、密钥）都会被剥离。

在 MCP 服务器的 env 配置中显式定义的变量会被透传：

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_..."  # 仅此项被传递

凭据编辑

MCP 工具的错误消息在返回给 LLM 之前会被清理。以下模式会被替换为 [REDACTED]：

GitHub PAT（ghp_...）
OpenAI 风格的密钥（sk-...）
Bearer 令牌
token=、key=、API_KEY=、password=、secret= 参数

网站访问策略

你可以限制 agent 通过其网络和浏览器工具可以访问的网站。这对于防止 agent 访问内部服务、管理面板或其他敏感 URL 很有用。

# 在 ~/.hermes/config.yaml 中
security:
  website_blocklist:
    enabled: true
    domains:
      - "*.internal.company.com"
      - "admin.example.com"
    shared_files:
      - "/etc/hermes/blocked-sites.txt"

当请求被阻止的 URL 时，工具会返回一个错误，说明该域名已被策略阻止。黑名单在 web_search、web_extract、browser_navigate 以及所有支持 URL 的工具中强制执行。

参见网站黑名单中的配置指南以获取完整详情。

SSRF 保护

所有支持 URL 的工具（网络搜索、网络提取、视觉、浏览器）在获取 URL 之前都会进行验证，以防止服务器端请求伪造（SSRF，Server-Side Request Forgery）攻击。被阻止的地址包括：

私有网络（RFC 1918）：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16
回环地址：127.0.0.0/8、::1
链路本地地址：169.254.0.0/16（包括 169.254.169.254 的云元数据）
CGNAT / 共享地址空间（RFC 6598）：100.64.0.0/10（Tailscale、WireGuard VPN）
云元数据主机名：metadata.google.internal、metadata.goog
保留、组播和未指定地址

SSRF 保护在面向互联网使用时始终处于活动状态，DNS 失败被视为阻止（故障安全关闭）。重定向链在每一步都会被重新验证，以防止基于重定向的绕过。

有意允许私有 URL

某些配置合法地需要私有/内部 URL 访问——将 home.arpa 解析到 RFC 1918 空间的家庭网络、仅限 LAN 的 Ollama/llama.cpp 端点、内部 wiki、云元数据调试等。针对这些情况，有一个全局退出选项：

security:
  allow_private_urls: true   # 默认：false

开启后，网络工具、浏览器、视觉 URL 获取和网关媒体下载不再拒绝 RFC 1918 / 回环 / 链路本地 / CGNAT / 云元数据目标。这是一个刻意的信任边界——只有在机器上运行 agent 执行任意提示注入的 URL 对本地网络是可接受风险时才启用。面向公众的网关应保持关闭。

主机子串防护（即使底层 IP 是公共的，也会阻止看起来相似的 Unicode 域名技巧）无论此设置如何都保持开启。

Tirith 预执行安全扫描

Hermes 集成了 tirith 进行内容级别的命令扫描，在命令执行前检测模式匹配无法捕捉的威胁：

同形异义字 URL 欺骗（国际化域名攻击）
管道到解释器模式（curl | bash、wget | sh）
终端注入攻击

Tirith 在首次使用时从 GitHub 发布版本自动安装，并带有 SHA-256 校验和验证（如果 cosign 可用，还有 cosign 来源验证）。

# 在 ~/.hermes/config.yaml 中
security:
  tirith_enabled: true       # 启用/禁用 tirith 扫描（默认：true）
  tirith_path: "tirith"      # tirith 二进制路径（默认：PATH 查找）
  tirith_timeout: 5          # 子进程超时秒数
  tirith_fail_open: true     # 当 tirith 不可用时允许执行（默认：true）

当 tirith_fail_open 为 true（默认值）时，如果 tirith 未安装或超时，命令仍会继续执行。在高安全环境中将其设置为 false，以在 tirith 不可用时阻止命令。

Tirith 为 Linux（x86_64 / aarch64）和 macOS（x86_64 / arm64）提供预构建二进制文件。在没有预构建二进制文件的平台（Windows 等）上，tirith 被静默跳过——模式匹配防护仍然运行，CLI 不会显示”不可用”横幅。要在 Windows 上使用 tirith，请在 WSL 下运行 Hermes。

Tirith 的判断结果会与审批流程集成：安全命令通过，而可疑和被阻止的命令都会触发用户批准，并附带完整的 tirith 发现（严重程度、标题、描述、更安全的替代方案）。用户可以批准或拒绝——默认选择是拒绝，以保持无人值守场景的安全。

上下文文件注入保护

上下文文件（AGENTS.md、.cursorrules、SOUL.md）在被包含到系统提示词之前会进行提示注入扫描。扫描器检查：

忽略/无视先前指令的指令
带有可疑关键词的隐藏 HTML 注释
尝试读取密钥（.env、credentials、.netrc）
通过 curl 泄露凭据
不可见的 Unicode 字符（零宽空格、双向覆盖）

被阻止的文件会显示警告：

[BLOCKED: AGENTS.md contained potential prompt injection (prompt_injection). Content not loaded.]

生产部署最佳实践

网关部署检查清单

设置显式白名单——在生产环境中绝不使用 GATEWAY_ALLOW_ALL_USERS=true
使用容器后端——在 config.yaml 中设置 terminal.backend: docker
限制资源——设置适当的 CPU、内存和磁盘限制
安全存储密钥——将 API 密钥保存在 ~/.hermes/.env 中，并设置适当的文件权限
启用 DM 配对——尽可能使用配对码代替硬编码的用户 ID
审查命令白名单——定期审计 config.yaml 中的 command_allowlist
设置 MESSAGING_CWD——不要让 agent 从敏感目录操作
以非 root 用户运行——绝不以 root 用户运行网关
监控日志——检查 ~/.hermes/logs/ 中的未授权访问尝试
保持更新——定期运行 hermes update 以获取安全补丁

保护 API 密钥

# 设置 .env 文件的适当权限
chmod 600 ~/.hermes/.env
 
# 为不同服务保留独立的密钥
# 绝不将 .env 文件提交到版本控制

网络隔离

为了最大安全性，在独立的机器或 VM 上运行网关。在 config.yaml 中设置 terminal.backend: ssh，然后通过 ~/.hermes/.env 中的环境变量提供主机详情：

# ~/.hermes/config.yaml
terminal:
  backend: ssh

# ~/.hermes/.env
TERMINAL_SSH_HOST=agent-worker.local
TERMINAL_SSH_USER=hermes
TERMINAL_SSH_KEY=~/.ssh/hermes_agent_key

SSH 连接详情放在 .env（而非 config.yaml）中，因此它们不会被检入版本控制或随配置集导出一起共享。这使网关的消息连接与 agent 的命令执行保持分离。

供应链安全公告检查

Hermes 附带一个内置的公告扫描器，用于标记活动虚拟环境中与已知受损版本目录匹配的 Python 包（供应链蠕虫，如 2026 年 5 月的 mistralai 2.4.6 投毒事件）。实现位于 hermes_cli/security_advisories.py。

运行方式：

CLI 启动横幅。 如果有任何公告匹配，会打印一行警告，并提示运行 hermes doctor 获取完整的修复方案。
hermes doctor。 显示每个活动公告的版本详细信息和 2-4 步修复说明。
网关启动。 记录到 gateway.log；第一个交互式消息会显示一个简短的操作员横幅。

每个公告有一个稳定的 ID。阅读并处理完后，可以永久忽略它：

hermes doctor --ack <advisory-id>

确认信息持久化到 config.security.acked_advisories，重启后仍然有效。旧公告有意不从目录中移除——保留它们可以确保新安装也能收到关于历史上被投毒版本的警告，这些版本可能仍缓存在私有镜像中。

检查本身仅使用标准库，每次检查从 importlib.metadata.version() 查找一次，因此每次启动时运行是安全的。

可选依赖的延迟安装

许多功能（Mistral TTS、ElevenLabs、Honcho 记忆、Bedrock、Slack、Matrix 等）依赖并非每个用户都需要 Python 包。Hermes 在首次使用时延迟安装这些包，而不是在 hermes-agent[all] 中急切安装。实现位于 tools/lazy_deps.py 中。

这解决了一个权衡问题：

脆弱性。 当一个 extras 的传递依赖在 PyPI 上不可用时（因恶意软件被隔离、被撤回、上传损坏），整个 [all] 解析会失败，新安装会静默回退到一个精简层级——同时丢失 10+ 个无关的 extras。延迟安装隔离了每个后端，因此一个受损的依赖不会破坏不相关的功能。
臃肿。 只与一个提供商对话的用户不再需要拉取数百个永远不会导入的包。

工作原理：

后端模块在其首次导入路径的顶部调用 ensure("feature.name")。
如果依赖缺失，ensure 检查 config.yaml 中的 security.allow_lazy_installs（默认 true），并为白名单中的规格运行虚拟环境作用域的 pip install。
如果安装失败或用户已禁用延迟安装，调用会抛出 FeatureUnavailable 异常，包含实际的 pip stderr 以及指向 hermes tools 的提示。

tools/lazy_deps.py 强制执行的安全保证：

保证	含义
仅限虚拟环境作用域	安装目标为 `sys.executable` 在活跃虚拟环境中——绝不安装到系统 Python
仅限 PyPI 名称	规格接受 `"package>=1.0,<2"` 语法。不支持 `--index-url`、`git+https://` 或 `file:` 路径——恶意的 `config.yaml` 无法重定向安装
白名单	只有出现在内置 `LAZY_DEPS` 映射中的规格才能通过此路径安装。功能名称的拼写错误不会获得”安装任何东西”的语义
可选择退出	设置 `security.allow_lazy_installs: false` 可完全禁用运行时安装。适用于受限网络或严格的安全策略
无静默重试	失败会以 `FeatureUnavailable` 形式展现——不会缓存错误状态，不会出现重试风暴

要禁用运行时安装：

# ~/.hermes/config.yaml
security:
  allow_lazy_installs: false

禁用后，需要可选依赖的后端会提示用户手动运行安装（pip install …）或通过 hermes tools 选择不同的后端。

好奇心花园🪴

探索

最近的笔记

note-template

getMoon.js

getWeather.js

安全

安全

概述