用户在你的智能体授权页面上点击一次“授权”。当会话结束时，该智能体已经链式调用了 11 个工具，协商了 3 次提权授权，现在拥有了它所触及的每个工具的权限并集。用户只记得授权了一件事。你的审计日志却显示它拥有半个账户的读写权限。OAuth 标准说一切都在按设计运行，而这恰恰就是问题所在。
经典的 OAuth 授权模型是为“一个应用与一个 API 通信”的世界构建的。智能体在两年前打破了这一假设，而标准在实践中尚未跟上，即使规范已经更新。其结果是一类无人刻意发布的静默权限提升——它随着每一次工具注册而累积，而你的安全审查却一直在盯着前门。
授权是一次性事件，权限范围是状态属性
OAuth 的授权页面被设计为一个瞬间：用户阅读权限列表，点击批准，然后应用收到令牌。该页面植入的心理模型是“我授权这个应用做这些事”。对于请求的权限对应于应用将执行的一组固定 API 调用的静态集成，这个模型是成立的。
但它不适用于智能体。会话开始时的智能体并不知道它将调用哪些工具。编排框架允许模型动态选择工具。每个工具可能需要智能体之前不持有的权限。大多数框架采用的务实补丁是：计算智能体在其注册工具目录中可能需要的所有权限的并集，在开始时一次性呈现该并集，并交给智能体一个足够宽泛的令牌，以涵盖它可能遇到的最坏情况。
用户面对冗长的权限列表，要么走马观花，要么出于对品牌的信任点击通过。现在，智能体拥有一个会话级别的令牌，其权限范围覆盖了整个工具图谱的最大包络，无论用户实际想调用哪些工具。2026 年的 OWASP 智能体应用 Top 10 将“过度特权身份”和“过度代理”列入前三大关注点是有原因的：一项针对 900+ 名从业者的 2026 年调查发现，74% 的受访者表示他们的智能体最终获得的访问权限超出了实际需求，仅有 8% 的组织表示其 AI 智能体从未超出预期权限。
架构上的错误不在于框架索要过多，而在于框架将一系列决策压缩成了单个决策。每一次工具调用都是独立的权限决策；而授权 UI 将所有决策的并集渲染为了同一个页面。
爆炸半径随工具图谱累积
假设用户安装了一个研究智能体，用于“总结工单并向我发送摘要”。这个描述清晰地对应两个权限：工单系统的读取权限和邮件服务的发送权限。用户授权了。
在实践中，智能体的工具目录包含了日历工具（“用于安排后续行动”）、CRM 工具（“用于获取客户背景”）、Slack 工具（“用于搜索团队讨论”）以及文件存储工具（“用于附加摘要”）。每个工具在安装时都会注册其所需的权限。框架计算并集，用户签名一次，运行中的会话现在持有的令牌跨越了六个领域。
智能体的会话日志显示，在任何给定的运行中，它实际上只使用了两个权限。安全团队事后的疑问——“当这个智能体处理工单 #4912 时，它能做什么？”——有一个安全团队不想听到的答案。答案是“其会话令牌允许的任何事情”，而会话令牌允许的是整个目录的并集，而不是工作的子集。
这相当于智能体界的“带有从未使用的 root 权限的长效容器”。权限每一刻都存在，工作负载却只行使其中一部分，审计结果显示的是最坏情况而非实际情况。在容器世界中，我们最终编写了工具将权限限定在工作负载实际行使的最小集合内。智能体世界尚未建立起相应的能力。
用户的心理模型落后于现实多个权限级别
最深层的问题不是技术问题，而是授权的完整性。用户在会话开始时同意了一组权限。智能体调用的工具其权限虽然在原始并集之内，但却在用户对其批准内容的心理模型之外。用户是否真正授权的法律问题并未通过 OAuth 流程得到解决——它取决于授权页面传达的是实际发生的授权还是最坏情况下的授权。
一个在“你的智能体可以读取工单并发送邮件”上点击“批准”的用户，期望智能体读取工单并发送邮件。同一个用户，如果被明确询问：“你是否授权该智能体在你的私人 Slack 频道中搜索与工单主题相关的关键词”，可能会拒绝。Slack 权限出现在原始授权页面上，埋在 12 个权限的列表里。从法律上讲，它是经过授权的。从实际操作看，用户并没有授权实际发生的行为；他们授权的是一个最坏情况的捆绑包。
MCP 授权规范承认了这一差距。2025 年 6 月的更新将 MCP 服务器归类为 OAuth 资源服务器，并要求客户端实现资源指示符 (Resource Indicators, RFC 8707)，因此为某个 MCP 服务器颁发的令牌无法静默地在另一个服务器上复用。这解决了受众问题的一部分，但没有解决授权完整性问题，因为单个 MCP 服务器仍然可以暴露许多工具，而这些工具的权限在授权时已被捆绑在一起。
JIT 及时授权将决策移至行动时刻
2026 年规范中最具前景的模式是 JIT 及时授权 (Just-in-time consent)，有时也被称为提权授权 (step-up authorization) 或 URL 引导 (URL Elicitation)。智能体运行时 (agent runtime) 初始仅持有一个涵盖基础、低成本、低风险权限范围的最小令牌 (token)。当智能体执行到需要尚未获取的权限范围的工具调用时，运行时会暂停执行，向用户展示特定上下文的授权 UI —— “智能体想要访问你的日历以完成你要求的任务” —— 获取针对该特定权限扩展的加密授权，获取新的令牌，并恢复执行。
URL Elicitation 是旨在将此过程标准化的 MCP 规范增强提案，它是智能体生态系统在协议层解决“一次性授权” (one-shot-consent) 问题上最接近成功的尝试。Cloudflare 的 Agents 平台在其托管的 OAuth 2.1 服务器中原生实现了这一功能；2025 年 12 月发布的 Claude Desktop MCP OAuth 实现也遵循了相同的握手流程。
JIT 授权是有代价的：智能体体验现在包含了用户必须处理的交互式停顿。而这种代价正是其核心所在。每一次停顿都是让用户的心理模型与智能体实际获得的授权保持同步的机会。一个静默扩展权限、无摩擦的智能体是更糟糕的选择，即便它在完成时间指标上表现更好。那些将 JIT 授权视为用户体验退化的团队，优化的是错误的指标。
使 JIT 授权变得可接受的实际结构是：将需要用户参与确认的权限范围与安装时即可安全授予的权限范围分开。阅读公开文档、搜索用户自己的日历、列出用户自己的工单 —— 这些可以放在基础授权中。而在日历事件上执行写入、发布到 Slack 频道、发送给组织外的联系人、转账 —— 这些权限范围在智能体每次调用时，都理应触发 JIT 授权提示。
逐动作权限封包与审计缺口
JIT 授权的补充是审计模式：在追踪 (trace) 中持久化一个逐动作权限封包 (per-action scope envelope)。对于智能体进行的每一次工具调用，都要记录运行时为该特定调用授权的精确权限范围 —— 不是会话级令牌，也不是框架的最坏情况捆绑包，而是调用离开智能体那一刻所行使的权限范围。
这样，安全团队的问题 —— “智能体在这一步到底能做什么？” —— 就会有一个精确的答案。不再是 “其会话令牌允许的任何操作”，而是 “该工具调用激活的精确权限封包”。审计日志变成了一个收窄权限的链条，而不是在每个条目中重复出现的单一宽泛授权。
这在事件响应期间至关重要。当客户报告意外的数据泄露时，安全团队需要重建泄露发生瞬间智能体所实现的授权。记录 “会话令牌包含权限 X” 的追踪只能告诉你智能体 可能 做了这件事。而记录 “工具调用 #7 激活的权限封包包含权限 X，并在时间点 T 通过 JIT 授权进行了扩展” 的追踪则能告诉你智能体 确实 做了什么，以及谁在何时授权了什么。
另一个相关的模式是会话级权限上限 (session-level scope cap)，它在反馈循环上比事件响应更短，非常有价值：这是一个运行时守卫，当会话通过提权累积的权限超过配置的上限时，它会默认拒绝 (fail closed)。即便每一次独立的 JIT 授权提示都是合法的，累积的权限范围也可能超出了用户对其构建内容的合理理解范围。该上限强制要求在智能体相对于其初始上下文变得过于强大之前，进行重新授权或会话重置。
授权现在是一个图问题
所有这些背后的架构共识是：智能体系统已将 OAuth 授权模型从 “用户授权应用” 转变为了 “用户授权应用，应用授权工具图谱，图谱执行一系列调用，这些调用的累积权限才是实际行使的权利”。
能够交付安全智能体的团队，是那些为“图”而非“应用”设计授权的团队。这意味着授权屏幕显示的是实际行使的权限封包，而非最坏情况下的并集。针对用户心理模型无法预见的权限范围设置 JIT 停顿。记录逐动作追踪，以便安全团队回答实际授权问题。设置会话级上限，当累积权限偏离用户最初意图时默认拒绝。
那些没有为图重新设计授权的团队正在交付静默提权。这并非出于故意，而是因为框架默认将一次会话视为一次决策，将工具目录视为一个捆绑包。在智能体静默积累能力的过程中，这两个假设与安全审计最终必须解释的实际权限之间产生了缺口。
OAuth 规范并没有失效。是智能体的部署模型破坏了规范编写时的假设。那些意识到这一点，并像构建工具图谱属性一样重新构建授权（而非将会话视为授权属性）的团队，其智能体才能在下一轮审计、监管审查和用户信任危机中幸存下来。那些将授权屏幕视为安全边界的团队，实际上检查错了周界。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
