Agent 权限校验应设在工具调用必经处

Agent 能调用工具，不代表它发起的每次调用都该被放行。原文讨论的是一个具体的架构问题：当 LLM 读取了不可信内容，又握有文件、邮件等工具权限时，访问控制应该放在哪里？

作者的结论是：把控制放进 Agent 到工具的必经请求路径，执行前检查身份、工具和参数，并记录每次放行与拒绝。这篇没有实测数据，但它指出的权限边界，值得正在接入 AI 工具调用的程序员检查。

为什么允许调用工具，还要检查每次调用

作者把 AI agent security 定义为：约束一个由 LLM 驱动的自主系统，能拿着已有凭据和工具做什么。它讨论的是访问控制，而非模型对齐。

Agent 通常持有 API key、工具定义，以及决定下一步调用哪个工具的循环。问题在于，它读取的内容可能来自外部，而它手中的权限却来自系统授权。外部文本一旦影响了行动，就可能借用这些权限完成原本无权执行的操作。

这就是「混淆代理」（confused deputy）：有权限的执行者，被没有权限的输入诱导去办事。

原文举了一个例子：Agent 拥有 read_file 和 send_email。它读取的文档要求它把某个配置文件的内容发到外部邮箱。整个过程未必需要模型被越狱，两个工具也都可能在允许列表里。

漏洞出在授权粒度。允许 send_email，并没有回答邮件可以发给谁；允许 read_file，也没有回答文件可以从哪里读取。作者给出的约束是：邮件仅允许发往内部域名，文件读取不得越过声明的根目录。

工具名只能限定动作种类，参数约束才能限定这次动作的范围。

控制点必须在执行前，而且无法绕过

作者提出在请求路径上设置策略执行点（policy enforcement point）。Agent 先请求这个控制点，通过检查后，调用才会转发给工具。

这个位置需要满足三个条件：

• 每次工具调用都必须经过它。如果 Agent 可以自行决定是否使用某个安全包装器，这个包装器就只能提供建议。
• 它必须看得到调用参数。只检查工具名，会漏掉「合法工具加危险参数」的调用。
• 它必须在执行前做决定。事后日志能帮助追查，但无法撤回已经发出的邮件。

执行顺序同样重要：先认证 Agent 身份，再根据工具及参数授权，决定允许、拒绝或要求审批，生成决策记录，最后才执行获准的调用。

每个 Agent 应有独立身份与凭据，并只获得任务需要的最小工具集合和参数范围。这样策略才能区分不同 Agent 的权限。

监控也要放进这条路径。作者要求每次允许或拒绝都生成结构化记录，包含 Agent 身份、工具、参数、策略裁决和时间戳。拒绝不能静默消失，否则团队既看不到被拦下的尝试，也缺少调整策略的依据。

这里的关键区别是：工具是否执行成功，与策略为什么放行，是两个需要分别回答的问题。

RESK 提供的是哪两块能力

原文用 RESK 承接这套架构，介绍了两个组件。

reskSecure 是执行前的控制层，用来判断哪个 Agent 可以调用哪个工具，以及参数需要满足哪些约束。按作者描述，被拒绝的调用不会到达工具。

ReskPoints 负责决策记录，把每次策略评估输出为结构化事件。作者希望通过这种组合，让监控成为授权路径的一部分，减少授权逻辑与日志集成之间的脱节。

但原文没有给出 SDK 调用示例、策略配置、性能开销或测试结果，也没展开身份认证和审批流程的具体实现。因此，能从文章里明确拿走的是架构与检查项；这些产品是否适合现有系统，还无法据此判断。

我的判断

我认同作者对控制位置的判断。提示词可以告诉 Agent 应该遵守什么规则，但如果工具端仍接受越界参数，提示词就承担不了权限边界的职责。工具允许列表依然有用，只是它还需要参数级授权来补全。

不过，「唯一请求路径」是一个需要验证的前提。假如 Agent 还能拿着同一份 API key 直接访问底层服务，中间控制层就可能被绕过。画出一个安全网关，并不等于所有调用已经受它约束。

原文把失败归因于缺少策略，表达得较绝对。更稳妥的理解是：这个例子暴露了权限边界缺口，不能据此排除模型行为对整体风险的影响。

集中控制也不是唯一实现方式。如果现有工具服务已经能识别调用者，并在执行前检查资源范围，可以沿用这套服务端授权。原文没有比较这种做法与 RESK 的成本、覆盖率和维护负担，也没有对照数据证明后者更好。

能拿来做什么

• 给 Node Agent 梳理一遍工具调用链，确认每次调用都经过执行前授权，并检查 Agent 是否还持有能绕过该路径的直连凭据。
• 把工具允许列表细化成参数规则。例如为 read_file 声明可读根目录，为 send_email 限制收件域名。
• 为每个 Agent 配置独立身份和任务所需的最小权限，避免所有 Agent 共用同一组宽泛授权。
• 把允许、拒绝和要求审批都纳入结构化决策记录，保留工具、参数、裁决与时间戳，让排查能回答「为什么执行」和「为什么被拦」。