Havenlon | 杂谈：AI Agent 安全正在出现一个新的词：Authority

企业安全走过的二十多年，本质上是在反复回答几个看起来非常基础的问题：你是谁，你能登录哪个系统，你属于什么角色，你可以访问哪些资源，又能够执行哪些操作。从账号密码、SSO 到 IAM、PAM，再到 RBAC、ABAC 与各种细粒度授权体系，安全架构不断变得复杂，但支撑它们的逻辑始终相对稳定：先确认一个主体的身份，再决定这个主体拥有怎样的权限。

在人主要负责最终操作的年代，这套逻辑非常有效。系统只需要告诉一位财务人员"你拥有付款权限"，至于具体付给谁、为什么付、金额是否合理、今天是否应该执行，往往由屏幕前的人结合业务流程完成最后的判断。权限系统负责划定能力的边界，人负责理解现实的具体形状。分工清晰，代价也不高。

AI Agent 正在改变这个结构。当一个 Agent 不再只是生成建议，而是可以读取数据库、调用 API、发送邮件、修改云资源、操作支付系统，甚至把任务继续委托给另一个 Agent 时，一个长期隐藏在人类判断背后的问题开始浮出水面：即使身份是真的，权限也是真的，这一次具体动作就一定应该发生吗？

正是这个问题，让一个过去经常被混在 Authorization 里的词，开始越来越明确地被单独拿出来——Authority。

一、身份可以证明"是谁"，却不能证明"这次动作应该发生"

2026 年 7 月，英国身份与信任技术公司 Nuggets 发布了一个名字颇有意味的产品：Authority Control Plane。它并不试图替代现有的身份体系。按照 Nuggets 自己的定义，IAM、PAM 和云基础设施继续负责身份与访问，而这一层位于 Agent 与工具、应用和企业系统之间；当 Agent 准备执行一个动作时，系统结合身份、被委托的 authority、组织策略、声明的 intent 与实时上下文，再决定这一次动作是允许、拒绝，还是转交人工处理。

真正值得关注的并不是这家公司，也不是这个产品，而是它选择了 Authority 这个词。

传统 Identity Security 最擅长回答的问题是"你是谁"；在此之上，Authorization 回答的是"你被允许访问什么、能够做什么"；而 Agent 把问题继续往后推了一步——此时此刻，这个具体动作是否被授权发生。三句话听起来非常接近，控制对象其实已经不同：前两句约束的是主体，最后一句约束的是事件。

一个财务 Agent 可以拥有合法身份，也可以拥有 payment.write 权限，但如果用户真正交给它的任务只是"支付供应商 A 的 3 万美元发票"，那么它能够调用支付接口这件事，并不能自动证明任何一笔支付都属于这次授权的范围。身份是真的，Token 是真的，API 权限也是真的，最后落地的那个动作仍然可能是错的。

合法的主体，可以产生不合法的执行。

这正是 Agent 时代传统安全模型开始暴露出来的空隙：每一道检查都通过了，结果依然可能不该发生。

二、Authorization 管的是能力，Authority 开始接近一次具体行动

这个区别在人类社会里其实并不陌生。公司可以授权一名财务人员付款，但不会因此认为他对账户里的每一笔资金都拥有自由处置权；医院允许医生进行手术，也不意味着任何病人、任何时间、任何术式都自然落入他的执行范围。现实世界中的权力从来同时依赖身份、职责、对象、目的、时间、状态与程序，只是进入数字系统之后，我们习惯把这些复杂关系压缩成 Role、Permission 和 Token。

过去这种压缩问题不大，是因为人在最后一步会把被压缩掉的上下文重新补回来。Agent 出现之后，那个负责补上下文的人开始退出执行链。系统于是不得不重新面对一个此前被软件权限模型部分隐藏的问题：Permission 描述一个主体原则上具有什么能力，而 Authority 更接近于这些能力在某个具体任务、对象和状态下，是否仍然有资格被兑现。

这一年里，几个来自不同方向的尝试恰好都落在同一个位置上。7 月底，Delinea 发布面向 AI Agent 的运行时授权能力时使用的正是类似思路：Agent 完成认证、进入一个合法 Session，并不意味着这个 Session 中后续的数据库查询、SSH 命令、Kubernetes 操作与工具调用都应该自动继承最初那一次"允许"，策略判断因此被继续推进到具体动作执行之前。而独立提出的 Mission-Bound Authorization 系列 Internet-Draft 则从另一端提出类似的疑问：OAuth 可以给 Agent 发出很多相互独立的 Token，却缺少一个持久的、经过用户批准的对象，把这些能力重新绑定回"用户原本到底授权了哪一项任务"，其核心担忧之一，正是一个概率模型握着过大的服务账号，对真实资源产生超出原始任务范围的影响。

这些方案彼此并不相同，也远没有形成统一标准，但它们共同指向了同一件事。

安全控制点正在从 Access 向 Action 移动。

三、Agent 改变的不是权限体系，而是权限与现实之间的距离

