ARTICLE / 安全
你的确认码，被AI静默发给了另一个应用
一个 ChatGPT 用户开了两个连接器（connector），都指向同一个 MCP 服务器。他发起一个需要确认的操作：模型通过连接器 A 调用确认工具，A 的弹窗组件展示变更内容，用户点确认，组件把一个一次性确认码发回对话。接下来，模型带着这个确认码发起后续调用——但走的是连接器 B。整个过程没有任何提示告诉用户：路由已经换了。
这是 OpenAI 开发者社区 11 月公开的一个案例（帖子作者 AldiPower）。结果没有造成损失：服务端把这次调用拒了，因为确认码绑定的是连接器 A 的 OAuth client，B 兑换不了。但正是这个"被拒"暴露了更要紧的问题——切换是编排层做的，用户不知情；拦截是服务端碰巧做到的，不是设计保证的。
来源：community.openai.com《Security: Follow-up tool call silently routed to a different connector》帖子页面截图，2026-11-07 采集。
两个连接器，一个 URL，边界在哪
这个案例的设置值得逐条看：连接器 A 是开发者模式添加的自定义连接器，连接器 B 是应用目录里的发布版应用，两者指向同一个 MCP 服务器，但各自持有独立的 OAuth client——在服务器眼里，这是同一个用户的两个不同客户端。
报告者后续发起确认操作时，确认码在 A 的组件里产生，却在 B 的会话里被拿去兑换。服务端按 OAuth client 绑定校验，拒绝生效。报告者总结的边界判断很准确：共享 MCP URL 不足以把两个连接器当作同一个东西。同一个 URL 背后，服务器可以按 OAuth client 服务于完全不同的主体——独立租户、合作伙伴、不同环境。信任边界是"带着自己 OAuth client 的连接器"，不是 URL。
落到设计上：如果你的 agent 宿主按"服务器地址相同就随便路由"来调度工具调用，等于把不同应用的授权上下文当成了可以互换的东西。
报告者在帖子里给出的期望行为也很明确：工具调用按 OAuth client 匹配连接器，后续调用走发起流程的同一个连接器和 OAuth client——选了 A，就走 A 到底。
为什么服务端拦截不算赢
这次事故链条里，防线是服务端的确认码绑定。它拦下了越界的兑换。但报告者和社区回复都指出了同一件事：静默路由本身仍然发生了。
数据已经从一个应用的上下文流到了另一个应用的上下文——这次流的是确认码，下次可能就是别的内容。服务端校验能挡住"越权使用"，挡不住"数据出域"。对一个多连接器会话来说，用户的心智模型是"我在跟连接器 A 交互"，任何绕开这个模型的路径切换都是授权语境的漂移。这次没有损失，是因为目标连接器的服务端恰好做了绑定校验；把场景换成两个没有这层绑定的第三方服务，结果就是一次成功的数据外带。
社区回复（OpenAI 社区大使身份）把这个案例提炼成一个架构命题：多步工具工作流应该在整个过程中保持发起连接器的身份和授权上下文，而不是只依赖 MCP 端点或工具名来匹配。这个表述把"选工具"（tool selection）和"授权连续性"（authorization continuity）分成了两件事——模型可以自由选工具，但授权上下文不能跟着漂移。
构建多连接器系统的五条防线
社区回复给出的加固清单，对任何构建 multi-connector agent 系统的团队都适用，原文五条：
- 把待定操作和确认绑定到发起它们的连接器及其已验证的 OAuth grant 上；
- 确认或执行期间禁止自动切换连接器；
- 确有必要切换连接器时，要求用户显式批准；
- 服务端校验短时效确认码时，同时核对目标操作、客户端身份和授权上下文；
- 把连接器路由决策写进诊断日志，但不暴露凭据或敏感确认值。
这五条的共同思路是把边界决策从"模型的自由裁量"里拿走：路由是编排层的事，编排层要么锁定发起上下文，要么把切换变成用户可见、可批准的动作。模型选哪个工具是模型的事；用哪个授权身份去调用，必须由架构钉死。
给普通用户的判断也简单：在一个会话里启用多个连接器时，留意确认类操作——确认弹窗来自哪个应用、确认之后动作由谁执行，这两个主体应当一致。看到"确认在 A、执行在 B"的迹象，先断开其中一个再操作。
披露流程的一个现实摩擦
案例还有个尾声：报告者试过走 OpenAI 的漏洞悬赏计划，但被要求先提交生物识别信息和身份证件，且是提交给无关的第三方——他拒绝了，改为社区公开披露。这条摩擦值得安全行业注意：身份门槛过高会把本想负责任披露的研究者推向公开渠道。社区回复也建议这份材料走协调披露流程，报告者的回应是"我试过，门槛过不去"。公开帖保留了完整的技术细节和可复现步骤，客观上让所有 multi-connector 系统的开发者都能对照自查——从防御视角看，这个结果不算坏，但它是流程摩擦的产物，不是流程的设计目标。
Agent 宿主的连接器路由是这两年新出现的一整类信任边界问题：模型在中间做调度，两端是彼此独立的授权域。这个案例里服务端兜住了，下一个未必。把"授权上下文跟着发起方走"写进你的编排层设计，比事后给服务端加校验便宜得多。
本文面向授权安全研究与防御建设，未经授权对任何系统实施文中技术属违法行为。
参考来源
- OpenAI 开发者社区帖子《Security follow up: tool call silently routed to a different connector》（community.openai.com，作者 AldiPower，采集于 2026-11-07）
- Hacker News 相关讨论（news.ycombinator.com/item?id=50399569，未逐条引用评论内容）