Agent 权限控制应细化到每次工具调用

API key 有效，不代表 Agent 发起的每一次工具调用都该被允许。一个负责总结文档的 Agent，如果被文档里的指令诱导去访问内网地址，模型接口的鉴权仍然会通过，危险动作也可能照常执行。

作者给出的方案是：在 Agent 决定调用工具之后、工具真正执行之前，检查身份、工具和参数，并记录允许或拒绝的决定。对正在接入工具调用的程序员，这篇文章的价值是讲清了权限应该放在哪里；但它没有代码和对照实验，距离可直接落地的实现指南还有一段距离。

为什么 API key 管不住工具调用

API key 解决的是模型接口的访问资格。Agent 则是一个循环：读取输入、决定动作、调用工具、读取结果，再决定下一步。拿到进入循环的凭证，并不等于循环中的每个动作都合理。

作者归纳了三个问题。

首先是提示注入（Prompt Injection）。Agent 读到的文档、网页或工具返回值中可能夹带指令，诱导它调用当前任务不该使用的工具。此时凭证没有失效，工具调用却已经偏离任务。

其次是授权过宽。某个工作流需要一项工具，团队就把工具交给 Agent 长期持有，其他工作流也能使用。一次错误决定能够影响的范围，便扩展到它持有的全部工具。

最后是记录缺失。只知道工具执行成功，却不知道哪个 Agent、带着什么参数、依据哪次授权发起调用，出事后就难以还原过程。

凭证鉴权只能证明调用者有资格接入，不能证明当前动作应该执行。

权限检查要卡在工具执行之前

作者提出的调用顺序很明确：

1. Agent 提出工具调用及参数。
2. 策略检查根据 Agent 身份、工具和参数，匹配明确授权。
3. 没有匹配授权，就拒绝执行并记录拒绝。
4. 匹配授权后，记录允许决定，再执行工具。

这里的默认拒绝（deny by default）很关键。没有规则覆盖的调用不会自动放行，团队需要按 Agent 和当前任务补充授权。

这也是动作级最小权限：不只判断 Agent 能不能使用某个工具，还要判断它这次带入的参数是否在授权范围内。同一个获取 URL 的工具，访问公开资料和访问内部地址，应当得到不同的检查结果。

原文的例子就是一个文档总结 Agent。文档要求它抓取内部地址，如果获取 URL 的工具有网络访问能力，又没有中间检查，这次请求就可能成功。加入动作级检查后，内部地址超出当前任务的授权范围，请求会被拒绝，同时留下 Agent 身份、工具和目标地址。

拒绝结果还要返回给 Agent，让它能够停止或调整后续步骤。只在后台拦住请求，却不给调用方明确反馈，会让恢复流程缺少依据。

RESK 提供了哪些部件，文章又省略了什么

作者把实现分成两个部件：

• reskSecure 负责执行前的权限检查，按 Agent 和工具定义明确授权，没有匹配授权就默认拒绝。
• ReskPoints 负责记录决策，每条记录包含 Agent 身份、工具、参数，以及允许或拒绝的结果。

推荐接入顺序也很直接：先定义各 Agent、各任务的授权，让工具调用经过 reskSecure，再把决定交给 ReskPoints。随着工作流变化，持续复查授权。

不过，原文没有给出版本号、安装命令、API 签名或代码，也没有展示授权规则如何表达、如何与现有工具运行时对接。它说明了组件职责，尚不足以让读者照着完成集成。

还要区分决策记录和执行结果。执行前留下「允许」记录，只能证明策略放行过这次调用，不能证明工具后来执行成功。原文没有展开两类记录如何关联，也没说明日志写入失败时是否继续执行。

我的判断

我认可把权限检查放在执行路径上。提示词可以约束模型行为，事后日志可以帮助排查问题，但前者不能替代实际拦截，后者也无法撤回已经发生的动作。动作级检查补上的是这个时间窗口。

不过，方案成立有两个前提：所有相关工具调用都必须经过检查；授权规则必须足够准确。若只检查工具名，允许「获取 URL」仍可能放过危险地址。身份和任务范围由谁提供、如何避免 Agent 自己扩大授权，文章也没说清。

原文没有提供攻击拦截率、性能开销或与其他方案的对照数据，因此，对 RESK 的效果只能视为作者的方案主张，不能当作经过验证的结论。

对已有工具网关或统一调用层的团队，先在现有入口加入策略检查和决策记录，也符合文章提出的机制。是否引入 RESK，还需要实际接口、集成成本和运行表现来支持判断。

能拿来做什么

• 如果你的 Node Agent 已有统一工具调用入口，可以先在那里检查 Agent 身份、工具名和参数，让未匹配授权的请求直接返回明确拒绝。
• 给网页抓取或文档总结 Agent 授权时，应限定当前任务允许访问的地址范围，并用文档中夹带内网访问指令的场景验证拦截是否发生在请求发出之前。
• 检查现有日志能否还原允许和拒绝的决定，至少保留身份、工具、参数和判定结果，同时确认敏感参数该如何处理。
• 每次增加工作流或工具时，都复查原有授权，避免某个任务临时需要的能力变成所有任务长期持有的权限。