Hermes Agent 安全策略

本文档介绍了Hermes Agent的信任模型，明确了项目中视为核心安全屏障的要素，并规定了漏洞报告的范围。

1. 漏洞报告方式

请通过GitHub安全建议通道或security@nousresearch.com进行私下报告。请勿为安全漏洞创建公开问题。Hermes Agent不设漏洞赏金计划。

一份有效的报告应包含以下内容：

• 简洁的描述及严重性评估。
• 受影响组件，需通过文件路径和行号范围标识（例如：path/to/file.py:120-145）。
• 环境信息（“hermes版本”、提交SHA值、操作系统、Python版本）。
• 在main分支或最新版本上的复现方法。
• 说明违反了第2节中的哪一安全边界。

提交报告前请先阅读第2节和第3节。对于那些因当前启发式机制存在局限而未被视为边界的情况，根据第3节规定将被视为超出范围而不予处理——但请参见第3.2节：此类问题仍可作为普通问题或拉取请求提交，只是不能通过私密的安全渠道。

2. 信任模型

Hermes Agent是一款单租户个人代理。其架构为分层设计，各层的安全承担能力并不相同。报告者和操作者应使用相同的概念来理解这些层次。

2.1 定义

• Agent进程：运行Hermes Agent的Python解释器，包括其加载的所有Python模块（技能、插件、钩子处理程序）。
• 终端后端：terminal()工具的可插拔执行目标。默认情况下，该工具会在主机上直接执行命令；其他后端则会在容器、云沙箱或远程主机内执行命令。
• 输入接口：内容进入代理上下文的任何通道：操作者输入、网络请求、电子邮件、网关消息、文件读取、MCP服务器响应、工具输出结果等。
• 信任范围：操作者通过运行Hermes Agent而隐式授予其访问权限的资源集合——通常即操作者自身在主机上可访问的所有内容。
• 处理方式：Hermes Agent文档或代码中关于消费层（适配器、用户界面、文件写入器、shell等）应如何处理代理输出的明确说明——例如：“仪表板将代理输出渲染为静态HTML。”

2.2 核心边界：操作系统级隔离

抵御恶意大语言模型的唯一安全屏障就是操作系统。 Agent进程内的任何机制都算不上真正的隔离措施——无论是审批门控、输出屏蔽、模式扫描器，还是工具白名单。任何用于筛选大语言模型输出的在进程内组件，本质上都是基于攻击者可能输入的字符串运行的启发式工具，本策略也将其视为此类工具。

Hermes Agent支持两种操作系统级隔离方案，它们针对不同的威胁，操作者需根据需求谨慎选择。

终端后端隔离

非默认的终端后端会在容器、远程主机或云沙箱中执行大语言模型生成的shell命令。文件操作工具（read_file、write_file、patch）也会通过此后端执行，因为它们是基于shell接口实现的——因此无法访问后端未暴露的路径。

这种隔离方式能限制的内容：代理通过shell或文件操作所能做的所有事情。而无法限制的内容：代理在其自身Python进程内能做的所有操作，包括代码执行工具（作为主机子进程启动）、MCP子进程（从代理环境启动）、插件加载、钩子调度以及技能加载（所有这些都会被导入到代理解释器中）。

当关注点在于大语言模型生成的破坏性shell命令或不必要的文件操作，且操作者可信度较高时，终端后端隔离是合适的选择。

全进程封装

全进程封装会将整个Agent进程树置于沙箱环境中运行。所有的代码路径——无论是shell命令、代码执行、MCP交互、文件操作工具、插件、钩子还是技能加载——都需遵循相同的文件系统、网络、进程以及（如适用）推理策略。

Hermes Agent提供了两种实现全进程封装的方式：

• Hermes Agent自身的Docker镜像及Compose配置：这种方式更为轻量，代理在标准容器中运行，支持操作者自定义的挂载点和网络策略。
• NVIDIA OpenShell：OpenShell可提供会话级沙箱，并通过声明式策略对文件系统、网络（L7出站）、进程/系统调用以及推理路由层进行管控。网络和推理策略支持热更新。凭证从提供商存储库中注入，不会触及沙箱文件系统。

在全进程封装模式下，Hermes Agent的在进程内启发式机制（第2.4节）实际上是在真实安全边界之上叠加的预防措施。当代理需要处理来自操作者无法控制的来源的内容——如开放网络、收到的电子邮件、多用户频道、不可信的MCP服务器——以及用于生产环境或共享部署时，应采用此方案。

那些在不可信输入环境下使用默认本地后端，或在使用终端后端沙箱的同时期望其能限制那些不经过shell的代码路径的操作者，实际上是在非推荐的安全架构下运行。

2.3 凭证范围控制

