引言

当下 AI 智能体（Agent）的自主执行、自动化决策、多工具联动能力愈发强大，能够独立完成复杂的科研、开发、运维、办公全流程任务，极大提升了工作效率。但能力越强，安全风险与失控隐患也就越大，想要放心落地使用智能体，核心难题始终围绕着权限管控：智能体可以合法访问哪些系统资源、严格禁止触碰哪些敏感资源、如何通过成熟机制精准约束其行为边界，成为至关重要的核心问题。只有彻底厘清智能体的资源访问规则、权限控制逻辑与安全隔离机制，从根源上规避越权访问、数据泄露、恶意操作、系统破坏等风险，才能真正实现智能体安全、可靠、可控的常态化使用。

摘要

Hermes Agent 是由 Nous Research 开发的主流开源 AI Agent 框架（以下简称 Hermes），其安全设计遵循纵深防御与最小权限原则，核心目标是限制系统被不当访问或控制后的潜在损害。与同类框架相比，Hermes 的访问控制逻辑具备典型的分层特征——不依赖单一防护边界，而是从用户接入、工具调用到资源执行，用多层校验机制形成完整的防护链条。

具体而言，Hermes 先通过用户授权层确认“谁能访问系统”，再在工具调用层用路径白名单、风险规则界定“工具能访问哪些资源”，最终由执行环境层的容器沙箱、权限裁剪实现“资源访问的隔离约束”。此外，其特有的 Tirith 权限审批系统与 Intent Bound Authorization（IBA）意图边界授权机制，还会对高风险资源操作进行二次校验，所有校验规则的配置入口统一落地在 config\.yaml 与环境变量中。

1. 资源访问控制的核心架构设计

Hermes 采用分层授权（Layered Authorization）和纵深防御（Defense in Depth）的安全架构，这是其资源访问控制的核心设计基底。这一架构的核心逻辑是：将资源访问的校验环节拆分到不同层级的防护边界上，上一层级无法覆盖的校验逻辑，会被下一层级的机制补全——即便某一层的防护机制被绕过，后续层级的校验规则仍能提供足够的安全防护。

这一架构的设计理念根植于官方定义的安全模型，从用户接入到资源执行的全链路覆盖了七层安全防护边界，每一层都有明确的防护重心与校验规则，且不同层级之间的校验逻辑形成了互补关系。

防护层级	核心功能	控制边界范围
用户身份授权层	验证访问者身份，确认其是否有权限与 Hermes 系统进行交互	消息平台（如 Discord、Telegram）的接入用户与交互权限
工具调用审批层	按照预设的风险规则，拦截需要额外确认的资源操作指令	工具发起的文件读写、命令执行、API 调用等资源操作请求
资源路径范围层	限定工具可访问的具体资源范围（如文件系统路径、可调用的外部工具）	文件系统、MCP 服务器等具备明确资源寻址路径的资源
执行环境隔离层	在资源执行环节裁剪权限，将进程资源访问行为约束在隔离环境中	工具进程、子进程在内的所有资源执行动作
凭证通信过滤层	隔离系统凭证与外部资源通信的环境变量，防止敏感信息泄露	系统凭证、外部通信链路在内的资源访问基础环境
会话状态隔离层	隔离不同会话的资源数据，避免资源访问冲突或越权	不同会话的资源数据、运行时状态信息
输入参数校验层	校验工具调用参数，阻断尝试绕过资源范围约束的注入类攻击	工具调用的所有输入参数，重点是与资源路径相关的参数

需要说明的是，上表中各层级的具体工作逻辑，均有对应的源码或配置项支撑：用户授权层的校验逻辑由 GatewayRunner 结合平台配置实现，工具调用审批层的规则由 tools/approval\.py 模块定义，资源路径范围层的配置项落地在 config\.yaml 中，执行环境隔离层的配置映射到容器启动参数，凭证通信过滤层的逻辑由 \_build\_safe\_env\(\) 方法实现，会话状态隔离层的逻辑在会话存储模块中，输入参数校验层的逻辑则嵌入在各工具的参数解析流程中。

在实际运行时，上述层级的校验逻辑并非完全按表格中的上下顺序严格执行，而是分为三个不同的校验阶段，不同阶段的校验逻辑各司其职，共同完成对资源访问的全链路控制：

- 接入阶段校验：仅在消息平台类网关部署场景下触发，由用户身份授权层对请求接入的用户身份进行校验——这是用户与系统交互的前置条件，未通过该校验的用户请求会被直接拦截。

- 请求阶段校验：用户请求通过接入阶段校验后，会被路由到对应的工具或 MCP 服务器。此时工具调用审批层会先拦截请求，判断该资源操作的风险等级；若需要进一步校验，则会触发资源路径范围层的逻辑，核对请求的资源目标是否在预设的允许范围内——任一环节校验不通过，请求将被直接拦截。

