В сообществе OpenAI опубликован отчёт о неожиданной маршрутизации tool calls в ChatGPT. По словам автора, в разговоре с двумя включёнными connectors модель начала операцию через один из них, а продолжила через другой, не сообщив пользователю о переключении. При этом во второй вызов попал одноразовый код подтверждения, созданный виджетом первого connector.
В эксперименте оба connector указывали на один MCP-сервер, но имели разные OAuth-клиенты. Первый был пользовательским connector в developer mode, второй — опубликованным приложением из каталога. После подтверждения действия через интерфейс первого приложения модель отправила код через второй. Сервер отклонил операцию, поскольку код был привязан к исходному OAuth-клиенту. Все повторные попытки в том разговоре завершались так же.
Автор считает проблемой не сам отказ, а скрытое изменение границы авторизации. Совпадение URL MCP-сервера не означает, что два приложения образуют единый доверенный контекст: за одним адресом могут работать разные арендаторы, партнёры или окружения. В описанном эксперименте привязка кода на сервере предотвратила выполнение. Однако автор предполагает, что при другой конфигурации данные одного приложения могли бы попасть стороннему провайдеру. Это ожидание, а не продемонстрированный в отчёте результат.
Ожидаемое поведение, по мнению автора, — сохранять исходный connector и OAuth-контекст на протяжении всей многошаговой операции. В обсуждении дополнительно предлагается запрещать автоматическое переключение во время подтверждения, требовать явного согласия на смену приложения и записывать решения маршрутизации в диагностические журналы без учётных данных и кодов. Проверка авторизации должна оставаться обязанностью сервера, а клиентская оркестровка — сохранять выбранный connector.
Автор также сообщил, что попытался передать сведения через bug bounty OpenAI, но не стал продолжать из-за требования заранее предоставить персональные данные, удостоверение личности и биометрическую идентификацию стороннему сервису. В исходном материале нет ответа OpenAI с подтверждением ошибки или оценкой её уязвимости, поэтому это следует считать публичным пользовательским отчётом, а не официально подтверждённой проблемой.