Overview
A developer-reported security issue in ChatGPT’s connector framework reveals that the model can silently switch which OAuth connector handles follow-up tool calls within a single multi-step workflow. Reported to OpenAI’s developer community forum on 5 November 2026, the finding shows that a one-time confirmation code generated by Connector A’s widget was subsequently submitted by the model through Connector B — a different app with a separate OAuth client — without any user notification.
While the specific test case was caught by server-side token binding, the broader architectural concern is significant: in the absence of strict server-side controls, sensitive artefacts generated within one application’s authorisation context can be silently exfiltrated to a different provider.
Technical Analysis
The setup involved a single ChatGPT account with two connectors enabled, both pointing to the same MCP server but registered under separate OAuth clients:
- Connector A: Custom developer-mode connector (OAuth Client A)
- Connector B: Published app from the app directory (OAuth Client B)
Attack flow:
- User initiates an action requiring confirmation. ChatGPT invokes a confirmation tool via Connector A.
- Connector A’s MCP Apps widget presents the confirmation UI. User approves, and a one-time code is injected into the conversation via
ui/message. - ChatGPT makes the follow-up tool call using the code — but routes it through Connector B instead of Connector A.
- The server rejects the call because the code is cryptographically bound to Connector A’s OAuth client.
The root cause is that ChatGPT appears to select connectors for tool calls based on MCP server URL or tool name matching rather than preserving the OAuth client identity that initiated the workflow. This means the conversation’s shared context — including sensitive tokens or codes — is accessible to any connector resolving to the same endpoint.
The reporter correctly notes that a shared MCP URL is not a sufficient boundary: the same URL can serve distinct tenants, partners, or environments depending on the OAuth client presented.
Framework Mapping
- AML.T0086 (Exfiltration via AI Agent Tool Invocation): The model inadvertently passes a credential artefact from one app’s context to another via tool call routing.
- AML.T0083 (Credentials from AI Agent Configuration): Confirmation codes function as short-lived credentials; their cross-connector transit is analogous to credential harvesting.
- LLM07 (Insecure Plugin Design): The connector framework lacks authorisation continuity enforcement across multi-step tool workflows.
- LLM08 (Excessive Agency): The model autonomously switches authorisation contexts without user awareness or consent.
Impact Assessment
The immediate blast radius is limited to scenarios where multiple connectors share an MCP server URL. However, the implied threat is broader: if a malicious or compromised third-party connector is active in the same conversation and shares a server endpoint, it could silently receive sensitive data intended for a different provider. Enterprises using multi-tenant MCP deployments and developers building confirmation-gated workflows are most exposed.
Mitigation & Recommendations
- Bind workflow state to OAuth client identity: Servers should cryptographically tie confirmation tokens to the originating OAuth client and reject cross-client redemption attempts.
- Enforce connector continuity at the platform level: OpenAI should propagate the originating connector’s OAuth client through all steps of a multi-step tool workflow.
- Audit connector combinations: Developers should review all connector pairs in production that share MCP server URLs but use separate OAuth credentials.
- Alert users on connector switches: ChatGPT should surface any mid-flow connector switch as an explicit user notification requiring re-confirmation.