- 执行阶段校验：这是资源访问的最后一道校验边界，由执行环境隔离层、凭证通信过滤层、会话状态隔离层、输入参数校验层共同完成。其中，输入参数校验层会在工具实际执行资源访问操作前，最后验证其调用参数是否符合安全规则；而执行环境隔离层、凭证通信过滤层、会话状态隔离层则会从运行时环境角度，将资源访问操作的影响范围严格约束在预设的隔离区域内。

此外，为了避免合法用户的合法请求被不必要的安全规则拦截，Hermes 对部分信任级别较高的执行环境提供了安全校验豁免机制——比如在 Docker、Singularity 这类容器化执行环境中，由于执行环境隔离层已经能将资源操作的影响范围完全约束在容器内部，工具调用审批层的部分重复性安全校验规则会被自动跳过。这一机制既保证了系统安全，又避免了信任级别较高的环境中出现不必要的性能损耗。

2. 资源范围界定的策略与实现

Hermes 采用白名单机制作为资源范围界定的核心策略。这一机制遵循最小权限原则：所有资源默认处于禁止访问状态，只有管理员在配置文件中明确通过白名单规则授权的资源，才允许被系统访问。在具体落地过程中，这一策略由配置驱动的声明式规则与多个子机制共同实现，不同类型的资源有不同的规则配置方式。

2.1 基于配置的资源路径约束

这是 Hermes 对数据类资源最直接、最基础的范围控制策略，核心是通过 config\.yaml 配置文件中的声明式规则，将工具对文件系统类资源的访问请求，约束在管理员预先设置的目录或路径范围内。这一策略的设计目标是避免工具越权访问文件系统上的非授权敏感资源——比如系统级配置文件、用户的私密业务数据目录，或者其他 Agent 会话的工作数据。

这一机制的核心配置项是 tools\.\*\.allowed\_paths 规则，该规则对所有涉及文件系统交互的工具生效——包括 terminal Shell 命令执行工具、file 文件读写工具、code\_execution 代码执行工具，以及所有以 mcp\_\_filesystem\_\_\* 为前缀的 MCP 挂载文件系统类工具；配置规则的写法采用标准的 YAML 格式，支持绝对路径、相对路径的明确声明，也支持通过 glob 通配符语法（如 /\*、/\*\*）匹配多个子目录或文件；路径规则的配置方式兼容不同的底层执行环境——包括 Linux、macOS 等主流容器环境，以及本地直接运行的宿主环境，都能直接解析配置规则。

例如，要限制 terminal 工具只能访问 /home/user/projects 目录，file 工具只能访问 /home/user/documents 目录，可以在 config\.yaml 中添加如下配置块：

tools:
  terminal:
    allowed_paths:
      - "/home/user/projects"  # 绝对路径约束
  file:
    allowed_paths:
      - "/home/user/documents" # 绝对路径约束

需要注意的是，在实际配置 allowed\_paths 规则时，路径的最后一个字符不能遗漏斜杠（/）——否则规则可能会被工具通过路径遍历攻击绕过（例如，若规则设置为 /home/user但末尾缺少 /，工具可以通过访问 /home/user\.\./other 路径，突破该规则的约束范围）。此外，为了避免配置规则与实际执行环境的路径特征不匹配导致意外拦截，在容器化部署场景中，allowed\_paths 规则必须与容器内的实际工作目录配置保持严格一致——比如在 Docker 容器中，若通过 terminal\.cwd 配置项将工作目录设置为 /workspace，则 allowed\_paths 规则必须包含 /workspace 路径，且所有父目录的执行权限都需要被显式裁剪。

除了明确的路径白名单规则外，Hermes 还提供了两个互补的路径范围约束配置项，进一步强化资源访问的边界安全：

- agent\.workdir** 配置项**：这是所有工具的默认基础路径约束——若管理员未对某个工具配置独立的allowed\_paths 规则，系统会自动将该工具的资源访问范围约束在 agent\.workdir 指定的目录下；而如果该配置项也未显式设置，系统会默认将其设置为 Hermes 进程的启动目录，即用户执行 hermes 命令时的当前工作目录。

- terminal\.cwd** 配置项**：这是专门针对 terminal 工具的强化路径约束——该工具执行的所有 Shell 命令，其资源访问的父目录都会被强制约束在 terminal\.cwd 指定的目录下；这一配置项在容器化环境中会被自动映射为容器的初始工作目录，且无法通过 cd 命令或其他 Shell 操作绕过，即便某个工具的参数声明中允许使用绝对路径，该配置项也会覆盖其默认行为。

