MCP-сервер подключается одной строкой в конфиге. И это весь процесс проверки

MCP-сервер: это стороннее расширение, которому AI-агент доверяет все привилегии текущей сессии. Подключается он обычно за секунды: разработчик просто добавляет несколько строк в конфигурационный файл, без ревью, без записи в реестр ПО, без согласования с безопасностью. Главная опасность здесь не во вредоносном коде как таковом, а в том, что описания инструментов (tool descriptions) и их схемы модель воспринимает как инструкции в момент выполнения. Статический код-ревью эту нагрузку просто не видит: её там физически нет до момента запуска сервера.

В любой компании есть процесс онбординга поставщиков: анкета по безопасности, соглашение об обработке данных, ответственный, дата пересмотра. Всё это занимает недели. И ничего из этого не применяется к тому, как реально появляются MCP-серверы. Разработчик находит сервер, который подключает его AI-ассистента к Jira, к внутренней базе данных или к дизайн-инструменту. Вставляет пару строк в конфиг. Агент перезапускается, считывает описания инструментов сервера и начинает вызывать их с теми правами, которые есть у текущей сессии. Без тикета, без ревью, без записи в инвентаризацию. Меньше минуты.

• Trend Micro в июле 2025 обнаружила 492 публично доступных MCP-сервера без аутентификации и шифрования трафика, суммарно раскрывающих 1402 инструмента; к апрелю 2026 их число выросло почти втрое
• Invariant Labs ещё в 2025 году показала, что инструкции, спрятанные в описании инструмента, модель выполняет ещё до выбора самого инструмента
• Серверы способны менять описания своих инструментов уже после того, как им дали доверие; большинство агентских хостов молча подгружают новую версию при переподключении
• Реально работающие меры защиты: инвентаризация, белый список разрешённых серверов, точка проверки на уровне выполнения, токены под конкретную задачу и логирование каждого вызова

Почему обычное код-ревью не ловит риски MCP

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

Опасная поверхность: это метаданные времени выполнения, а не исходный код. Когда агент подключается к серверу, он получает описания и схемы инструментов, и модель читает их как инструкции. Invariant Labs ещё в апреле 2025 показала: инструкции, встроенные в описание инструмента, модель считывает и выполняет ещё до того, как выбран сам инструмент. Позже, во второй половине 2025 года, CyberArk развила эту идею под названием full-schema poisoning, показав, что модель воспринимает как источник команд не только текст описания, но и имена параметров, поля типа и обязательности, произвольные свойства схемы и даже результаты работы инструмента. Статическое сканирование репозитория этого не видит в принципе: полезная нагрузка существует только тогда, когда сервер запущен и отвечает на запросы.

Описания могут измениться уже после того, как вы доверились серверу. Это классический «rug pull»: сервер безупречно ведёт себя на этапе установки, завоёвывает доверие, а затем обновляется. Большинство агентских хостов подгружают новые описания инструментов автоматически при переподключении, поэтому новая версия занимает то же место доверия, что и старая, без нового запроса на подтверждение и без повторной проверки.

Заражение через соседний сервер: это норма, а не исключение. В мае 2025 года Invariant Labs продемонстрировала, как официальный MCP-сервер GitHub был использован против собственного пользователя: вредоносный issue в публичном репозитории, который агент прочитал по обычной просьбе «посмотреть последние issues», содержал скрытые инструкции, в результате агент перенёс содержимое приватного репозитория в публичный. Сам сервер GitHub не содержал уязвимости в классическом понимании. У агента просто была одна сессия, несколько инструментов и никакой границы между ними.

Задокументированные инциденты с MCP: с датами

Дискуссия давно вышла из теоретической стадии.

Июль 2025, Trend Micro. Найдено 492 публично доступных MCP-сервера без клиентской аутентификации и без шифрования трафика, суммарно раскрывающих 1402 инструмента. Никакого специального мастерства не требовалось: серверы были просто открыты. По данным на апрель 2026, их количество выросло почти в три раза.

Июль 2025, CVE-2025-6514 в пакете mcp-remote. Критическая уязвимость с оценкой 9.6 в прокси-пакете, который используют для подключения локальных AI-клиентов к удалённым MCP-серверам. Пакет был скачан более 437 000 раз. Он безоговорочно доверял URL авторизации OAuth, полученному от удалённого сервера, поэтому вредоносный сервер мог выполнить произвольные команды на машине разработчика прямо во время рукопожатия при подключении.

