一、一个被默认了三十年的前提正在失效
企业安全走了二十多年，本质上在反复回答几个基础问题：你是谁？你能登录哪个系统？你属于什么角色？你能访问哪些资源？你能执行哪些操作？
从账号密码、SSO到IAM、PAM，再到RBAC、ABAC，安全架构越来越复杂，但底层逻辑从未变过：
先确认身份，再赋予权限。人负责最终操作。
这个模型在"人操作"时代极其有效。系统告诉财务人员"你有付款权限"，至于付给谁、金额对不对、今天该不该付，由屏幕前的人结合业务判断。权限系统划边界，人理解现实。分工清晰，代价低。
AI Agent正在撕裂这个结构。
当一个Agent不再只是生成建议，而是能读取数据库、调用API、发送邮件、修改云资源、操作支付系统、甚至把任务委托给另一个Agent时，一个被长期隐藏在人类判断背后的问题浮出水面：
即使身份是真的，权限也是真的，这一次具体动作就一定应该发生吗？
二、三个概念，三种控制对象
传统安全体系的核心链条是 Identity → Authentication → Authorization。Agent时代，这条链被迫向执行端延伸，出现了一个新的独立环节：
| 概念 | 回答的问题 | 控制对象 |
|---|---|---|
| Identity / Authentication | "你是谁？" | 主体 |
| Authorization | "你被允许访问什么、能做什么？" | 主体的能力 |
| Authority（新） | "此时此刻，这个具体动作是否被授权发生？" | 事件/行动 |
前两句约束的是主体，最后一句约束的是事件。这不是措辞变化，是控制对象发生了质变。
用一个场景说明：
一个财务Agent拥有合法身份，拥有payment.write权限。用户交给它的任务只是"支付供应商A的3万美元发票"。它调用支付接口这件事，并不能自动证明任何一笔支付都属于这次授权范围。
身份是真的，Token是真的，API权限也是真的——最后落地的那个动作仍然可能是错的。
合法的主体，可以产生不合法的执行。
三、权限与执行之间的距离被消灭了
理解Authority为什么必须被单独提出，需要看清Agent真正改变了什么。它没有推翻权限模型，改变的是权限与现实结果之间的距离。
传统软件时代，一项权限和一次真实变化之间隔着大量人工步骤：
- 财务人员登录后要选收款人、填金额、核对、点确认
- 工程师有服务器权限后还要自己敲命令
人的判断天然存在于Authorization与Execution之间。那段看似低效的距离，实际上是整个体系最后的缓冲。
Agent的价值恰恰在于消灭这段距离。用户说"把这批供应商账款处理掉"，Agent就读取数据、判断对象、生成支付请求、调用执行接口。自动化越高，Permission与Execution之间越短，缓冲越薄。
输出一段错误文字可以重新生成，一次真实执行却可能已经修改数据库、转出资金、停止服务。前者的成本是重来一次，后者的成本是现实本身。
这就是为什么单纯把IAM做得更细粒度仍然不够。因为需要回答的已经不只是"这个Agent有没有调用支付API的权限"，而是：它为什么调用、调用的对象是谁、金额是否属于原始任务、条件是否已变、任务是否仍有效，以及——在这一刻，执行是否仍然应该发生。
四、行业信号：安全控制点正在从Access向Action移动
2026年，多个独立方向不约而同落在同一个位置：
| 时间 | 来源 | 方案 | 核心思路 |
|---|---|---|---|
| 7月 | Nuggets（英国） | Authority Control Plane | 位于Agent与工具/应用/企业系统之间；结合身份+委托authority+策略+intent+上下文，决定动作"允许/拒绝/转人工" |
| 7月底 | Delinea | 运行时授权（Runtime Authorization） | Agent进入合法Session ≠ 后续所有操作自动继承"允许"；策略判断推进到具体动作执行之前 |
| 同期 | 独立草案 | Mission-Bound Authorization | OAuth给Agent很多独立Token，缺少一个持久对象把能力绑定回"用户原始授权的那一项任务" |
| 同期 | 行业 | Action Governance / Authority Layer | 安全控制点从"能不能进入"移到"能不能执行" |
它们彼此不同，远未形成统一标准，但共同指向一件事：安全系统的控制对象，正在从主体拥有的权限，逐渐移动到主体准备实施的具体行动。
五、核心任务：企业安全在Agent时代必须回答什么
Agent时代的企业安全，不再是"防入侵"，而是"约束不可预测性"。核心任务可以归结为五个问题：
1. 谁授权了这一次行动？
不是"谁拥有权限"，而是"谁在这一次具体行动中行使了授权"。授权必须可追溯、可定位、可撤销——不能依附于某个人的判断力，必须沉淀为结构。
2. 这项授权因为什么而存在？
授权必须绑定到具体任务、具体对象、具体状态。"有支付权限"不是授权，"被授权支付供应商A的3万美元"才是。
3. 它现在是否仍然有效？
上下文会变化：业务条件变了、审批过期了、数据状态不同了。授权不是一次性授予，而是一个持续有效的判断窗口。
4. 谁可以把它撤销？
权限可以授予，也可以收回。Agent时代的授权必须具备实时可撤销性——不是定期轮换，而是在上下文变化时立即失效。
5. 系统能否在最后那一刻说"不"？
这是最核心的一条。成熟体系的标志不是授权做得多精细，而是在现实真正改变之前保留拒绝的能力。一次执行之前，系统必须有权拒绝，也必须有人为这次拒绝或放行负责。
六、安全治理的范式转变
Agent时代，安全面对的风险性质变了：
| 旧范式 | 新范式 |
|---|---|
| 防止未经授权的人做事 | 防止被授权的系统把事情做错 |
| 权限的不确定性 | 行为的不确定性 |
| 信任一个可靠的人 | 信任一套可靠的结构 |
| 确定性：相同输入得到相同输出 | 非确定性：相同目标得到不同路径、不同执行 |
传统安全有一个隐含前提：只要把"程序被允许做什么"定义清楚，就能大致知道"程序会做什么"。AI改变的不是权限体系本身，而是这个前提——大模型不是确定性程序，你可以规定它有哪些工具，却无法精确预测它每次如何组合这些工具。
这意味着安全第一次面对的不是"权限的不确定性"，而是**"行为的不确定性"**。
七、Authority不是新名词，是旧问题的显性化
Authority是否最终成为行业标准术语，现在还很难下结论。但它的出现意味着一件事被不可逆地看见了：
权限的终点，从来不应该只是"可以做什么"，而应该一直延伸到"这一次，事情究竟能不能发生"。
过去，这个判断由可信的人在执行前一秒默默完成。当人退出执行链，答案不能继续依附于个人判断力，必须沉淀为可定义、可委托、可审计、可撤销的结构。
Runtime Authorization、Mission-Bound Authorization、Action Governance、Authority Control Plane在短时间内接连出现，本身已经说明了一个方向：
Agent安全真正成熟的标志，不是我们能多准确地证明Agent是谁，也不是它拥有哪些权限，而是能在现实真正改变之前回答：这一次行动，到底凭什么发生。
八、一句话总结
企业安全过去花了几十年回答"谁可以进入系统、谁拥有权限"。当AI开始自主行动之后，一个更贴近现实的问题成为独立问题：
谁最终能够让动作发生。