在实际执行过程中，所有文件系统访问请求都会被提交到 Hermes 的核心资源校验引擎，与配置的路径规则进行逐字符的精准比对。为了避免性能损耗，这一校验环节在工具启动时仅执行一次，不会对工具的运行时性能造成影响；同时，该校验环节会在符号链接解析完成后执行——这意味着即使用户在文件系统上创建了指向其他敏感目录的符号链接，只要该链接的目标路径不在 allowed\_paths 规则范围内，其资源访问请求仍会被拦截。

2.2 工具集与 MCP 服务器的资源范围控制

Hermes 对工具类资源（非数据类资源）采用两级范围控制策略，确保工具的资源访问能力被严格约束在最小范围内。第一级是平台级的工具集配置约束，第二级是 MCP 服务器的显式过滤规则约束。

第一级的平台级工具集配置，是通过 platform\_toolsets 配置项实现的——该配置项的核心逻辑是“按场景预设工具集、按平台授权使用范围”：Hermes 预先将具备相同资源访问权限的工具打包成工具集，比如将 file、browser、terminal 这类对本地资源有访问权限的工具归入 hermes\-cli 工具集，将 web\_search、web\_extract 这类仅对外部网络资源有访问权限的工具归入 web 工具集；管理员可以根据实际使用场景，在配置文件中为不同的运行平台（如 CLI 命令行终端、Discord 机器人平台、Telegram 机器人平台）分配对应的工具集，只有归入已授权工具集的工具，才能在对应的平台上被调用。

例如，若希望在 CLI 环境中禁用可能对系统造成损害的 terminal 工具，仅保留file、browser、web 这类风险较低的工具，可以在 config\.yaml 中添加如下配置块：

platform_toolsets:
  cli: [file, browser, web] # 仅授权指定的工具集

这一配置机制的关键在于，它是一个“全或无”的启用开关——未被归入已授权工具集的工具，不会出现在任何可用工具列表中，也不会被代理调用；同时，这一配置项在所有支持的消息平台中都独立生效，不同平台之间的工具集授权规则不会相互影响。

第二级的 MCP 服务器过滤规则，是 Hermes 对工具类资源范围控制的核心手段，也是其资源范围界定策略中最具特色的机制。MCP（Model Context Protocol）是 Hermes 中用于扩展外部工具能力的标准协议，支持从外部工具服务器发现并调用额外的资源工具——比如 GitHub 代码仓库、企业内部数据库、云服务 API 等；而 MCP 服务器的资源范围控制，本质上是对“外部工具能通过 MCP 协议访问哪些资源”的约束，且所有约束规则都需要在 config\.yaml 中显式配置。

这一机制的核心是“白名单优先、按需裁剪”，管理员需要通过配置项显式控制每个 MCP 服务器允许暴露的资源范围，只有在配置中明确授权的资源，才会被注册到系统中。具体来说，这一机制通过三个维度的配置实现：

- 服务器级启用控制：通过 enabled 配置项，决定是否将该 MCP 服务器的工具注册到 Hermes 中——若设置为 false，Hermes 会跳过该服务器的所有工具注册流程，甚至不会尝试建立连接。

- 工具级过滤规则：通过 tools\.include 白名单规则或 tools\.exclude 黑名单规则，精细控制该 MCP 服务器允许注册的具体工具列表——若同时配置白名单和黑名单，白名单规则会优先生效；这一过滤规则可以覆盖所有支持 MCP 协议的外部工具，比如对基于 MCP 协议的文件服务器，管理员可以通过白名单规则限制其只能访问指定路径下的资源；对基于 MCP 协议的 GitHub 代码仓库服务器，管理员可以通过白名单规则限制其仅能访问 search\_code、create\_issue 这类低风险的工具。

- 资源级权限控制：通过 tools\.resources 和 tools\.prompts 两个配置项，控制是否允许该 MCP 服务器暴露资源列表、资源读取能力——若设置为 false，该服务器对应的 list\_resources、read\_resource 这类资源操作工具将被禁用；这一配置项在默认情况下处于禁用状态，管理员需要手动开启，避免外部工具通过 MCP 协议获取资源的元数据或内容。

例如，要配置一个 MCP 文件系统服务器，使其仅能访问 /home/user/projects 目录下的资源，且仅允许调用 list\_files 和 read\_file 两个工具，可以在 config\.yaml 中添加如下配置块：

mcp_servers:
  filesystem:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/projects"]
    tools:
      include: [list_files, read_file] # 白名单规则，仅允许指定的工具
      resources: false # 禁用资源类工具

