ChatGPT quietly switched connectors mid-flow, and only the server noticed
An MCP developer caught ChatGPT crossing an app boundary without telling anyone. The report, posted Nov 5 on the OpenAI developer forum and picked up by Hacker News Friday night, describes a follow-up tool call that went out through a different connector from the one that started the flow.
The setup: one ChatGPT account, two connectors pointing at the same MCP server, each with its own OAuth client. The user asks for an action that needs confirmation. The model calls the confirmation tool through connector A, A's widget shows the change, the user confirms, and the widget passes a one-time code back into the conversation. Then the model makes the follow-up call with that code through connector B. Nobody told the user. The developer's server rejected it, because the code was bound to A's OAuth client, and every attempt in that conversation failed.
So nothing leaked here. The worry is the next case. Both connectors came from the same company, so its own check caught the switch. With a third-party connector behind a shared URL in the same conversation, the reporter expects the same silent switch to hand one app's data to another provider. Their proposed rule is clean: match tool calls to a connector by OAuth client, not by server URL, and keep follow-ups on the connector that started the flow. We found no OpenAI response in the thread. The HN headline also mentions a bug bounty asking for an ID card; we couldn't read that part of the thread, so treat it as unverified.
What MCP builders should take from it: never trust the client to route correctly. Bind every confirmation code, pending operation and token to the exact OAuth client that minted it, and reject anything else. This developer did that and turned a cross-app leak into a failed call. The model decides which tool to call, and models pick by name and description, not by who you granted consent to. The boundary has to live on your server.
Thread: https://community.openai.com/t/security-follow-up-tool-call-silently-routed-to-a-different-connector/1413053
← Back to all articles
The setup: one ChatGPT account, two connectors pointing at the same MCP server, each with its own OAuth client. The user asks for an action that needs confirmation. The model calls the confirmation tool through connector A, A's widget shows the change, the user confirms, and the widget passes a one-time code back into the conversation. Then the model makes the follow-up call with that code through connector B. Nobody told the user. The developer's server rejected it, because the code was bound to A's OAuth client, and every attempt in that conversation failed.
So nothing leaked here. The worry is the next case. Both connectors came from the same company, so its own check caught the switch. With a third-party connector behind a shared URL in the same conversation, the reporter expects the same silent switch to hand one app's data to another provider. Their proposed rule is clean: match tool calls to a connector by OAuth client, not by server URL, and keep follow-ups on the connector that started the flow. We found no OpenAI response in the thread. The HN headline also mentions a bug bounty asking for an ID card; we couldn't read that part of the thread, so treat it as unverified.
What MCP builders should take from it: never trust the client to route correctly. Bind every confirmation code, pending operation and token to the exact OAuth client that minted it, and reject anything else. This developer did that and turned a cross-app leak into a failed call. The model decides which tool to call, and models pick by name and description, not by who you granted consent to. The boundary has to live on your server.
Thread: https://community.openai.com/t/security-follow-up-tool-call-silently-routed-to-a-different-connector/1413053
Comments