ChatGPT enruta llamadas a otro conector MCP sin avisar

Un código de confirmación que salió por el conector equivocado

Dos conectores, un mismo servidor MCP y un código de confirmación de un solo uso que terminó en la app equivocada. Así describe un reporte publicado en el foro de desarrolladores de OpenAI un fallo de diseño en ChatGPT: el modelo inició un flujo con un conector, el usuario confirmó la acción en el widget de ese conector, y la llamada de seguimiento salió por otro conector distinto sin ningún aviso en pantalla.

Para cualquier founder que ya conectó su CRM, su base de datos o su pasarela de pagos a un asistente de IA, la pregunta es concreta: si el asistente puede mover datos de una app a otra sin autorización, el modelo de permisos que asumiste al aceptar el consentimiento de OAuth no se sostiene.

MCP (Model Context Protocol) es el estándar abierto que permite a un asistente de IA llamar herramientas y datos externos a través de una interfaz común. Cada conector es una app con su propia concesión OAuth, y esa distinción es el corazón del problema.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Qué pasó exactamente en el flujo

El montaje del reporte es mínimo: una sola cuenta de ChatGPT con dos conectores habilitados que apuntan al mismo servidor MCP. El conector A es un conector personalizado agregado en modo desarrollador; el conector B es la app publicada en el directorio de apps. Cada uno tiene su propio cliente OAuth, así que el servidor ve dos clientes separados para el mismo usuario.

El flujo, paso a paso:

El usuario pide una acción que requiere confirmación.
El modelo llama a la herramienta de confirmación a través del conector A. El widget de MCP Apps muestra el cambio, el usuario confirma y el widget envía un código de confirmación de un solo uso a la conversación mediante ui/message.
El modelo hace la llamada de seguimiento con ese código, pero la enruta en silencio por el conector B.

El servidor rechazó la llamada porque el código estaba atado al cliente OAuth del conector A. Todos los intentos de esa conversación fallaron. En el intento que el autor registró en detalle, el código se confirmó por el conector A y se canjeó por el conector B. Nada le indicó al usuario que la llamada de seguimiento había ido a otro conector.

Por qué es un problema de consentimiento y no un detalle cosmético

El usuario arranca el flujo en el conector A y confirma en el widget del conector A. La llamada siguiente va al conector B y lleva un valor producido en el widget del conector A. Como los conectores son apps separadas con concesiones OAuth separadas, ese cambio silencioso pasa datos de una app a otra sin el consentimiento del usuario.

En este caso ambos conectores venían del mismo proveedor y el binding del lado del servidor fue lo que frenó la llamada. El propio autor advierte que, con un conector de terceros habilitado en la misma conversación, espera el mismo salto silencioso transportando datos de una app a otro proveedor si la URL del servidor MCP es compartida. Es una expectativa del reporte, no un caso confirmado.

El límite es el cliente OAuth, no la URL del servidor

La conclusión técnica del reporte es la parte que más debería interesar a quien construye integraciones: una URL MCP compartida no alcanza para tratar dos conectores como uno solo. Detrás de la misma URL, un servidor puede actuar para partes distintas según el cliente OAuth, por ejemplo tenants separados, socios o entornos diferentes.

El comportamiento esperado, según el reporte: las llamadas se emparejan con un conector por su cliente OAuth y no por la URL del servidor MCP, y una llamada de seguimiento sale por el mismo conector y el mismo cliente OAuth que inició el flujo.

Qué exige hoy la documentación de OpenAI

La guía de autenticación para plugins de OpenAI exige un flujo OAuth 2.1 conforme a la especificación de autorización de MCP: metadata del recurso protegido, metadata OAuth publicada por el servidor de autorización, PKCE con S256 y el parámetro resource replicado a lo largo de todo el flujo para que el token quede atado al servidor que lo va a consumir.

La misma documentación indica que el servidor MCP debe verificar firma, emisor, audiencia, expiración y scopes en cada request, y que esa responsabilidad es del servidor, no de ChatGPT. Para el caso de múltiples cuentas, agrega que OpenAI enruta cada llamada usando las credenciales autenticadas de la conexión seleccionada. El reporte del foro describe un escenario distinto, varios conectores en lugar de varias cuentas, donde esa garantía no se cumplió.

MCP ya es infraestructura crítica: el contexto de seguridad