需要补充的是，这里的 tools\.include 白名单规则，与第一级 platform\_toolsets 配置的生效逻辑存在本质区别：platform\_toolsets 配置是在工具注册阶段生效，决定是否将某个工具加入到可用工具列表中；而 tools\.include 白名单规则是在 MCP 协议握手阶段生效，决定是否将某个外部工具的能力暴露给 Hermes 代理——两者在实际执行过程中互为补充，共同限定了工具类资源的访问范围。

2.3 意图边界授权（IBA）的动态范围控制

这是 Hermes 中针对资源访问范围的动态校验层，是对静态配置资源范围的运行时补充。静态配置的规则（如 allowed\_paths、MCP 过滤规则）是基于资源目标的防护边界，而 IBA 机制是基于资源访问意图的防护边界——它会在运行时对工具的资源操作意图进行二次校验，确认实际操作范围是否在预设的静态规则内。

这一机制的核心设计目标，是解决静态配置规则无法覆盖的资源访问风险场景——比如某个工具被合法调用后，其执行逻辑被恶意篡改，试图访问该工具的静态资源范围之外的敏感资源；或者工具的某个合法参数被恶意修改，试图绕过路径约束规则。这类风险仅靠静态配置的规则无法完全防护，必须在运行时进行额外的校验和约束。

IBA 机制的核心逻辑是“加密绑定、动态校验、超时吊销”：管理员先在配置文件中为每个工具声明明确的资源操作范围边界——比如允许执行哪些具体操作、允许访问哪些资源、允许传递哪些参数；在实际运行时，系统会为每一个合法的资源操作请求生成一个带加密签名的有效凭证，凭证中会绑定该操作的具体资源范围、执行用户、操作意图和有效期；而在实际执行每一次资源操作前，系统会先校验凭证的合法性，再将本次操作的实际资源路径、参数与声明的范围进行正则匹配校验；若校验通过，工具才能访问目标资源；若校验不通过，系统会直接拦截该操作，并将事件记录到审计日志中。

具体来说，IBA 机制会对以下几类资源访问操作进行重点校验，覆盖了资源越权访问的典型风险场景：

- 工具的资源操作范围是否超出了管理员的预设范围——比如 file 工具的 allowed\_paths 规则被设置为 /home/user/documents，但实际操作时试图访问 /home/user/\.ssh 目录下的文件。

- 工具的运行时参数是否被恶意篡改，试图绕过静态配置的规则——比如某个工具的参数中包含 \.\./ 路径遍历字符，试图突破 allowed\_paths 规则的约束范围。

- 子进程的资源访问范围是否超出了父进程的委托授权范围——比如父进程被授权仅允许访问 /home/user/projects 目录下的资源，但其 spawn 启动的子进程试图访问该目录以外的资源。

- 工具的操作类型是否与预设的风险等级匹配——比如被标记为只读风险等级的工具，试图执行写入或删除类的资源操作。

- 工具的操作凭证是否有效——比如凭证的签名被篡改、会话时间过期，或凭证对应的操作意图与实际执行的操作不匹配。

与静态配置的资源范围规则不同，IBA 机制的校验逻辑无法通过配置文件的修改或执行环境的隔离规则被绕过——即便用户在配置文件中将某个工具的 allowed\_paths 规则设置为包含所有磁盘路径，该工具的资源操作请求仍需经过 IBA 机制的二次校验；如果操作范围与配置的范围不匹配，仍会被拦截。此外，这一机制的校验环节被设计为轻量级，对工具的运行时性能影响极小——目前的官方版本中，单条校验规则的执行时延被控制在 5 毫秒以内。

3. 资源访问的优先级设定

在资源访问优先级的维度上，Hermes 采用了“分层校验、逻辑递进、隐式优先级覆盖”的设计思路。与传统的 RBAC 权限模型不同，它没有采用显式的优先级编号或权重值来定义资源访问的优先顺序，而是通过不同安全层级的校验逻辑前后顺序，以及配置规则的覆盖优先级，来间接实现资源访问的优先级排序——确认资源访问权限的过程，本质上是多个层级的校验逻辑依次博弈的结果，只有通过前一层校验的请求，才能进入下一层的校验环节。

3.1 校验层级的优先级顺序

这是资源访问优先级的核心体现——Hermes 的所有资源访问请求，都必须经过接入阶段校验、请求阶段校验、执行阶段校验三个层级的依次验证，且上一层级的校验结果优先于下一层级的校验结果生效。这意味着，只有通过前一阶段所有校验规则的请求，才会被允许进入下一阶段的校验环节；只要在其中一个层级的校验中被判定为“拒绝”，该请求就会被立即拦截，不会进入后续的任何校验环节。

三个校验层级的优先级顺序与校验逻辑细节如下：

