Hermes 是一个具有终端访问能力的 AI 代理系统，这意味着它能执行命令、访问文件、甚至调用外部 API。在生产或半生产环境中，这类系统的安全性至关重要。如果访问控制没有收紧，攻击者可能通过你的机器人执行任意命令；如果 MCP 工具没有合理配置，敏感凭据可能泄露给不受信任的外部服务。
这篇文章梳理 Hermes 的安全边界、授权机制与风险控制思路，帮助你在真实环境中部署时守住底线。
理解七层安全模型
Hermes 采用纵深防御（defense in depth）策略，将安全控制分散到七个不同层次。每层各自负责一块风险面，单一层的失效不至于全面崩溃。
用户授权是第一道门槛。Hermes 支持平台级 allowlist（如 TELEGRAM_ALLOWED_USERS）、全局 allowlist（GATEWAY_ALLOWED_USERS）以及 DM pairing 配对码三种方式控制谁能访问系统。
危险命令审批是第二道防线。即使一个用户通过了身份验证，当他尝试执行敏感操作（如写文件、执行 shell 命令）时，系统会触发审批流程。审批模式默认为 manual，即每次都需要人工确认。
容器隔离确保不可信代码在受限环境中运行。支持 Docker、Singularity、Modal、Daytona 等后端。启用后会应用 --cap-drop ALL、--security-opt no-new-privileges 等加固参数，并限制进程数和挂载 tmpfs 文件系统。
MCP 凭据隔离处理外部工具集成的风险。Hermes 只会传递明确配置的环境变量（如 PATH、HOME），不会把 API keys 和 tokens 暴露给 MCP 服务器。错误信息也会自动脱敏。
上下文文件扫描在加载 AGENTS.md、.cursorrules 等配置文件前检查提示注入攻击。
会话隔离保证不同会话间的数据完全独立，cron 任务的存储路径经过验证以防止路径遍历。
输入清洗对终端工具后端的工作目录参数进行白名单验证，防止 shell 注入。
收紧 Gateway 访问控制
消息网关是所有外部请求的入口。Hermes 的默认策略是拒绝所有未授权用户，这是一项重要的安全默认值。
Allowlist 是首选方案
配置允许用户列表是最直接的方式。通过设置 TELEGRAM_ALLOWED_USERS=123456789,987654321 这样的环境变量，指定哪些用户 ID 可以访问。不同平台有各自对应的变量名：Discord 用 DISCORD_ALLOWED_USERS，Signal 用 SIGNAL_ALLOWED_USERS，还有 SMS、Email、Feishu、WeCom 等支持。这种方式适合用户群体固定、管理员能够提前拿到所有用户 ID 的场景。
DM Pairing 作为补充
并非所有场景都能提前知道所有合法用户。DM pairing 提供了另一种思路：未知用户首次 DM 机器人时，系统会生成一个一次性配对码发送给管理员。管理员审批后，用户才能正常使用。配对码有效期为 1 小时，有速率限制，且使用加密随机数生成，难以预测。
审批命令很简单：
hermes pairing approve telegram XKGH5N7P
hermes pairing list
hermes pairing revoke telegram 123456789
当需要临时授权某个用户、又不想把他加入永久 allowlist 时，这套机制很合适。
避免开放访问
设置 GATEWAY_ALLOW_ALL_USERS=true 允许所有用户访问。对于有终端访问能力的机器人来说，这个选项本质上是不安全的——除非你的机器人功能极其有限、且完全信任所有可能联系它的人。
容器隔离与危险命令管控
不可信的代码仓库、用户提交的脚本、甚至模型生成的代码，都应该在隔离环境中执行，而不是直接在宿主机上跑。
选择合适的隔离后端
Hermes 支持多种容器后端：
- Docker：最广泛使用，生态成熟
- Singularity：HPC 场景常用，对非 root 用户友好
- Modal：适合需要按需弹性扩展的工作负载
- Daytona：专注于沙箱隔离
启用容器后端时，Hermes 会自动应用安全加固参数：--cap-drop ALL 移除所有 Linux 能力，--security-opt no-new-privileges 禁止提权，限制最大进程数，并用 tmpfs 挂载临时文件系统。
危险命令审批机制
危险命令审批有三个模式可选：
- manual（默认）：每次执行都需要人工审批
- smart：系统根据上下文智能判断是否需要审批
- off（YOLO 模式）：完全跳过审批
YOLO 模式听起来方便，但如果你在处理来自用户的请求、或者处理来源不明的代码，这相当于把安全阀拆掉。审批超时默认 60 秒，如果超时没有人审批，请求会被拒绝。
黑名单与白名单
除了审批机制，还可以通过配置限制某些工具或命令的可用性。对于 MCP 工具，可以用 tools.exclude 黑名单危险工具，用 tools.include 白名单敏感服务器上仅允许使用的工具。
MCP 工具的安全接入
MCP（Model Context Protocol）让 Hermes 能快速接入 GitHub、数据库、文件系统、浏览器等外部工具生态。接入很方便，但每引入一个外部服务，都相当于扩大了攻击面。
攻击面的放大效应
MCP 工具使用 mcp_<server_name>_<tool_name> 格式命名，避免与内置工具冲突。但外部工具的代码不受 Hermes 控制，如果某个 MCP 服务器存在漏洞或被恶意利用，影响会直接传导到 Hermes。
工具在启动时自动发现和注册，服务器还可以动态推送工具列表变更。这意味着你接入的 MCP 服务如果中途新增了某个危险工具，Hermes 可能会在不知情的情况下暴露它。
环境变量与凭据隔离
对于 stdio 类型的 MCP 服务器，Hermes 不会盲目传递完整 shell 环境。它只传递明确配置的 env 变量加上安全基线（PATH、HOME 等）。API keys、数据库密码、其他敏感凭据默认不会被传递。
但这不意味着可以随意配置——你需要检查每个 MCP 服务器的文档，确认它需要哪些环境变量，只提供必要的最小权限。
最小权限原则
对每个 MCP 服务器，问自己几个问题：
- 这个服务器真的需要启用吗？如果不需要，用
enabled: false关掉。 - 这个服务器需要用到哪些工具？只暴露
tools.include中明确列出的工具。 - 有没有危险工具应该被禁用？用
tools.exclude黑名单它们。 - 服务器需要的最小环境变量是什么？不要多给。
其他重要安全措施
SSRF 保护
Server-Side Request Forgery 是一种常见攻击，攻击者利用服务器发起对内部网络的请求。Hermes 内置 SSRF 保护，会阻止对私有网络（如 10.0.0.0/8、172.16.0.0/12）和云元数据端点（如 AWS 169.254.169.254）的访问。
Tirith 预执行扫描
Tirith 是 Hermes 的静态分析组件，在命令执行前检测潜在攻击模式，包括：
- 同形字欺骗（Homograph attacks）：用看起来相似的字符替换敏感字符
- 管道解释器攻击（Pipe interpreter attacks）：试图通过管道向解释器注入代码
上下文文件扫描
AGENTS.md、.cursorrules 等文件在加载前会经过扫描，检测提示注入攻击。这些文件可能被恶意修改以诱导模型执行非预期操作，提前扫描能在执行前拦截风险。
网站访问策略
Hermes 支持配置域名黑名单，限制能访问哪些网站。如果你的工作流不需要访问某些类别域名，把它加入黑名单可以减少攻击面。
生产环境部署建议
综合以上各层安全机制，生产环境部署时应关注以下几点：
访问控制层面，始终使用 allowlist 或 DM pairing，不要开启 GATEWAY_ALLOW_ALL_USERS=true。定期审计允许用户列表，及时移除不再需要的权限。
容器隔离层面，处理不可信代码时务必启用容器后端。优先选择 Docker 或 Daytona 之类有成熟沙箱实践的后端。
MCP 接入层面，接入新的 MCP 服务器前评估风险，遵循最小权限原则配置工具过滤。
监控层面，关注危险命令审批队列，避免审批超时影响业务可用性。
运行用户层面，不要用 root 用户运行 Hermes，创建专用低权限账户。
Hermes 的安全模型设计得相当全面，七层防御覆盖了从身份验证到代码执行再到网络访问的各个环节。但工具的安全性最终取决于使用方式——默认配置提供了基础保障，合理收紧访问控制、谨慎处理外部工具、保持对审批流程的关注，才能真正在生产环境中守住安全底线。