Зачем компании реестр MCP-серверов?

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

Реестр MCP-серверов нужен не для того, чтобы запретить инженерам экспериментировать. Он отделяет эксперимент с коротким сроком жизни от подключения, которое стало частью рабочего процесса. Хорошая запись отвечает на скучные, но решающие вопросы: какой именно сервер запущен, откуда он поставлен, какие инструменты он объявляет, какие данные видит, кто отключит его ночью и когда решение надо пересмотреть.

Реестр фиксирует решение компании, а не список находок

Внешний каталог отвечает на вопрос «какие MCP-серверы вообще существуют». Внутренний каталог отвечает на другой вопрос: «какие из них наша компания допускает в конкретных средах и на каких условиях». Смешивать эти два смысла опасно. Появление записи в публичном реестре или в популярном репозитории не создаёт для неё доверия внутри банка, телеком-оператора или SaaS-команды.

Официальный реестр MCP описывает сервер через метаданные, версии, пакеты или удалённые точки подключения. Это полезный формат для обнаружения и поставки. Но метаданных поставщика недостаточно для внутреннего допуска: там обычно нет вашей классификации данных, владельца бизнес-системы, срока проверки, списка разрешённых групп пользователей и решения по журналированию.

Внутренний реестр не обязан копировать внешний. Он должен добавлять те поля, по которым служба безопасности, платформа и владелец системы смогут принять действие: разрешить, оставить в песочнице, приостановить или заблокировать.

У записи должно быть неизменяемое внутреннее имя. Не используйте для него только отображаемое название вроде crm-mcp или filesystem-tools: такие названия быстро дублируются. Практичнее сочетать домен владельца и назначение, например com.company.sales.crm-readonly. Это имя остаётся в аудит-логах, конфигурациях и заявках, даже если команда позже переименовала репозиторий.

Минимальная запись должна содержать:

• внутренний идентификатор и понятное отображаемое название;
• статус допуска и среды, где он действует;
• технического владельца и владельца подключаемой системы;
• способ поставки, точную версию или digest образа;
• транспорт, адрес удалённого сервера либо команду запуска;
• заявленные инструменты, права, типы данных и срок следующей проверки.

Если поля нельзя проверить машинно или человеком за несколько минут, они не помогут во время инцидента. Поле «используется для аналитики» не годится. Поле «читает таблицы orders и customers из реплики CRM, запись запрещена, доступ через сервисную учётную запись svc-mcp-crm-ro» уже годится.

Три статуса лучше длинной шкалы зрелости

Для первого рабочего реестра достаточно статусов «разрешён», «тест» и «заблокирован». Длинная шкала с «кандидатом», «на рассмотрении», «пилотом», «ограниченно одобренным», «устаревающим» обычно превращает решение в спор о словах. Дополнительные признаки лучше хранить отдельными полями, а не создавать новые статусы.

Разрешён означает, что конкретная версия или допустимый диапазон версий прошли проверку для чётко определённых сред, пользователей и прав. Этот статус не означает «можно подключить всем». Сервер чтения базы знаний может быть разрешён для сотрудников поддержки, но запрещён для внешнего чат-бота. Коннектор к системе закупок может быть разрешён только в тестовом контуре.

Тест означает, что компания допускает ограниченный эксперимент. У него заранее определены участники, контур, набор данных, дата окончания и хозяин эксперимента. Тестовый статус без даты окончания, лимита пользователей и возможности быстро отозвать доступ превращается в теневой production. Я видел, как именно так в рабочую среду попадали токены, выданные «на пару дней».

Заблокирован означает, что клиент, прокси или политика установки не должны позволять подключение. Причину блокировки надо писать прямо: неподтверждённый источник пакета, лишние разрешения, уязвимость, прекращение поддержки, конфликт с требованиями по размещению данных, нарушение условий поставщика. Формулировка «не рекомендован» не годится, потому что оставляет человеку пространство для удобного толкования.

Запрещённая запись не должна исчезать. Архив с причиной и датой блокировки предотвращает повторный импорт того же проекта под новым названием. Он также показывает аудитору, что команда не просто перестала обсуждать проблему, а закрыла доступ и отозвала секреты.

