企业安全走过的二十多年本质上是在反复回答几个看起来非常基础的问题你是谁你能登录哪个系统你属于什么角色你可以访问哪些资源又能够执行哪些操作。从账号密码、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 真正重要的地方并不在于它创造了一个新的安全名词而在于它让我们第一次更清楚地看见——权限的终点从来不应该只是可以做什么而应该一直延伸到这一次事情究竟能不能发生。