混淆代理人问题（Confused Deputy）
| 分类 | 🛡️ 安全风险 |
| 阅读时间 | ⏱️ 15 分钟 |
| 更新时间 | 📅 2026-10-05 |
| 条目编号 | ENC-SECURITY-17-confused-deputy |
关键要点 ✦
- 概念源自 1989 年计算机学者 Levy 对一起系统事故的分析：一个编译器在用户指示下把输出写入计费文件，因其自身拥有该文件的合法写权限而得逞——权限授予本身合理，问题出在请求来源不可辨。
- 智能体是混淆代理人问题的高发载体：智能体聚合了多源凭证与工具，一条被污染的输入（网页、邮件、文档中的提示注入）就可能借智能体之手调用其合法权限，把外部不可信内容变成内部高权限操作。
- MCP 官方规范的安全最佳实践章节明确将令牌透传（token passthrough）列为反模式：智能体把上游 OAuth 令牌原样转发给下游 API，下游无法区分请求来自最终用户还是智能体，授权与审计体系随之失效（据 MCP 官方规范）。
- 常见缓解手段包括：受众受限令牌（audience-scoped token，见 RFC 8707）、按会话隔离授权同意、来源绑定与完整审计链，让下游每次都能回答「这个请求究竟代表谁」。
- 与过度代理（Excessive Agency）的区别：过度代理指权限本就超出必要；混淆代理人指权限合理但请求来源被伪造——防御重心因此从「收权」转向「验源」。
概念起源与经典案例
混淆代理人问题的经典案例发生在 1980 年代的分时系统上：系统按用户计费，计费文件只允许编译器服务账号写入。某用户要求编译器把输出写入计费文件，编译器照办了——它拥有写权限，请求也来自合法用户会话，真正被绕过的是「谁在发起这次写操作」的来源判断。
Levy 在 1989 年的分析中把这个模式命名为 Confused Deputy：中间人（deputy）并不糊涂，糊涂的是它的授权模型——它只验证了请求形式合法，没有能力也没有机制去验证请求意图的归属。这一 30 多年前的教训，在智能体时代重新变得锋利。
智能体场景下的攻击形态
智能体天然是「权限放大器」：它同时持有用户的邮箱、日历、代码库、支付工具等凭证，并且被设计为接受外部内容作为输入。当外部内容中藏有提示注入指令时，攻击路径清晰可见——攻击者不直接持有任何凭证，只需让智能体读到一段恶意文本，就能借用智能体的全部合法权限完成读取、外发甚至支付操作。
多智能体链路进一步扩大攻击面：上游智能体的输出是下游智能体的输入，一条被污染的中间结论可以沿调用链传播，每经过一环就多借一层权限。此时的防御难点在于，链路中每一环的单点授权都可能完全合规。
MCP 令牌透传：一个被写进规范的案例
MCP 官方规范的安全最佳实践章节专门讨论了令牌透传问题：如果 MCP 服务器把客户端的 OAuth 令牌原样转发给下游 API，下游服务将无法区分「用户亲自操作」与「智能体代为操作」，静态的授权规则、细粒度的同意管理与全面的审计能力都会因此失效。规范建议 MCP 服务器获取自己独立的令牌，并对下游明确声明请求的代理身份。
同类风险也出现在浏览器代理、桌面自动化等场景：迁移到沙箱中的登录会话本身就是一个「活的凭证」，谁控制了目标环境，谁就能以用户身份行动。这也是相关产品在会话迁移环节普遍引入显式确认与密钥托管机制的原因。
防御模式：从收权到验源
混淆代理人的防御重心不在「把权限砍小」，而在「让每次权限使用都可归因」。工程上通常组合四类手段：一是受众受限令牌，令牌内绑定目标服务与用途，跨服务重放即失效；二是来源绑定，在协议层携带最终用户与发起智能体的双重身份；三是同意隔离，每个会话、每个目标的授权相互独立，防止一次同意被无限复用；四是审计链，把「谁的请求、经谁转发、执行了什么」完整落盘。
对智能体开发者而言，还有一条务实原则：把外部内容默认视为不可信输入，凡涉及高权限工具调用的决策，都应在模型与工具之间加一道策略校验，而不是让模型的一句输出直接换取一次真实世界的写操作。
🎯 应用场景
✅ 最佳实践
- 禁止在服务间原样转发 OAuth 令牌；需要代理调用时改用目标明确、受众受限的独立令牌。
- 敏感操作前校验请求来源：既验证发起智能体的身份，也验证其代表的最终权益人。
- 对智能体的每次高权限工具调用保留不可篡改的审计记录，事后可完整还原决策链。
- 把外部内容（网页、邮件、文档）一律视为不可信输入，高权限操作前置策略校验而非直接执行。
🔮 未来展望
随着智能体深度接入企业 SSO、多租户平台与支付链路，「请求来源可验证」正在从工程最佳实践上升为协议层标配：受众受限令牌、委托凭证与代理身份声明等机制已陆续进入各大协议草案。可以预期，混淆代理人问题将成为智能体安全评审的标准检查项，相关防御模式也将随协议演进持续细化。