MCP в компании: три точки контроля

сверено с первичными источниками 4 октября 2026

Каждая строка таблицы и каждый абзац с утверждением несут одну метку. Она показывает, откуда взято утверждение и какой у него вес.

Метка	Название	Что это	Источник
A	механизм протокола	правило спецификации MCP редакции 2026-07-28	текст спецификации
B	официальная рекомендация	официальные материалы MCP вне основной спецификации: расширения, рекомендации по безопасности, документация реестра, план развития, блог, уставы групп	modelcontextprotocol.io и официальные репозитории
C	схема этого сайта	наш способ разложить тему по полкам	эта страница
D	реализация поставщика	настройка или функция конкретного продукта	документация самого поставщика

Слова «обязан», «не должен», «следует» встречаются только в строках A и B и передают силу источника: MUST, MUST NOT, SHOULD. В строках C их нет: схема сайта ничего не предписывает. В строках D описано, что делает продукт по словам его поставщика.

[C] Запрос к серверу MCP проходит через три места, где компания способна на него повлиять. Это модель сайта, спецификация MCP её не содержит.

Точка контроля	Вопрос, на который она отвечает	Метка
1. Политика клиента	какие серверы сотрудник вообще подключит в своей программе	C
2. Шлюз	что проходит между клиентом и сервером, кто это видит и записывает	C
3. Поставщик удостоверений	кому и для какого сервера выдаётся токен	C

[C] Вокруг трёх точек лежат ещё пять тем: частные реестры, списки разрешённых серверов, аудит, учётные данные и согласование вызовов. Ниже каждая разобрана по тем же меткам.

Подробный разбор - на страницах «Авторизация» и «Безопасность сервера». Здесь только то, что важно для трёх точек контроля.

Что	Сила и формулировка	Источник	Метка
авторизация	необязательна для реализаций MCP (OPTIONAL); защищённый сервер MCP выступает как сервер ресурсов OAuth 2.1	Authorization	A
сведения о защищённом ресурсе	сервер обязан реализовать OAuth 2.0 Protected Resource Metadata (RFC 9728)	Authorization	A
указание ресурса	клиент обязан реализовать Resource Indicators (RFC 8707)	Authorization	A
привязка токена к серверу	сервер обязан проверять, что токен доступа выдан именно ему как получателю	Authorization	A
чужие токены	клиент не должен отправлять серверу токены, выданные не сервером авторизации этого сервера; сервер не должен принимать или передавать дальше другие токены	Authorization	A
запрет сквозной передачи	сервер не должен передавать во внешний API токен, полученный от клиента MCP; для внешнего API берётся отдельный токен	Security Considerations	A
согласие на посреднике	посредник («MCP proxy server») со статическим идентификатором клиента обязан получить согласие пользователя для каждого динамически зарегистрированного клиента до перехода к стороннему серверу авторизации	Security Considerations	A
заголовки для посредников	Mcp-Method и Mcp-Name обязательны (REQUIRED); они повторяют поля тела запроса, чтобы посредник маршрутизировал и проверял запрос, не разбирая тело	Streamable HTTP	A
cacheScope	при значении public любой клиент, общий шлюз или кэширующий посредник может хранить ответ и отдавать его любому пользователю	Caching	A
аудит	клиенту следует вести журнал использования инструментов для целей аудита	Tools	A
роль хоста	хост управляет разрешениями на подключение клиентов и применяет политики безопасности и требования согласия	Architecture	A

[A] Про аудит в спецификации есть одно положение - строка из таблицы выше, с силой SHOULD и обращённая к клиенту. Формата журнала и отдельной возможности для аудита спецификация не описывает: поиск слова «audit» по разделам архитектуры, основ, клиента и сервера в редакции 2026-07-28 (коммит 75db1e9) даёт одно это место.

[B] Рекомендации по безопасности объясняют, чем сквозная передача мешает расследованиям: сервер не различает клиентов, если они приходят с токеном, выданным внешней системой, и это затрудняет разбор происшествий и аудит. Там же сказано, что сервер не должен принимать токены, которые не были выданы явно для него.