Не ставьте статус «разрешён» серверу целиком, если версия и набор инструментов меняются без контроля. Разрешают не бренд, не GitHub-организацию и не домен. Разрешают конкретный артефакт с понятным поведением в заданной среде.

Владелец должен иметь полномочия выключить коннектор

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

Например, команда AI Platform может поддерживать сервер для поиска по внутреннему хранилищу документов. Но право допустить чтение договоров или кадровых файлов принадлежит не платформенной команде. Его должен подтвердить владелец хранилища и, при необходимости, ответственный за данные. Иначе платформа случайно принимает решение, на которое у неё нет полномочий.

В реестре указывайте не просто почтовый список. Нужны конкретная роль, команда и рабочий путь эскалации. Запись owner: data-team плохо работает в пятницу вечером, когда непонятно, кто отзовёт токен. Запись с техническим владельцем, резервной группой дежурства и владельцем системы позволяет действовать без поисков по оргсхеме.

Владельцу нельзя назначать номинальную обязанность. Он должен уметь выполнить хотя бы четыре действия:

• подтвердить или отклонить расширение инструментов и прав;
• остановить распространение новой версии;
• отозвать секреты и отключить сервер при инциденте;
• ответить на переоценку до истечения срока.

Если человек не контролирует ни конфигурацию, ни токены, ни выпуск, он не владелец. Он контакт для уведомлений. Это разные роли, и попытка выдать одну за другую делает реестр декоративным.

Полезно добавить поле successor_required. Когда владелец меняет команду или увольняется, запись автоматически должна стать ограниченной или тестовой, пока новый ответственный не примет её. Иначе старый коннектор продолжает читать данные годами только потому, что никто не заметил смену людей.

Разрешения надо описывать действиями и данными

Фраза «сервер имеет read-only доступ» почти ничего не говорит. Он может читать безобидный каталог товаров, а может выгружать клиентские договоры, исходный код и записи разговоров. Реестр должен описывать разрешения на уровне конкретных действий и классов данных.

Спецификация MCP разделяет возможности сервера на инструменты, ресурсы и промпты. Для контроля риска это важное различие. Инструмент вызывает действие или получает данные по параметрам, ресурс обычно предоставляет контекст по URI, а промпт поставляет шаблон взаимодействия. На практике самый опасный объект часто не тот, у которого страшное название, а инструмент с невинным именем search, который принимает произвольный запрос и возвращает документы без фильтра по правам пользователя.

Для каждого инструмента заведите карточку разрешения. В ней не нужно переписывать весь JSON Schema, но нужно отразить последствия вызова:

Не ограничивайтесь пометкой «чтение» и «запись». Отправка сообщения во внешний канал, запуск запроса к базе, загрузка файла, создание задачи, удаление объекта и изменение прав доступа дают разные последствия. Реестр обязан показать их до того, как модель предложит вызов человеку, который не знает устройство коннектора.

Особое внимание уделите косвенной записи. Сервер может формально только читать из CRM, но затем передавать найденный текст в сторонний API для классификации. Для владельца CRM это уже передача данных, а не простое чтение. В реестре фиксируйте входящие данные, исходящие данные и все внешние получатели.

Не принимайте аргумент «модель всё равно спросит пользователя». Клиенты MCP могут показывать подтверждения, но дизайн интерфейса, политика клиента и детали реализации меняются. Сервер с опасным действием должен быть ограничен сам по себе, а не держаться на надежде, что пользователь каждый раз прочитает диалог.

Удалённый доступ и локальный процесс требуют разных проверок

Локальный сервер, который клиент запускает через stdio, и удалённый сервер по Streamable HTTP имеют разные границы риска. Их нельзя оценивать одной галочкой «MCP поддерживается».

Локальный процесс работает на устройстве пользователя или на рабочем хосте. Он может получить доступ к файловой системе, переменным окружения, прокси-настройкам, локальным сертификатам и учётным данным, если вы не ограничили среду запуска. Для него в реестре важны источник пакета, хеш или digest, команда запуска, разрешённые переменные окружения, права файловой системы и политика обновления.

