Безопасность реестра MCP начинается после проверки издателя

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

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

Проверка издателя подтверждает контроль, а не добросовестность

Официальный реестр MCP проверяет, что издатель контролирует пространство имен в имени сервера. Это значимое свидетельство, но область его действия узка. Имя вида io.github.example/weather связано с пользователем или организацией GitHub, а имя в формате обратной DNS связано с контролем домена через проверку DNS или HTTP. Посторонний человек без аутентификации не сможет опубликовать сервер прямо в чужом проверенном пространстве имен.

Такая проверка не доказывает, что издатель написал безопасный код, по-прежнему контролирует все зависимости, защищает учетные данные для релизов или безопасно управляет удаленным сервером. Она также не подтверждает, что знакомое на вид пространство имен принадлежит организации, о которой вы подумали. Проверенный владелец может выпустить вредоносный релиз. У честного владельца могут взломать учетную запись. Домен может перейти другому человеку. Автор пакета может добавить зависимость, которая позже станет вредоносной.

Документация реестра прямо проводит эту границу. В обзоре MCP Registry сказано, что сервис занимается аутентификацией пространств имен и хранением метаданных. Проверку кода он оставляет базовым реестрам пакетов и нижестоящим агрегаторам. Условия использования Official MCP Registry идут дальше и рекомендуют пользователям самостоятельно оценивать каждый сервер для своего сценария. Я согласен с таким разделением: центральный сервис метаданных не должен выдавать проверку схемы за ревью кода. Ошибка начинается, когда от него ждут гарантии, которую он никогда не обещал.

При проверке разделяйте четыре утверждения:

• Идентичность: кто контролировал пространство имен при публикации?
• Связь: указывает ли запись в реестре на пакет или удаленную точку, заявленную издателем?
• Целостность: получили ли вы именно ту версию артефакта, которую проверяли?
• Пригодность: стоит ли давать этому коду такие права в этой среде?

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

Публикация создает цепочку, которую можно проследить

Правильная публикация связывает имя в реестре, данные релиза и исполняемый артефакт, не заставляя проверяющего догадываться. Для сервера из npm официальный краткий учебник требует, чтобы значение mcpName в пакете совпадало с name в server.json. Пакет должен стать общедоступным до публикации метаданных, поскольку реестр хранит метаданные, а не сам артефакт.

Сокращенный пример выглядит так:

{
  "name": "@example/weather-mcp",
  "version": "1.4.2",
  "mcpName": "io.github.example/weather"
}

{
  "name": "io.github.example/weather",
  "version": "1.4.2",
  "repository": {
    "url": "REPOSITORY_LOCATION",
    "source": "github"
  },
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@example/weather-mcp",
      "version": "1.4.2",
      "transport": { "type": "stdio" }
    }
  ]
}

Сверять нужно намеренно скучные значения. Имя MCP должно совпадать в пакете и метаданных реестра. Для локального сервера версия сервера должна соответствовать версии пакета. Идентификатор пакета должен приводить к ожидаемому артефакту. Адрес репозитория должен вести к исходному коду и истории релизов, которые вы собираетесь изучить. Любое расхождение без объяснения разрывает цепочку.

Способ аутентификации определяет, какое пространство имен может использовать издатель. GitHub OAuth поддерживает пространства пользователей и организаций в io.github.*. GitHub OIDC позволяет автоматически публиковать из GitHub Actions. Проверки DNS и HTTP работают с доменными пространствами имен в формате обратной DNS. В официальном руководстве по аутентификации доменные способы описаны как доказательство доступа к TXT-записи DNS или файлу в стандартном расположении. Ни один из этих способов не поручается за каждого человека, который стоит за учетной записью. Они подтверждают контроль в момент публикации.

Процесс mcp-publisher дает издателю воспроизводимый порядок действий: создать server.json, пройти подходящую аутентификацию и опубликовать запись. Успешный ответ содержит имя сервера и версию. Команде стоит хранить этот вывод рядом с коммитом релиза и хешем артефакта. Такая короткая квитанция позволяет позже ответить на конкретные вопросы: какой процесс опубликовал релиз, под какой идентичностью прошла аутентификация, из какого коммита собран пакет и какая версия попала в реестр.

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

Знакомые имена помогают захвату пространства имен