Свойство	Значение	Источник	Метка
что это	официальное расширение: организация управляет доступом к серверам MCP через свой поставщик удостоверений	страница расширения	B
идентификатор	io.modelcontextprotocol/enterprise-managed-authorization	страница расширения	B
место	вне основной спецификации, в репозитории ext-auth	ext-auth	B
состояние	Stable; объявлено стабильным 2026-06-18	ext-auth, официальный блог	B
SEP	SEP-990, состояние Final, тип Standards Track	SEP-990	B
включение	расширения включаются явно и никогда не действуют по умолчанию; поддержка зависит от клиента	страница расширения	B
основа	черновик IETF «Identity Assertion JWT Authorization Grant» (ID-JAG), не RFC	ext-auth	B

[B] Порядок работы по странице расширения: клиент запрашивает у корпоративного поставщика удостоверений особый токен ID-JAG и обменивает его на токен доступа у сервера авторизации сервера MCP. Поставщик удостоверений ведёт перечень одобренных серверов и проверяет политику (группы, роли, условия доступа) до выдачи токена. Отзыв доступа делается в одном месте. В тексте расширения токен доступа обязан быть ограничен тем сервером MCP, который указан в ID-JAG.

[B] «Cross App Access» (XAA) - название, которым компания Okta называет эту схему у себя. Оно встречается в официальном блоге, в тексте самого расширения его нет.

[C] Первая точка - настройки самой программы, в которой работает сотрудник.

[A] Спецификация относит применение политик безопасности к роли хоста. Правил о списках разрешённых серверов в редакции 2026-07-28 мы не нашли, поэтому вся таблица ниже - реализации поставщиков. В неё вошли только продукты, чью документацию мы открывали напрямую.

Продукт	Настройки, как они названы в документации	Что они делают по словам поставщика	Источник	Метка
Claude Code	файл managed-mcp.json; managedMcpServers; allowedMcpServers, deniedMcpServers; allowManagedMcpServersOnly	файл задаёт фиксированный набор серверов, остальные пользователь не добавит; списки фильтруют уже настроенные серверы и реестром не являются; без allowManagedMcpServersOnly разрешающие списки из всех областей складываются, включая личный файл пользователя; совпадение с запрещающим списком ничем не отменяется	Managed MCP	D
Claude, планы Team и Enterprise	включение коннекторов владельцем организации; для действий - «Always allow», «Needs approval», «Blocked»	коннектор включает владелец, каждый участник после этого проходит вход сам; ограничение действий только сужает доступ, но не расширяет его сверх прав в исходной системе	справка Claude	D
VS Code	chat.mcp.access (политика ChatMCP) со значениями all, registry, none; McpGalleryServiceUrl; ChatAllowedMcpServers, ChatDeniedMcpServers, ChatAllowManagedMcpServersOnly	registry разрешает запуск серверов только из заданного реестра, none выключает поддержку MCP; запрещающие правила всегда сильнее разрешающих	Enterprise policies, Manage AI settings	D
GitHub Copilot	политика «MCP servers in Copilot»; allowedMcpServers в managed-settings.json с ключами serverUrl, serverCommand; политика «Restrict MCP access to registry servers»	первая политика решает, запускаются ли серверы MCP вообще; рекомендованный способ - managed-settings.json; способ через собственный реестр назван более слабым: совпадение только по имени или идентификатору, пользователь обходит его правкой файлов настроек	MCP management, Configure enterprise allowlist	D
Cursor	раздел «MCP Configuration» в панели команды (только Enterprise); поле Tools у сервера; файл ~/.cursor/permissions.json с ключом mcpAllowlist	список разрешённых серверов в панели сверяется с полной строкой команды или с URL; разрешение не устанавливает сервер; поле Tools ограничивает инструменты сервера; ключ mcpAllowlist - это личный список инструментов, которые запускаются без подтверждения, в виде сервер:инструмент	Model and integration management	D
ChatGPT	не проверялось	страницы справки OpenAI на дату проверки отвечали на прямой запрос кодом 403, напрямую текст не прочитан	-	D