Удалённый сервер переносит часть риска на сеть и удалённую инфраструктуру. Для него фиксируйте доменное имя, способ аутентификации, регион обработки, TLS-политику, ограничения исходящего трафика, журналирование и поведение при недоступности. Если сервер использует OAuth, храните не только факт «OAuth включён», но и аудиторию токена, необходимые scopes, срок жизни, путь отзыва и тип учётной записи.

Официальная спецификация MCP по авторизации для удалённых серверов опирается на OAuth-подход и отдельно описывает защиту от подмены ресурсов и неправильной передачи токенов. Это не разрешение скопировать один bearer token из конфигурации разработчика в общий секрет. Токен должен быть выдан конкретному клиенту и конкретному ресурсу, а сервер не должен принимать токен, предназначенный для другого получателя.

Ниже пример того, как можно хранить не секреты, а проверяемый контракт удалённого подключения:

id: com.company.support.ticketing
status: approved
transport:
  type: streamable-http
  endpoint: https://mcp.support.internal.example/mcp
identity:
  method: oauth2
  audience: https://mcp.support.internal.example
  scopes:
    - tickets.read
    - tickets.create
network:
  egress: internal-only
  data_region: kz
allowed_tools:
  - search_ticket
  - create_ticket
review:
  reviewed_on: 2026-07-23
  expires_on: 2026-10-23
owners:
  technical: ai-platform-oncall
  system: service-desk-owner

Этот фрагмент предотвращает частую ошибку: команда помнит адрес сервера, но не зафиксировала, для какой аудитории выдан токен и какие действия действительно разрешены. Секреты остаются в менеджере секретов или в системе идентификации. Реестр хранит правила, по которым вы проверяете, что секрет вообще имеет право существовать.

Срок проверки должен зависеть от изменения риска

Ежегодный пересмотр всего списка удобен для отчёта и плох для безопасности. Сервер, который читает обезличенный справочник из тестовой среды, и сервер, который создаёт финансовые операции, не должны жить по одному календарю.

Срок проверки назначают по тому, насколько быстро изменятся последствия ошибки. Учитывайте хотя бы четыре вещи: возможность записи, чувствительность данных, внешнюю передачу и автономность вызова. Чем больше из этого есть у сервера, тем короче срок и строже условия.

Переоценка нужна раньше даты в записи, если произошло одно из событий:

• сервер получил новый инструмент или изменил смысл существующего;
• поменялись scopes, сервисная учётная запись или модель авторизации;
• обновился пакет, контейнерная база или удалённая точка подключения;
• поменялся владелец данных, регион обработки или поставщик;
• сработало расследование инцидента, даже если оно не подтвердило утечку.

Разделяйте пересмотр артефакта и пересмотр допуска. Обновление библиотеки с исправлением CVE требует технической оценки. Добавление send_email к существующему серверу требует заново оценить сам допуск, потому что изменились бизнес-последствия. В командах это часто смешивают: обновление выкатывают как обычный patch, а через него приезжает новый набор инструментов.

Срок не должен просто истекать в таблице. Автоматизация должна переводить запись из «разрешён» в ограниченный режим либо блокировать новые подключения, если владелец не подтвердил пересмотр. Что именно отключать, зависит от критичности системы. Но статус approved после истечения даты нельзя оставлять как есть, иначе поле с датой становится ритуалом.

Проверка должна видеть реальный список инструментов

Главная ошибка при допуске MCP-сервера, это проверять README, а не поведение запущенного экземпляра. Описание быстро устаревает. Сервер может отдать другой набор инструментов из-за версии, флага окружения, учётной записи или удалённой конфигурации.

Проверка должна запускать сервер в изолированной среде с тестовыми учётными данными и сохранять результат инициализации, список инструментов и их входные схемы. MCP Inspector подходит для такой технической проверки, но его нельзя путать с решением о допуске. Inspector показывает, что сервер объявляет. Владельцы и процесс контроля решают, можно ли это использовать.

Практический контроль можно построить вокруг снимка возможностей. Допустим, команда хранит ожидаемый набор в репозитории:

{
  "server_id": "com.company.docs.search",
  "version": "1.8.4",
  "allowed_tools": [
    "search_documents",
    "get_document_excerpt"
  ],
  "forbidden_tools": [
    "download_document",
    "share_document"
  ]
}