Hermes Agent会过滤并限制传递给那些信任度较低的进程内组件的环境信息：shell子进程、MCP子进程、定时任务脚本以及代码执行子进程。默认情况下，提供商API密钥和网关令牌等凭证会被移除；仅操作者明确声明的变量或已加载的技能中所定义的变量才会被传递。

这有助于防止凭证被随意窃取，但并非真正的隔离措施。任何在Agent进程内运行的组件（技能、插件、钩子处理程序）都能读取代理本身能够访问的所有内容，包括内存中的凭证。针对已被攻破的进程内组件的防护措施，是在安装前由操作者进行审查（第2.4节、第2.5节），而非单纯清理环境信息。

2.4 在进程内的启发式机制

以下组件可用于筛选或警告大语言模型的异常行为。它们具有实用价值，但并非安全边界。

• 审批门控：能够检测常见的破坏性shell命令模式，并在执行前向操作者发出提示。由于shell语言具备图灵完备性，仅依靠禁止列表来过滤shell字符串在结构上是不够的。该机制只能捕捉到合作模式下的错误，无法防范恶意输出。
• 输出屏蔽：会从显示内容中移除类似敏感信息的模式。但心怀不轨的输出生成者仍可能绕过此机制。
• 技能防护机制：会扫描可安装的技能内容，查找潜在的注入模式。它仅作为审查辅助工具；对于第三方技能而言，其安全边界仍是安装前的操作者审查。审查技能意味着需要阅读其Python代码和脚本，而不仅仅是SKILL.md描述文件——因为技能在导入时即可执行任意Python代码。

2.5 插件信任模型

插件会被加载到Agent进程中，并以与内置组件相同的权限运行：它们可以读取相同的凭证、调用相同的工具、注册相同的钩子，以及导入相同的模块。对于第三方插件而言，其安全边界同样是安装前的操作者审查——这一规则与技能相同（第2.4节），之所以单独列出，是因为插件在架构上更为复杂，通常还会自带后台服务、网络监听器及依赖项。

恶意或存在缺陷的插件本身并不构成Hermes Agent的漏洞。但如果Hermes Agent的插件安装或发现机制存在缺陷，导致操作者无法知晓自己正在安装什么内容，那么这类问题则属于第3.1节规定的覆盖范围。

2.6 外部接口

外部接口指的是Agent进程之外的任何通道，通过这些通道，调用者可以调度Agent任务、处理审批请求或接收Agent输出结果。每个接口都有其独立的授权机制，但以下规则对所有外部接口均适用。

Hermes Agent中的外部接口包括：

• 网关平台适配器：位于gateway/platforms/目录下的消息集成功能（如Telegram、Discord、Slack、电子邮件、短信等），以及以插件形式提供的类似适配器。
• 面向网络的HTTP接口：API服务器适配器、仪表板插件、看板插件对应的HTTP端点，以及任何其他绑定监听套接字的插件。
• 编辑器/IDE适配器：ACP适配器（acp_adapter/）以及能够接收本地客户端进程请求的类似集成功能。
• TUI网关（tui_gateway/）：用于Ink终端用户界面的JSON-RPC后端，通过本地进程间通信实现访问。

统一规则：

1. 任何跨越信任边界的接口都需进行授权控制。 对于消息传递和网络HTTP接口，其边界在于网络层：授权方式即操作者配置的调用者白名单。而对于编辑器和本地进程间通信接口（ACP、TUI网关），其边界在于主机用户账户：授权方式依赖于操作系统级的访问控制机制（如文件权限、仅允许本地回环连接），且除非有明确的网络授权层，否则不会向本地用户之外的地址暴露该接口。
2. 所有已启用的面向网络接口都必须配置白名单。 在未设置白名单之前，这些适配器不得调度Agent任务、处理审批请求或转发输出结果。若未配置白名单却仍能正常运行，那么这类代码缺陷属于第3.1节规定的覆盖范围。
3. 会话标识符仅用于路由定位，而非授权边界。 了解其他调用者的会话ID并不能赋予其访问该调用者审批结果或输出内容的权限；授权检查始终会基于白名单（或操作系统级的等效机制）重新进行。
4. 在已获授权的调用者范围内，所有调用者均被视为同等可信。 Hermes Agent不会在单个适配器内部对不同调用者设置不同的权限。如果操作者需要实现更细粒度的权限控制，应运行多个独立的Agent实例，并为每个实例配置独立的白名单。
5. 将仅限本地访问的接口绑定到非回环地址上，属于操作者的特殊决策（见第3.2节）。 仪表板及其他插件HTTP服务器默认采用回环绑定方式；若通过--host 0.0.0.0或类似参数将其暴露在公网，那么后续的公共访问安全加固工作（见第4节）则由操作者负责。

3. 覆盖范围

3.1 覆盖范围内的内容- 逃逸已声明的操作系统级隔离机制（§2.2）：由攻击者控制的代码路径突破了该机制本应限制的状态。

