A02 授权范围与 Privilege Drift

当一个 Agent 第一天上线时拿到的工具权限恰到好处，三个月后它能做的事却远超任何人当初的设计意图——本节点要解决的问题是：为什么”授权范围（authorization scope）“这个看似静态的配置项，在 Agent 系统里会随时间自发膨胀成攻击面？框架是把”权限漂移（privilege drift）“当作一个制度性病理而非运维疏忽来诊断——它不是某个工程师忘了回收权限，而是”默认宽授权 + 缺乏回收机制”这套设计模式的必然产物。

§0 为什么是”漂移”框架而不是”越权”框架

读者脑中的默认框架往往是”越权访问”（unauthorized access）——一个本不该有 X 权限的主体拿到了 X 权限。这个框架对人类用户成立，但用在 Agent 上会看错病根。

Agent 的问题恰恰是：它合法地拿到了每一项权限，每一次授权在签发当时都是”合理”的，没有任何单点越权。问题出在时间维度上的累积——任务 A 需要读邮件，给了 mail.read；任务 B 需要发邮件，加了 mail.send；任务 C 接入了日历，又加了 calendar.write。每一步都通过了审批，但三个月后这个 Agent 持有的是 mail.read + mail.send + calendar.write + ... 的并集，而没有任何一个当前任务需要这个全集。这就是”漂移”——权限的边界在缓慢、合法、无人察觉地外移。

所以正确的框架不是”谁越权了”（一个空间问题），而是”权限的有效边界如何随时间脱离任务的实际需求”（一个时间 + 治理问题）。这个区分决定了你的防御要建在哪：越权框架让你去查 ACL 配置，漂移框架逼你去建生命周期回收机制。这正是本节点链向 m208 - AI 基础设施与中间件选型与 0435 红队专题 S03 权限边界（0436 同批 staging 专题，下同）的接口。

§1 授权范围（Scope）：为什么 OAuth 的粒度天生对不上 Agent 任务

授权范围指 Agent 被允许执行的操作集合，通常以 OAuth 2.0 scope token、RBAC/ABAC 角色绑定或 capability token 的形式表达。问题的制度性根因在于一句话：OAuth scope 绑定在 operator 层而非 task 层。

也就是说，Agent 拿到的令牌表达的是”允许访问某系统/某资源类”（如 gmail.modify），而不是”允许完成此具体任务”（如”把这一封会议纪要转发给参会者”）。Scope 与任务意图天然脱节——gmail.modify 这一个 scope 同时授予了”读取所有邮件、修改标签、删除邮件、批量退订”等一大堆操作，而任务只需要其中极小一块。

表达层	授权对象	粒度	漂移风险
operator 层（OAuth scope 现状）	“访问某系统”	粗（一个 scope = 一类操作集）	高：scope 永远 ≥ 任务所需
task 层（学术提案方向）	“完成此任务”	细（最小操作集）	低：每任务签发即用即弃

学术界对此有明确共识。arXiv 2510.26702（El Helou 等，2025-10-30）提出让授权服务器对访问请求做语义任务-范围匹配（semantic task-to-scope matching），仅签发完成任务所需的最小 scope token，并引入 ASTRA 数据集做 benchmark。但同一篇论文也诚实地报告了边界：当任务需要多个 scope 时，模型的匹配准确率显著下降——这意味着”用 LLM 推导最小权限”本身又引入了概率性不确定性。这是后文争议点的伏笔。

§2 Privilege Drift：默认宽授权 + 无回收 = 攻击面膨胀

权限漂移的判断主轴可以写成一个等式：

默认宽授权（over-provisioning）＋缺乏回收机制（no de-provisioning）＝攻击面随时间单调膨胀。

两个变量都必须成立漂移才发生。只有宽授权而有严格回收，权限会回弹；只有无回收而初始最小，权限至少不增长。Agent 系统的灾难在于它同时踩了两个：初始为了”让 Agent 别动不动卡住”而给宽 scope，运行中又因为”不知道哪些权限还在用”而不敢回收。

