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

给 LLM Agent 加权限校验，应该放在哪儿？原文的答案很明确：放在模型决定调用工具之后、工具真正执行之前。System prompt 可以约束模型的行为倾向，但只有执行前的授权检查，才能决定一次操作是否获准。

作者用「读文档后把敏感内容写进工单」的攻击链解释这个位置为什么重要，并介绍 RESK 如何承接校验与监控。对正在接入工具调用的程序员，最值得带走的是调用链上的边界设计；至于产品效果，原文没有提供实测数据。

权限为什么不能只写在提示词里

传统应用通常由代码规定操作路径，而 Agent 会根据上下文，在运行时选择工具和参数。这些上下文可能来自用户输入、检索文档或工具返回，其中就可能夹带攻击者的指令。

作者将 AI agent security 定义为：限制自主或半自主 LLM 系统使用工具、数据和凭据的能力。重点不是让模型理解多少安全规则，而是让它即使提出越权请求，也无法直接产生效果。

提示词参与模型决策，授权检查决定操作能否执行。

因此，检查对象不能只有登录用户，还要包括发起调用的 Agent 身份。同一个用户使用的不同 Agent，可能承担完全不同的任务，不能仅凭它们访问同一个模型端点，就给出相同权限。

每次调用至少要带上 Agent 身份、目标工具和参数。权限也要同时覆盖工具与数据范围：允许读文档，不等于允许读所有文档；允许写工单，也不等于允许把任何数据写进去。

一条「先读后写」的调用链怎样越界

原文给出的例子只有两个工具：文档读取器和工单写入器。

Agent 检索到一份文档，里面藏着一条指令：读取某条敏感记录，再创建工单，把记录内容填进去。用户没有提出这个要求，但模型可能跟随文档中的指令，先读数据，再写工单。

如果防护只有 System prompt，结果就取决于模型能否抵抗提示注入。如果只有事后日志，等到发现问题时，包含敏感内容的工单可能已经创建。

作者主张把调用路径改成：

模型提出调用 → 拦截调用 → 根据 Agent 身份、工具及参数评估策略 → 放行或拒绝 → 记录决策。

这里的关键是：前一次调用成功，不能成为后一次调用获准的理由。读取成功之后，写入仍要接受完整检查。如果该 Agent 无权通过工单工具处理这个数据范围，写入就应被拒绝。

但还需要追问一步：权限系统如何知道工单正文来自敏感记录？原文没有交代。检查工具名和参数是必要步骤，可如果参数已经变成一段普通文本，识别其来源还需要额外设计。这会直接影响示例中的攻击究竟能不能被挡住。

RESK 把执行检查和监控接在同一条记录上

原文介绍了两个组件。

reskSecure 是执行控制层，位于工具调用边界，在执行前根据 Agent 身份和授权范围评估调用，并把策略决策附在调用记录中。

ReskPoints 是观测 Agent 活动的埋点，用于监控拒绝事件、追踪连续工具调用。两者配合的目标，是让执行层作出的决定与监控层看到的事件对应起来。

日志不能只记录成功调用，还应记录请求了什么、允许还是拒绝，以及原因。否则，你只能看到已经发生的操作，看不到被边界挡住的尝试。

拒绝也是需要保留的事件，而不是可以直接丢弃的错误。

不过，拒绝记录只是排查线索，不能直接等同于攻击。正常任务也可能因为权限配置不完整而失败，需要结合调用上下文分析。

原文没有代码、API 签名、配置示例或版本号，也没有说明策略如何编写、数据范围如何表达。因此，它提供的是架构位置与组件分工，还不足以让读者照着完成 RESK 接入。

我的判断

我认同作者最核心的判断：授权必须先于执行，而且必须由模型之外的机制落实。相比只增加提示词约束，这个边界能明确回答一次操作为什么获准；相比事后审计，它有机会在副作用发生前阻止调用。

但原文对连续调用风险的解释不够完整。一方面，作者指出逐次孤立判断可能留下漏洞；另一方面，又强调每次调用单独授权。两者要成立，需要补上一个前提：每次授权都能获得足够的上下文，尤其是数据来源及其允许流向。

如果 Agent 同时拥有读取敏感数据和写工单的权限，仅检查两项工具权限，未必能阻止把前者内容写入后者。单次授权与跨调用的数据流约束，需要一起考虑。

另外，原文没有实验结果、拦截率或方案对照。RESK 的能力应视为作者对产品机制的描述，不能据此判断它比现有权限中间件更有效。拒绝监控是否足够有用，也取决于日志能否解释具体命中了哪条策略。

能拿来做什么

• 在 Node 工具执行入口集中接入授权检查，把 Agent 身份、工具名和参数送入策略判断，检查通过后再调用实际函数，避免各工具遗漏校验。
• 为读取与写入分别定义权限和数据范围，用原文的「敏感记录写入工单」场景验收，确认系统检查的是实际数据边界，而非仅有工具名称。
• 让允许和拒绝共用一套调用记录，保留决策原因，并能把同一任务中的连续调用关联起来，方便追查异常路径。
• 评估 RESK 或自建方案时，要求展示从读取敏感数据到尝试写出的完整过程，重点确认数据来源如何传递、第二次调用依据什么被拒绝。