ChatGPT Silently Switched Connectors in a Follow-Up Tool Call, and the Bounty Wanted an ID

A developer says ChatGPT quietly sent a follow-up tool call to the wrong connector. Both connectors pointed at the same MCP server. The server refused the call, so nothing was lost. But the report asks a fair question: who decides which connector handles a call, the user, the model, or the platform?

The report appeared on November 5, 2026, in a thread titled "Security: Follow-up tool call silently routed to a different connector" on the OpenAI Developer Community forum, posted by a user named AldiPower. It reached the front page of Hacker News with 43 points and 14 comments. This is one person's account. OpenAI has not confirmed it, and we have not reproduced it. This post separates what is claimed from what is checkable, and explains the protocol rules that apply.

TL;DR: claimed versus verified

Agents that act on your behalf need rules. See how explainx helps secure your agents →

What exactly did the report describe?

The author describes a setup with two connectors enabled in one conversation. Connector A was a custom connector created in developer mode. Connector B was the published app. Both pointed to the same MCP server URL.

Connector A showed a confirmation widget. After the user confirmed an action, the server produced a one-time code. The model then needed to make a follow-up call to complete the action.

Per the post, the model made that follow-up call through connector B, not connector A, and did not tell the user. The server checked the code, found it was bound to connector A's OAuth client, and rejected the request. Every attempt in that conversation failed the same way.

The author's core point is about consent. In their view, the switch moved a call from one app to another without the user agreeing. They argue that tool calls should be matched to a connector by its OAuth client, not by the MCP server URL. They also note that if the shared URL belonged to a third-party connector, the same behavior could pass data across apps.

That last step is a hypothesis. The post documents a failed call on the author's own server. It does not show data reaching a different party.

Why would two connectors share one server?

This happens in normal development. A developer builds an MCP server, tests it as a custom connector in developer mode, then publishes the same server as an app. During testing both entries may stay enabled. From the model's point of view, two tool lists look nearly identical, because they come from the same server.

The Model Context Protocol defines how a client talks to a server. It does not define how a chat product chooses between two connections that expose the same tools. That choice sits in the host application. So the question "which connector got this call?" is a product decision, not a protocol rule.

For readers new to the stack, our MCP explainer covers clients, servers and tools, and our MCP security guide covers the common failure modes.

What the MCP authorization spec already says

OAuth token handshake between client and server, the check behind ChatGPT connector routing

The report is useful because it shows the server-side control working. The MCP authorization specification treats the MCP server as an OAuth 2.1 resource server. It makes several rules that bear directly on this case:

• MCP clients must send the resource parameter, which names the server the token is for, in both authorization and token requests.
• MCP servers must validate that access tokens were issued specifically for them as the intended audience.
• MCP servers "MUST NOT accept or transit any other tokens."
• The spec describes the confused deputy problem, where a server acting as an intermediary is tricked into acting on authority it should not have.

Audience binding answers the question of which server a token is for. It does not answer a different question: which client of that server a pending action belongs to. In this report, the server went one step further than the spec requires. It tied a one-time confirmation code to the OAuth client that created it. That extra binding is what stopped the call.

This is a good pattern. It is also exactly why the author is uneasy. The protection worked because one developer chose to add it. Another server that only checks the user's token would have accepted the call from connector B.

What developers are saying

The Hacker News thread had little technical argument, but two comments are worth reading.

• simonw assumed the ID requirement was about sanctions compliance, since OpenAI cannot pay someone in a sanctioned country. He then pointed to Bugcrowd documentation that, as he quoted it, makes identity verification mandatory for researchers before submitting to managed bug bounty programs, and gives the reason as cutting high volumes of low-quality submissions. We tried to open that page and could not, so this is his report of the text.
• kristjansson argued the author overestimates what OpenAI and MCP can guarantee. If confirmation is a separate tool call, he wrote, there is no scoping or binding, and handing control back to the model hands it the whole decision.

The forum thread also has one reply from another user, techsoft.ye, who suggested binding confirmations to the originating connector, asking for user approval before a connector switch, and logging routing decisions. That echoes the author's own proposal.

The kristjansson comment is the sharpest. A confirmation widget is a user-interface step. The follow-up call is still a model decision. Unless the platform pins the second call to the first connector, the model is free to choose.

The bug bounty and the ID card

The author says they tried to report through OpenAI's bug bounty program and was asked for personal data, including biometric identification and an ID card. They refused and did not submit. The forum post is therefore the only public record.