[D] Две оговорки из документации поставщиков. У Claude Code файл managed-mcp.json нельзя доставить через серверные управляемые настройки: это отдельный файл на машине. По документации VS Code список из управляемых настроек Copilot заменяет такую же политику, доставленную через шаблон ADMX или профиль конфигурации, а не объединяется с ней. Подробности о клиентах - на страницах Claude Code и VS Code.

[A] Спецификация не определяет понятие «MCP gateway». Поиск этого словосочетания по дереву документации в коммите 75db1e9 не даёт совпадений. Слово «gateway» встречается только в общем смысле. В разделе о транспорте: «intermediaries (load balancers, gateways, observability tooling) can route and inspect requests without parsing the body». В разделе о кэшировании: «Any client, shared gateway, or caching proxy MAY store and serve the cached response to any user». Роли, набора возможностей или класса соответствия для шлюза в спецификации нет.

[A] Термины, которые в спецификации есть: «MCP proxy server» в правиле о согласии и «intermediary» в разделах о заголовках и кэшировании. Правила для них перечислены в таблице раздела «Что даёт компании сам протокол».

[B] Группа Enterprise IG в своём уставе пишет, что поведение шлюзов относится к пробелам, которые на уровне протокола пока не закрыты. Документ «Gateway Deployment Patterns» значится там как запланированный. Результаты группы не являются обязательными.

[C] На этом сайте шлюзом MCP называется посредник, который понимает сам протокол: видит метод и имя инструмента, применяет к ним правила и ведёт запись. Обычный обратный посредник (reverse proxy), который только пересылает HTTP, шлюзом MCP в этом смысле не является.

В таблице - продукты, чья собственная документация описывает функции посредника именно для MCP. «да» стоит только там, где на открытой странице поставщика есть прямая формулировка. «не заявлено» значит, что на открытых страницах формулировки не нашлось; это не утверждение, что функции нет.

Продукт (название поставщика)	Авторизация	Политика	Аудит	Реестр	Фильтрация инструментов	Согласование	Наблюдаемость	Метка
Docker MCP Gateway	да	да	не заявлено	да	не заявлено	да	да	D
Azure API Management (поставщик пишет «AI gateway»)	да	да	не заявлено	да	не заявлено	не заявлено	да	D
Microsoft MCP Gateway (открытый код)	да	не заявлено	не заявлено	не заявлено	не заявлено	не заявлено	да	D
Cloudflare MCP server portals	да	да	да	не заявлено	да	не заявлено	да	D
Kong AI Gateway, MCP Traffic Gateway	да	да	да	да	да	не заявлено	да	D
Amazon Bedrock AgentCore Gateway	да	не проверялось	да	не заявлено	не заявлено	не заявлено	да	D
MCP in Apigee	да	да	не заявлено	не заявлено	не заявлено	оставлено клиенту	да	D
IBM ContextForge	да	да	да	да	да	не заявлено	да	D

[D] Пояснения к строкам, все - по словам самих поставщиков:

