Ваш MCP-сервер — самая большая дыра в вашей системе

Вредоносный MCP-сервер может украсть ваши SSH-ключи, даже не написав ни одной полной вредоносной инструкции. Группа исследователей ASSET доказала это: когда команда кражи дана модели целиком, крупные модели почти всегда отказывают. Раздробите ту же команду на безобидные на вид фрагменты — и GPT-4o, Gemini 2.0 Flash и Llama 3.3 выполняют её в 100% протестированных случаев.

При этом большинство разработчиков добавляют новый MCP-сервер к своему агенту каждую неделю, копируя строку конфига, найденную на GitHub. Каждый такой сервер хранит часть вашего доступа: API-токены, облачные ключи, сервисные аккаунты. MCP полезен — с этим никто не спорит. Но MCP-сервер стал слабым звеном всего агентского стека.

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

MCP-сервер — это мост между вашим агентом и внешним инструментом: базой данных, GitHub, Slack, облаком. Чтобы работать этим мостом, он хранит всё нужное, чтобы войти под вашим именем — токены, API-ключи, учётные данные сервисов — открытым текстом, в конфиг-файле на диске, обычно без шифрования.

Одна деталь протокола важна для того, что будет дальше. Когда агент подключается к MCP-серверу, тот присылает список инструментов, каждый с текстовым описанием, когда и как его использовать. Эти описания попадают прямо в контекст модели, с тем же весом, что и ваши собственные инструкции, и результаты, которые возвращают инструменты, — тоже туда. MCP-сервер непрерывно говорит с вашим агентом текстом, который никто никогда не перечитывает. Именно это делает возможной атаку GhostSplice.

Экосистема выросла быстрее, чем её защита:

Показатель	Число
Серверов в официальном реестре MCP	9 600+
Рост удалённых развёртываний с мая 2025	5×

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

Вот и вся картина: тысячи серверов, никакой проверки, а ваши ключи — посередине.

Первая дыра — учётные данные хранятся открытым текстом. The Hacker News опубликовал подробный разбор механики утечек 17 августа, и отправная точка проста: токены вставляют прямо в строки конфигурации, и они остаются читаемыми на диске. Одного слегка поспешного коммита достаточно, чтобы отправить конфиг в Git-репозиторий вместе с ключами внутри. Хуже становится из-за того, что статья называет разрастанием: одни и те же ключи дублируются в конфиг-файлах, переменных окружения и копиях в dev, staging и production. Со временем никто не знает, где живут секреты, поэтому их никто не обновляет — а статичный ключ, который никогда не меняют, — это ключ, ждущий своего злоумышленника.

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

Третья дыра — цепочка поставок. CVE-2025-6514 затронула mcp-remote, OAuth-прокси, скачанный более 400 000 раз, и позволяла вредоносному серверу выполнить инъекцию команд на машине пользователя — запустить код и уйти с учётными данными. Один популярный npm-пакет, установленный одной строкой, — и дверь была открыта.

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

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

GhostSplice — имя, которое группа исследователей ASSET дала технике, заставляющей вашего собственного агента выполнить кражу данных с его полного согласия. Принцип умещается в одной фразе: вместо того чтобы написать команду кражи целиком, вредоносный сервер дробит её, кладёт один фрагмент в описание инструмента, а другой — в результат, который возвращает этот инструмент. Каждый кусок по отдельности выглядит безобидно. Но агент объединяет всё, что попадает в его рабочий контекст: он восстанавливает полную инструкцию и выполняет её с полной верой — с его точки зрения он просто заполняет форму, о которой попросил инструмент.

Цифры тестов — вот в чём вся суть:

Модель	Инструкция целиком	Раздробленная инструкция
GPT-4o	Отказывает в 100%	Выполняет в 100%
Gemini 2.0 Flash	Отказывает в 100%	Выполняет в 100%
Llama 3.3	Отказывает в 100%	Выполняет в 100%
Claude Haiku 4.5	Отказывает через API	Выполняет в 100% в тесте из трёх частей внутри Cursor

Деталь с Claude разрушает любой простой вывод: одна и та же модель может отказать в одном клиенте и слить данные в другом — в зависимости от защиты, которую добавляет этот клиент.

Что крадёт GhostSplice в тестах: SSH-ключи, секреты окружения, исходный код, данные клиентов. Исследователи работали на изолированных проектах с фейковыми ключами, а не на реальных жертвах, но метод опубликован и воспроизводим.

GhostSplice — не первая попытка этой лаборатории. Та же лаборатория опубликовала Ghostcommit в июне — атаку, прятавшую свои инструкции в PNG-файлах, на которые ссылались конвенции проекта, а затем кодировавшую украденные секреты в исходный код в виде чисел. Дробление инструкций — целое семейство закрепляющихся атак, а не отдельный курьёз.

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