This claim is checkable in part. OpenAI launched its bug bounty in April 2023 with Bugcrowd, according to TechTarget. We could not open OpenAI's own program page, which returned a 403 to our fetcher, so we cannot confirm the current verification steps. We also could not find a public OpenAI statement on the matter.

Why would a program require ID? Reasons that platforms commonly give include payment compliance and reducing low-quality submissions. The second reason matters more this year. Google froze its open source bounty over a flood of automated reports, as we covered in our Google OSS VRP freeze post. Stricter identity checks are one way platforms can respond to AI-generated spam.

The cost is that good-faith researchers who do not want to hand over biometric data may stay silent, or post publicly instead. That is the pattern in this case. OpenAI recently raised its critical bounty to $30,000 and has run a separate bio bug bounty. A higher payout helps little if the intake path turns reporters away.

We make no claim about whether this finding would qualify as a security bug. Some programs treat model behavior, such as which tool a model picks, as out of scope. That is a policy question for OpenAI.

Is this a vulnerability or a design gap?

Reasonable people can read it either way.

The vulnerability reading. A platform should never move a user's confirmed action to a different principal without telling them. If the follow-up call had gone to a connector with weaker server-side checks, a confirmed action might have run under the wrong identity or sent data to the wrong app.

The design-gap reading. Both connectors belonged to the same developer and shared one server. The call failed safely. The model chose a tool from a list that contained two near-identical entries, which is a quality problem in tool selection rather than an authorization bypass.

The truth likely sits between the two. The failure mode is real, and the outcome here was safe. The worst case depends on facts we do not have: how ChatGPT matches a follow-up call to a connector, and whether the user interface shows which connector ran each call.

How this connects to wider agent risk

Misrouted tool calls are one member of a larger family: an agent holding more authority than the user realizes. Related stories on explainx.ai include prompt injection against agentic workflows that exposed private repositories and our guide to indirect prompt injection. In each, the weak point is the same. The model is asked to make a decision that the surrounding system should have made.

For a survey of products that sit between the agent and its tools, see our comparison of AI agent security platforms.

What to do now

Access scopes for MCP connectors, limiting what each connector may do in ChatGPT

For people who build MCP servers:

1. Bind pending actions to the OAuth client. Store the client ID with every confirmation code, and reject use from any other client. This is the control that worked in this report.
2. Validate token audience on every request. The MCP spec requires it. Do not forward tokens you received to other services.
3. Make confirmations single use and short lived. A code that expires in minutes limits the window for misuse.
4. Log the client ID and connector for each call. If a routing problem happens, you want to see it in your own logs rather than learn about it from a user.
5. Remove duplicates in testing. Disable the developer-mode connector before testing the published app, and the reverse.

For people who use connectors:

1. Check which connectors are enabled before a conversation that touches sensitive systems.
2. Avoid enabling two connectors that point at the same service in one chat.
3. Read the tool-call details when a confirmation fails. A failed call may show which connector tried it.

For teams that run coding agents and tool-calling agents at scale, a runtime layer that watches and blocks risky actions adds a second check. AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions.

What would settle the questions

Three things would turn this report into a verified finding or close it:

• An OpenAI statement on how ChatGPT chooses among connectors that expose the same server, and whether it shows the user which one ran.
• An independent reproduction with logs, preferably with two connectors from different developers pointing at the same URL.
• A clear public statement of what the bug bounty requires from researchers, and which categories of tool-routing issues it accepts.

We will update this post if OpenAI responds or someone reproduces the behavior.

Key takeaways

• One developer reports a silent connector switch on a follow-up call in ChatGPT. It is unconfirmed and unreproduced.
• The server blocked the call because its code was bound to the OAuth client. No data loss is described.
• The MCP spec requires audience validation, but client-level binding of pending actions is the server's choice.
• The bounty ID requirement is the author's report, partly echoed by a Hacker News commenter about Bugcrowd. We could not verify the current terms.
• Builders should bind confirmations to the client. Users should avoid duplicate connectors on one server.

Related reading

• What is the Model Context Protocol? A complete guide
• MCP security guide 2026
• Indirect prompt injection against AI agents
• AI agent security platforms compared
• OpenAI raises bug bounties to $30,000
• Google freezes its open source bug bounty over AI slop
• GitLost: prompt injection in agentic workflows

Details are accurate as of November 7, 2026. The forum report is unconfirmed and may change.