文章总结： 本文从Agent系统视角分析HermesAgent的安全风险，指出其作为持续运行的Agent操作系统具备权限聚合、时间扩展、边界漂移和入口扩张四大核心风险。文章详细剖析了执行面（终端、审批边界、代码执行、浏览器自动化）、记忆系统（上下文文件、固定记忆、会话搜索、外部记忆）、扩展面（MCP、Skill、插件）以及多入口协同（计划任务、后台任务、Sub-agent）等层面的攻击面，并将关键风险映射至OWASPAgenticTop10框架，强调需从系统整体视角而非单点提示词层面进行安全评估。 综合评分： 88 文章分类： 应用安全,AI安全,安全运营,红队,漏洞分析

从Agent系统角度来看Hermes Agent攻击面

原创

林之冰寒 林之冰寒

Security for AI

2026年4月15日 12:01 韩国

在小说阅读器读本章

去阅读

引言

Hermes Agent已经不再是单一、短时、单入口的普通Agent。它为自我改进型AI Agent，具备跨会话记忆、skill创建与改进、计划任务、并行Sub-Agent、浏览器自动化、外部MCP集成、、外部记忆等多种能力。同时它已经有落在典型的高权限Agent系统风险：既能看外部内容，也能调工具，还能跨会话记忆、跨平台送达、跨进程并行、跨边界扩展。

为什么Hermes Agent不能按普通Agent理解

Hermes Agent已经超出单入口、短会话、有限工具调用的普通Agent范围。它有CLI、消息网关、ACP、API接口与Python调用入口，有终端、浏览器、MCP、文件、视觉等工具面，有跨会话记忆、会话搜索、计划任务、背景任务、Sub-Agent、外部记忆、第三方skill与插件生态。因此Hermes Agent更像一层持续运行的Agent操作系统，而不是一个只在当前对话里回答问题的工具。

而它的风险也来自能力叠加。普通Agent的风险很多时候停留在单轮判断偏差、单工具误用或一次性文本污染。Hermes Agent的能力组合会把问题扩展到四个方向。

1. 权限聚合。终端、浏览器、MCP、消息投递与计划任务共存于同一推理链路，单次错误判断的影响范围更大
2. 时间扩展。记忆、会话搜索、后台任务与Cron会把一次输入影响拉长到后续会话和后续时段。
3. 边界漂移。第三方skill、插件、MCP服务器与外部记忆持续改变运行时工具面，系统边界并不固定
4. 入口扩张。CLI之外还有Slack、Discord、Email、WhatsApp等多平台，输入源头和触发时点都更复杂

很多开源Agent框架也有工具调用、记忆或插件，但Hermes Agent把这些能力集中在同一产品形态里，并且强调长期运行、跨平台送达与运行时扩展。

执行面风险

Hermes Agent最大的风险在执行面。官方文档把危险命令审批、容器隔离、上下文文件扫描、输入清理、跨会话隔离、MCP凭据过滤列为安全模型的一部分。这说明官方很清楚Hermes Agent具备真实执行能力。因此风险判断也从这里开始。

首先是终端风险。官方文档写明Hermes支持本地、Docker、SSH、Singularity、Modal与Daytona多种终端后端。这意味着同一个Agent任务既可能直接落到本机，也可能落到容器、远端主机或云执行环境。从安全角度来说，问题不只是会不会执行命令，还包括命令在哪一层执行、携带什么环境变量、能访问什么网络、会把结果写回哪里。只要执行环境里存在源代码、密钥、SSH上下文或业务数据等，终端能力就会把文本错误转成真实系统副作用。

其次是审批边界风险。官方提供危险命令审批，也允许关闭审批或通过YOLO模式跳过。这类设计很常见，也很有必要。但从风险角度看，审批只能覆盖命令层的一部分显性危险，无法覆盖高层意图偏差、复杂多步链路与环境配置失误。更重要的是，容器被当作安全边界后，一部分命令检查会被弱化，风险焦点会转移到挂载、网络、镜像、凭据与持久化配置上。换句话说，控制点并没有消失，只是从命令文本移动到了运行时环境。

然后是execute_code带来的审计稠密化风险。这一能力会让模型写脚本，再由脚本通过RPC连续调用工具，中间结果不全部回到上下文窗口。这种设计提升了效率，也压缩了人工观察面。对于用户而言，一次调用看起来更像单个动作。但对于系统而言，背后可能是多步工具链、条件分支与中间状态读写。问题一旦出现，复盘难度会明显增加，尤其在缺乏细粒度任务记录时更明显。