• 未经授权的外部访问：来自配置的授权集（允许列表，或本地IPC接口对应的操作系统级机制）之外的调用方试图发起任务、接收输出或处理审批请求（§2.6）。
• 凭据泄露：通过本应防止此类行为的机制（如环境清理漏洞、适配器日志记录、将凭据上传至上游的传输错误等），导致操作员凭证或会话授权信息泄露到信任范围之外的目标。
• 违反信任模型文档规定：代码行为与本政策、Hermes Agent自身的文档说明或操作员的合理预期相悖——包括Hermes Agent已明确规定其输出应如何被下游组件（如仪表板、网关适配器、文件写入工具、shell）处理，但实际代码路径却违反了这些规定。

3.2 不在覆盖范围内

此处的“不在覆盖范围内”意为“根据本政策不属于安全漏洞”，并不等同于“无需上报”。对进程内检测规则的优化、增强安全性措施以及用户体验改进均欢迎以常规问题或拉取请求的形式提交——审批机制总能识别更多异常模式，数据脱敏功能也能不断改进，适配器行为亦可进一步严格管控。这类内容只是不会通过私密披露渠道处理，也不会获得相关通告。

• 绕过进程内检测规则的行为（§2.4）：包括绕过审批机制的正则表达式、绕过数据脱敏机制、绕过Skills Guard规则，以及针对未来可能出现的检测规则的类似报告。这些机制并非安全边界，绕过它们并不构成本政策定义下的漏洞。
• 提示注入行为本身：通过注入内容、幻觉现象、训练数据残留或其他原因导致大语言模型产生异常输出，其本身并不属于漏洞。若仅声称“实现了提示注入”，但并未引发§3.1中列出的连锁后果，则不属于本政策要求上报的问题。
• 所选隔离机制的固有后果：若某代码路径在其所在隔离机制的允许范围内执行预期功能，此类报告并不构成漏洞。例如：在本地后端模式下，shell或文件工具能够访问主机系统；在仅能限制shell运行的终端后端隔离模式下，代码执行或MCP子进程仍可访问主机系统；那些以预先具备对操作员配置文件或凭证文件的写入权限为前提的报告（此类文件本就处于信任范围内），同样不属于漏洞。
• 已明确记录的应急设置：操作员主动选择的、用于禁用安全保护的配置，如仪表板或其他组件上的--insecure及其同类标志、已禁用的审批功能、生产环境中的本地后端模式、可绕过hermes-home安全机制的开发模式等。针对此类配置的报告不属于漏洞——这正是相关设置的存在目的。
• 社区贡献的技能与插件：第三方技能（包括社区技能仓库）及第三方插件均处于操作员的审核范围内，而非Hermes Agent的信任范围内（§2.4、§2.5）。若某个技能或插件出现恶意行为，那只是未被审核的预期故障表现，而非Hermes Agent本身的漏洞。若Hermes Agent的技能安装或插件安装流程存在缺陷，导致操作员无法察觉所安装的内容，则属于§3.1的覆盖范围。
• 无外部控制下的公开暴露：未通过身份验证、VPN或防火墙机制，就将网关或API直接暴露在公共互联网上。
• 在允许使用shell的隔离模式下，工具级的读写限制：若某路径可通过终端工具访问，那么声称其他文件工具也能访问该路径的报告并无实际意义。

4. 部署加固措施

最重要的加固决策是将隔离机制（§2.2）与Agent需处理的内容的信任级别相匹配。除此之外，还需注意以下几点：

• 以非root用户身份运行Agent。所提供的容器镜像默认已实现此设置。
• 将凭证保存在操作员凭证文件中，并设置严格的权限限制，绝不可存放在主配置文件中或版本控制系统中。在OpenShell模式下，应使用Provider存储机制而非磁盘上的凭证文件。
• 未经VPN、Tailscale或防火墙保护，切勿将网关或API暴露在公共互联网上。在OpenShell模式下，可通过网络策略层来限制数据外发。
• 为每个已启用的面向网络的适配器配置调用方允许列表（§2.6）。
• 在安装第三方技能和插件之前进行审查（§2.4、§2.5）。对于技能而言，需仔细查看其Python代码及脚本文件，而不仅仅是SKILL.md文档。Skills Guard的报告及安装审计日志可作为审查依据。
• Hermes Agent为MCP服务器的启动过程以及CI环境中的依赖项/打包包变更提供了供应链安全防护机制；具体细节请参阅CONTRIBUTING.md文档。

5. 暴露处理流程

• 协调披露时间窗口：从报告提交之日起90天内，或直至修复版本发布为止，以较早者为准。
• 反馈渠道：通过GHSA讨论帖或发送邮件至security@nousresearch.com。
• 致谢机制：除非报告人要求匿名，否则其贡献将在版本说明中予以致谢。