• Docker: политики доступа и согласование вызовов описаны для Docker Sandboxes и не действуют на сервер, который агент подключил напрямую изнутри песочницы. MCP Gateway в составе Docker AI Governance доступен только по приглашению. Реестр здесь - собственные каталоги Docker; соответствие их API официального реестра MCP на открытых страницах не заявлено.
• Azure API Management: политики применяются ко всем операциям API, выставленным как инструменты. Поддерживаются инструменты MCP, но не ресурсы и не шаблоны запросов. Реестр вынесен в Azure API Center.
• Microsoft MCP Gateway: README называет продукт обратным посредником и слоем управления для серверов MCP в Kubernetes и сообщает, что эта версия работает с клиентами редакции 2026-07-28. Регистрация в нём - это регистрация инструментов (POST /tools), а не каталог серверов. Наблюдаемость заявлена общими словами.
• Cloudflare: поставщик называет продукт порталом, а не шлюзом, и отмечает, что раньше его иногда называли «Agents Gateway». Пользователь, которому портал отказал, всё ещё подключится к серверу по его прямому адресу. Журналы выгружаются во внешние хранилища и системы SIEM через Logpush.
• Kong: реестр MCP в Catalog имеет состояние «tech preview».
• Amazon Bedrock AgentCore Gateway: поставщик называет продукт шире, чем шлюз инструментов MCP. Аудит и наблюдаемость заявлены общими словами. Страницы о тонком управлении доступом мы не открывали.
• Apigee: на странице нет слова «gateway». Она описывает, как выставить уже существующие API в виде инструментов MCP, с поддержкой методов tools/list и tools/call, а не как встать перед чужими серверами MCP. Описания API попадают в API hub, который сопоставляет операции с инструментами MCP; реестром серверов MCP страница это не называет. Контроль со стороны человека страница оставляет клиенту.
• IBM ContextForge: README называет продукт реестром и посредником. Про аудит в нём одна строка - источник и пользователь передаются в заголовках. Отбор инструментов делается через «virtual server».

Что	Формулировка	Источник	Метка
место сервера авторизации	устройство сервера авторизации лежит вне рамок спецификации; он может размещаться вместе с сервером ресурсов или быть отдельной стороной	Authorization	A
порядок регистрации клиента	первым идёт заранее зарегистрированный клиент, затем Client ID Metadata Documents, затем Dynamic Client Registration как запасной путь, затем ручной ввод	Client Registration	A
доверие по доменам	сервер авторизации может вводить доменные политики доверия при приёме Client ID Metadata Documents	Security Considerations	A
варианты политики доверия	список доверенных доменов для защищённых серверов; приём любого client_id по HTTPS для открытых; проверка репутации неизвестных доменов	Security Best Practices	B
решение принимает поставщик удостоверений	в расширении Enterprise-Managed Authorization политика проверяется до выдачи токена; сотрудник без права доступа получает ошибку, клиент токена не получает	страница расширения	B
Claude	«Enterprise-managed auth»: администратор выдаёт доступ к коннекторам через поставщика удостоверений организации; на запуске поддерживается Okta	справка Claude	D
VS Code	политика McpEnterpriseManagedAuthIdp задаёт настройки поставщика удостоверений для этого расширения	Enterprise policies	D
Okta	название «Cross App Access»; документация Okta нами не открывалась	-	D, не проверялось

[D] Две статьи справки Claude расходятся в состоянии функции: одна называет её общедоступной для планов Team и Enterprise, другая - доступной в бета-версии. Какая из них действует сейчас, неизвестно.

[C] В нашей схеме эта точка отвечает на вопрос «кому», а не «что именно делается»: токен выдан или не выдан. Что сотрудник делает внутри сервера после выдачи токена, видно в двух других точках. Как устроена регистрация клиентов - на странице «Регистрация клиента».

Про самостоятельное размещение реестра первичные источники говорят разное. Мы приводим оба и не выбираем.

Кто говорит	Что сказано	Источник	Метка
документация официального реестра	реестр находится в состоянии preview; частные серверы он не поддерживает, для них рекомендуется свой частный реестр	About the registry	B
документация официального реестра	частные реестры могут реализовать тот же программный интерфейс, чтобы работать с уже существующими программами	About the registry	B
документация официального реестра	код официального реестра не рассчитан на самостоятельное размещение, сопровождающие такую установку не поддерживают	About the registry	B
документация GitHub	администратору предложено: «Fork and self-host the open-source MCP Registry»	Configure MCP registry	D
документация GitHub	реестр для Copilot поддерживает спецификацию реестра v0.1, начиная с GET /v0.1/servers; функция в состоянии public preview и не является рекомендованным способом ограничения	Configure MCP registry	D
VS Code	адрес частного реестра задаёт политика McpGalleryServiceUrl, запуск только из него - значение registry у chat.mcp.access	Manage AI settings	D
Azure API Center	выставляет конечную точку реестра MCP для VS Code, GitHub Copilot и других программ; формат адреса на странице поставщика и пример на той же странице не совпадают, поэтому адрес здесь не приводится	Register and discover MCP servers	D
Claude Code	встроенного реестра серверов MCP нет; списки разрешённых и запрещённых реестром не являются	Managed MCP	D