Пайплайн поднимает сервер, вызывает tools/list и сравнивает имена с этим снимком. Если появился share_document, сборка не должна автоматически получать статус разрешённой. Даже если разработчик считает, что инструмент пока не использует модель, он уже изменил поверхность доступа.

Проверяйте не только имена. Посмотрите на описания, обязательные параметры, ограничения длины, URI ресурсов и поведение на ошибке. Инструмент get_invoice может казаться безопасным, пока не выяснится, что параметр id принимает шаблон и позволяет перебрать чужие документы. Ручная проверка нескольких негативных сценариев обычно находит больше, чем формальное чтение схемы.

Полезен короткий протокол проверки. Он должен содержать версию артефакта, дату, среду, использованные тестовые учётные данные, список обнаруженных возможностей, отклонения от реестра и решение. Не храните в нём реальные токены, фрагменты персональных данных или полные ответы бизнес-системы.

Блокировка должна отключать путь, а не только менять строку

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

У блокировки есть последовательность действий. Сначала остановите новые подключения и отключите сервер в центральной конфигурации. Затем отзовите OAuth grants, API-ключи, сервисные учётные записи и доступы к секретам. После этого проверьте аудит-логи: кто пользовался коннектором, какие инструменты вызывались, какие токены остались активны. Только потом помечайте запись архивной.

Временная недоступность и блокировка не одно и то же. Если поставщик упал, сервер можно временно вывести из эксплуатации, сохранив статус допуска. Если вы обнаружили, что сервер отправляет рабочие документы в неразрешённый внешний сервис, это блокировка до отдельного решения. Такая разница важна для дежурной команды: первая ситуация требует восстановления, вторая требует сдерживания.

Для организаций Казахстана и Центральной Азии отдельно фиксируйте размещение данных и маршрут их передачи. Требование хранить данные внутри страны не выполняется одной надписью «локальный сервер». Нужны подтверждённые сведения о том, где работают компоненты, куда сервер отправляет запросы, какие логи остаются у поставщика и что происходит при резервном переключении.

AI Router может быть точкой контроля для удалённых вызовов моделей через единый OpenAI-совместимый API, но он не заменяет реестр MCP-коннекторов. Реестр отвечает за доступ сервера к системам и данным, а шлюз модели отвечает за маршрут LLM-запроса, правила ключа и журналирование на своём уровне.

Реестр надо встраивать в поставку, а не поручать одной таблице

Таблица в начале полезна, но ручное сопровождение не переживает десятки команд и быстрые обновления. Источник истины лучше хранить в репозитории или системе, где изменения проходят review, имеют историю и проверяются автоматикой. Веб-интерфейс можно добавить позже, когда людям станет неудобно работать с файлами.

Начните с схемы записи, которую CI валидирует при каждом изменении. Проверка должна отклонять запись без владельца, без даты истечения, без среды, без способа поставки или с разрешённым инструментом, которого нет в утверждённом профиле. Так вы ловите не атаки, а обычную инженерную небрежность до выкладки.

Затем свяжите реестр с тремя местами, где серверы реально появляются:

1. С конфигурацией MCP-клиентов. Клиент получает только записи со статусом approved и подходящей средой.
2. С CI/CD. Пайплайн сравнивает опубликованный артефакт и обнаруженные возможности с карточкой допуска.
3. С системой идентификации. Токен или сервисная учётная запись выдаётся только тому серверу и тем scopes, которые указаны в записи.

Не пытайтесь в первый месяц описать каждый неофициальный скрипт. Сначала внесите коннекторы, которые уже касаются production, персональных данных, финансовых систем, почты, файловых хранилищ и внешних API. Одновременно введите правило: новый MCP-сервер не попадает в общий каталог и не получает рабочие секреты без записи в реестре.

После этого найдутся старые подключения, о которых никто не хотел вспоминать. Это нормальный результат, а не провал процесса. Гораздо хуже оставить их невидимыми и узнать о них тогда, когда модель уже получила возможность создать платёж, открыть документ или отправить данные за пределы допустимого контура.

Реестр не должен обещать абсолютную безопасность. Он должен сделать ответственность, права и срок действия видимыми до подключения. Когда новый коннектор появляется в компании, первый вопрос должен быть не «какой у него красивый demo», а «какой у него статус, что он умеет и кто нажмёт стоп».