Исследователи OX Security изучили 15 465 публично индексируемых MCP-серверов и обнаружили, что у экосистемы почти нет механизмов проверки операторов, происхождения кода и инфраструктуры. Для компаний, подключающих AI-агентов к внутренним данным и инструментам, безопасность MCP-серверов становится не вопросом удобной интеграции, а вопросом контроля над тем, кому агент отправляет запросы и какие действия может выполнить.
Аналитики собрали данные из пяти реестров MCP, убрали дубликаты и получили 5 095 уникальных хостов, сообщает The Hacker News. Среди них 15,6% разрешаются в инфраструктуру за пределами США; авторы отдельно насчитали 19 хостов в Китае и 18 в России. Сам по себе адрес сервера не доказывает злоупотреблений, но для организации с правилами хранения данных и согласованными юрисдикциями это уже повод не подключать инструмент по принципу «нашли в каталоге — значит, можно».
MCP, или Model Context Protocol, появился в 2024 году как общий способ подключать модели, агентные приложения и среды разработки к данным и внешним инструментам. Идея проста и полезна: вместо отдельной интеграции для каждого клиента разработчик поднимает сервер с описанными функциями, а совместимое приложение может ими пользоваться. Проблема начинается там, где этот сервер получает контекст диалога, доступ к API, файловой системе, базе знаний или корпоративным учётным данным.
Каталог не равен проверенному поставщику
В OX Security сравнивают нынешние MCP-маркетплейсы с магазином приложений без охранника на входе. Опубликовать сервер может практически любой разработчик; обязательной проверки, подписи кода и подтверждения происхождения в исследованных каталогах нет. Авторы подчёркивают, что даже ручной аудит репозитория не решает задачу полностью: удалённый MCP-сервер способен исполнять на бэкенде код, который не совпадает с опубликованным исходником. Репозиторий показывает намерения автора на момент публикации, но не гарантирует, что именно выполняется на удалённом хосте.
Это важное отличие от привычной проверки open source-зависимостей. В библиотеке команда хотя бы фиксирует версию, сверяет хеши и собирает артефакт в своём контуре. При подключении удалённого MCP-сервера доверие распространяется и на его текущую инфраструктуру, и на оператора, и на маршрутизацию трафика. Владелец может начать работу на одном IP-адресе, а затем перенести сервис или изменить маршрут запросов. Если агент продолжает считать прежнее имя сервера доверенным, политика безопасности может заметить перемену слишком поздно.
В исследовании есть и менее экзотичные, но очень практичные сигналы риска. Около 0,45% хостов направляют трафик через потребительские туннельные сервисы, главным образом бесплатные адреса ngrok. Такие серверы могут работать с личного компьютера или из домашней сети. Для демо и прототипа это обычная инженерная практика; для инструмента, которому агент передаёт фрагменты внутренних документов, токены или параметры запросов, — слабое место, которое нельзя закрыть одной галочкой в настройках клиента.
Домен может исчезнуть, доверие — остаться
Ещё 2,3% изученных доменов уже не разрешались в DNS. Шесть из них, по данным OX Security, находились на истёкших доменах, которые можно зарегистрировать за несколько долларов. Такой сценарий опасен не потому, что каждый забытый домен непременно захватят злоумышленники. Риск в другом: новый владелец потенциально получает имя, которое ранее было связано с MCP-сервером. Если у пользователей или команд остались старые конфигурации, запросы агентов могут прийти на чужую инфраструктуру под знакомым адресом.
Для разработчиков это аргумент относиться к MCP-серверам как к внешним поставщикам, а не как к безобидным плагинам. До подключения стоит определить, какие данные реально уходят в инструмент, нужен ли ему доступ на запись, где находится его инфраструктура и кто отвечает за домен. Для локальных и self-hosted сценариев полезнее закреплять версии и запускать проверенный код в контролируемом окружении. Для удалённых сервисов нужны хотя бы инвентаризация подключений, разрешённый список серверов, минимальные права для токенов и регулярная перепроверка DNS, сертификатов и маршрутов.
Бизнесу придётся включить MCP в уже знакомые процессы управления SaaS, облаками и цепочкой поставки. Нельзя считать, что агентный клиент автоматически унаследовал корпоративный Zero Trust только потому, что его установили на корпоративный ноутбук. Если агент может читать CRM, обращаться к Git-репозиторию или вызывать внутренний API, MCP-подключение становится ещё одной точкой принятия решений об идентичности, правах и передаче данных. Авторы также описывают в полном отчёте сценарии prompt injection: сервер может попытаться повлиять на модель через возвращаемый инструментом контент, а не только через очевидную уязвимость в коде.
Безопасность MCP-серверов теперь зависит не только от самого протокола, но и от дисциплины вокруг него: верификации владельца, подписи артефактов, контроля доменов и понятной модели разрешений. Пока маркетплейсы не предлагают эти гарантии по умолчанию, компаниям придётся строить собственный контур доверия — иначе удобный мост между моделью и корпоративными системами легко превратится в неконтролируемый канал доступа. Детали методики и сценариев OX Security опубликованы в материале .