优先级顺序	校验层级	校验逻辑核心要点	校验结果覆盖范围
1（最高）	接入阶段校验	验证用户身份的合法性，确认其是否有权限与系统进行交互	整个系统的交互访问权限
2（中等）	请求阶段校验	先校验工具的操作风险等级，再校验请求的资源范围是否被允许	工具级别的资源访问权限
3（最低）	执行阶段校验	对资源操作的参数、环境凭证、运行时权限做最终校验	进程级别的资源访问权限

需要说明的是，上表中的校验层级顺序是由 Hermes 的核心架构设计决定的，无法通过任何配置文件的修改或执行环境的调整被调换——这一设计确保了只有经过前序多轮校验的请求，才会在执行环节被允许实际访问资源。

其中，接入阶段校验的逻辑是由 GatewayRunner 内部的 \_is\_user\_authorized\(\) 方法实现的，该方法会按照严格的优先顺序逐条校验用户请求的来源信息——只要其中一条校验规则通过，就会直接放行该请求，不再执行后续的校验逻辑。具体来说，该方法的校验顺序为：

1. 首先校验对应平台的全允许标志（如 DISCORD\_ALLOW\_ALL\_USERS 环境变量）是否开启；

2. 若未开启，再校验该用户是否通过配对码被加入到 DM 配对批准列表；

3. 若不在该列表中，再校验该用户的 ID 是否被加入到对应平台的允许列表中；

4. 若仍不在该列表中，再校验该用户的 ID 是否被加入到全局允许列表中；

5. 若以上校验均未通过，则默认拒绝该用户的访问请求。

而请求阶段校验和执行阶段校验的逻辑，分别对应工具调用审批层和执行环境隔离层的校验规则——这意味着，即便某个用户通过了接入阶段的校验，其实际资源访问操作仍需要经过工具级、进程级的两层细粒度校验，才能被允许执行。

3.2 配置规则的优先级覆盖

在同一校验层级内部，Hermes 也设计了明确的优先级覆盖机制，保证在多条配置规则同时存在时，系统只会采用最严格或最具体的那条规则——这一设计的核心目标，是避免不同配置规则之间出现冲突，或被恶意用户利用规则冲突绕过安全校验。

具体来说，同一校验层级内部的优先级覆盖机制，主要分为三类场景：

- 白名单规则优于黑名单规则：若在 MCP 服务器的配置中同时存在 tools\.include 白名单规则和 tools\.exclude 黑名单规则，白名单规则会优先生效——例如，若管理员在配置中通过白名单规则允许了 create\_issue 工具的访问，又通过黑名单规则排除了该工具，最终系统会采用白名单的规则，允许访问该工具。这一设计是为了确保管理员的“明确授权”的优先级高于“间接限制”的优先级。

- 特定配置优于全局配置：在所有支持多维度配置校验规则的场景中，针对单个工具的配置规则，优先级高于针对所有工具的全局配置规则——例如，若管理员在配置中通过 terminal\.allowed\_paths 规则，为 terminal 工具单独设置了资源访问路径，又通过 agent\.workdir 全局配置，为所有工具设置了默认的资源访问路径，系统会优先采用 terminal\.allowed\_paths 规则的配置值。这一设计是为了确保管理员对单个工具的精准授权优先级高于全局的通用限制，避免全局规则覆盖针对单个工具的必要安全配置。

- 安全校验规则优于资源访问请求规则：在所有支持校验规则豁免的场景中，高风险操作的安全校验规则优先级高于普通资源访问请求的规则——例如，若用户在配置文件中将 approvals\.mode 设置为off，意图关闭所有安全审批规则，但同时又在hardline\_blocklist 中配置了禁止 rm \-rf / 这类高危命令的规则，系统会优先采用 hardline\_blocklist 规则的配置值，拒绝执行这类高危命令。这一设计是为了确保即使用户错误地关闭了部分安全校验规则，核心的安全防护机制仍能生效。

3.3 风险等级的优先级逻辑

这是资源访问优先级的另一种体现——Hermes 的 Tirith 安全审批系统会根据工具的操作风险等级，对资源访问操作进行差异化的优先级处理，决定是否需要用户额外人工审批，或直接拒绝该操作的执行。具体来说，Tirith 系统将所有工具的资源操作行为划分为四个风险等级，从低到高依次为：

1. 只读级（Read-Only） ：无任何副作用的资源操作，不会对系统状态或资源内容产生任何持久化修改——比如读取文件、查询数据库、获取资源列表等操作。这类操作通常会被自动允许，不需要额外的人工审批。

2. 低风险写入级（Low-Risk Writes） ：仅对非核心资源进行局部修改的操作，不会对系统的核心功能或关键资源造成不可逆的损害——比如编辑项目中的普通文件、修改本地工作目录下的资源内容、调用测试环境中的外部 API 等操作。这类操作需要在日志中记录，但不需要额外的人工审批。

