智能体最小权限：把身份与授权分开设计

Agent 能证明「自己是谁」，不代表它有权替某个人修改某张表。原文讨论的正是这个缺口：当工具连接多个租户、任务交给子代理执行时，身份认证之外，还需要一条能验证、能撤销、能追责的授权链。

作者给出的结论是：每次操作都应对应具体授权，并由模型控制范围之外的执行层检查。它适合用来审查 AI 编程工具和自动化工作流，但目前提供的是工程框架与合成示例，没有生产效果数据。

登录成功，为什么还不能执行操作

身份认证回答「谁在调用」，授权回答「谁允许它对哪个资源做什么」。一个带签名的工作负载身份，可以证明请求来自某个 Agent，却不能证明业务负责人允许它写入某个租户的数据。

作者建议把授权表示为动作元组，也就是一份描述具体操作权限的结构化记录。Ariftly Agent Authority Matrix 列出十二个维度：委托主体、已认证的 Agent、任务、目标租户或对象、操作、获准使用的工具、上下文条件、有效期、父级委托引用、审批约束、撤销状态、审计关联。

例如，「协助完成验证」只是任务描述；允许哪个 Agent、通过哪个工具、在多长时间内读取哪些对象，才接近可执行的授权。

这十二维矩阵是概念模型，不是标准传输协议，也不是 NIST 标准。字段可以分别落在 token 声明、授权服务器、策略引擎、工作流元数据和证据存储中，不必全部塞进 token。

协议层面，作者建议从已有积木开始：

• SPIFFE 提供可加密验证的工作负载身份。
• RFC 8693 定义 OAuth token exchange，包含委托和身份模拟语义；RFC 9396 支持更丰富的授权细节。
• RFC 9068 描述 JWT access-token profile；RFC 9449 通过 DPoP 支持发送方约束 token；RFC 9700 提供更新后的 OAuth 安全实践。

这些协议各管一部分，拼起来仍需要部署方验证签发者与受众、落实资源服务器检查、轮换密钥，并处理当前撤销状态。Agent 相关的 Internet-Drafts 还要检查状态和日期，不能当成成熟 RFC。

子代理可以接任务，不能顺手继承全部权限

多代理工作流容易把任务拆分和权限转交混在一起。主 Agent 请验证 Agent 帮忙，并不等于后者可以继承操作者的完整身份。

作者提出建立父子授权图：子授权必须落在父授权的策略范围内，同时保存父授权 ID，以及可重复计算的范围比较结果。真正需要提权时，应另外签发授权，明确责任人和到期时间。

模型判断某条命令有用，不等于它有权执行这条命令。

这要求执行层检查实际请求的操作和目标资源，结合可信属性作出决定。模型生成的参数、检索内容和工具返回文本都只是输入，不能成为修改权限的指令。确定性的权限检查必须放在模型控制之外。

人工审批也要绑定具体交易。审批记录应包含动作摘要或规范化表示、资源、约束、预期影响、到期时间和审批人身份。如果模型之后实质修改了这些参数，就不能继续复用旧审批。

审批界面还得让人看懂影响。对日常低风险步骤无差别弹窗，会消耗人的注意力；原文引用的 NIST 利益相关方综合材料也提出了同意疲劳问题。不过，作者没有给出审批频率与误操作率之间的对照数据。

权限能撤销，还得证明撤销确实生效

有效期和撤销解决的是两件事。短期凭证可以限制存活时间，却不保证已经接受的 token 或正在执行的工具调用立即停止。

因此，团队必须提前定义取消授权后的行为：新调用是否拒绝，排队动作是否拦截，下游授权是否失效或受自身到期时间约束，已经产生重要影响的部分执行如何交给负责人处理。撤销传播时间要在自己的环境中实测；如果声称某个延迟，就应交代测量方法。原文没有提供延迟成绩。

审计则要能还原某次操作的完整链路：请求 ID、身份与委托主体引用、任务、授权、策略版本、决策原因、审批引用、工具执行 ID、验证结果和异常处置。

能还原，不等于什么都存。作者明确反对为了可观测性，把任意对话、敏感记录和长期密钥一股脑倒进审计库；适合时使用哈希或受控引用，并设置访问权限和保留期限。

测试也不能只证明正常流程能跑通。原文要求覆盖身份不存在、跨越租户、操作被禁止、子代理扩大范围、授权过期、审批被修改、凭证被撤销，以及工具输出夹带恶意指令。每个案例既要检查拦截结果，也要检查证据记录。

配置看起来完整，只能证明设计覆盖度，不能证明系统安全。

作者特意澄清了两个数字：NIST 收到针对其 2026 年 2 月概念文件的 600 多份回应，这不是安全事件数量，也不是企业占比；一条虚构授权记录有十二项中的九项通过设计核验，得到的 75% 只是完整度。安全效果百分比还需要明确统计总体、威胁模型、可重复测试、环境和分母。

我的判断

这套框架最有价值的地方，是把「Agent 能自主做多少事」和「某次动作拥有什么权限」分开。自动执行几步经过验证的操作，不必附带更宽权限；更高自主程度也不能靠一个角色名获得无限授权，异常仍需要责任人处理。

但文章没有证明十二维矩阵优于其他实现。它没有提供生产部署数据、性能开销或维护成本，也没有与 RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）做对照。我的看法是，可以用它补查任务、委托、审批和撤销环节，未必需要替换已有权限系统。

原文的 Oracle-to-Snowflake 场景同样只是设计示例：评估 Agent 读取合成 SQL，专门的验证 Agent 执行只读检查，不能据此推导出生产写入权限。Ariftly 的 Forge experience 仍在开发中，这不是已交付功能或客户成果。

小团队可以先拿一次有实际影响的操作做审查：能否指出准确授权、执行时的决策和验证后的结果？这比先搭一套庞大治理平台更容易检验价值。

能拿来做什么

• 给现有 Agent 工具入口补一次权限梳理，至少明确调用主体、目标租户或对象、操作和有效期，并在服务端执行检查。
• 在前端审批界面展示具体动作、目标资源和预期影响，让后端把审批绑定到该动作；关键参数改变后重新判断审批是否有效。
• 为 Node 工具服务或 AI 编程工作流加入拒绝案例，优先验证跨租户请求、子代理扩大范围、过期授权和工具输出中的恶意指令，同时检查审计证据。
• 选一次撤销操作做端到端演练，观察新请求、队列任务和下游授权分别如何响应，记录传播时间与部分执行的处置结果。