Захват пространства имен срабатывает, когда проверяющий узнает форму имени и перестает выяснять, кому оно принадлежит. Проверка не позволит постороннему публиковать в io.github.real-org/* без контроля над этой организацией GitHub. Но она не мешает зарегистрировать io.github.realorg/*, купить похожий домен или выпустить пакет с описательным именем, напоминающим популярный проект.

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

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

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

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

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

Поиск должен давать кандидатов, а не разрешения

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

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

До установки любого кандидата соберите пять фактов:

• Полное имя сервера, владелец пространства имен и способ аутентификации.
• Идентификатор пакета и зафиксированная версия либо точный адрес удаленного сервиса.
• Репозиторий исходного кода и коммит релиза, если исходный код доступен.
• Запрошенные секреты, пути к данным, сетевые назначения и операции записи.
• Проверяющий, дата решения, разрешенная среда и срок действия либо причина повторной проверки.

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

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

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

Проверяйте артефакт, который действительно запустится

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

Для пакета npm эти команды до установки показывают поля идентичности и точный набор файлов:

npm view @example/[email protected] \
  name version dist.integrity dist.tarball repository.url scripts

npm pack @example/[email protected]
tar -tf example-weather-mcp-1.4.2.tgz

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

name = '@example/weather-mcp'
version = '1.4.2'
dist.integrity = 'INTEGRITY_VALUE'
repository.url = 'REPOSITORY_LOCATION'
scripts = { build: 'BUILD_COMMAND' }
example-weather-mcp-1.4.2.tgz
package/dist/index.js
package/package.json

Особенно внимательно изучайте сценарии install, preinstall и postinstall, потому что менеджер пакетов может запустить их до старта сервера в хосте MCP. Проверяйте собранный JavaScript и не считайте, что он совпадает с TypeScript в репозитории. Ищите неожиданные исполняемые файлы, крупные сгенерированные блоки, изменения зависимостей, сетевые клиенты, пути телеметрии и код, который читает большие области домашнего каталога. Отсутствие сценариев жизненного цикла не делает среду выполнения безопасной, а лишь убирает один путь запуска кода.

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

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

Описания инструментов не ограничивают права

Заявленные инструменты сервера MCP описывают предполагаемые операции, но реальные возможности определяют права процесса. Файловый сервер может обещать чтение одного проекта и при этом читать все пути, доступные его системной учетной записи, если хост или контейнер не поставит ограничение. Инструмент для базы данных с описанием «только чтение» сможет записывать данные, если его учетные данные разрешают запись. Описания направляют модель, а учетные данные и изоляция ограничивают программу.

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

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

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

Секреты нужно изучить до запуска. Примеры конфигурации часто предлагают записать токены прямо в JSON-файл хоста. Такой файл может попасть в резервную копию настроек, архив для службы поддержки, снимок экрана или систему контроля версий. Предпочтите менеджер секретов или передачу через окружение с явными именами, а затем убедитесь, что процесс сервера получает только необходимые переменные. Сервер, который просит общие учетные данные облака ради одного узкого вызова API, не прошел проверку даже при подлинном пространстве имен.

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

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

Каждое обновление требует нового решения по безопасности

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

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

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

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

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

Рабочая политика встраивается в выпуск продукта

Команды обходят проверку MCP, когда она занимает больше времени, чем задача, которую сервер должен автоматизировать. Нужен небольшой барьер на основе свидетельств под ответственностью инженерной команды, а не комитет с недельным обсуждением каждого инструмента. Доступ с высоким риском требует глубокого анализа, а локальный сервер только с синтетическими данными может пройти быстрее.

Для общедоступных серверов используйте такой порядок одобрения:

1. Инициатор записывает полное имя в реестре, задачу, класс данных и необходимые действия.
2. Проверяющий подтверждает владельца пространства имен, связь с артефактом, историю исходного кода и происхождение релиза.
3. Инженер фиксирует артефакт, изолирует среду выполнения и выдает учетные данные с минимальными правами.
4. Тестовый хост сохраняет список инструментов после инициализации и выполняет ожидаемые вызовы на нерабочих данных.
5. Владелец одобряет одну версию, среду и набор возможностей, а также задает причины для повторной проверки.

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

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

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

Во время Team & AI Audit от oleg.is внедрение MCP рассматривается вместе с ревью кода, доступом к развертыванию и стоимостью разработки, потому что инструменты без владельцев позже создают дорогую уборку. Цель не в запрете полезных серверов. Безопасный путь должен быть достаточно быстрым, чтобы инженеры им пользовались.

Издатель должен уменьшать неопределенность для установщика

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

Выбирайте доменное пространство имен, если организация способна управлять доменом весь срок жизни сервера. Используйте пространство организации GitHub, когда эта учетная запись лучше подходит как долговечная идентичность. Не публикуйте сервер организации в личном пространстве одного сотрудника. Зафиксируйте владельцев DNS, GitHub, реестра пакетов и учетных данных для релизов, а также порядок отзыва доступа после смены ролей.

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

Поддерживайте server.json точным и небольшим. Указывайте конкретную версию пакета или удаленный адрес, обязательные переменные окружения, секретные поля, транспорт и репозиторий исходного кода. Не смягчайте опасные возможности формулировками в описании. Если инструмент удаляет записи, скажите прямо. Если удаленный сервис хранит входные данные, опишите это вне метаданных реестра и направьте проверяющих к подходящим условиям через обычную документацию продукта.

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

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

Для рабочего одобрения нужны свидетельства на каждой границе

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

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

Official MCP Registry полезен именно потому, что дает общий слой метаданных и пространств имен. Используйте его свидетельства только в пределах того, что они доказывают. Затем изучите артефакт, ограничьте среду выполнения, зафиксируйте релиз и требуйте новую проверку при изменении возможностей. Сервер, который не выдерживает таких проверок, не должен стоять между агентом и вашими рабочими системами.