Сентябрь 2025, Kaspersky GERT. Полноценный proof-of-concept, показывающий MCP как точку входа в цепочку поставок: сервер выглядит легитимно, устанавливается без проблем и собирает конфиденциальные данные при каждом вызове инструмента разработчиком. Ни повреждения памяти, ни классической уязвимости для этого не требовалось.

Сентябрь 2025, поддельный MCP-сервер Postmark. Пакет в npm, имитирующий популярный сервис транзакционных писем, работал точно так, как заявлено. Письма формировались и доставлялись как обычно. Каждое из них также незаметно копировалось на адрес злоумышленника.

Февраль 2026, Straiker STAR Labs. Организованная группа около трёх месяцев выстраивала фейковую экосистему разработчиков: несколько аккаунтов на GitHub, сгенерированные ИИ персоны, перекрёстные форки для имитации живого сообщества, а затем опубликовала в легитимном реестре троянизированную версию MCP-сервера для популярного носимого устройства. Полезная нагрузка: инфостилер, ворующий пароли браузера, облачные сессионные токены, SSH-ключи и API-ключи.

Апрель 2026, небезопасные настройки по умолчанию. Исследование OX Security, о котором писал The Hacker News, описало архитектурную слабость в реализациях MCP, способную привести к удалённому выполнению кода, а также десять уязвимостей в широко используемых AI-проектах, включая LiteLLM, LangChain, LangFlow и Flowise.

Во всех случаях закономерность одна: сама атака несложная. Проблема в чрезмерно щедрой модели доверия.

Проблема привилегий, которая стоит за всем этим

Даже полностью благонадёжный сервер обычно получает от агента куда более широкие права, чем требует задача. OAuth-токен с областью действия «repo» открывает агенту все репозитории, доступные пользователю, а не только тот, над которым он сейчас работает. Подключение к базе данных, задуманное для одного read-запроса, на практике часто оказывается тем же соединением, что используется для всего остального.

Это важно, потому что prompt injection не обязана повышать привилегии: ей достаточно дотянуться до сессии, у которой они уже есть. История с GitHub, наглядный пример: злоумышленник не получал никаких учётных данных. Он одолжил чужую сессию.

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

Пять мер защиты MCP, от простой к сложной

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

1. Сначала: инвентаризация. Соберите конфигурации MCP со всех рабочих машин разработчиков, всех CI-раннеров и всех внутренних агентских развёртываний. Список почти всегда оказывается длиннее, чем ожидает служба безопасности.
2. Белый список, а не чёрный. У экосистемы реестров нет надёжного централизованного механизма доверия, а февральский случай 2026 года доказал, что само присутствие в реестре ничего не гарантирует. Явный список одобренных серверов и инструментов: единственная реально работающая позиция.
3. Точка проверки между агентом и сервером. Прокси, который анализирует описания и схемы инструментов на предмет инъекций и фиксирует изменение определений сервера между вызовами, ловит и отравление инструментов, и «rug pull».
4. Токен под конкретную задачу. Один токен на сервер, минимально необходимая область действия, короткое время жизни, никаких общих сессионных токенов. Это та мера, которая ограничивает ущерб, если остальные четыре не сработали.
5. Логирование каждого взаимодействия с MCP и оповещение по паттерну. Какой сервер, какой инструмент, какие аргументы, какой результат. Утечка данных через агента выглядит абсолютно нормально на уровне сети и сразу бросается в глаза на уровне вызовов инструментов.

Что сделать на этой неделе

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

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

Частые вопросы

Сам протокол MCP небезопасен?
Протокол: это транспорт и соглашение о схемах. Риск создаёт типовая практика внедрения вокруг него: непроверенные серверы, слишком широкие права, отсутствие проверки во время выполнения и модель, которая безоговорочно доверяет метаданным инструментов. Всё это решаемо без отказа от протокола как такового.

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

Увидит ли это наш существующий DLP или файрвол?
Практически нет. Трафик к одобренному SaaS-эндпоинту по TLS выглядит легитимно на сетевом уровне, значимый сигнал появляется только на уровне вызовов инструментов: какой инструмент, какие аргументы, в какой последовательности. Эту видимость нужно создавать отдельно, именно на границе MCP.

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

---

Материал подготовлен командой Optimum Code (Кишинёв, Молдова), компании, работающей с клиентами в Европе, США и Азии в сфере разработки ПО, пентестинга и AI-безопасности.

Услуга по теме: MCP Security Gateway, прокси-шлюз между AI-агентами и MCP-серверами с проверкой метаданных, принудительным применением принципа минимальных привилегий и логированием всех взаимодействий.