GhostSplice предполагал, что вредоносный сервер уже подключён. Но кто решает, что подключать? В команде честный ответ — никто. Это проблема, которую Cloudflare называет теневым MCP: все серверы, которые разработчики подключают к своим агентам без какой-либо проверки безопасности. До недавнего времени этот трафик был невидим — запрос MCP выглядит как любой другой HTTPS-вызов.

Cloudflare изменил это детекцией на уровне протокола. После обновления спецификации каждый совместимый MCP-клиент отправляет заголовок MCP-Protocol-Version в своих запросах, и Gateway проверяет этот заголовок во всём TLS-трафике, который расшифровывает. Теперь команда безопасности может увидеть каждый MCP-сервер, используемый в компании, с отдельной панелью: уникальные серверы, пользователи, объёмы запросов. Такой подход по заголовку лучше, чем фильтрация по доменному имени, потому что у MCP-сервера нет причин называть себя как-то вроде mcp-что-то — протокол выдаёт себя тем, что он говорит, а не тем, чем притворяется.

Команда может и действовать: селектор is_mcp позволяет блокировать любой MCP-трафик, который не прошёл через одобренный портал. Портал — вторая половина этой настройки: единая точка доступа, объединяющая проверенные серверы за аутентификацией по личности.

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

Cloudflare разделяет это на два случая: чистый теневой MCP — сервер, который никогда не был одобрен, и обход портала — одобренный сервер, к которому обратились напрямую в обход проверки. Оба блокируются одним и тем же базовым правилом. Логика проста: всё, что идёт через портал, известно и залогировано, всё остальное блокируется. Для компании это конец призрачного MCP-сервера, установленного в пятницу вечером.

Даже одобренный сервер может навредить, потому что агент наследует все права своего пользователя разом. Здесь на сцену выходит WriteGuard, который Cloudflare только что открыл в приватной бете. Идея: классифицировать каждый инструмент каждого MCP-сервера по уровню риска и применять свою политику для каждого уровня.

• Чтение проходит без трения.
• Ограниченная запись, вроде публикации комментария, проходит, но обогащённой: действие подписывается как исходящее от агента, от имени конкретного человека, и событие аудита уходит в центральный лог.
• Критическое действие — слияние кода, деплой в продакшен, массовое удаление — блокируется ещё до того, как сервер вообще его обработает.

Пример с GitLab в посте Cloudflare хорошо показывает эту градацию: чтение merge request проходит, комментарий к нему проходит с указанием авторства, а слияние отклоняется, пока человек не сделает это сам.

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

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

Об ограничениях нужно сказать прямо. WriteGuard — приватная бета за формой регистрации, а детекции Gateway нужно развёртывание Cloudflare Zero Trust с включённой TLS-инспекцией: для соло-разработчика или маленькой команды это просто не ваша инфраструктура. Даже в компании детекция видит только тот сетевой трафик, который она расшифровывает — локальный MCP-сервер, работающий через stdio, запущенный как обычный процесс на вашей машине, остаётся невидимым для Gateway. А именно так и работает большинство серверов, которые ставят себе разработчики.

Прежде всего, ни один из этих инструментов не чинит основной механизм, который раскрыл GhostSplice: пока агент свободно объединяет всё, что попадает в его контекст, безобидные фрагменты будут продолжать складываться во враждебные инструкции. Исследователи ASSET сами это говорят: решение требует относиться к результату работы инструмента как к данным, никогда — как к инструкциям, а такого разделения пока не существует в агентах от природы.

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

Что делать, начиная с сегодняшнего дня:

1. Инвентаризация. Составьте список MCP-серверов, реально подключённых к вашим агентам, и уберите те, которыми вы больше не пользуетесь.
2. Сортировка по происхождению. Официальный сервер известного поставщика — да. Репозиторий на GitHub с 40 звёздами, найденный в треде, — нет, пока вы не прочитали, что он делает с вашими данными.
3. Ограничьте права. Дайте каждому серверу отдельный токен с минимальным набором прав, никогда — свой мастер-ключ, и обновляйте эти токены так же, как для любой продакшен-системы.
4. Держите руку на чувствительных действиях. Агент, который пишет, сливает или удаляет, должен возвращаться через вас — это, по сути, ручная версия того, что индустриализирует WriteGuard.
5. Применяйте правило GhostSplice каждый день. Когда ваш агент выстраивает цепочку действий инструментов, о которой вы не просили, остановите его и прочитайте, что говорил ему сервер.

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

Если вы работаете в компании, добавьте сетевой уровень: детекция MCP от Gateway и порталы стоят внедрения, потому что теневой MCP уже существует в вашей организации — видите вы его или нет.

MCP — не проблема. Проблема — это скорость, с которой мы отдали ему свои ключи.