有调查数据支撑这不是危言耸听。Cloud Security Alliance《AI Agent Security Starts with Scope Control》（2026-05-12）报告：只有 8% 的组织表示其 AI Agent 从未超出预期权限；53% 表示 Agent 偶尔或有时超出权限；47% 在过去 12 个月内经历过涉及 AI Agent 的安全事件。CSA 把漂移归为四大根因：(1) 过度授权的集成（API scope 比任务所需更宽）；(2) 模糊自然语言指令导致意图误判；(3) 任务链自主执行（无显式人工批准的中间步骤）；(4) 上下文漂移（Agent 在迭代中偏离原始意图）。

〔需注意：CSA 这份报告未披露样本量与受访者构成，“8%/53%/47%“的代表性应保留——本节点用它佐证趋势，不当作精确总体估计。〕

更宏观的数据点：2025 年 agentic AI 相关 CVE 数量同比增长 255%（WorkOS Blog），其主因被追溯至”凭证权限过大、生命周期过长”——这恰好是漂移等式的两个变量。

§3 判断主轴：90% 的人在权限漂移上会搞错的四个点

这是本节点的命门。每点按”症状 → 为什么会错 → 正确做法 → 真实反例”四件套。

① 把”初始授权合理”当成”持续授权合理”。

症状：上线评审时逐项确认了每个 scope 的必要性，签字通过，之后再不回看。
为什么会错：评审是一个时点快照，而漂移是一个过程；任务在演化、Agent 在被复用、工具在被追加，初始合理性不传递到未来。
正确做法：把授权设计成有过期时间的（time-boxed scope），到期自动失效、需重新授予；Google Cloud Agent Identity 的 X.509 证书 24 小时自动过期就是这个思路的工程化（来源：Google Cloud Agent Identity 官方文档，更新 2026-06-05）。
真实反例：那 2,000 个被 arXiv 2603.24775（2026-03-25）实测全部缺乏认证的 MCP server——它们上线时或许”够用”，但从未有人回头收口。

② 用”最小权限”代替”最小自主”，以为给对了 scope 就安全了。

症状：精心配置了最小 scope，却允许 Agent 在该 scope 内无需确认地自主连续行动。
为什么会错：最小权限（least privilege）≠ 最小自主（least agency）。即使 Agent 只有 mail.send 这一个最小权限，它能不能”未经回确认就群发 500 封邮件”是另一个维度的问题。OWASP Agentic AI Top 10（2025-12-09 发布）专门引入了 Least Agency 这一区分。
正确做法：scope 之外再设确认门（confirmation gate）按操作的副作用分级触发，把”有权做”和”可自主做”解耦。
真实反例：OpenAI Model Spec（2025-12-18 版）明确规定”批量退订邮件”这类不可逆操作执行前必须向用户展示列表并取得确认——拥有权限不等于可静默执行。

③ 让子 Agent 直接继承父 Agent 的全部权限。

症状：orchestrator 把任务委托给 sub-agent，后者直接复用父的 service account 凭证、环境变量里的 API key。
为什么会错：委托链上没有权限递减，每一跳都把全集传下去，等于把漂移在空间上复制了一遍。RFC 8693（Token Exchange，正式 RFC）甚至明确承认嵌套 act claim “仅供参考，不得用于访问控制决策”——多跳授权链在标准层面无法强制执行。
正确做法：Scope Attenuation（范围递减）——每一跳子 Agent 的 token 必须比上游严格，禁止平级或升级传递。
真实反例：2025 年的 Cross-Agent Privilege Escalation（2025-09）攻击，正是低权限 sub-agent 诱导高权限 trusted agent 代为执行受限操作。

④ 把”暂时放宽”当成”临时”，却没有配套的自动回收。

症状：为某次紧急任务临时给 Agent 加了写权限，事后没人记得收回。
为什么会错：人类世界里”临时”权限靠记忆和工单回收，而 Agent 每小时可能发起数千次调用，人工回收根本跟不上节奏；机器身份与人类身份的数量比已达 45:1 到 100:1（CSA 研究），靠人管回收注定漂移。
正确做法：任何提权都必须带 TTL（time-to-live），到期自动降级；把回收做成默认行为而非例外动作。
真实反例：IBM 2025 报告称 97% 被 AI 相关事件波及的组织缺乏适当的 AI 访问控制（经 Aembit 引述）——“加了忘了收”是常态而非个案。

§4 产品 PM 视角补盲：漂移不是工程问题，是组织 incentive 问题

跳出工程 PM 视角，权限漂移有三个容易被技术团队看走眼的非技术面：