3. 高风险写入级（High-Risk Writes） ：对核心资源有影响的资源操作，可能会对系统的核心功能或关键资源造成损害，但可以被回滚或恢复——比如执行部署命令、修改核心配置文件、调用外部有数据写入能力的 API 等操作。这类操作需要经过管理员人工审批通过后，才会被允许执行。

4. 破坏性级（Destructive） ：对系统资源有不可逆破坏的操作，可能会导致系统崩溃、数据丢失或其他不可恢复的损害——比如递归删除文件系统中的目录、格式化磁盘分区、直接删除数据库表、停止系统核心服务等操作。这类操作会被直接拦截，无法通过人工审批豁免。

在实际执行过程中，Tirith 系统会优先拦截风险等级较高的资源操作请求——只要工具的操作风险等级匹配到了高风险等级的规则，系统就会直接进入对应的审批或拦截流程，不会再进行低风险等级的校验逻辑。同时，这一风险等级的校验规则，优先于工具的普通资源访问控制规则生效——即便是被允许在 allowed\_paths 规则范围内的资源操作，只要其风险等级较高，仍需要经过对应的审批流程；若用户拒绝了该操作的审批请求，或该操作的风险等级为破坏性级，系统仍会拦截该操作。

例如，若管理员在配置中通过 terminal\.allowed\_paths规则，将 terminal 工具的资源访问范围限制在/home/user/projects 目录下，但该工具试图执行 rm \-rf /home/user/projects 这类递归删除命令时，Tirith 系统会先识别到该命令的风险等级为破坏性级，会直接拦截该操作，不再校验资源路径是否在允许范围内。

这一设计的核心逻辑是，“操作的风险等级”这一安全要素，比“操作的资源目标范围”这一业务要素更优先——即便资源目标的范围被严格限制，只要操作的风险等级较高，系统仍会要求额外的审批或直接拦截。这是防止系统被恶意代码或误操作破坏的最后一道业务线防护屏障。

3.4 资源访问优先级的实际表现

上述两种优先级逻辑的组合，在实际场景中主要表现为两种形式：

- 优先校验用户身份：所有资源访问请求，必须先通过接入阶段的用户身份校验，再进行资源范围的校验——即便是被允许在 allowed\_paths 规则范围内的资源操作，若发起请求的用户未通过网关层的身份校验，该请求仍会被拦截。例如，若某个未被加入允许列表的 Discord 用户，试图通过消息平台调用工具访问资源，系统会直接拦截该请求，不再进行后续的任何资源范围校验。

- 优先校验操作风险：在用户身份校验通过后，系统会先校验工具的操作风险等级，再校验其资源范围——即便是被允许在 allowed\_paths 规则范围内的资源操作，只要其风险等级较高，仍需要经过用户人工审批；若用户拒绝了该操作的审批请求，系统仍会拦截该操作。例如，若某个用户被允许调用 terminal 工具，且该工具的 allowed\_paths 规则包含 /home/user/projects 目录，但该工具试图执行 rm \-rf /home/user/projects 这类递归删除命令时，系统会先识别到该命令的风险等级为破坏性级，会直接拦截该操作，不再校验资源路径是否在允许范围内。

4. 不同类型资源的访问控制差异

Hermes 将系统资源分为三类分别进行控制，不同类型的资源采用的控制机制、约束范围与严格程度存在明显差异——这种差异化的控制逻辑，是为了在安全风险与功能可用性之间找到精准平衡。

4.1 数据资源的访问控制

数据资源是指文件系统、数据库、消息系统等存储和承载数据的资源，是 Hermes 中最基础也是最受关注的资源类型——这类资源的安全防护重点，是防止数据被未授权访问、修改或删除。Hermes 对数据资源采用了“路径约束+环境隔离+参数校验”的三重核心控制机制，其控制逻辑在所有资源类型中最严格。

具体来说，数据资源的访问控制逻辑覆盖了所有可能的资源访问渠道，包括：

- 文件系统资源：这是 Hermes 中最基础的数据资源类型，其访问控制的核心是 allowed\_paths 规则与agent\.workdir、terminal\.cwd 配置项的组合约束——所有文件的读写操作都必须在允许的路径或工作目录内进行，且这一规则会被所有文件系统类工具继承和执行。此外，在执行环境隔离层，容器的文件系统会被设置为只读模式，所有可能包含敏感数据的系统目录（如 /etc、/root、/home/user/\.ssh）会被明确设置为只读权限，或通过容器的挂载规则被完全隔离。

