ChatGPT silently passes data between connectors, bounty wants ID

A researcher has reported that ChatGPT, during a conversation with two connectors enabled, made a follow-up tool call through a different connector from the one that began the flow, without telling the user, while carrying a one-time confirmation code produced by the first connector. The case matters because connectors are separate apps with separate OAuth grants, so a silent switch can move data from one app to another without consent, even when a server-side check stops the particular call.

The report was posted on 5 November 2026 in the OpenAI Developer Community by AldiPower and was carried on the Hacker News front page on 6 November 2026. A reply on 6 November from techsoft.ye treated it as an important distinction between choosing a tool and preserving authorisation across a multi-step workflow. AldiPower then added a separate dispute about disclosure, saying he tried to use OpenAI's bug bounty programme but was asked for personal data, including biometric identification and an ID card, before he could submit a report, and that he was not willing to provide it.

What happened in the ChatGPT conversation?

According to AldiPower, the setup involved one ChatGPT account with two connectors enabled that pointed to the same MCP server. Connector A was a custom connector added in developer mode. Connector B was the published app from the app directory. Each connector had its own OAuth client, so the server saw two separate clients for the same user.

The steps, as described in the OpenAI Developer Community thread, were as follows. In a conversation with both connectors enabled, the user asked for an action that needed confirmation. The model called a confirmation tool through Connector A, and its MCP Apps widget displayed the change. The user confirmed, and the widget sent a one-time confirmation code into the conversation through ui/message. The model then made the follow-up call using that code, but through Connector B instead of Connector A.

AldiPower says the server rejected the call because the code was tied to Connector A's OAuth client. Every attempt in that conversation failed. In the attempt logged in detail, the code was confirmed through Connector A and redeemed through Connector B. The user was not informed that the follow-up call had gone to another connector.

That sequence is the core of the report. The flow started in one connector, the user confirmed in that connector's widget, and the next step was attempted in a different connector while carrying a value created in the first widget. No notice of the switch was shown to the user, according to the report.

Why does switching connectors matter?

The concern is not simply that a call failed. It is that data produced in one app's context appeared in another app's context without the user knowing. Connectors, in this account, are not interchangeable labels for the same endpoint. They are separate apps with separate OAuth grants. When a follow-up call moves from one to the other, a value from the first app crosses an authorisation boundary.

AldiPower notes that in this test both connectors came from the same provider and pointed to the same server, so server-side binding stopped the call. He argues that, with a third-party connector enabled in the same conversation, the same silent switch could pass one app's data to another provider if the server URL is shared. That is presented as an expectation based on the mechanism, not as a demonstrated transfer to a third party in the logged attempt.

The underlying point is about identity. A shared MCP URL does not, in his argument, make two connectors the same. Behind one URL, a server can act for different parties depending on the OAuth client, for example separate tenants, partners or environments. The relevant boundary is therefore the connector and its OAuth client, not the URL alone.

For users, the practical risk is invisibility. A confirmation in a widget can look like approval for a single, continuous operation. If the system then routes the next step elsewhere, the user has no visible cue that the context has changed. For developers, the risk is that tool selection based on endpoint or tool name may not preserve the authorisation context that the user actually approved.

What did the server do, and what did it not do?

In the logged case, the server did one thing clearly: it rejected the redemption because the code was bound to Connector A's OAuth client. Techsoft.ye, in the reply, said that protection appears to have worked. That distinction matters, because the report is not claiming that the code was accepted by the wrong connector in this instance.

What the server did not do, on this account, is prevent the routing decision itself. The follow-up call was still attempted through Connector B. The failure happened at redemption, after the switch. AldiPower's expected behaviour is therefore about the client-side orchestration as well as the server: tool calls should be matched to a connector by its OAuth client, not by the MCP server URL, and a follow-up call should go through the same connector and OAuth client that started the flow.

Techsoft.ye framed the same issue as a broader architectural requirement. A multi-step tool workflow, the reply argues, should preserve the identity of the connector and its authorisation context throughout the operation, rather than relying only on the MCP endpoint or tool name. The reply also asked whether traces showed the connector identity changing during confirmation handling or only when the model selected the follow-up tool call, a question that would help narrow down the root cause.

No response from OpenAI beyond the community reply quoted in the thread is included in the retrieved material. The thread does not establish whether the behaviour has been fixed, whether it affects other setups, or how widespread it is. Readers should treat the case as a documented, reproducible report from one user, not as a confirmed statement of current behaviour for all ChatGPT connector use.