incentive 错配：放宽权限的人（让 Agent 跑通的工程师）和承担漂移后果的人（安全/合规团队）不是同一拨人。放宽的收益即时可见（任务不卡了），漂移的成本延迟且分散（某天出事）。这是典型的外部性问题——和滴滴风控里”业务方要转化率、风控方背欺诈损失”的张力同构。PM 的职责是把延迟成本前置成可见指标（如”权限-任务对齐度”看板），否则任何技术方案都会被 incentive 冲垮。
确认疲劳的反噬：以为”多设确认门”就安全，但 Anthropic 共享责任模型（2026-04-29）披露的数据显示，开发者在 93% 的权限提示弹窗中未经有效审查即点击批准。逐操作确认在心理上已经失效——这把球踢回给”计划级治理”（plan-level governance）而非”操作级治理”。PM 要设计的是少而重的确认，不是多而滥的弹窗。
合规边界的时间错位：EU AI Act 等监管要求”全生命周期”可审计，但漂移恰恰发生在生命周期的中段（上线后、退役前），是审计最薄弱的窗口。一个上线时合规的 Agent，可能在第四个月因为漂移而事实上不合规，却没有任何告警。

§5 对手框架回应：最小权限原则在 Agent 时代是否已经”失效”

业界有一种尖锐的反方立场，值得正面接住而非回避。

反方（以 Karl McGuinness 等身份领域研究者为代表，经 Resilient Cyber 引述）： “给 Agent 设计’身份护照’和静态最小权限是错的方向——Agent 不需要一张固定的权限名单，它需要的是按需的授权授予（authorization grant）。把人类 IAM 的’角色 + 权限’范式套到 Agent 上，本身就是范式错误。”

接受的部分： 这个批评对了一半。静态的、长期有效的最小权限确实对不上 Agent 的动态任务流——你不可能预先枚举一个 Agent 未来要做的所有任务，再给它配一个”刚好够”的固定 scope 集。这正是 §1 说的”operator 层 vs task 层”脱节。从这个角度，传统 IAM 的”先发权限、后用”模型确实在 Agent 场景整体失效。

坚持的边界（本节点的赌注）： 但”最小权限失效”不等于”最小权限原则失效”——失效的是它的静态实现，而非它的规范目标。正确的回应不是放弃最小权限，而是把它从”静态配置”重构为”动态的、即用即弃的、任务绑定的”授权——这恰恰是 arXiv 2603.24775 的 Invocation-Bound Capability Token（IBCT，把身份验证、递减权限、溯源追踪合并为统一 token 链，验证开销仅 0.049ms）和 PAuth（arXiv 2603.17170，2026-03-17，“任务即授权”语义，在 AgentDojo 测试中良性任务全通过、注入攻击全拦截）在做的事。

我赌的是：未来 18 个月内胜出的方案是”动态最小权限”而非”放弃最小权限”。理由有二——其一，监管（EU AI Act、NIST NCCoE 概念文件）的可审计要求本质上要求权限可归因，而”无名单的授权授予”难以满足审计的可追溯性；其二，“按需授予”如果没有一个递减的、可验证的权限边界做底，本质上只是把漂移问题从”配置时”推迟到”运行时”，并未消解。这个赌注会失效的场景：如果出现一种被广泛采纳的、能在运行时密码学证明”每次授予都收窄”的标准（IETF 当前有衰减令牌、可验证 actor 链等 4 个方向在研），那么”静态名单”这个概念会彻底消失，“最小权限”作为一个需要显式设计的环节也随之溶解——届时本节点的框架需要重写。

§6 跨域呼应：共享资源治理与公地悲剧

权限漂移的深层结构，是一个**公地悲剧（tragedy of the commons）**问题——这正是 0421 机制设计专题（同批 staging）共享资源治理的核心母题。

把”系统的总攻击面”看作一片公地：每个团队为了让自己的 Agent 跑顺而多要一点权限，单看每次都是理性的、收益归己；而漂移带来的攻击面膨胀是成本外溢、由全组织共担。没有人有动机主动回收自己的权限（回收的成本归己、收益归全体），于是公地被逐步耗尽——这与 Garrett Hardin 1968 年《The Tragedy of the Commons》描述的牧场过度放牧结构完全同构。

