Agent 工具调用鉴权应放在模型之外

给 AI Agent 一枚权限很大的 API token，再在提示词里写上「不要泄露数据」，权限边界就算建好了吗？原文的回答是否定的：模型会读取不可信文本，不能同时负责判断这些文本是否应该改变自己的权限。

作者主张把访问控制放到 Agent runtime 与工具之间：先确认身份、核对任务范围和具体动作，再决定是否放行。这篇值得读的地方，是把提示词约束、工具权限和审计记录各自该承担的责任讲清楚了。

为什么提示词不能替工具守住权限

原文设想了一个 Agent：它持有长期有效、范围很广的 API token，可以访问工单、代码仓库和内部搜索工具。攻击者在用户提交的内容里夹入指令，让它把内部搜索结果搬进工单。模型一旦照做，现有凭证就足以完成操作。

这里的问题不只是模型有没有识别出恶意文本，而是整个调用链允许它动用这些权限。

作者把这种失败称为「混淆代理」（confused deputy）：Agent 拥有合法权限，攻击者通过输入提供操作意图，借它的身份办事。工具看到的是有效凭证，却不知道这次操作是否符合任务要求。

模型可以提出工具调用，但是否允许执行，应由模型之外的控制层决定。

提示词仍然可以指导行为，但只存在于提示词里的安全要求，仍要依赖那个正在被外部文本影响的模型来遵守。

一次工具调用，应该经过哪些检查

作者给出的顺序是：识别 Agent 身份，解析当前任务范围，检查具体动作，签发短期凭证，记录决策。检查必须发生在工具执行之前。

首先，每个 Agent 应有独立身份，不能都挂在同一个共享服务账号下。否则即使记录了操作，也很难分清是谁在什么授权范围内发起的。

其次，要区分 Agent 的总权限与当前任务权限。Agent 平时可以使用多个工具，不代表处理眼前这项任务时都应该能用。当前任务声明的范围，应比总权限更窄。

接下来，策略针对具体动作判断是否放行，通过后才签发仅限这一次动作的短期凭证。找不到匹配规则时，默认拒绝。工具权限也应逐个建模，避免把所有工具打包成一份宽泛授权。

最后，每次允许或拒绝，都要关联 Agent 身份、请求动作和结果。这样的监控才能回答「实际执行了什么策略」，而不只是保存模型声称自己要做什么的对话记录。

原文没有说明任务范围由谁批准、策略如何表达，以及目标工具如何接受单次动作凭证。这些都需要在落地时补齐。

RESK 承担的是执行入口和决策记录

原文用 RESK 说明这套职责如何拆分。

按作者描述，reskSecure 位于工具前方，负责 Agent 身份与工具调用的权限执行，在动作发生前检查策略，并按调用签发受限凭证，避免给 Agent 一枚长期持有的通用 token。

ReskPoints 则提供决策与事件记录，把每次允许、拒绝与 Agent 身份、请求动作关联起来。

作者建议的起点很直接：先盘点 Agent 能访问哪些工具，再声明每个工具的权限范围，最后把检查移到调用前面。重点是改变权限执行的位置，而不只是增加日志。

我的判断

我认同这条边界：工具执行权限不该只靠提示词维持。它把「模型想做什么」与「系统允许做什么」分开，也让审计有了可核对的对象。

但这篇属于架构建议和产品方案说明，没有提供攻击测试结果、对照数据或性能开销。文中的攻击链是示例，不能当成作者已经复现的实验；RESK 的效果也不能仅凭这些描述确认。

还有一个关键前提：所有工具访问都必须经过检查入口。如果 Agent 仍能拿到旧的宽权限 token，或绕过入口直接请求工具，这层控制就无法覆盖实际操作。

默认拒绝也不能自动解决数据流转问题。假如「读取内部搜索」和「创建工单」分别合法，仍需明确哪些搜索内容可以写入哪些工单。原文没有展开这种跨工具的数据约束。

对已有权限中间件的 Node 服务，可以先评估能否扩展现有入口来承接这些检查。采用 RESK 还是自行实现，需要看工具接入和策略需求，原文没有给出足够的比较依据。

能拿来做什么

• 给日常 AI 编程助手盘点工具权限，列出代码仓库、搜索、工单各自能执行的动作，先找出共享账号和长期宽权限 token。
• 在 Node 的工具调用入口检查 Agent 身份、当前任务范围与具体动作，让未匹配规则的请求直接被拒绝。
• 为允许和拒绝记录统一字段，至少包含 Agent 身份、请求动作与结果，让排查能落到具体调用。
• 检查跨工具的数据搬运场景，尤其是内部搜索结果写入工单这类操作，明确单项权限通过之后还需要哪些限制。