AI Agent 安全新关键词：Authority 将授权判断从“能力”推进到“具体动作”
2026/08/23 10:20阅读量 7
AI Agent 开始自主执行支付、运维、云资源操作后，传统身份与权限体系暴露出“身份合法、权限合法但具体动作不该发生”的安全空白。业界开始用 Authority 指代对“这一次动作是否应被授权”的判断，安全控制点正从 Access 转向 Action。Nuggets 的 Authority Control Plane、Delinea 的运行时授权以及 Mission-Bound Authorization 草案等，都在同一方向上探索落地，安全治理也从“信任个人”转向“信任可审计、可撤销的结构”。
事件概述
AI Agent 不再只生成建议，而是能读取数据库、调用 API、修改云资源、操作支付系统甚至委托其他 Agent。传统 IAM 体系只回答“你是谁、能访问什么”，无法回答“这次具体动作是否应该发生”。Authority 由此被独立提出，用于描述对每一次实际执行的授权判断。
核心信息
- 传统安全模型出现空白：身份、Token、API 权限都真实，Agent 仍可能执行超出原始任务范围的动作，形成“合法主体产生不合法执行”。
- Authority 与 Authorization 的区别：Authorization 管“主体原则上能做什么”（能力），Authority 管“这一次具体动作是否应该发生”（事件），安全控制从约束主体推进到约束每次执行。
- 安全控制点从 Access 向 Action 移动：Agent 消除了 Permission 与 Execution 之间的人为判断缓冲，系统必须回答为什么调用、调用哪个对象、条件是否变化，运行时授权（Runtime Authorization）成为关键。
- 相关实践：
- 英国身份与信任技术公司 Nuggets 于 2026 年 7 月发布 Authority Control Plane。它位于 Agent 与工具/应用/企业系统之间，不替代 IAM/PAM，而是结合身份、被委托的 authority、组织策略、声明的 intent 与实时上下文，决定动作允许、拒绝或转交人工处理。
- Delinea 发布面向 AI Agent 的运行时授权能力：Agent 完成认证并进入合法 Session，不意味着后续数据库查询、SSH 命令、Kubernetes 操作和工具调用都应自动继承最初的“允许”。
- 独立提出的 Mission-Bound Authorization Internet-Draft 指出，OAuth 可以给 Agent 签发多个相互独立的 Token，却缺少一个持久且经用户批准的对象，把这些能力重新绑定回用户真正授权的任务。其核心风险在于，概率模型持有过大服务账号，可能对真实资源产生超出原始任务范围的影响。
- 安全治理从信任人转向信任结构：当人退出执行链，授权判断必须沉淀为可定义、可委托、可审计、可撤销的结构，以应对“身份合法、权限合法、任务合法但动作错误”的风险。