- MCP 服务器提供的数据资源：这类资源的访问控制逻辑分为两个层面：一是 MCP 服务器的白名单/黑名单规则约束——只有在配置中明确授权的资源，才会被注册到系统中；二是 MCP 服务器的自身权限约束——若 MCP 服务器的实际执行环境是本地的，则需要遵循本地系统的权限配置；若 MCP 服务器是容器化部署的，则需要遵循容器的文件系统权限配置。

- 敏感数据资源：Hermes 会对包含敏感数据的环境变量、配置文件或系统资源路径进行额外的隔离防护——所有的环境变量、配置文件或系统资源路径在传递给工具进程或 MCP 服务器前，会被自动过滤；包含敏感数据的资源路径（如 \~/\.ssh、/etc/passwd），会在工具进程启动时被自动设置为只读权限，或通过容器的挂载规则被完全隔离。此外，对这类资源的访问操作，会被强制记录到审计日志中，且无法通过任何配置规则被豁免。

需要补充的是，数据资源的访问控制逻辑，对所有工具和 MCP 服务器类型都统一生效——这意味着，即便是由第三方开发者开发的外部工具，其对数据资源的访问操作也必须遵循这些约束条件；同时，这类资源的访问控制逻辑，在接入阶段、请求阶段、执行阶段的校验环节中都会被重点覆盖。

4.2 计算资源的访问控制

计算资源是指执行工具实际代码的进程、容器或虚拟机资源，包括 CPU、内存、磁盘、网络等基础计算资源——这类资源的安全防护重点，是防止恶意代码消耗宿主系统资源，或在执行过程中越权访问系统的其他安全边界。Hermes 对计算资源的控制手段完全集中在执行环境隔离层，通过“容器隔离+权限裁剪+资源限制+网络隔离”的组合策略实现，这是与数据资源访问控制逻辑的核心差异。

具体来说，计算资源的访问控制逻辑覆盖了所有可能的执行环境，包括：

- 容器化执行环境：这是 Hermes 中计算资源访问控制的核心实现方式——无论采用 Docker、Singularity、Modal 还是 Daytona 容器化后端，所有工具的实际执行进程都会被约束在一个独立的容器沙箱中；该沙箱会使用严格的安全配置参数启动，限制工具的执行权限，并且与宿主系统的资源环境完全隔离。这一机制的核心是将计算资源的访问范围限制在容器的独立命名空间和文件系统视图内，一旦工具执行的命令突破了这个安全环境的资源约束范围，就会被系统直接拦截。

- 资源配额限制：管理员可以在 config\.yaml 中通过 container\_cpu、container\_memory、container\_disk 等配置项，为容器设置可用的计算资源配额——比如限制容器只能使用 1 个 CPU 核心、5GB 内存，或者 10GB 磁盘空间；若容器内的工具执行进程尝试申请更多的资源配额，或执行了类似 fork bomb 这类消耗系统资源的恶意操作，系统会直接拦截该操作，并终止对应的容器进程。

- 权限裁剪机制：这是计算资源访问控制的核心安全手段——无论容器的启动参数如何配置，Hermes 会在容器启动时将其所有的 Linux 系统权限（capabilities）全部裁剪掉，只保留与工具执行相关的必要三个权限，即 DAC\_OVERRIDE、CHOWN 和 FOWNER；若需要增加额外的权限配置，必须在配置文件中明确通过 docker\_extra\_args 这类配置项声明。此外，Hermes 会在容器启动时强制添加\-\-no\-new\-privileges 标志——这会防止容器内的工具执行进程通过 setuid 或 setgid 位，提升自己的权限，或篡改宿主系统的资源权限配置。

- 非容器化执行环境：若工具的执行环境不是容器化部署的，比如在宿主机器上直接执行或通过 SSH 连接执行，Hermes 会采用“进程级权限裁剪+工作目录约束”的组合策略进行防护——所有工具的执行进程会被以非 root 用户的身份启动，工作目录被自动设置为 terminal\.cwd 或 agent\.workdir 指定的路径；若该进程尝试访问这些路径之外的资源，或尝试获取更高的权限，系统会直接拦截该操作。

- 网络隔离机制：这是计算资源访问控制的补充防护手段——在容器化部署场景中，容器的网络命名空间会被默认设置为隔离模式，即容器内的工具执行进程无法访问宿主机器的网络权限，也无法通过网络访问宿主机器上的其他资源；若需要允许容器内的工具执行进程访问特定的网络服务或资源，必须在配置文件中明确通过 docker\_extra\_args 这类配置项声明额外的端口映射或网络连接规则。

