Agent 权限校验应放在工具执行之前

Agent 能读文件、发邮件之后，安全问题就不只是模型会不会乱答，而是它能否把错误指令变成真实操作。原文的核心主张很明确：权限检查应放在工具调用路径中，由模型之外的代码执行，提示词不能承担这道防线。

这篇文章值得读的地方，是把认证、授权和监控各自该放在哪里讲清楚了。它也介绍了 reskSecure 和 ReskPoints 两个产品，但没有提供代码、实测结果或对照数据。可以借鉴架构思路，产品效果则要另行验证。

权限检查为什么要等模型选完工具

一次典型的 Agent 请求，会经过用户输入、模型推理、工具选择、工具执行，再把结果交回模型。

这里有两个不同的问题：调用者是谁，以及这次具体操作能不能做。前者是认证，应该在模型处理输入之前完成；后者是授权，要等模型生成工具参数之后、执行之前完成。

原因很直接：只知道用户身份，还不知道他准备操作什么；只知道工具名称，也不知道它将访问哪个文件、把邮件发给谁。拿到具体参数，才能把身份和目标资源放在一起判断。

模型负责提出调用，代码负责决定是否放行。

因此，把「不得读取敏感文件」写进 system prompt，并不能替代工具入口的权限判断。提示词可以指导模型，但不能保证模型始终遵守。真正的拦截必须在模型不配合时依然执行。

监控也要跟着工具调用走。只保存最后一段回答，看不出中间访问过什么，更难判断是否发生过越权尝试。

工具有权限，不代表调用者有权限

原文用读文件和发邮件两个工具说明攻击路径。

假设邮件工具使用一个拥有广泛发送权限的服务凭据。用户粘贴的文本中夹带了指令，要求 Agent 读取配置文件，再发到外部邮箱。模型接受这段注入指令，依次调用两个工具。从底层服务看，凭据有效，API 也接受请求，两次操作都可能成功。

问题出在：工具层只检查了凭据是否可用，没有判断当前调用者能否读取这个文件，也没有判断这个收件人是否在允许范围内。

这里需要两层约束。

第一层是缩小工具凭据的权限。读取工具只访问指定路径集合，发送工具只面向指定收件人集合，尽量减少单个工具失控后能触及的范围。

第二层是逐次授权。每一次调用，都用已认证的调用者身份和模型生成的具体参数重新判断。即便工具具备读取能力，也不能据此推定所有用户都能读取它覆盖的全部资源。

原文把顺序归纳为：认证、授权、执行、记录。这里的执行应以授权通过为前提，被拒绝的调用同样需要留下记录。日志至少包含调用者、工具、参数、授权决定和结果，才能解释一次操作为什么被允许或拒绝。

作者给出的产品分工是：reskSecure 在工具边界执行最小权限检查，ReskPoints 记录调用参数和结果，用于观察拒绝事件与异常模式。接入方式是包装工具执行入口，让每次调用都经过检查，同时写入监控记录，模型本身保持不变。

我的判断

我认同文章对控制位置的判断。与不断补充提示词规则相比，在工具执行前做权限检查，更适合承担必须强制遵守的约束。它也比只在入口验证登录状态更完整，因为登录成功并不等于可以操作所有资源。

但「最小权限」说起来简单，落到系统里仍有不少细节。指定路径如何处理路径别名，收件人范围如何维护，用户身份怎样可靠地传到工具层，原文都没有展开。凭据能否直接限制到路径或收件人，也取决于底层服务；不能原生限制时，需要在执行层补充检查。

日志同样不是越全越好。原文要求记录参数和结果，这有助于审计，但配置文件内容、邮件正文或凭据也可能因此进入日志。我的判断是，实际接入时还需要设计脱敏、访问权限和保留策略，这些并非文章已经解决的问题。

至于 reskSecure 和 ReskPoints，原文只有能力描述，没有集成示例、性能开销、绕过测试或与自建方案的比较。不能据此认定它们优于在现有工具网关中实现授权与审计。这部分属于方案介绍，尚不足以构成效果验证。

另外，「只有这一处才能同时知道身份和操作内容」说得过满。工具边界确实适合做检查，底层服务也可以继续执行资源授权。两处检查可以共同承担防护。

能拿来做什么

• 在 Node Agent 服务里统一包装工具执行入口，先取得调用者身份，再检查工具参数对应的资源权限，授权通过后才调用底层 API。
• 给 AI 编程助手开放文件读取能力时，先限定允许访问的项目路径，再按当前用户校验目标文件，避免把服务进程的文件权限直接交给模型使用。
• 为发送邮件这类工具同时约束凭据和目标收件人，并记录调用者、参数、授权决定与执行结果；涉及敏感内容时，对日志做必要脱敏。
• 定期查看被拒绝的工具调用，检查它们来自正常需求、参数错误还是注入尝试，再据此调整策略，避免为了消除报错直接扩大权限。