[B] Официальная документация отдельно предупреждает: реестр не даёт гарантий проверки содержимого, и потребителю предложено исходить из того, что проверки почти нет. Углублённая проверка отнесена к реестрам пакетов и к нижестоящим реестрам. Об устройстве реестра - на страницах «Реестр MCP» и «Каталоги».

[C] Реестр и список разрешённых - разные вещи. Реестр отвечает на вопрос «что есть», список - на вопрос «что позволено».

[D] В документации Claude Code и Cursor это различие названо прямо: разрешение не добавляет и не устанавливает сервер.

Тема	Что есть	Источник	Метка
аудит	клиенту следует вести журнал использования инструментов; формата журнала нет	Tools	A
аудит	общий формат журнала аудита - предмет изучения в группе Enterprise IG, а не готовый стандарт	устав Enterprise IG	B
аудит	Claude Code при настроенной выгрузке OpenTelemetry записывает имена серверов и инструментов, если задано OTEL_LOG_TOOL_DETAILS=1	Managed MCP	D
аудит	Cursor пишет события mcp_server_config и mcp_authentication; запись каждого вызова инструмента на этой странице не заявлена	Compliance and monitoring	D
учётные данные	реализациям на транспорте stdio не следует использовать порядок авторизации из спецификации, учётные данные берутся из окружения	Authorization	A
учётные данные	токены доступа не должны передаваться в строке запроса URI	Authorization	A
посредник для stdio	посреднику следует изолировать запускаемые процессы, ограничивать им доступ к файловой системе и записывать всё использование stdio	Security Best Practices	B
учётные данные	подстановку учётных данных на стороне посредника заявляют Docker MCP Gateway, Cloudflare MCP server portals и Amazon Bedrock AgentCore Gateway	Docker, Cloudflare, AWS	D
согласование	клиенту следует запрашивать подтверждение пользователя для чувствительных операций	Tools	A
согласование	Claude: для действия коннектора выбирается «Always allow», «Needs approval» или «Blocked»	справка Claude	D

[C] Это перечень нашего сайта. Он помогает собрать сведения о сервере в одном месте и ничего не предписывает.

1. Чей это сервер: поставщика самого сервиса, сообщества или ваш собственный? Откуда берётся его код или адрес?
2. Какой у него транспорт: локальный процесс stdio или удалённый адрес по HTTP?
3. Как сервер проверяет подлинность: OAuth, ключ в окружении, ничего?
4. Привязан ли токен к этому серверу и что сервер делает с ним дальше, при обращении к внешним API?
5. Какие инструменты сервер объявляет и какие из них меняют данные?
6. В какой из трёх точек контроля этот сервер виден: в политике клиента, на шлюзе, у поставщика удостоверений? Есть ли путь мимо этой точки, например прямой адрес сервера?
7. Где останется запись о вызовах и кто её читает?
8. Кто согласует вызовы, меняющие данные: сам сотрудник в клиенте, администратор заранее, никто?
9. Как отзывается доступ у одного сотрудника и у всех сразу?
10. Кто внутри компании отвечает за этот сервер и за его обновление?

• Авторизация - сервер ресурсов OAuth 2.1, привязка токена и запрет сквозной передачи подробно.
• Безопасность сервера - правила спецификации для самого сервера.
• Расширения протокола - как устроены официальные расширения и их включение.
• Реестр MCP - что такое официальный реестр и чем он не является.