ChatGPT 连接器串号：确认码发给了另一个应用
11 月 5 日上午，一位开发者在 OpenAI 官方社区发了一篇帖子：同一个对话里装了两个 ChatGPT 连接器之后，ChatGPT 把后续的工具调用悄悄发给了另一个连接器——而不是用户刚刚确认过的那一个。帖子在 Hacker News 上拿了 83 分，讨论很快就偏了方向，因为同一个帖子里还有另一件事：这位报告者想走官方漏洞赏金流程，却被要求先交身份证和人脸照片。
这两件事放在一起看很有意思：一个关于 AI 产品内部「谁有权处理谁的数据」的技术问题，一个关于「谁能向 AI 公司报告安全问题」的制度问题。这篇文章把两件事都拆开讲清楚。
一句话结论
- 技术层面：数据隔离的边界画错了位置。两个连接器指向同一个 MCP 服务器，但是两套 OAuth 客户端。ChatGPT 按服务器地址匹配连接器，于是把 A 的确认码送到了 B。
- 实际损害：目前被服务端挡住了。因为确认码在服务端绑定在 A 的 OAuth 客户端上，B 拿去兑换会被拒绝。也就是说，这是一次「被拦住的越界」，还不是一次成功的越权。
- 制度层面：Bugcrowd 的身份验证现在卡在提交之前。这是为了压制 AI 生成的劣质报告，但副作用是匿名研究者被挡在门外，报告转向公开论坛，反而扩散得更快。
需要先说清楚信息边界：整件事只有报告者的描述和一位社区用户的回复，OpenAI 至今没有官方回应，没有严重性评级，没有修复状态，也没有公开任何赏金金额。下面的技术细节都来自报告者自述。
1）技术细节：ChatGPT 连接器为什么会把确认码发错门
报告者的环境很具体：一个 ChatGPT 账号，启用了两个连接器，都指向同一个 MCP 服务器。
- 连接器 A：开发者模式下自建的连接器；
- 连接器 B：应用目录里发布的应用；
- 共同点：同一个 MCP 服务器地址；不同点：各自独立注册的 OAuth 客户端。
对那个服务端来说，这两条连接是两个不同的客户端，虽然背后是同一个用户。这个前提很重要，它决定了后面所有问题。
复现路径是这样的：
- 在一个对话里同时启用两个连接器，发起一个需要用户确认的操作；
- 模型通过连接器 A 调用确认工具，A 的 MCP Apps 组件在界面上展示这次变更；
- 用户确认，组件通过
ui/message把一个一次性确认码送进对话； - 模型带着这个确认码做后续调用——但这次走的是连接器 B，而且没有任何提示。
结果：服务端拒绝了这次调用，因为确认码绑定在 A 的 OAuth 客户端上。报告者说那个对话里每一次尝试都失败了。
所以严格来说，这不是「数据已经被偷走」，而是「数据被试图送去了错误的地方，被服务端拦住了」。报告者的担忧在于：一旦某个第三方连接器的服务端审核更松，就会接受来自别人组件的确认码。在同一个 MCP 地址背后，服务端可能服务不同的租户、合作方或环境——URL 相同不代表是同一个应用。
他给出的修复方向很明确：工具调用应当按 OAuth 客户端来匹配连接器，而不是按 MCP 服务器地址；后续调用必须使用发起流程时那个连接器和那个 OAuth 客户端。
2）为什么这不是「低危」
HN 上有一条评论把这事讲得很直接：如果「确认」本身也是一次独立的工具调用，那它就是一次独立的工具调用——交还控制权给模型，就是把控制权交还给模型，中间没有作用域、没有绑定。这话听起来像在替 OpenAI 开脱，但其实是点到了要害：多步 agent 流程里，「身份」很容易在步骤之间丢失。
传统 Web 应用里，一次请求的租户、用户、权限是绑在会话上的，跨步骤调用天然继承。而在 agent 架构里，每一步都是「模型重新决定用哪个工具」，只要匹配逻辑不够严，身份就会漂移。这里漂移的是 OAuth 客户端，下次可能是租户、可能是环境、可能是某个被降权的凭证。
对用 MCP 生态的人来说，这件事的实际含义是：
- 别把「同一个服务器地址」当成「同一个应用」。如果你的服务端按 OAuth 客户端区分租户或权限，客户端侧也必须这样区分，否则两端的行为就对不上。
- 确认码必须校验完整上下文。不只是「这个码对不对」，还要「这个码是不是这个客户端、这个操作、这次授权发出来的」。社区回复里的建议就是这五条：把待办操作绑定到发起连接器与已验证的 OAuth 授权、禁止确认或执行期间自动切换连接器、必要时要求用户显式同意切换、按目标操作与客户端身份校验短时效确认码、在诊断日志里记录路由决策但不泄露凭证。
- 同时开多个连接器时要留意界面提示。这次的问题之一就是「没有任何提示」，用户以为自己还在 A 里确认。
3）赏金流程：ID 卡这一刀砍在了谁身上
帖子后半段才是 HN 上吵得最凶的地方。报告者说，他尝试通过 OpenAI 的漏洞赏金计划提交，但该计划要求在上报之前提交个人数据，包括生物特征识别和人脸/身份证件。他不愿意在提交阶段就把这些交给第三方，于是没走官方流程，改为公开发帖。
这不是 OpenAI 自己发明的规矩。Bugcrowd 的官方文档写得很清楚，原文是：
To improve platform integrity by reducing high volumes of low-quality submissions, identity verification (IDV) is now mandatory for all researchers before submitting reports to Managed Bug Bounty (MBB) programs (public and private, excluding on-demand MBBs).
流程上，研究者要上传一份经认可的身份证件，再加一张光线充足的自拍，交由第三方 Jumio（NetVerify）核验；护照、身份证、驾照都可以，但必须是塑料卡片形态；如果此前已经因为收款或背景调查完成过验证，则不必重复。
这条政策的动机是可以理解的：2025 年以来 AI 生成的「漏洞报告」大量涌入，质量低、噪音高，平台需要一个成本来过滤。要求提交者「押上真实身份」，确实能压掉大部分批量灌水。
但它有个明显的副作用，而且这次就发生了：匿名研究者被挡在门外，报告转而发到公开论坛。原本应该在私下流转、由厂商评估严重性再决定披露节奏的漏洞细节，直接变成了公开情报——任何想利用它的人都能看到。
HN 上有人提到，这个位置变化值得警惕：过去赏金计划里身份核验一般发生在拿到奖励、决定收款的时候，现在被挪到了提交报告之前。也有评论指出，真正的白帽如果不愿意交生物信息，可能干脆不上报；另一些人认为这正是过滤噪音的代价，值得付。
两边都有道理。这里不给结论，只指出一个事实：对 AI 公司来说，这套机制恰好把「安全研究者」和「AI 灌水者」混在同一道闸门里，而闸门的代价是真实姓名和人脸。
4）如果你是开发者，现在该做什么
这件事对普通 ChatGPT 用户的直接影响很小——你不太可能同时装两个指向同一 MCP 服务器的连接器。但对做 MCP 服务端、或者在做 agent 产品的团队，它是一份现成的检查清单：
- 确认你的服务端是按 OAuth 客户端鉴别身份，而不是只看 URL 或 tool 名。如果你的多租户是靠 client_id 区分的，这一点必须写进安全模型文档。
- 短时效令牌要绑定完整上下文：操作内容、客户端身份、授权范围、有效期。只校验「码对不对」等于没校验。
- 客户端侧也要保持身份连续。如果产品会在多步流程里自动选工具，加一条硬规则：发起流程的连接器，就是这个流程结束前唯一允许的连接器。
- 把路由决策写进日志，但别把凭证和确认码本身写进去。这次报告者能拿出详细日志，是整件事能被复现的关键。
- 给用户可见的切换提示。一个「本次操作由 XX 连接器处理」的界面提示，成本极低，能消掉大部分「我以为是同一个」的误解。
小结
技术问题本身不算惊悚：确认码走错了门，被服务端拦下来了，没有数据真的流出去。但它暴露的架构问题不小——agent 多步流程里的身份连续性，目前还主要靠「约定」而不是「强制」。MCP 生态正在快速铺开，连接器越装越多，这类身份漂移会越来越常见。
制度问题更值得一想。为了挡住 AI 生成的劣质报告，平台把身份验证推到了提交之前；结果是这位报告者没进官方流程，直接把细节发在公开论坛上。对厂商来说，这未必是想要的结果。用身份闸门过滤噪音，代价是把一部分真实信号也一起过滤掉了。
接下来值得留意的是 OpenAI 会不会给出官方回应，以及连接器匹配逻辑是否从「服务器地址」改成「OAuth 客户端」。在此之前，所有关于这件事的结论都只能建立在一位报告者的自述上——这一点比结论本身更重要。
想同时跑 Claude、ChatGPT 几家顶级模型的订阅、做横向对比？可以看看俱乐部的 Claude Max / ChatGPT Pro 拼车方案。
