Journal / 2026 / AI技术

ChatGPT 把工具调用悄悄转给了另一个连接器

2026 年 11 月 5 日，OpenAI 开发者论坛出现一份复现报告：两个连接器指向同一个 MCP 服务器时，ChatGPT 会把后续工具调用静默地转到另一个连接器，并把前一个连接器的一次性确认码带过去。本文只转述报告内容，未经我们独立验证。

本文发表于 2026 年 11 月 8 日 4 分钟阅读 1570 字

目录 · 1570 字 / 4 分钟

2026 年 11 月 5 日，一位名叫 AldiPower 的开发者在 OpenAI 开发者论坛发帖，标题是“安全：后续工具调用被静默路由到另一个连接器”。他说自己在一个同时启用了两个连接器的会话里，看到 ChatGPT 把后续工具调用发给了另一个连接器，而用户没有收到任何提示。

这条报告到目前为止只是发帖人的单方说法。我们没有复现，帖子里也没有 OpenAI 官方账号的回应；下面所有关于“发生了静默切换”的描述，都应当读作“报告称”，而不是已经坐实的事实。

报告里的场景

一个 ChatGPT 账号，同时启用两个连接器，两个连接器指向同一个 MCP 服务器
连接器 A 是在开发者模式里添加的自定义连接器
连接器 B 是从应用目录发布的 App
两个连接器各有自己的 OAuth 客户端，所以服务器眼里是同一个用户的两个不同客户端
会话里请求一个需要用户确认的动作；模型通过 A 调用确认工具，A 的 MCP Apps 组件展示变更；用户确认后，组件通过 ui/message 把一次性确认码发回会话
模型随后带着这个确认码发起后续调用，但走的是 B，而不是 A
服务器拒绝了这次调用，因为确认码绑定在 A 的 OAuth 客户端上；报告说这个会话里的每次尝试都失败
在详细记录的那次尝试里，确认码在 A 确认、在 B 兑换；没有任何提示告诉用户后续调用换了连接器

工具调用应当按 OAuth 客户端匹配连接器，而不是按 MCP 服务器 URL
后续调用应当始终走发起流程的那个连接器与 OAuth 客户端
另一位回复者把问题归纳为“工具选择”和“授权连续性”的区分，并建议把待处理操作与确认绑定到发起连接器，在确认或执行期间禁止自动切换连接器，必要时要求用户显式批准

准备两个连接器，都指向同一个你自己控制的 MCP 服务器，但使用两套独立的 OAuth 客户端；一个在开发者模式里自建，一个从应用目录发布
在服务器端按 OAuth 客户端记录每次工具调用，并保留确认码的签发与兑换记录
在一个会话里同时启用两个连接器，触发一个需要确认的动作，然后看后续调用落在哪个客户端上
如果后续调用换了客户端、用户却没有任何提示，且确认码能跨客户端兑换，那才是报告描述的问题；如果服务器像报告里那样拒绝，至少说明服务端绑定生效了，但静默切换本身仍然存在
这个验证需要 ChatGPT 账号、可发布的连接器和一套 OAuth 服务器；我们当前没有这些条件，所以没有跑

我们核对了论坛原帖，确认发帖时间、连接器设置、调用顺序和“服务器拒绝”的结果都与文中一致
我们核对了 OpenAI 的 MCP 认证文档：已认证的 MCP 服务器被要求实现符合 MCP 授权规范的 OAuth 2.1 流程，这与“每个连接器一套 OAuth 客户端”的前提一致
我们没有复现路由行为，也没有看到 OpenAI 对该帖的官方结论；把这件事当成“报告称”的问题是当前最准确的说法

本文基于以下公开报道整理。

OpenAI 开发者论坛：Security: Follow-up tool call silently routed to a different connector{: rel=“nofollow noopener” target="_blank"}（2026-11-05）
OpenAI 文档：MCP Authentication{: rel=“nofollow noopener” target="_blank"}（2026-11-08 访问）

本文由 AI 辅助整理，事件经过来自公开论坛帖；路由行为未经我们独立验证，请勿当作已确认的安全结论。

Topics

主题只是把现有标签归并后的浏览方式，标签本身不变；全部标签 · 画廊