- 子进程环境过滤机制：这是计算资源访问控制的补充防护手段——工具的所有子进程（比如由 terminal 工具启动的 Shell 进程，或由 MCP 服务器启动的子进程），都会继承父进程的资源访问权限配置；Hermes 会在子进程启动时对其执行环境进行过滤，仅将安全的基础环境变量（如 PATH、HOME、XDG\_\*）传递给子进程，所有包含敏感信息的环境变量或配置文件路径会被自动剥离，无法被子进程继承或访问。

需要补充的是，计算资源的访问控制逻辑与数据资源的访问控制逻辑存在明确的先后顺序：工具必须先通过数据资源的路径范围校验，再通过计算资源的环境校验，才会被允许执行——这意味着，数据资源的路径范围校验是计算资源环境校验的前置条件；若数据资源的校验失败，计算资源的校验环节不会被触发。

4.3 工具资源的访问控制

工具资源是指由 Hermes 或外部 MCP 服务器提供的可执行的工具能力，比如 Shell 命令、文件读写、HTTP 请求、API 调用等——这类资源的安全防护重点，是防止未授权的工具被调用，或授权的工具被恶意调用时访问非授权资源。Hermes 对工具资源采用了“工具集配置+MCP 过滤+风险审批+参数校验”的组合控制策略，控制逻辑的严格程度介于数据资源和计算资源之间。

具体来说，工具资源的访问控制逻辑覆盖了所有可能的工具类型，包括：

- 平台级工具集的授权约束：这是工具资源访问控制的第一道防护边界——管理员可以通过 platform\_toolsets 配置项，为不同的运行平台分配对应的工具集，只有归入已授权工具集的工具，才能在对应的平台上被调用；若某个工具未被归入对应平台的已授权工具集，系统会在工具注册阶段跳过其注册流程，该工具将无法被代理调用。

- MCP 服务器的过滤规则约束：这是工具资源访问控制的第二道防护边界——管理员可以通过 MCP 服务器的 tools\.include 白名单规则或 tools\.exclude 黑名单规则，精细控制该服务器允许注册的具体工具列表；若某个工具未被加入白名单或被加入黑名单，系统会在 MCP 协议握手阶段跳过该工具的注册流程，该工具将无法被代理调用。

- 工具级的风险审批规则约束：这是工具资源访问控制的第三道防护边界——Tirith 系统会根据工具的风险等级，对其访问请求进行差异化处理；若工具的风险等级高于管理员预设的阈值，系统会在执行该工具前，向管理员发送人工审批请求；若管理员在预设的时间内（默认 5 分钟）未通过审批，或直接拒绝了该审批请求，系统会直接拦截该工具的执行。

- 工具级的路径范围约束：这是工具资源访问控制的第四道防护边界——所有工具的资源访问请求，都会被提交到资源路径范围层进行校验；若工具的资源访问请求不在配置的允许路径范围内，系统会直接拦截该工具的执行，不再进行后续的校验环节。

- 执行环境的隔离规则约束：这是工具资源访问控制的最后一道防护边界——所有工具的执行进程，都会被约束在执行环境隔离层的沙箱内；若工具的执行进程突破了隔离层的资源约束范围，系统会直接拦截该工具的执行，并终止对应的容器进程。

4.4 不同资源类型的控制差异总结

从实际执行效果来看，三类资源的访问控制逻辑并非完全独立，而是形成了一套完整的、覆盖资源访问全流程的防护链条，其控制手段差异清晰可辨：

资源类型	核心控制机制	主要控制依据	控制严格程度
数据资源	路径范围约束、工作目录约束、容器文件系统权限配置、服务端权限隔离	工具配置的 allowed\_paths 规则、agent\.workdir 配置项、容器的文件系统挂载规则	高（直接限制资源的访问目标）
计算资源	容器资源配额限制、容器权限裁剪、容器网络隔离、子进程环境过滤、非容器化进程的权限隔离	容器的启动参数、container\_\* 配置项、工具的执行用户身份	中（直接限制资源的执行环境）
工具资源	平台级工具集授权、MCP 服务器工具过滤、工具风险等级审批、工具级资源路径范围约束	platform\_toolsets配置项、MCP 服务器的过滤规则、Tirith 系统的风险等级规则	低（直接限制资源的调用入口）

从资源访问的全流程角度看，这三类资源的访问控制逻辑组成了完整的链条：工具资源是访问数据资源的前置入口，必须经过工具资源的校验，才能被允许调用；数据资源是工具资源的访问目标，必须经过数据资源的校验，才能被允许实际访问；计算资源是前两类资源的实际执行环境，所有资源的实际执行进程都必须在其约束范围内运行。

需要强调的是，在实际执行过程中，三类资源的访问控制逻辑并非完全独立，而是存在多个互补的校验重叠环节——例如，对文件资源的