Один вход может охватить больше, чем одно разрешение
Общие подключения сервисов появляются в Copilot. При переносимом входе нужно сохранить границы конкретных действий.
Общие подключения сервисов появляются в Copilot. При переносимом входе нужно сохранить границы конкретных действий.
Что изменилось
28 октября GitHub объявил публичное preview GitHub-verified MCP servers, или connectors. Подключенный сервис должен работать в приложении Copilot, CLI, VS Code, облачном Copilot и GitHub Mobile. Я прочитал объявление и документацию GitHub MCP Server 1 ноября. Это разбор источников, не испытание клиентов и не подтверждение доступности функции в каждом аккаунте.
Где теперь проверять доступ
Названы 26 стартовых сервисов, включая Slack, Figma, Notion, Sentry, Linear и Atlassian Rovo. GitHub описывает единое подключение и фоновое поддержание входа. Мой вывод: новая форма входа больше не будет напоминать о каждой новой точке доступа. Команде нужен список клиентов, сервисов и разрешенных операций. История ввода пароля не показывает текущую область доступа.
Условия preview
По объявлению rollout охватывает все планы Copilot. Для Business и Enterprise администратор должен включить Editor preview features. Управляемый MCP allowlist требует добавления проверенных серверов. Сам сервис тоже может требовать одобрение администратора, например Slack MCP. Это условия поставщика, не проверка конкретной организации. Пост не описывает полностью хранение данных и отзыв доступа для каждого сервиса.
Три разных решения
Отдельный README GitHub MCP Server описывает наборы инструментов, отдельные инструменты и read-only режим, исключающий запись даже при явном выборе write-инструмента. Нельзя переносить эти переключатели на любой managed connector. Наличие инструмента также не означает согласие человека опубликовать комментарий или изменить репозиторий. Я бы отдельно записывал подключение, конфигурацию и одобрение конкретного действия.
Предложенный тест
В разрешенном временном репозитории с вымышленными issues сначала прочитать данные одним клиентом, затем открыть второй. Попросить предложить комментарий без публикации. Проверить отказ записи и честное сообщение при потере подключения. Затем отозвать доступ документированным способом и проверить нужные клиенты. Это план, не выполненный эксперимент; время распространения отзыва не установлено.
Сохранить наблюдение
Для каждого шага нужны клиент и версия, сервис, метка аккаунта, права, операция, точная цель и фактический результат. Отказ сервера отличается от решения помощника не вызывать инструмент. Важно время отзыва и следующей попытки. Скриншот настроек не доказывает прекращение доступа везде. JSON ниже является примером незаполненной записи, а не работающим контролем.
{"trial":"proposed_not_run","service":"example","client":"PIN_VERSION","operation":"draft_comment","target":"synthetic_issue","write_approved":false,"revoked_at":null,"observed_result":null}Критерий пользы
Мне важно облегчить поиск контекста, сохранив ясность его источника и границ записи. Сможет ли администратор сузить доступ? Понятно ли, почему комментарий остался черновиком? Код GitHub MCP Server имеет MIT LICENSE, но эта лицензия не определяет условия облачного сервиса, стоимость или права аккаунта. Я ничего не подключал для статьи.