文章总结： 本文通过对比Hermes智能体的七层安全模型与《人工智能安全治理框架》2.0版，指出AI智能体的发展已部分超越现有治理框架的监管范围。研究发现Hermes在数据安全、隔离执行等层面存在技术优势，但缺乏对模型算法安全的系统性覆盖。文章揭示治理框架在智能体工具权限、提示注入防御等新型风险面前存在监管空白，建议未来需融合顶层制度与底层架构实现协同治理。 综合评分： 82 文章分类： 技术标准,政策法规,AI安全,应用安全,安全建设

智能体安全风险与应对机制的演进对现有AI治理框架的挑战：以Hermes安全模型与《人工智能安全治理框架》2.0映射为例

原创

原浩 原浩

苏州信息安全法学所

2026年5月3日 11:36 江苏

在小说阅读器读本章

去阅读

Hermes Agent作为当前主要的AI智能体（Agent）应用，在功能和安全两端都备受瞩目。本文通过将其官方（Nous Research）提出的分层安全模型（seven layers security model）（以下统称“分层安全模型”）与TC260等于2025年9月更新的《人工智能安全治理框架》2.0版本（以下统称“《框架》”）进行系统性比对。指出：Hermes为代表的智能体发展已经“部分”超出了当前《框架》等主流标准、指引类治理框架的约束范畴，在观察监管“真空”的同时，亦需对整体性的AI治理思路进行审视、反思。

一、Hermes分层安全模型（非从模型到审计的递进线性关系，部分安全机制存在多层级交叉配置、协调调度和持续改进等情形；基于主要安全特性总结，内容和中英文对照上可能存在不完全准确对应）：

| | | | | — | — | — | | | | | | 1 | 模型安全层（Dangerous Command Approval） | 有害请求拒绝、命令审批和超时机制、工具权限、人工介入（human-in-the-loop）等 | | 2 | 网关授权层（User Authorization (Gateway)） | 与消息平台的授权、认证和通讯安全机制等 | | 3 | 隔离执行层（Container Isolation） | 容器隔离、沙箱机制、文件系统持久化等 | | 4 | 终端安全层（Terminal Backend Security Comparison） | 区分不同适用场景的隔离机制（本地、远程、容器、沙箱）等 | | 5 | 数据访问层（Environment Variable Passthrough） | 沙箱过滤、凭据安全传递、会话隔离等 | | 6 | 接入安全层（MCP Credential Handling） | 接入安全、凭证保护、上下文注入保护、内容扫描、访问策略等 | | 7 | 实施部署层（Best Practices for Production Deployment） | 网关安全、API Key保护、网络隔离、日志和安全更新等 |

整体上看，Hermes的分层安全模型能够（部分）覆盖从模型底层到用户交互的大致的攻击面，但难以线性的做自下而上（如OSI模型等）的从物理层到应用层的清晰的“传统”理解，这也客观上说明该分层安全的模型化考虑仍有极大的优化和调整空间。

二、将Hermes分层安全模型映射到《框架》上的缺失观察

《框架》通过将人工智能安全风险区分为内生安全风险、应用安全风险和衍生安全风险的方式，并进一步细分为30项具体安全风险，建立了《安全风险与技术应对措施、综合治理措施映射表》。

如果将Hermes智能体作为《框架》的一类治理技术对象，则应能通过该映射表将Hermes智能体的安全风险进行对应，以评价其可能引入的安全风险，特别的，应能评价其分层安全模型是否可作为技术应对措施，以及有效性的问题。

一般而言，Hermes智能体应归为人工智能技术“应用”，并主要的涉及“应用安全风险”中的网络系统安全、信息内容安全、现实安全风险的问题，同时，尽管Hermes智能体非模型算法本身，但应至少涉及“内生安全风险”中的数据安全风险问题（Hermes智能体实际上假设了模型算法本身的安全，未评价模型算法安全风险中的决策可靠性、对抗攻击性等问题，但理论上应涉及。本文为简要起见，对模型算法安全风险不做讨论）。基于以上，将Hermes分层安全模型映射到上述四类安全（域）的符合性讨论如下：

1、模型安全层、接入安全层等与《框架》的数据安全风险应对措施相呼应，通过指令拒绝、内容过滤等“拒绝前馈”（Refusal Before Action），在后端模型作出指令、决策之前进行安全拦截。但该安全机制属于“推理阶段”的方案，并不涉及模型算法安全风险的回应——因其实际上假定了模型安全，故也不涉及真正意义上的“训练阶段”的算法和数据安全。

