ChatGPT silently swaps connectors mid-flow, carrying data across separate OAuth clients

What happened

A developer has published a reproducible case in which ChatGPT silently routed a follow-up tool call through a different connector than the one that started the flow, without telling the user. The report appeared on the OpenAI community forum under the title "Security: Follow-up tool call silently routed to a different connector," posted by a user going by AldiPower, and surfaced via Hacker News on November 5, 2026.

The setup used one ChatGPT account with two connectors enabled against the same MCP server. Connector A was a custom connector added in developer mode; Connector B was the published app from the app directory. Crucially, each connector has its own OAuth client, so the server sees two separate clients for the same user.

According to the report, the flow went like this: the user asked for an action that needed confirmation, and the model called a confirmation tool through Connector A. Connector A's MCP Apps widget showed the change, the user confirmed, and the widget sent a one-time confirmation code into the conversation. The model then made the follow-up call carrying that code — but through Connector B. The server rejected every attempt, because the code was bound to Connector A's OAuth client. In the attempt logged in detail, the code was confirmed through Connector A and redeemed through Connector B, and nothing told the user that the follow-up call had switched connectors.

Why the silent switch matters

Connectors are separate apps with separate OAuth grants. A follow-up call that leaves Connector A carrying a value produced in Connector A's widget therefore moves data from one app to another without the user's consent, even though the user never chose Connector B.

In this case both connectors came from the same provider, and the server-side binding stopped the call. But the reporter warns that with a third-party connector enabled in the same conversation and sharing the same server URL, the same silent switch would pass one app's data to another provider.

The report's core argument is that a shared MCP URL is not enough to treat two connectors as one. Behind the same URL, a server can act for different parties depending on the OAuth client — for example separate tenants, partners or environments. The real boundary is the connector with its own OAuth client, not the URL. The expected behaviour, per the report, is that tool calls are matched to a connector by its OAuth client, and a follow-up call goes through the same connector that started the flow.

The suggested fixes

A reply in the thread, which points to OpenAI's MCP authentication documentation, acknowledged the distinction between tool selection and authorization continuity. It noted that the server-side protection appears to have worked, but that the rejection does not remove the underlying concern about silent routing.

The measures it suggests include binding pending operations and confirmations to the originating connector and its verified OAuth grant, preventing automatic connector switching during confirmation or execution, requiring explicit user approval if a switch becomes necessary, validating short-lived confirmation codes against the intended operation, client identity and authorization context, and recording connector-routing decisions in diagnostic traces. The reply also frames the responsibility split: the MCP server must enforce authorization, while the client-side orchestration layer must preserve the connector selected for the workflow.

A disclosure process that asks for an ID card

The reporter says they attempted to disclose the issue through OpenAI's bug bounty program, but were asked to hand over personal data — including an ID card and biometric identification, to a third party they knew nothing about — before they could submit the report. They declined, which is why the finding currently sits in a public forum thread rather than a coordinated disclosure.

Why it matters

• This is an architectural question for any agent that orchestrates multiple tools: routing by endpoint or tool name can cross authorization boundaries that are defined per OAuth client.
• The failure stayed benign only because the reporter's own server bound confirmation codes to a specific client. Servers without that binding have no backstop.
• As more connectors from different providers share a single conversation, silent cross-connector routing becomes a data-flow privacy issue, not merely a correctness bug.
• And if bounty intake requires identity verification up front, researchers unwilling to provide it are effectively pushed toward public disclosure — which is exactly what happened here.