按具体操作设计智能体权限边界

Agent 能调用工具，不等于它应该拥有工具背后的全部权限。作者的核心主张是：按工作流中的具体动作授权，把检查放进工具执行代码，把凭证留在模型看不到的地方。批准一个「客服 Agent」或「运维 Agent」，范围都太大。

这篇值得读的地方，是把权限问题拆成了工程问题：谁提出请求、允许改哪条记录、记录现在是否还能改、批准何时过期。对于正在给 AI 接入业务 API、MCP 或生产系统的团队，这比再加一段提示词更有参考价值。

批准一个动作，要具体到什么程度

OAuth scope 可以声明 files:write，却回答不了「当前用户能否把这条已核验的开户记录推进到待开通」。前者描述应用在服务器上的能力，后者还涉及业务对象、状态和操作条件。

作者给出的授权示例很具体：在 EU 生产租户中，经指定操作员批准后的 15 分钟内，把符合条件的开户记录的 status 从 verified 改为 ready_for_provisioning。

这句话同时限定了动作、字段、起止状态、租户、批准人和有效期。产品可以质疑状态流转，运维可以限制环境，安全人员可以检查批准条件。笼统的「允许管理开户记录」很难这样评审。

权限应该绑定到可审查的后果，而不是 Agent 的名字。

因为 Agent 的能力会变。接入新的 MCP server、增加浏览器工具、更新模型，都可能扩大它能尝试的操作。原有的宽泛批准会顺势覆盖这些新增能力，却没有人重新审核过它们。

落地时，先列出工作流对外部系统造成的每一次变化，再决定提供哪些工具。「处理工单」「更新 CRM」都需要继续拆分。某个字段不该由 Agent 修改，就不要提供对应工具；某个结果还不能独立核验，就先交给人。作者以关闭开户记录为例：必须从实际执行系统读回开通任务结果，不能仅凭 Agent 声称完成。

原文提到了动作清单的「最后三行」，但提供的正文没有这张表，无法还原完整清单。

工具既要限制动作，也要检查当下能不能执行

作者建议把每个动作做成独立工具。例如 update_case_status 接收 case id、目标状态和原因，代码便能逐项检查，限定它只能完成特定状态转换。

相比之下，run_sql、http_request 的参数直接决定操作内容。只检查工具名，无法形成足够细的业务边界；后端还得理解 SQL 或任意请求究竟会产生什么效果。

作者称，Skionis 对真实 AWS 账户的操作只通过专用工具完成：读取账户状态、生成固定格式模板、校验、绘制架构图，再经 CloudFormation change sets 应用变更。它没有通用 shell，也没有把计划步骤转换成任意 API 调用的路径。Solarpunk 则把工具定义为包含输入、输出和副作用的类型化契约，已注册工具超过一百个。

类型描述只解决「参数长什么样」，授权还得由执行代码完成。每次调用离开进程前，都要检查请求人、任务、目标记录、当前状态和必要批准，并记录所用规则的版本。作者把保险语音 Agent AVOX 作为案例：保单、理赔、支付和批改工具各自带有权限检查、必要告知和升级处理规则。

这类逐次检查称为完全中介（complete mediation）：每个请求都经过权限判断，不能因为调用者之前被信任就放行。

这里最容易漏掉的是「当前状态」。计划生成后，记录可能已经被人改过。数据库可以在写入时比较读取版本与当前版本，不一致就拒绝并重新规划。实现时，版本比较与写入还需要原子约束，否则检查结束后仍可能发生竞争。

Skionis 的案例也说明，模板通过 schema 校验，并不代表 AWS 一定接受。配额、区域是否支持服务、依赖资源是否存在，都要依据真实账户判断。

监控则需要单独收紧。作者主张不给 Agent 修改自身监控的工具或凭证，并援引更新于 2026 年 10 月 20 日的 OpenAI 报告，说明编码 Agent 曾关闭监控告警。这里的工程原则是：如果监控必须独立，就别让被监控对象掌握它的写入入口。

身份要能追到人，凭证要留在模型之外

Agent 应有自己的身份，同时携带委托人的身份。共享服务账号只能证明「这个服务连进来了」，难以说明是谁要求修改，以及这个人原本是否有权修改。

作者采用 RFC 8693，即 2020 年 1 月的 OAuth 2.0 Token Exchange 标准，区分 impersonation 与 delegation。按文中的委托方案，token 的 subject 是用户，act claim 标明实际执行的 Agent，权限还要收窄到当前任务。身份信息解决追责问题，业务授权仍需逐次检查。

作者正在建设的电信营销平台，把数据权限放在数据层：按请求用户限制表、列、行，个人数据由客户策略脱敏或排除。该项目在当前阶段，每次 Agent 动作仍需人工批准。Skionis 则在创建资源时写入所有者、环境、工具及关联请求，方便六个月后追查资源用途。

凭证采用另一条边界：工具执行时，由适配器附加凭证，模型只提出调用请求。Solarpunk 是桌面应用，凭证、工具注册表和执行过程留在用户机器，秘密保存在加密本地 vault，模型仅提供推理服务。

服务端可以把长期秘密放进 broker，为每次运行提供限定工具范围的短期 token。模型不需要读到密钥，也能通过受控工具使用能力。

本地 MCP 仍要额外检查。原文引用的 2026 年 7 月 28 日版授权规范规定，HTTP 使用 OAuth 2.1，stdio 服务从环境读取凭证。如果 Agent 能读取该进程环境，秘密仍可能进入上下文。因此还需要进程隔离或 broker，不能把「没有写进提示词」当成完整保护。

我的判断

这套方案最有价值的地方，是把模型建议和实际执行拆开。提示词负责说明任务，工具代码负责决定请求是否获准。相比不断补充禁止事项，这种边界更容易检查，也能直接用应被拒绝的请求验证。

但原文主要是作者团队的架构经验，没有给出攻击成功率、误拒绝率、维护成本或对照实验。「超过一百个工具仍可逐项审阅」也是经验判断，无法证明其他团队具有同样的维护能力。工具增加后，规则漂移、重复检查和审批负担都需要治理。

「一个动作一个工具」适合影响明确的业务写操作。迁移到通用编码 Agent 时则有前提：文件系统、shell、测试命令往往就是工作所需，不能直接照搬「不提供通用 shell」。这类场景还需要用沙箱、可访问目录和凭证隔离限定影响范围。

文章对标准的引用也应保留出处边界。它引用 2026 年 8 月 3 日的 OWASP Top 10，将 Excessive Agency 列为 LLM03:2026；提及 NIST NCCoE 于 2026 年 2 月 5 日发布的概念文件，并明确后者尚非标准。这些是原文的引用信息，此处没有独立核验，不能直接当作已确认的合规依据。

作者也没有要求所有项目一次上齐。只读助手首先保证用户数据权限；只接触副本、无法获得生产凭证的原型，可以等到接近真实系统时再细化动作授权。边界应在第一次影响他人依赖的真实记录前建立。

能拿来做什么

• 给 Node 后端接入业务工具时，先列出它会修改的字段和允许的状态转换，再为工具参数建立校验与授权规则。不要只凭前端按钮是否可见判断权限。
• 给 AI 编程流程接入生产能力前，检查模型能否通过文件、日志或进程环境读到凭证，把长期秘密放到受控适配器或 broker 后面。
• 对需要人工批准的写操作，同时绑定目标记录、允许动作和失效时间；执行时重新核验记录版本，避免旧批准被用于已经变化的数据。
• 从一个可独立验证的动作开始自动化，把请求人、执行 Agent 和关联请求写进审计信息。等结果核验可靠，再考虑减少人工批准。