What should happen instead?

AldiPower's expected behaviour is straightforward: a follow-up call should stay with the connector and OAuth client that started the flow. Techsoft.ye proposed a set of safeguards that follow from that principle. Pending operations and confirmations should be bound to the originating connector and its verified OAuth grant. Automatic connector switching during confirmation or execution should be prevented. If changing the connector becomes necessary, explicit user approval should be required. Short-lived confirmation codes should be validated against the intended operation, client identity and authorisation context on the server. Connector-routing decisions should be recorded in diagnostic traces, without exposing credentials or sensitive confirmation values.

The reply also separated responsibilities. The MCP server must enforce authorisation, but the client-side orchestration layer should preserve the connector selected for the workflow. In other words, server rejection is a safety net, not a substitute for keeping the workflow in the context the user approved.

Techsoft.ye encouraged submitting the technical evidence through OpenAI's coordinated vulnerability disclosure process, and linked to OpenAI documentation on MCP authentication and coordinated vulnerability disclosure. That suggestion sits alongside AldiPower's later comment about the bug bounty programme, which raises a different question about how researchers are asked to disclose issues that may involve an authorisation boundary.

Why is the bug bounty dispute part of the story?

AldiPower said he tried to disclose the issue through the bug bounty programme, but that he was required to give personal data, such as biometric identification and an ID card, up front, even to another party he had nothing to do with, before he could submit the report. He said that was nothing he was willing to do.

That comment does not change the technical claim, but it affects how the claim can be investigated. If a researcher declines to submit through a formal channel, the public record may remain a community thread rather than a tracked disclosure. Techsoft.ye's suggestion to use coordinated vulnerability disclosure was made before AldiPower's comment about the bounty requirements, so the thread leaves an unresolved tension: the technical evidence is public, the recommended disclosure route was named, and the reporter says he did not use the bounty route because of the identity requirements.

For other researchers, the lesson is procedural as well as technical. Before testing connector flows that involve confirmation codes, it is worth checking what a disclosure programme requires, what evidence can be submitted without exposing sensitive values, and whether diagnostic traces can be shared safely. For users, it is a reminder that public bug reports may be incomplete by design, especially where personal data, credentials or confirmation values are involved.

How can readers explore this with Grafy?

There is no direct Grafy equivalent of ChatGPT's connector and MCP Apps widget flow in the apps listed for this desk, so Grafy does not offer a like-for-like test of that routing behaviour. A constructive way to explore the underlying topic is to use Grafy Reader to read and question the OpenAI Developer Community thread and related documentation side by side, checking exactly what was claimed, what was rejected by the server, and what remains unproven. Readers can also use Grafy Chat to compare how different models explain connector identity, OAuth binding and multi-step tool workflows, and to draft questions for a disclosure report without including credentials or confirmation values.

Developers who want to work through the design problem can use Grafy Code to sketch a small state machine for a multi-step workflow: bind a pending operation to a connector ID and OAuth client, reject a follow-up if either changes, require explicit approval for a switch, and log routing decisions without sensitive values. That exercise does not replicate ChatGPT's behaviour, but it makes the principle in the report testable in your own system.

The Grafy News Desk view is that the most durable takeaway is a design rule, not a single failed call. Keep the authorisation context with the operation from start to finish, treat a shared URL as insufficient evidence of sameness, and make any change of connector visible and approved. Server-side rejection helped in this case, according to the report, but the silent switch is the part that needs fixing.

Frequently asked questions

Did the server accept the confirmation code when it was redeemed through the other connector?

No. According to AldiPower, the server rejected the call because the one-time code was bound to Connector A's OAuth client. Every attempt in that conversation failed, including the logged attempt where the code was confirmed through Connector A and redeemed through Connector B.

Does a shared MCP server URL mean two connectors are the same?

No. AldiPower argues that a shared 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, such as separate tenants, partners or environments. The boundary is the connector, not the URL.

Did the reporter submit a report through OpenAI's bug bounty program?

No. AldiPower said he tried to disclose the issue through the bug bounty program, but declined to provide personal data such as biometric identification and an ID card up front, before he could submit the report. He said that was nothing he was willing to do.

Source: OpenAI Developer Community thread, via Hacker News front page

---

Source: Hacker News — front page — ChatGPT silently passes data between connectors and the bounty wants an ID card