最后是浏览器自动化风险。Hermes Agent支持多种浏览器执行模式，具备导航、点击、填表、提取页面内容与视觉分析能力。这类能力会把间接提示注入从纯文本层推进到真实网页交互层。网页中的隐藏文本、混杂说明、按钮语义、页面跳转与登录态上下文都可能影响后续动作。从已有的AI浏览器风险看，把网页内容、连接器内容与工具返回内容中的恶意文本会影响AI浏览器。把这一点与Hermes Agent的浏览器能力放在一起看，只要Agent拥有登录态、表单填写与外部站点交互能力，执行面风险就会大幅上升

提示、上下文、记忆与搜索风险

很多Agent的风险分析容易停在当前提示词。但Hermes Agent更值得注意的部分，是提示、上下文、记忆、会话搜索与外部记忆之间形成了长期链路。本地记忆会写入MEMORY.md与USER.md，并在会话开始时作为固定记忆区块注入系统提示。同时，Hermes还能保存全部会话并通过搜索工具回忆过往内容。这意味着污染一旦进入长期状态，后续任务很可能再次召回它。因此主要有四大风险。

第一类风险是上下文文件风险。Hermes会自动发现并加载项目中的上下文文件，把其中内容放进高权重提示区域。只要这些文件里混入诱导性指令、伪装成规范的流程文本、与真实项目说明掺杂的恶意描述，模型就可能把它们当成优先级更高的任务约束。由于这类内容看起来像正常项目文档，污染很容易在代码库、协作目录和模板仓库中长期存在。

第二类风险是固定记忆风险。记忆一旦在会话开始时被注入，当前任务中的判断会围绕这一快照展开。风险点不只是恶意内容被写入记忆，也包括旧信息长期保留、环境变化后记忆没有同步更新、历史偏差在后续任务中重复出现。随着任务累积，Agent会越来越依赖过去保存的环境事实、用户偏好和工作习惯。一旦这些内容被污染或陈旧化，影响会反复出现。

第三类风险是会话搜索风险。Hermes使用SQLite与FTS5支持跨会话搜索。从功能上看，这能提升长期可用性。但从风险上看，系统可回忆面显著扩大。敏感信息、旧指令、错误总结、包含误导的历史讨论，都可能在后续任务里被再次召回。很多问题第一次出现时影响有限，进入搜索层之后才真正变成长期隐患。

第四类风险是外部记忆风险。Hermes支持多个外部记忆，并会在每轮对话前预取上下文、在对话后同步内容。这会把记忆边界从本地文件扩展到外部系统。风险随之增加：存储位置更多、同步链路更长、跨设备与跨平台关联更强、错误与污染的传播面更广。

同时论文arXiv2407.12784直接指出，面向长期记忆或知识库的污染可以在极低毒化比例下取得很高攻击成功率，同时对正常性能影响很小。这类结果的意义不在于具体攻击数字，而在于它证明了一个事实：只要Agent依赖可检索记忆与外部知识层，长期污染就有现实可行性

扩展面：MCP、skill、插件与外部集成风险

Hermes Agent通过MCP、第三方skill、插件与外部记忆接入外部对象。这条链路带来的核心问题，是系统行为不再只由Hermes自身lai决定，还会持续受到运行时扩展影响。

先看MCP。Hermes可以接入任意兼容的MCP服务器，自动发现工具，并额外注册资源与提示相关工具。同时Sampling默认启用，服务器还能在采样会话中带入工具定义并触发多轮工具使用。从风险角度看，这相当于把外部服务器的能力、工具描述、错误消息、提示内容和模型请求一起接进了Agent主循环。只要其中任一层存在误导、过度授权、错误工具设计或恶意文本，影响都可能透过MCP边界进入核心执行链路。

再看第三方skill。Hermes允许从多个来源安装skill，并对风险做扫描和分级。风险点在于skill本身常常以说明文档、模板和自动化指令的形式出现，它很容易被用户理解成可直接复用的任务模板或操作封装，而低估其对模型行为和执行路径的影响。一个写得像工作流指南的skill，完全可能改变模型如何组织任务、如何调用工具、如何处理凭据、如何理解边界。形式看起来越像文档，风险越容易被低估。

同时插件风险更高。Hermes插件可以注册工具、命令和生命周期，也可以注入消息与捆绑skill。这意味着插件不只是添加一个新能力，它还能插入Agent主循环周边，在模型调用前后、工具调用前后改变运行行为。项目本地插件一旦启用，本地仓库本身就成了运行时供应链的一部分。很多团队会对第三方依赖保持警惕，却对项目目录中的本地插件、脚本模板和自定义插件放松审查，这恰恰是高风险区域。