要理解这种移动为什么会发生，需要看清楚 Agent 真正改变了什么。它并没有推翻权限模型本身，改变的是权限与现实结果之间的距离。

传统软件时代，一项权限和一次真实变化之间通常还隔着很多东西。财务人员登录系统之后，要选择收款人、填写金额、核对信息，再点击确认；工程师拥有服务器权限之后，也仍然需要自己敲下具体命令。人的判断天然地存在于 Authorization 与 Execution 之间，那段看似低效的距离，实际上一直是整个体系最后的缓冲。

Agent 的价值恰恰在于消灭这段人工距离。用户只需要说"把这批供应商账款处理掉"，Agent 就可以读取数据、判断对象、生成支付请求并调用执行接口。自动化程度越高，Permission 与 Execution 之间的距离就越短，缓冲也就越薄。

这也是为什么单纯把传统 IAM 做得更加细粒度，可能仍然无法完整解决问题。因为需要回答的已经不只是这个 Agent 有没有调用支付 API 的权限，而是它为什么调用、调用的是哪一个对象、金额是否属于原始任务的一部分、相关条件有没有发生变化、这项任务是否仍然有效，以及最关键的一点：在这一刻，执行是否仍然应该发生。这些问题原本都由人在点击确认之前，用一瞬间的常识完成。

当它们开始进入安全架构，我们治理的对象也随之改变：不再只是一个主体拥有的权限集合，而是一次具体现实变化的执行资格。这大概正是 Authority 开始被单独提出的原因。

四、真正重要的变化，是安全第一次开始追问"谁能让事情发生"

从 Identity 到 Authentication，再到 Authorization，过去的安全体系主要围绕访问建立边界；而 Agent 正在迫使这个体系继续向执行端延伸，粗略地看，是一条从 Identity 到 Authentication、Authorization，再到 Authority 与 Execution 的链条。

这并不意味着未来一定会出现一个公认的"Authority Layer"标准，更不意味着 IAM 会被取代。事实上，Nuggets 明确把自己的体系定义为现有 IAM、PAM 与云基础设施的补充而非替代；Mission-Bound Authorization 目前也只是独立提出的 Internet-Draft，而不是已经形成共识的行业标准。真正值得注意的，是行业所面对的问题本身正在变化。

过去企业最担心的是一个没有权限的人进入系统；后来变成一个拥有过多权限的人访问了不该访问的数据；而 Agent 时代又增加了一种更复杂的情况——一个身份合法、权限合法、任务也合法的自主主体，在执行过程中做出了一次不应该发生的动作。到了这一层，"谁拥有权限"已经不足以描述全部风险。

于是必须继续追问的问题变成了：谁授权了这一次行动，这项授权因为什么而存在，它现在是否仍然有效，如果上下文发生变化，谁可以把它撤销。这些问题指向的其实是同一个更根本的追问：

谁拥有让这一次现实变化真正发生的权力？

值得注意的是，这些问题过去并非无人回答，而是由一个可信的人在执行的前一秒默默回答完毕。当那个人退出执行链，答案就不能再依附于某个人的判断力，而必须沉淀为可以被定义、被委托、被审计、也被撤销的结构。安全治理由此从"信任一个可靠的人"，转向"信任一套可靠的结构"。

五、Authority 可能成为 AI Agent 进入生产环境的一条新分界线

今天大量 Agent 仍然停留在读取信息、生成内容与辅助决策的阶段，因此身份、Token、最小权限和人工审批往往已经足够。这也是许多企业至今没有强烈痛感的原因：Agent 还没有真正握住方向盘。

但随着 Agent 开始进入财务、运维、供应链、云基础设施甚至物理设备，系统面对的风险性质会发生变化。输出一段错误文字可以重新生成，一次真实执行却可能已经修改数据库、转出资金、停止服务或者改变设备状态。前者的成本是重来一次，后者的成本是现实本身。也正因如此，一个成熟体系最关键的能力，未必是把授权做得多么精细，而是在最后那一刻仍然保留说"不"的能力——一次执行之前，系统必须有权拒绝，也必须有人能够为这次拒绝或放行负责。

这也是为什么未来 Agent 安全真正成熟的标志，可能不只是我们能够越来越准确地证明这个 Agent 是谁，也不只是它拥有哪些权限，而是能够在现实真正改变之前回答：这一次行动到底凭什么发生。

Authority 是否最终成为行业里的标准术语，现在还很难下结论。但 Runtime Authorization、Mission-Bound Authorization、Action Governance 以及 Authority Control Plane 在短时间内接连出现，本身已经说明了一种值得关注的方向：安全系统的控制对象，正在从主体拥有的权限，逐渐移动到主体准备实施的具体行动。

过去我们花了几十年回答谁可以进入系统、谁拥有权限。而当 AI 开始自主行动之后，一个更贴近现实的问题正在成为独立问题：谁最终能够让动作发生。

也许 Authority 真正重要的地方，并不在于它创造了一个新的安全名词，而在于它让我们第一次更清楚地看见——

权限的终点，从来不应该只是"可以做什么"，而应该一直延伸到"这一次，事情究竟能不能发生"。