你的智能体在链式工具调用中获得的 OAuth 权限范围

用户在你的智能体授权页面上点击一次“授权”。当会话结束时，该智能体已经链式调用了 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 个权限的列表里。从法律上讲，它是经过授权的。从实际操作看，用户并没有授权实际发生的行为；他们授权的是一个最坏情况的捆绑包。

加载中…