Agent 权限控制应落在工具调用层
文章将 Agent 安全拆为能力授权和调用可观测性：代码应决定调用者能访问哪些工具及其范围，并记录执行结果。提示词无法代替这些控制，审计还需还原每次调用的权限上下文。
AI 深度解读
给 AI Agent 加上文件、数据库和内部 API 工具后，安全问题就从「它会说什么」变成了「它能执行什么」。原文的核心主张是：真正的权限边界在工具调用代码里，提示词不能承担授权职责。
作者给出的方案分两部分：在模型调用前确定身份与权限，在每次工具执行前重新校验，并记录成功和拒绝。这套思路值得拿来检查现有 Agent，但文中的产品介绍缺少代码和对照数据，需要与通用设计原则分开看。
为什么提示词挡不住工具越权
原文把 Agent 拆成模型、工具和循环。模型选择工具，读取结果，再决定下一步。循环让它能连续完成任务，也让一次错误选择可能继续影响后续操作。
每个工具都代表一种实际能力：读取文件、查询数据库、调用内部 API，或者发送消息。工具背后的凭据有多大权限，潜在影响范围就有多大。检索工具能访问整个索引，并不会因为提示词写了「只看当前用户的数据」就自动缩小访问范围。
作者举出的风险路径很常见：开发时为了方便给 Agent 接入一个持有服务凭据的工具，后来又让它接收不可信输入。此时，攻击者可能通过输入影响模型选择，触达原本就暴露给 Agent 的能力。
问题不在于少写了一句警告，而在于执行代码没有建立可靠限制。
提示词可以描述行为要求，授权代码必须决定操作能否执行。
这也解释了为什么「给某个 Agent 开通访问权限」太粗。读取和写入需要分别授权；允许查询，不能顺带允许修改。权限应当落到具体工具调用及其作用域上。
权限要先算清，再让模型选择工具
原文最有用的部分，是把授权顺序明确下来：
- 解析调用者身份和 Agent 身份。
- 根据这对身份计算可用工具及各自的作用域。
- 只把这组工具和权限范围提供给模型。
- 模型提出工具调用时，再检查是否符合已解析的权限。
- 校验通过才执行，并记录决定与结果。
这里的作用域（scope），可以理解为「这次调用具体能碰哪些资源」。它不能只存在于提示词描述里，执行代码必须按它限制访问。
第 3 步和第 4 步解决的是不同问题。提前过滤工具，让模型少走无效路径；执行前复核，则负责拦住不符合权限的请求。原文还指出，模型反复选择最终会被拒绝的工具，也会浪费 token、增加调用噪声。不过，文章没有给出节省比例。
作者关于「不能在工具选择后才检查」的表述，容易让人误读。结合后面的流程看，它强调的是：身份和初始权限不能等模型选完工具后才确定，而不是取消执行前检查。
模型应当在既定权限内规划，每次执行仍然需要授权校验。
这套顺序尤其适合检查那些把全部工具统一注册给模型、仅靠系统提示词区分用户权限的实现。
日志要回答每次调用发生了什么
只有对话记录，通常只能证明用户使用过 Agent。真正排查问题时，需要知道它调用了哪个工具、使用什么权限、是否被拒绝，以及最后有没有执行成功。
原文要求每次调用至少记录四项信息：工具名、解析后的作用域、授权决定、执行结果。拒绝和成功应当经过同一条记录路径，便于放到同一时间线上检查。
「没有执行记录」和「明确拒绝执行」差别很大。前者可能是模型没有尝试，也可能是日志缺失；后者才提供了权限检查生效的证据。
文章随后介绍了 RESK 的两个组件。按作者的描述，reskSecure 负责工具权限执行层，解析身份和作用域，并决定是否放行；ReskPoints 负责记录工具调用、作用域及结果，让拒绝和成功都可见。
但原文没有提供接入代码、API 签名、配置示例或测试结果。因此，这部分能说明产品的职责划分，还不足以判断它在具体项目中的接入成本和覆盖程度。
我的判断
我认同文章把控制点放在工具边界上。对已经具备服务端开发经验的程序员来说，这与普通接口授权有相通之处：调用请求可以来自模型，但授权决定仍应由可信代码作出。
相比只写提示词，逐工具授权更容易检查，也更容易留下审计证据。不过，过滤工具列表并不等于完整授权。即便某个数据库工具允许调用，也仍要判断这次操作是否处于允许的资源范围内。原文强调了作用域，却没有展开参数如何参与检查、底层凭据如何收窄，这些都需要落地时补齐。
监控部分也有边界。记录授权决定，不能自动证明工具执行符合预期；记录执行结果，也不能自动解决日志自身的访问保护问题。文章没有讨论这些细节，不宜把它当成完整的安全方案。
至于 RESK，作者没有给出与自建授权层、复用现有接口权限系统的对照数据。它的效果目前只能按文中的设计说明理解，不能据此推导出性能、成本或安全性优势。这是一份边界清晰的设计建议，产品能力还需要另行验证。
能拿来做什么
- 检查 Node 服务中注册给模型的工具，把读取、写入、发送消息等能力分别列出，并确认每项能力都受调用者身份约束。
- 将身份解析和可用工具计算放到模型调用之前，再在工具执行入口复核作用域，避免权限只写在提示词里。
- 给工具调用补齐工具名、作用域、授权决定和执行结果四类记录，同时检查拒绝路径是否也会留下日志。
- 在 Agent 开放给不可信输入前，清理开发阶段的便利工具，收窄服务凭据和资源访问范围，尤其检查能直接调用内部 API 的入口。