2、区分不同终端、后端的隔离执行层和容器安全层（体现在不同层级中的各类安全沙箱机制）将智能体作为“具有操作系统级别代码执行权限的Agentic AI（新加坡《智能体人工智能模型治理框架》术语）”进行安全考虑，限制智能体的代码执行在隔离的进程或沙箱容器中进行，不可访问宿主文件系统，并通过黑白名单、工具权限等进一步约束，其权限管理已经深入智能体内部工具（命令、插件、函数等）调用、编排和执行过程的权限传播。

上述这些安全机制尚无法在现有《框架》中得到对应和充分体现，《框架》将“沙箱”作为一类仿真技术适用于“模型算法研发安全”的开发测试和验证，将API接口的身份认证和权限控制作为一类 “应用建设部署安全”措施仅作最小权限原则规定，不能适用或针对AI智能体的模型、工具调用场景，说明智能体的发展已经超越了《框架》设想范围。

3、数据访问层体现的隐私/个人信息、敏感/重要数据保护主要关注于运行期本地、用户的数据访问控制，仅涵盖《框架》构造的数据全生命周期的一小部分节点，不涉及数据采集、数据清洗、数据跨境流动、数据质量（投毒、偏见、歧视）、训练数据（脱敏）审查等等，其仅（能）解决本地文件系统和用户数据的安全，这又佐证了Hermes智能体作为一类AI智能体应用的典型特点。

4、数据访问层和接入安全层中的提示注入和上下文安全机制与《框架》的提示注入攻击风险和鲁棒性是两个不同层面的安全机制：（1）Hermes分层安全模型从工程应用角度构建了多层提示注入防御，包括系统提示加密存储、用户输入与系统指令隔离、提示模板安全检查、安全扫描、角色反转检测等等，对系统提示泄露、指令劫持、间接提示注入等智能体特有攻击面进行回应；（2）《框架》则是从模型开发和算法安全层面上提及对抗性训练和降低注入攻击风险，其所考虑的注入攻击和风险传导是“自上（模型）而下（应用）”方向，这也与Hermes分层安全模型的Tirith 预执行安全扫描、上下文文件注入防护思路不同。

5、实施部署层和审计追溯机制方面，严格而言这并不构成智能体单独的一层安全模型，而是要求分析与决策执行过程的日志化，并提供一些经过初步验证的行业最佳实践的尚未体系化的汇总，也说明其意识到不同国家地区技术发展阶段和治理理念差异，因此实际上给出了弹性的宽泛建议。《框架》则可理解为这些建议在中国法语境下的（强制和非强制性）体现和制度安排，并对应到数据安全、算法备案、监测预警、事件报告等具体的现有法律法规、部门规范性文件、相关规则标准中。

一个初步的映射关系如下表（需注意：智能体分层安全模型的部分考虑超出了《框架》设计范围，基于《框架》的下表无法体现）：

三、结论与建议

Hermes分层安全模型体现了开源AI智能体作为应用安全定位和基于行业最佳实践的努力。其与《框架》映射的情况一方面可以得出：即使仅从“应用安全风险”应对措施上，AI智能体本身也仍有改进空间的结论（特别是对各类外部工具权限的理解和透传（Passthrough）认识上，Hermes智能体的版本演进上可以看出其审慎姿态）；但同时也在更深层面上反映了当前治理框架在面对智能体发展时部分监管机制落空的现实。这种反差暗示了当前所设想的人工智能整体性安全治理，可能仅是未来充分发展的人工智能全貌中的片段或阶段。这种“局部与整体”的辩证关系，在制定人工智能综合性立法时，应给与足够重视。

乐观展望，《框架》的迭代代表着中国在AI治理领域的系统性思考，它在数据安全、对抗鲁棒性、供应链合规、伦理治理等方面展示了远见，但AI 智能体的发展速度已超越了《框架》设想范围，需要Hermes智能体等开源架构、应用提供丰富的安全治理工程实践和可能性范本。

两者不存在“谁取代谁”“谁优于谁”的问题，而是“互补”“奔赴”的关系：《框架》提供了“为何安全”的治理逻辑与合规框架，Hermes分层安全模型尝试着“如何安全”的工程实现与架构范式。未来的AI智能体安全，应然的走向多者融合——既要有顶层治理的制度约束，也要有底层架构的安全内建，还要有各类中间层的弹性周全。

下期我们将讨论企业场景中部署Hermes智能体的合规考虑和实务建议。

（本文仅为作者观点，不代表所在单位意见或提供咨询、合规建议）

免责声明：

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

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

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

本文转载自：苏州信息安全法学所 原浩 原浩《智能体安全风险与应对机制的演进对现有AI治理框架的挑战：以Hermes安全模型与《人工智能安全治理框架》2.0映射为例》