Vale dimensionar sobre qué se está discutiendo. Según TechTimes, MCP fue presentado por Anthropic en noviembre de 2024 y donado a la Agentic AI Foundation de la Linux Foundation en diciembre de 2025. Sus descargas mensuales de SDK pasaron de unas 100.000 al lanzamiento a 97 millones en marzo de 2026, según el mismo medio.

Ese crecimiento explica por qué la seguridad de MCP dejó de ser un tema de nicho:

Una alerta de la NSA publicada en mayo de 2026 documentó CVE-2025-49596, una vulnerabilidad de ejecución remota de código en la cadena de herramientas MCP-Inspector, y describió el envenenamiento semántico de herramientas como sistémico y no aislado, según el reporte de TechTimes sobre riesgos en la cadena de suministro de MCP.
El OWASP Top 10 for Agentic Applications 2026 clasifica la inyección de prompts como la amenaza principal para aplicaciones basadas en LLM.
Ars Technica reportó la vulnerabilidad BadHost (CVE-2026-48710) en Starlette, un framework con 325 millones de descargas semanales, que alcanza a servidores MCP, vLLM y LiteLLM. La falla fue corregida en Starlette 1.0.1.

Del lado de las plataformas, la tendencia va justo en la dirección que pide el reporte. TechTimes detalla que el servidor MCP de Snapchat Ads, lanzado el 3 de agosto de 2026, asigna a cada agente de IA su propio client ID de OAuth, con identificadores como claude-snap-ads o chatgpt-snap-ads, de modo que cada agente se autoriza, audita y revoca por separado. Es exactamente el modelo de frontera por cliente OAuth que el reporte reclama.

En paralelo aparecen capas de gobierno para empresas: Help Net Security reportó en junio de 2026 el lanzamiento de WitnessAI Agentic Control, un plano de control único para descubrir qué agentes operan, a qué servidores MCP y herramientas llegan y con qué permisos.

Qué significa esto para tu startup

Si construyes un servidor MCP o una app para ChatGPT, este reporte te da una lista de tareas concreta. Si solo eres usuario, te da una advertencia de higiene operativa.

Ata los códigos de confirmación al cliente OAuth, no a la URL. Si tu servidor emite códigos de un solo uso, registra en qué cliente se emitieron y rechaza el canje desde otro. El binding del lado del servidor es lo único que detuvo el caso reportado.
Trata cada conector como un tenant separado. Dos conectores sobre la misma URL pueden representar clientes, entornos o socios distintos. No los agrupes por URL en tu lógica de permisos ni en tus logs.
Registra quién confirma y quién canjea. El autor pudo reconstruir el caso porque tenía trazabilidad del lado del servidor. Sin esos logs, un salto silencioso es invisible hasta que algo falla en producción.
Audita qué conectores conviven en una misma conversación. Si tienes un conector con acceso a datos sensibles, no lo mezcles con conectores de terceros en el mismo hilo mientras el comportamiento no esté resuelto.
Pide autorización por agente en tu próximo vendor review. El modelo de client ID por agente que ya usan plataformas como Snapchat permite revocar un agente sin tocar los demás. Es la pregunta correcta para hacerle a cualquier proveedor que te venda una integración de IA.

¿Es un fallo de ChatGPT o de los conectores?

El reporte lo plantea como un problema de emparejamiento del lado del host: la llamada de seguimiento debería resolverse contra el mismo conector y el mismo cliente OAuth que inició el flujo, y no lo hizo. El servidor MCP actuó correctamente al rechazar el canje, porque el código pertenecía a otro cliente.

La lección para quien construye es incómoda pero útil: no puedes delegar esta frontera solo al servidor. El host que orquesta los conectores también tiene que respetarla, y si no lo hace, tu única defensa es la validación estricta del lado del servidor.

Conclusión

El caso reportado no filtró datos porque el servidor rechazó la llamada, pero expone un supuesto que muchos equipos dan por sentado: que un conector es una frontera de permisos y que el asistente la respeta. El reporte muestra que, al menos en este flujo, la frontera se cruzó en silencio.

Para un founder, la lectura práctica es doble. Si vendes integraciones, la validación por cliente OAuth y la trazabilidad de cada canje son parte del producto, no un extra de seguridad. Si consumes integraciones, revisa qué conectores tienes habilitados al mismo tiempo y con qué permisos, y exige a tus proveedores autorización y revocación por agente. La comodidad de conectar todo a un mismo asistente tiene un costo que conviene conocer antes de que lo descubra un incidente.