扩展面最危险的地方在于变化看起来通常合理。接一个GitHub的MCP服务器、装一个常用skill、打开一个项目本地插件、连一个外部记忆，单独看都像提升效率的正常操作。多项变化叠加之后，Hermes Agent的工具面、提示面、身份面与执行面都会跟着变化，系统边界会逐步偏离初始认知。这种偏离不像单点漏洞那样显著，却更贴近真实风险。

多入口、计划任务、后台任务与Sub-Agent风险

Hermes Agent与很多普通Agent的另一条明显分界线，在于它不只存在于当前终端。Hermes可以连接多平台，并共享会话路由，同时承接计划任务与后台运行。这会把风险从单入口问题扩大成多入口、多时段、多上下文问题。

第一类是身份入口风险。消息平台每增加一个入口，身份识别、配对关系、允许列表与消息来源判断就多一层复杂性。普通命令行Agent的输入源通常是当前操作者本人。Hermes Agent的输入源可能是群聊成员、Webhook来源、平台消息转发、定时任务或后台会话。只要入口识别和会话边界不够清楚，任务就可能在错误身份上下文里运行。

第二类是无人监管风险。Cron和后台任务会让Agent在用户离线时继续工作。风险因此从即时交互转向延迟触发。问题不一定出现在你发出指令的那一刻，也可能在数小时后、下一个周期、另一个平台或另一个Sub-Agent链路中出现。对于审计和复盘来说，时间断裂会显著提高理解成本。

第三类是Sub-Agent风险。Sub-Agent拥有隔离上下文、独立终端会话和独立工具限制，父上下文只接收摘要。但是隔离不意味着没有风险。父Agent传入的目标与上下文如果存在偏差、遗漏或污染，Sub-Agent会在错误前提下继续行动。父Agent只看到摘要，又会形成摘要型信任。多路并发执行时，误差会随着汇总和转发继续放大。

第四类是级联失败风险。只要一个系统同时具备多平台入口、计划任务、后台会话、MCP服务和Sub-Agent，单次偏差就更容易在后续阶段扩散。风险焦点不只是谁先出错，更在于错误如何穿过会话、时间和执行体继续传播。

把Hermes Agent放进OWASP Agentic Top 10

如果从OWASP Agentic Top 10的角度出发，Hermes Agent最值得优先关注的五类风险大致如下。

第一类是工具误用与利用，以及非预期代码执行，对应终端、浏览器、MCP与execute_code。这两类风险排位最高，因为它们直接连接真实动作。只要Agent能执行命令、调用外部工具、写脚本、操作浏览器页面，文本判断偏差就有机会转成系统风险。

第二类是身份与权限滥用，对应消息网关、平台令牌、环境变量、凭据文件挂载与远端执行上下文。Hermes Agent的权限很多时候是真实业务系统权限、真实平台身份和真实执行环境权限。权限边界一旦扩张，风险会沿着工具面向外继承。

第三类是记忆与上下文污染，对应上下文文件、冻结记忆、会话搜索与外部记忆提供者。这类风险危险在潜伏性。问题第一次出现时未必引发显性故障，进入长期状态后才会持续影响后续任务。

第四类是供应链漏洞风险，对应第三方skill、插件、MCP服务器与外部记忆提供者。Hermes Agent的供应链不只包括源码依赖，还包括提示、元数据、工具描述与运行时资源。对象类型越多，行为边界越难稳定。

第五类是级联失败、代理间通信不安全与持续失控活动，对应Sub-Agent、计划任务、后台任务和多平台投递。这类风险的可怕之处在于它们常常不会在第一步就暴露，而会在后续阶段以任务错位、摘要错误、错误传播和持续活动的形式表现出来。

总结：Hermes Agent的核心风险在于它已经像一层持续运行的Agent系统

Hermes Agent的最大危险，并不只来自单个脆弱点被击穿，更来自很多看似合理的功能在同一系统里逐步叠加，多个合理的功能合在一起就会把Agent推向高权限、长时运行、跨边界协同的状态。

换个角度看，Hermes Agent已经具备把语言理解、工具编排、持久记忆、跨平台通信与长期任务执行压进同一运行体的条件。这类Agent生产力提升会非常明显。但是一旦边界模糊，风险也会以同样速度放大。因此普通Agent常见的问题在HermesAgent里依然存在，但影响范围更大、持续时间更长、复盘难度更高、入口更多、扩展更快。换句话说，Hermes Agent的风险研究必须从系统视角展开，单轮提示词安全远远不够解释它的真实暴露面。

全文风险总结

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Security for AI 林之冰寒 林之冰寒《从Agent系统角度来看Hermes Agent攻击面》