Agent权限应由身份与调用链强制约束

给 Agent 的 system prompt 写上「禁止访问敏感数据」，并没有收回它手里的数据库权限。只要凭证还能读全库，一次看似合理的查询，就可能越过团队预想的边界。

这篇文章的核心主张很直接：Agent 的访问控制要放在工具执行前的请求路径上，每次调用都检查身份、动作和目标资源，并记录允许与拒绝。它没有提供实测数据，但把 AI 编程中容易混淆的两件事讲清了：模型是否听话，以及系统是否允许它行动。

为什么写进提示词的禁令不算权限控制

作者把 Agent 拆成模型、执行循环和能力集合。安全问题的关键，在于最后一项：它能调用什么工具，读取什么资源，修改什么东西。

只输出文字的模型，主要需要处理内容风险；能够查数据库、调用工具、打开 pull request 的 Agent，已经是持有凭证的系统执行者。权限系统需要把它当成一个独立主体（principal），就像对待服务账号一样。

提示词能影响模型如何选择行动，却不能决定底层凭证是否有效。模型生成了一次越界调用，如果执行层照单全收，提示词里的禁令就没有形成访问边界。

权限控制要在模型行为偏离预期时，仍然能够阻止动作执行。

原文用三个场景解释了这个差别，它们是风险示例，并非作者披露的事故记录：

• 数据库凭证可以读取所有表，Agent 为回答一个问题，查询了本不该接触的表。这里甚至不需要提示词注入，只需要权限给得过宽。
• 仓库 token 拥有写权限，Agent 为修复失败的检查推送了错误改动，或者分支保护没有达到团队预期。token 仍然是在权限范围内工作。
• Agent 读取的文档夹带指令，诱导它改变下一次工具调用。如果凭证足够宽，重定向就可能成功；如果调用超出明确授权，执行前的检查应当拒绝并留下记录。

团队期待 Agent 不去做的事，可能恰好是凭证允许它做的事。

每次工具调用前，到底要检查什么

作者提出的机制由三部分组成：独立且受限的身份、逐次调用的授权判断，以及基于这些判断建立的监控。

先给每个 Agent 独立身份，不共用服务账号，也不直接使用人的凭证。这样才能单独缩小权限、撤销访问，并在审计日志里确认动作来自哪个 Agent。独立身份还要配合最小权限：任务需要哪些工具、哪些资源，就明确授予哪些。

接着，把授权判断放在每次工具调用之前，而非只在会话开始时放行。检查时需要同时拿到 Agent 身份、请求动作、目标资源和调用参数。允许访问某个工具，并不等于允许它通过这个工具操作所有资源。

默认策略是拒绝，授权通过白名单表达。黑名单只能覆盖团队已经想到的危险动作；白名单则要求每一项可用能力都有明确依据。

这里还有一个执行顺序问题：检查必须发生在工具执行前。先写入数据库、再判断是否越权，得到的只是损害发生后的记录，无法起到预防作用。

日志也不能只记录成功结果。作者要求记录身份、动作、资源、参数、授权决定和执行结果。拒绝记录能帮助团队看到 Agent 尝试过什么，再据此关注异常工具调用、偏离任务的参数模式，以及不符合预期的拒绝行为。

授权决定既是执行的门槛，也是后续监控的依据。

权限还需要随任务变化重新审查。部署时配置过一次，不代表 Agent 接手新任务后仍然合适。

我的判断

我认同文章对控制位置的判断。它把讨论从「怎样让模型更守规矩」，推进到了「模型不守规矩时，系统能否兜住」。对已经接入数据库、仓库写操作的 Agent，这个区分很实用。

但最小权限只能限制行动范围，不能保证范围内的行动正确。Agent 可能有权修改目标分支，却提交了错误代码；也可能有权读取某张表，却生成了不合业务预期的查询。前面的权限检查仍然需要与现有的分支保护、代码审查等机制配合。

文章也没有展开几处实现难点：资源如何精确匹配，复杂参数如何参与判断，权限规则由谁维护，监控中的「偏离任务」如何定义。它给出的是设计原则，没有提供实现代码、性能开销或对照实验，不能据此判断接入成本与实际拦截效果。

最后一部分带有明确的产品介绍：作者将 reskSecure 定位为身份与策略执行组件，将 ReskPoints 定位为活动监控组件。原文没有展示配置、接口或验证过程，因此这些属于产品能力陈述，不能当成已经验证的效果。

与数据库权限、仓库 token scope、分支保护等常见做法相比，文章的增量是要求把 Agent 身份和每次调用的授权判断串起来。普通团队是否需要额外产品，要看现有基础设施能否完成这条链路；原文没有给出必须选择 RESK 的证据。

能拿来做什么

• 给日常 AI 编程助手盘点一次实际凭证权限，尤其检查仓库 token 是否允许直接推送，以及可操作的仓库和分支是否符合任务需要。
• 在 Node 工具执行层加入统一的授权入口，让数据库查询、仓库操作等调用先经过身份、动作、资源和参数检查，再进入执行函数。
• 给 Agent 使用独立身份，并把允许与拒绝记录在同一条审计链路里，让异常调用能够追溯到具体任务和调用参数。
• 当 Agent 从只读分析扩展到修复代码、写入数据时，重新审查授权范围，明确新增能力需要开放哪些工具与资源。