这个跨域框架改变了一个具体的技术判断：它告诉我们，纯技术手段（更细的 scope、更强的 token）无法根治漂移，因为问题的根在 incentive 结构而非技术能力。Elinor Ostrom 对公地悲剧的经典反驳（《Governing the Commons》，1990）给出了出路——公地不必然走向悲剧，前提是建立清晰的边界、与本地条件匹配的规则、有效的监督与分级惩罚。映射到 Agent 授权：这意味着治理设计要包含”谁有权放宽/谁负责回收”的清晰产权（对应 NIST AI RMF Agentic Profile 的”为每个 agent 设置所有权”）、可观测的漂移监督（权限-任务对齐看板）、以及对长期不回收的分级响应。换句话说，漂移是个治理问题，要用治理工具（产权 + 监督 + 惩罚）解，不是只用 IAM 工具解——这是 Rick 的安全 PM 视角相对纯工程视角的增量。

[!note] 跨域赌注我赌”漂移本质是公地悲剧”这个类比成立，且 Ostrom 式的”分级治理”比纯技术管控更能持续。它会失效的边界：如果”动态最小权限 + 自动回收”被做到了完全自动化、零人工成本，那么公地的”维护成本归己”前提消失，悲剧逻辑也随之失效——但以 2026 年的工程现实看，全自动回收仍是理想而非现实。

§7 PM 决策启示

面试怎么用：被问”你怎么给 Agent 设计权限”时，不要停在”最小权限”这个口号——那是 5 年前的答案。区分清楚三层：最小权限（least privilege，空间维度）、最小自主（least agency，自主度维度）、最小生命周期（time-boxed，时间维度），并指出”默认宽授权 + 无回收 = 漂移”这个等式。再补一句”漂移本质是公地悲剧式的 incentive 问题”，立刻区分出”读过两篇博客”和”真想过”。
选型怎么用：评估 Agent 编排框架（参照 m208 - AI 基础设施与中间件选型的选型维度）时，加四个权限问题：(1) 是否支持任务级（而非全局）工具权限白名单？(2) 委托给 sub-agent 时是否强制 scope 递减？(3) 授权是否带 TTL、能否自动回收？(4) 是否有权限-任务对齐的可观测性？缺一即在高合规场景扣分。
复现怎么用：自建 Agent 时，把”权限回收”做成默认而非例外——任何提权带过期时间，到期自动降级；接入 MCP server 前先验证其认证（别成为那 2,000 个裸奔 server 之一）；对副作用分级，高副作用操作走确认门而非自主执行。

§8 与已有节点的关系

对 Function Calling（基础节点）：本节点是其安全侧深化。Function Calling 讲”Agent 如何调用工具”，本节点讲”调用工具的权限如何随时间漂移”——补的是工具调用的生命周期治理这一缺口，不复述 Function Calling 的机制基础。
对 m208 - AI 基础设施与中间件选型（工程化模块）：本节点为其补安全选型维度。m208 §2.5.2 编排框架对比缺少”任务级权限白名单 / scope 递减 / 自动回收”这三个判据，本节点给出可操作的四问框架，是对它的补缺。
对 m207 - Agent 产品化：场景推演与失败模式（工程化模块）：本节点把”权限漂移”补为一类新的失败模式——它不是单点 bug，而是缓慢累积的系统性病理，应进入 m207 的失败模式清单。
对 0435 红队专题 S03 Agent 权限边界与最小权限设计（0436 同批 staging，降级文本引用）：本节点是其概念前置——S03 讲”权限边界怎么设计”，本节点讲”边界为什么会漂移、漂移的判断框架是什么”，二者是病理诊断与防御设计的关系。
对 0421 机制设计专题共享资源治理（同批 staging，降级文本引用）：本节点借用其公地悲剧框架解释漂移的 incentive 根因，是跨专题的框架复用。

§9 关联节点

核心（必读）：

延伸（可选）：

修订日志

R0.1（2026-06-07）：首稿。建立”默认宽授权 + 无回收 = 漂移”判断等式；四件套判断主轴四点；对手框架（McGuinness “授权授予 vs 身份护照”）接受+边界；跨域呼应（公地悲剧 / Ostrom）；接地 CSA 2026-05-12、arXiv 2603.24775 / 2603.17170 / 2510.26702、RFC 8693、Google Cloud Agent Identity、OWASP Agentic Top 10、Anthropic 共享责任模型等。staging 区，0435/0421 引用降级为文本。