MCP-сервер — это не плагин, а код и учётные данные, которые действуют от имени сотрудника по указанию языковой модели. Описания инструментов, ответы серверов и загружаемые пакеты нужно считать недоверенными: реальные инциденты 2025–2026 годов (поддельный пакет postmark-mcp, утечка между клиентами в MCP-сервере Asana, критические уязвимости mcp-remote и MCP Inspector, системная проблема STDIO-конфигураций по данным OX Security) показали, что атакуют все звенья цепочки. Минимальный управленческий набор: реестр одобренных серверов, запрет самостоятельной установки, токены с минимальными правами и привязкой к адресату, изоляция исполнения, журналирование каждого вызова инструмента и подтверждение человеком опасных действий. Внедрять MCP стоит поэтапно, начиная с серверов только для чтения и внутренних шлюзов.
Что такое MCP и зачем он бизнесу
Model Context Protocol (MCP) — открытый протокол, который задаёт единый способ подключения приложений на базе LLM к внешним данным и инструментам. Спецификация описывает три роли: хост (приложение с моделью, например ассистент в IDE или корпоративный чат-бот), клиент (коннектор внутри хоста, поддерживающий соединение с одним сервером) и сервер (сервис, который предоставляет модели ресурсы, шаблоны запросов и инструменты). Сообщения передаются в формате JSON-RPC 2.0. Протокол часто сравнивают с Language Server Protocol: так же, как LSP унифицировал поддержку языков программирования в редакторах, MCP унифицирует подключение AI к системам компании.
Для бизнеса ценность MCP в скорости интеграции. Вместо отдельной доработки под каждую модель и каждый сервис команда один раз публикует MCP-сервер для CRM, базы знаний, тикет-системы или хранилища, и им могут пользоваться разные агенты и ассистенты. Крупные вендоры встроили поддержку MCP в среды разработки, офисные и облачные продукты, а публичные каталоги насчитывают тысячи серверов. Именно поэтому MCP быстро проникает в компанию снизу: разработчик или аналитик подключает сервер за несколько минут, без заявки в ИТ и без оценки рисков.
Ключевая особенность, которую нужно понимать руководителю: инструмент MCP — это действие, которое модель выполняет от имени пользователя. Сама спецификация прямо указывает, что инструменты означают произвольное исполнение кода и требуют осторожности, а описания их поведения следует считать недоверенными, если они получены не от доверенного сервера. Решение о вызове принимает модель, которая по своей природе не умеет надёжно отличать инструкции от данных. Это и делает MCP отдельным предметом управления безопасностью, а не очередной интеграцией по API.
Помимо инструментов, сервер может предоставлять ресурсы (данные и документы для контекста) и шаблоны запросов, а клиент — встречные возможности: сэмплирование (сервер просит модель хоста сгенерировать текст), корни (границы файловой системы или URI, в которых серверу разрешено работать) и запрос дополнительных сведений у пользователя (elicitation). Каждая из этих функций — канал, по которому сервер влияет на модель или пользователя. Спецификация требует явного одобрения пользователем запросов на сэмплирование и ограничивает видимость запросов для сервера, но реализация этих принципов лежит на разработчиках хостов и клиентов: протокол сам по себе не может их обеспечить.
Архитектура и границы доверия
В типичной схеме участвуют пять элементов: пользователь, хост с моделью, один или несколько MCP-клиентов, MCP-серверы и внешние системы, к которым серверы обращаются (почта, Git, базы данных, SaaS). Каждая стрелка между ними — граница доверия. Модель получает в контекст системные инструкции, запрос пользователя, описания всех подключённых инструментов и результаты их вызовов. Для модели это единый поток текста, поэтому любой фрагмент, пришедший от сервера, потенциально способен повлиять на её дальнейшие действия.
Протокол определяет два стандартных транспорта. STDIO: клиент запускает сервер как дочерний процесс на той же машине и обменивается с ним через стандартный ввод и вывод. Такой сервер работает с правами пользователя или хоста, видит его файлы, переменные окружения и сеть. Streamable HTTP: сервер работает как самостоятельный сетевой сервис и обслуживает множество клиентов. Для него спецификация требует проверять заголовок Origin во всех входящих соединениях (защита от DNS rebinding), при локальном запуске привязываться только к 127.0.0.1, а не ко всем интерфейсам, и аутентифицировать все соединения.
Авторизация в MCP формально необязательна, но для HTTP-транспорта, если она реализована, должна строиться на OAuth 2.1. MCP-сервер выступает сервером ресурсов, клиент обязан указывать параметр resource (RFC 8707), чтобы токен выдавался для конкретного сервера, а сервер обязан проверять, что токен выпущен именно для него, и не имеет права принимать или пересылать дальше чужие токены. PKCE обязателен, токены нельзя передавать в строке URL, авторизационные серверы должны выдавать короткоживущие токены. Для STDIO-серверов спецификация рекомендует не использовать этот механизм, а брать учётные данные из окружения — на практике это часто означает долгоживущие персональные ключи в конфигурационных файлах на рабочих станциях.
Практический вывод для архитектора: границы доверия проходят не там, где их привыкли рисовать. Удалённый сервер стороннего вендора, локальный пакет из npm или PyPI, ответ инструмента, который содержит текст из письма или тикета, — всё это недоверенный ввод, который попадает прямо в контекст модели, управляющей вашими учётными данными.
В корпоративной среде встречаются три типовые схемы развёртывания. Локальная: ассистент на ноутбуке разработчика запускает STDIO-серверы из пакетов, ключи хранятся в конфигурации пользователя. Удалённая вендорская: сотрудник подключает облачный MCP-сервер SaaS-поставщика по OAuth. Централизованная: компания размещает собственные серверы во внутреннем контуре, а агенты обращаются к ним через MCP-шлюз, который аутентифицирует пользователей, применяет политики и журналирует вызовы. Третья схема даёт наилучшую управляемость и является целевой для промышленного использования; первые две допустимы при наличии реестра, ограничений и мониторинга.
- Хост и модель: принимают решения о вызове инструментов; доверять им как механизму контроля нельзя.
- Клиент: отвечает за согласие пользователя, показ описаний инструментов, проверку URL при OAuth-обнаружении.
- Сервер: исполняет действия, хранит или получает токены к внешним системам, определяет, что вернуть модели.
- Транспорт STDIO: исполнение локального кода с правами пользователя; транспорт HTTP: сетевой сервис со всеми классическими веб-рисками.
- Внешние системы: источник данных, которые могут содержать внедрённые инструкции.
Почему MCP расширяет поверхность атаки
Первая причина — смешение каналов управления и данных. Описание инструмента, результат поиска, текст тикета в GitHub или строка в таблице поддержки для модели неотличимы от инструкции. Invariant Labs в апреле 2025 года показала отравление описаний инструментов, а в мае 2025 года — сценарий с официальным MCP-сервером GitHub, когда текст в публичном issue заставлял агента вынести данные из приватных репозиториев пользователя. Исследователи подчеркнули, что проблему нельзя закрыть исправлением одного сервера: она архитектурная и требует ограничения прав и контроля потоков данных на уровне агента.
Вторая причина — агрегация прав. Один агент одновременно подключён к почте, файлам, коду и базе данных. Сочетание доступа к приватным данным, контакта с недоверенным содержимым и возможности отправить что-либо наружу создаёт канал утечки даже без единой уязвимости в коде. Случай с MCP-сервером Supabase (исследование General Analysis, июль 2025 года) показал, как агент с ключом сервисной роли, обходящим политики доступа на уровне строк, мог по внедрённой в тикет инструкции прочитать закрытую таблицу и записать её содержимое туда, где его увидит злоумышленник.
Третья причина — цепочка поставок. MCP-серверы распространяются как пакеты npm и PyPI, образы контейнеров и записи в публичных каталогах, часто от частных авторов. В сентябре 2025 года Koi Security обнаружила пакет postmark-mcp, который копировал название и код официального проекта, а в версии 1.0.16 добавил одну строку, отправлявшую скрытую копию каждого письма на внешний адрес. В апреле 2026 года OX Security опубликовала исследование о том, что механизм запуска STDIO-серверов в официальных SDK исполняет переданную в конфигурации команду без проверки, что привело к серии CVE в продуктах, позволявших пользователю или модели менять конфигурацию MCP; Anthropic, по данным исследователей и The Register, назвала такое поведение ожидаемым и не стала менять протокол.
Четвёртая причина — классические уязвимости в новом коде. CVE-2025-6514 в mcp-remote (CVSS 9.6, JFrog, июль 2025 года) позволяла вредоносному удалённому серверу добиться исполнения команд на машине клиента через подставной адрес авторизации. CVE-2025-49596 в MCP Inspector (CVSS 9.4, Oligo, июнь 2025 года) была связана с отсутствием аутентификации у локального прокси и позволяла атаковать разработчика через посещение веб-страницы. Ошибка изоляции клиентов в MCP-сервере Asana в июне 2025 года потенциально открывала данные одной организации пользователям другой. Это обычные ошибки веб-разработки, но последствия умножаются правами агента.
Центр безопасности AI при NSA в бюллетене 2026 года обратил внимание на особенность, которая отличает MCP от привычных интеграций: в протоколе серверы могут сами инициировать запросы к клиенту и опосредованно влиять на действия, которые клиент выполняет. Это переворачивает привычную модель клиент-сервер и создаёт пути атаки, которые плохо отслеживаются существующими средствами. Добавим скорость: экосистема растёт быстрее, чем зрелеют её процессы безопасности, а многие популярные серверы — небольшие проекты отдельных разработчиков без формального процесса обработки уязвимостей.
Пятая причина — человеческий фактор в цикле одобрения. Клиенты просят пользователя подтверждать вызовы, но при десятках однотипных запросов подтверждение превращается в формальность, а многие среды позволяют включить автоматическое выполнение. Trail of Bits в серии публикаций 2025 года показала, как сервер может скрыть от пользователя часть выводимого текста с помощью управляющих последовательностей терминала и как внедрённая инструкция приводит к исполнению кода в обход механизма одобрения. Поэтому подтверждение человеком работает только для небольшого числа действительно опасных операций и только при понятном отображении того, что будет выполнено.
Управление MCP в компании: реестр, одобрение, владельцы
Главный управленческий риск — теневые MCP-серверы. OWASP выделяет его в отдельную категорию MCP09 «Shadow MCP Servers». Если любой сотрудник может добавить сервер в конфигурацию своего ассистента, компания не знает, какой код исполняется на рабочих станциях и какие токены к каким системам выданы агентам. Поэтому первым шагом должен стать реестр MCP-серверов как часть общего реестра AI-систем.
Для каждой записи реестра фиксируются: назначение и бизнес-владелец; технический владелец; источник (внутренняя разработка, вендор, открытый проект) и точная версия с контрольной суммой; транспорт и место исполнения; перечень инструментов с описаниями и уровнем риска каждого (чтение, запись, внешняя отправка, исполнение кода); системы и данные, к которым сервер имеет доступ; используемые учётные данные и их права; дата последней проверки. Реестр должен быть машиночитаемым, чтобы клиенты и шлюз могли применять его как список разрешённых серверов.
Процесс одобрения строится по аналогии с допуском стороннего ПО, но с дополнительными вопросами: кто контролирует описания инструментов и может ли их изменить без смены версии; какие данные сервер возвращает в контекст модели и может ли в них оказаться текст от внешних лиц; есть ли инструменты с необратимыми действиями; как сервер хранит токены. Для удалённых серверов SaaS-вендоров добавляется оценка поставщика: изоляция клиентов, журналирование, порядок уведомления об инцидентах.
Ответственность распределяется так: CISO утверждает политику и классы риска, архитектура — эталонные схемы подключения и шлюз, владельцы систем — согласие на доступ агентов к своим данным, команды разработки — соответствие серверов требованиям. Политика должна явно запрещать подключение неодобренных серверов к корпоративным учётным записям и данным и предусматривать технический контроль этого запрета через управление конфигурацией конечных точек.
Удобно ввести три класса риска. Низкий: серверы только для чтения к внутренним некритичным данным без доступа к недоверенному содержимому; одобряет владелец системы по упрощённой процедуре. Средний: чтение конфиденциальных данных или обработка внешнего содержимого (почта, тикеты, веб); требуется проверка службой ИБ, журналирование через шлюз и ограничение исходящих каналов. Высокий: запись в критичные системы, отправка данных наружу, исполнение кода, финансовые операции; обязательны изоляция, подтверждение человеком каждого опасного действия, тестирование на внедрение инструкций и ежеквартальный пересмотр.
Отдельного внимания требуют договоры с поставщиками удалённых MCP-серверов. В них стоит фиксировать: какие данные сервер получает и где хранит, как изолированы клиенты, как долго хранятся журналы вызовов и доступны ли они заказчику, как поставщик уведомляет об изменениях набора и описаний инструментов, в какие сроки сообщает об инцидентах, как отзываются токены при расторжении. Случай Asana показал, что даже у крупного вендора ошибка изоляции в новом MCP-сервере может появиться в первый месяц работы, и решающим становится то, насколько быстро поставщик отключит сервис и уведомит клиентов.
- Реестр MCP-серверов с владельцами, версиями, хэшами и классами риска.
- Список разрешённых серверов, применяемый технически на клиентах и шлюзе.
- Классификация инструментов: чтение, изменение, внешняя отправка, исполнение кода.
- Повторное одобрение при любом изменении описаний инструментов или прав.
- Регулярная инвентаризация конфигураций MCP на рабочих станциях и серверах.
Требования к MCP-серверам
Требования стоит закрепить в стандарте разработки и в договорах с поставщиками. Базовый слой берётся прямо из спецификации и раздела Security Best Practices: проверка адресата токена, запрет пересылки клиентских токенов в нижележащие API, OAuth 2.1 с PKCE, короткоживущие токены и ротация refresh-токенов, точное совпадение redirect URI, согласие пользователя для каждого динамически зарегистрированного клиента у серверов-прокси, проверка Origin и привязка к localhost для локальных HTTP-серверов.
Второй слой — минимизация прав. Спецификация рекомендует прогрессивную модель областей доступа (scopes): минимальный набор для чтения при первом подключении и запрос дополнительных прав только при попытке выполнить привилегированную операцию. Типичные ошибки — публикация всех возможных областей, универсальные области вида «полный доступ» и объединение несвязанных привилегий заранее. Для серверов, работающих с базами данных, разумно использовать отдельную учётную запись только для чтения на уровне СУБД, а не полагаться на то, что модель не станет писать.
Третий слой — безопасность описаний и ответов. Описания инструментов должны быть короткими, фиксированными в версии и проверяемыми; изменение описаний должно приводить к новой версии и повторному одобрению. Ответы инструментов следует ограничивать по объёму и структуре, явно помечать недоверенное содержимое (текст писем, тикетов, веб-страниц) и не возвращать в контекст секреты. Microsoft в рекомендациях по MCP предлагает разделять доверенные инструкции и недоверенные данные с помощью разметки и фильтров внедрённых инструкций, но подчёркивает, что это лишь один из слоёв защиты.
Четвёртый слой — устойчивость к классическим атакам: проверка путей и символических ссылок у файловых серверов (уязвимости CVE-2025-53109 и CVE-2025-53110 в эталонном Filesystem-сервере, найденные Cymulate, были связаны именно с этим), защита от SSRF при обращении по URL из недоверенных источников, запрет передачи пользовательских значений в командную оболочку, привязка идентификаторов состояния к аутентифицированному пользователю, а для облачных серверов — строгая изоляция клиентов.
Требования предъявляются и к клиентам, которые компания допускает к использованию. Клиент должен показывать пользователю полную команду запуска локального сервера без сокращений и предупреждать, что сервер получит права пользователя; показывать полные описания инструментов и уведомлять об их изменении; проверять URL, получаемые от серверов при OAuth, отклоняя опасные схемы и не открывая их через командную оболочку; блокировать обращения к частным диапазонам IP при обнаружении серверов авторизации; поддерживать централизованное управление списком серверов и запрет автоматического выполнения инструментов без подтверждения. При выборе ассистентов и сред разработки эти возможности стоит включать в критерии закупки.
- Токены только для этого сервера; никакого token passthrough.
- Минимальные области доступа и пошаговое повышение прав.
- Неизменяемые версии с подписью или хэшем; описания инструментов — часть версии.
- Опасные инструменты помечены и требуют подтверждения человеком.
- Ответы ограничены по объёму, недоверенный текст помечен, секреты не возвращаются.
- Журнал каждого вызова: пользователь, клиент, инструмент, параметры, результат.
Мониторинг и реагирование
OWASP выделяет отсутствие аудита и телеметрии в отдельную категорию MCP08. Без журнала вызовов инструментов расследовать инцидент с агентом практически невозможно: в журналах внешней системы действие выглядит как обычный запрос от учётной записи сотрудника. Минимальный набор событий: подключение и отключение серверов, получение и изменение списка инструментов (с хэшем описаний), каждый вызов инструмента с параметрами и идентификаторами пользователя и сессии, запросы на повышение прав, отказы авторизации, запуск локальных процессов STDIO-серверов.
Удобнее всего собирать эту телеметрию на MCP-шлюзе — промежуточном сервисе, через который проходят все соединения агентов с серверами. Шлюз применяет список разрешённых серверов и инструментов, фиксирует хэши описаний, обнаруживает их изменение, ограничивает исходящие соединения и передаёт события в SIEM. Для локальных серверов источником служат EDR и журналы управления конфигурацией конечных точек.
Правила корреляции для SOC: изменение описания инструмента без смены версии; вызов инструмента, не связанного с запросом пользователя; цепочка «чтение приватных данных — отправка наружу» в одной сессии; обращения к внутренним адресам и метаданным облака; запуск командной оболочки или сетевых утилит дочерним процессом ассистента; массовые вызовы и аномальный объём возвращаемых данных.
План реагирования должен включать быстрые действия, специфичные для MCP: отключение сервера во всех клиентах через централизованную конфигурацию, отзыв всех токенов, выданных серверу и через него, проверку, какие данные возвращались в контекст и куда отправлялись, поиск того же пакета и версии на других рабочих станциях, уведомление владельцев затронутых систем. В случае с postmark-mcp пострадавшим рекомендовали удалить пакет и сменить все учётные данные, которые могли пройти через почту, — подобный сценарий стоит отрепетировать заранее.
Мониторинг дополняется проверками до инцидента. Для серверов среднего и высокого класса риска стоит проводить тестирование на внедрение инструкций: размещать в данных, к которым обращается агент, контролируемые тестовые инструкции и проверять, остановят ли их ограничения прав и правила шлюза. Результаты таких проверок показывают руководству не теоретический, а измеренный остаточный риск и помогают обосновать, какие инструменты можно оставить без подтверждения человеком.
Важно заранее договориться о границе ответственности между SOC и командами, владеющими агентами. SOC получает события и реагирует по плейбукам, но решение об отключении сервера, от которого зависит бизнес-процесс, должно приниматься быстро, поэтому в реестре нужен дежурный контакт владельца и заранее утверждённое право службы ИБ отключать сервер без согласования при признаках компрометации.
Как внедрять поэтапно
Этап 1, инвентаризация (2–4 недели). Выявить, где уже используются MCP-клиенты и серверы: среды разработки, ассистенты, автоматизация. Собрать конфигурации, сопоставить их с реестром AI-систем, временно запретить подключение новых неодобренных серверов к корпоративным данным.
Этап 2, контролируемый пилот. Выбрать 2–3 сценария с понятной ценностью и низким риском: серверы только для чтения к внутренней базе знаний или документации. Использовать внутренние или проверенные вендорские серверы, развернуть шлюз, включить журналирование, настроить токены с минимальными правами. Опасные инструменты не подключать.
Этап 3, расширение с контролем записи. Добавлять инструменты, изменяющие данные, только после введения подтверждения человеком, ограничения исходящих соединений и правил мониторинга. Для разработчиков — изолированные среды исполнения локальных серверов (контейнеры или песочницы с ограниченной файловой системой и сетью) и закрытые зеркала пакетов.
Этап 4, промышленная эксплуатация. MCP-серверы проходят тот же жизненный цикл, что и остальное ПО: моделирование угроз, анализ кода и зависимостей, тестирование на внедрение инструкций, регулярная переоценка, учения по реагированию. Метрики для руководства: доля серверов в реестре, доля токенов с минимальными правами, число неодобренных подключений, время отзыва доступа сервера.
Быстрые меры на первые 30 дней, не требующие крупных бюджетов: опубликовать временную политику использования MCP; собрать перечень установленных серверов через средства управления конечными точками; отозвать персональные ключи с широкими правами из конфигураций ассистентов и заменить их ограниченными; запретить автоматическое выполнение инструментов без подтверждения в настройках корпоративных клиентов; включить в SIEM события запуска дочерних процессов ассистентов. Эти шаги закрывают наиболее вероятные сценарии — вредоносный пакет и утечку через внедрённую инструкцию — ещё до развёртывания шлюза.
Связь с OWASP и стандартами
OWASP MCP Top 10 (проект в статусе бета) перечисляет: MCP01 управление токенами и раскрытие секретов, MCP02 повышение привилегий через расширение областей доступа, MCP03 отравление инструментов, MCP04 атаки на цепочку поставок, MCP05 внедрение и исполнение команд, MCP06 внедрение инструкций через контекстные данные, MCP07 недостаточная аутентификация и авторизация, MCP08 отсутствие аудита и телеметрии, MCP09 теневые MCP-серверы, MCP10 внедрение контекста и избыточное раскрытие данных. Этот список удобно использовать как чек-лист для оценки серверов.
OWASP Top 10 for Agentic Applications 2026, опубликованный в декабре 2025 года, описывает риски агентов шире: перехват цели агента (ASI01), злоупотребление инструментами (ASI02), злоупотребление идентичностью и привилегиями (ASI03), уязвимости агентной цепочки поставок (ASI04), неожиданное исполнение кода (ASI05), отравление памяти и контекста (ASI06). Почти все классы атак на MCP укладываются в эти категории. OWASP Top 10 для LLM-приложений 2025 дополняет картину рисками LLM01 (внедрение инструкций), LLM03 (цепочка поставок) и LLM06 (избыточная автономность).
Государственные регуляторы также выпустили профильные документы. В мае 2026 года шесть агентств, включая CISA, NSA и национальные центры кибербезопасности Австралии, Канады, Новой Зеландии и Великобритании, опубликовали руководство Careful Adoption of Agentic AI Services с акцентом на минимальные привилегии, короткоживущие учётные данные агентов и подтверждение человеком значимых действий. Центр безопасности AI при NSA в мае 2026 года выпустил отдельный информационный бюллетень о проектировании защищённых систем на MCP. Для российских организаций, на которые распространяется приказ ФСТЭК России № 117, требования к защите при использовании технологий искусственного интеллекта и к контролю взаимодействия пользователей с AI-сервисами также применимы к агентам, подключённым через MCP.
Для внутренней модели угроз полезно сопоставить каждый класс атак из этого гайда с категориями OWASP и с мерами из чек-листа. Например, отравление описаний и подмена после одобрения соответствуют MCP03 и ASI04, внедрение через ответы инструментов — MCP06 и ASI01, кража токенов и token passthrough — MCP01 и MCP07, выполнение команд через STDIO — MCP05 и ASI05, теневые серверы — MCP09. Такая привязка упрощает аудит, отчётность перед руководством и согласование требований с вендорами, которые всё чаще ссылаются на эти списки в своей документации.
Классы атак на MCP
Отравление описаний инструментов
Вредоносный или скомпрометированный сервер помещает в описание инструмента или его параметров скрытые для пользователя инструкции, которые модель читает как часть контекста. Trail of Bits показала, что такое воздействие срабатывает уже при подключении сервера, ещё до вызова инструмента (эффект «line jumping»). Интерфейсы клиентов часто показывают пользователю сокращённое описание, поэтому одобрение не означает понимания. Модель может выполнить скрытую инструкцию с использованием прав других, легитимных инструментов.
Для бизнеса: Утечка файлов, ключей и переписки или несанкционированные действия от имени сотрудника без видимых признаков в интерфейсе.
Публичные случаи: Invariant Labs, 1 апреля 2025 года: демонстрация Tool Poisoning Attacks для популярных MCP-клиентов; Trail of Bits, 21 апреля 2025 года: исследование «line jumping» — влияние сервера на модель до вызова инструмента
- Допуск только серверов из реестра с проверенными описаниями инструментов
- Показ пользователю и проверяющему полного текста описаний, включая параметры
- Автоматическое сканирование описаний на внедрённые инструкции и скрытые символы
- Фиксация хэша описаний и блокировка при изменении
- Подтверждение человеком вызовов инструментов с доступом к чувствительным данным
Подмена инструмента после одобрения
Сервер проходит проверку с безобидными описаниями, а позже меняет их или поведение инструментов без смены имени. Удалённые серверы могут делать это в любой момент, локальные — через обновление пакета. Модель доверия «один раз одобрил — пользуйся» не учитывает, что список инструментов в MCP динамический. Особенно опасно в сочетании с автоматическим обновлением зависимостей.
Для бизнеса: Ранее одобренная интеграция превращается в канал утечки или саботажа, при этом формальная проверка в реестре остаётся пройденной.
Публичные случаи: postmark-mcp (Koi Security, сентябрь 2025 года): 15 безобидных версий, затем в 1.0.16 добавлена скрытая копия всех писем на внешний адрес
- Закрепление версий по хэшу или подписи; запрет автоматических обновлений
- Контроль изменения списка и описаний инструментов на шлюзе по принципу «доверие при первом использовании» с оповещением
- Повторное одобрение при любом изменении
- Закрытые зеркала пакетов с проверкой перед публикацией внутрь
Затенение инструментов
Описание инструмента одного сервера содержит инструкции о том, как модели вести себя при работе с инструментами другого, доверенного сервера, например куда отправлять письма или какие данные добавлять. Вредоносный сервер может вообще не вызываться: достаточно, что его описание находится в общем контексте. В журналах фиксируются только вызовы легитимного инструмента, поэтому атака плохо заметна. Риск растёт с числом серверов, подключённых к одному агенту.
Для бизнеса: Перенаправление коммуникаций и утечка данных через доверенные корпоративные каналы, которые не вызывают подозрений у DLP.
Публичные случаи: Invariant Labs, апрель 2025 года: сервер-приманка переопределял поведение агента с подключённым whatsapp-mcp и мог вынести историю переписки
- Ограничение набора серверов в одной сессии по сценарию (принцип разделения контекстов)
- Запрет совместного подключения недоверенных серверов и серверов с доступом к коммуникациям
- Проверка описаний на упоминания чужих инструментов и адресатов
- Политики шлюза для параметров чувствительных инструментов (разрешённые получатели, домены)
Внедрение инструкций через данные, которые возвращает инструмент
Сервер может быть полностью честным, но возвращать модели текст, написанный внешними лицами: письма, тикеты, issues, веб-страницы, записи в базе. Инструкции в этом тексте модель воспринимает так же, как запрос пользователя. Сочетание доступа к приватным данным, обработки недоверенного содержимого и канала отправки наружу превращает агента в инструмент утечки. Исправить это патчем сервера нельзя, нужны архитектурные ограничения.
Для бизнеса: Утечка исходного кода, персональных данных и секретов по инициативе внешнего лица, не имеющего доступа к системам компании.
Публичные случаи: Invariant Labs, 26 мая 2025 года: официальный GitHub MCP-сервер — текст в публичном issue приводил к выносу данных из приватных репозиториев; General Analysis, июль 2025 года: Supabase MCP — инструкция в тикете поддержки приводила к чтению закрытой таблицы агентом с ключом сервисной роли
- Разделение сессий: агент, читающий недоверенный контент, не имеет инструментов внешней отправки
- Пометка и фильтрация недоверенного содержимого в ответах (разметка, классификаторы внедрённых инструкций)
- Ограничение области действия токена одним репозиторием, проектом или схемой БД
- Учётные записи только для чтения на уровне целевой системы
- Подтверждение человеком действий записи и отправки
«Обманутый посредник» и избыточные права токенов
MCP-сервер-прокси обращается к стороннему API от своего имени с единым идентификатором клиента и может выполнить запрос, на который у конкретного пользователя или клиента нет согласия. Спецификация описывает сценарий, при котором cookie согласия у стороннего сервера авторизации позволяет злоумышленнику получить код авторизации без повторного подтверждения. Отдельная проблема — токены с широкими областями доступа, выданные заранее: их компрометация открывает всё сразу. OWASP относит это к категории MCP02.
Для бизнеса: Злоумышленник получает доступ к SaaS-данным пользователя от имени легитимного сервера; ущерб от одного токена охватывает все связанные системы.
- Согласие пользователя для каждого динамически зарегистрированного клиента до перенаправления к стороннему серверу авторизации
- Точное совпадение redirect URI, одноразовый state, защита страницы согласия от CSRF и встраивания
- Минимальные области доступа и пошаговое повышение прав
- Мониторинг запросов на повышение прав
Кража и повторное использование токенов
При антипаттерне token passthrough сервер принимает токен, выпущенный не для него, и пересылает его в нижележащий API. Это обходит контроль на сервере, ломает аудит и позволяет использовать украденный токен через сервер как через прокси. Спецификация прямо запрещает принимать и пересылать токены, выпущенные не для этого сервера. Кроме того, локальные серверы часто хранят долгоживущие персональные ключи в открытом виде в конфигурационных файлах, а облачные хостинги серверов концентрируют чужие ключи.
Для бизнеса: Компрометация одного сервера или рабочей станции даёт доступ к множеству систем с невозможностью восстановить, кто и что делал.
Публичные случаи: GitGuardian, 2025 год: уязвимость сборки на хостинге MCP-серверов Smithery.ai открывала доступ к токену инфраструктуры, управлявшему более чем 3000 размещённых приложений; сообщено 13 июня 2025 года, токен отозван
- Проверка адресата токена (audience) и параметр resource по RFC 8707
- Отдельные токены для нижележащих API, выданные самому серверу
- Короткоживущие токены и ротация refresh-токенов
- Хранение секретов в менеджере секретов, а не в конфигурационных файлах
- Сканирование рабочих станций и репозиториев на ключи в конфигурациях MCP
Выполнение команд через локальные STDIO-серверы и небезопасный запуск
STDIO-сервер — это процесс, который клиент запускает по команде из конфигурации, с правами пользователя. Если конфигурацию может изменить пользователь веб-интерфейса, модель или внешний источник, это равносильно исполнению произвольного кода. Отдельный риск — передача недоверенных значений в командную оболочку, например URL от сервера при OAuth. Спецификация требует от клиентов показывать полную команду перед запуском и рекомендует песочницу.
Для бизнеса: Полная компрометация рабочей станции разработчика или сервера с AI-платформой, включая доступ к ключам, коду и внутренней сети.
Публичные случаи: OX Security, 15 апреля 2026 года: системная проблема запуска STDIO-серверов в официальных SDK, серия CVE в LiteLLM, Flowise, Windsurf, DocsGPT и других; Anthropic не стала менять протокол (подтверждено The Register); JFrog, 9 июля 2025 года: CVE-2025-6514 в mcp-remote, CVSS 9.6, исполнение команд при подключении к недоверенному серверу, исправлено в 0.1.16; Cymulate, 2025 год: CVE-2025-53109 и CVE-2025-53110 — выход за пределы разрешённых каталогов в Filesystem MCP-сервере, исправлено в версии 2025.7.1
- Запрет изменения конфигурации MCP пользователями веб-интерфейсов и моделью
- Список разрешённых команд запуска с фиксированными аргументами
- Запуск локальных серверов в контейнере или песочнице с ограничением файловой системы и сети
- Никакой передачи недоверенных строк в оболочку; открытие URL без shell
- Своевременное обновление клиентов и прокси MCP
Вредоносные и поддельные MCP-пакеты в реестрах
Публичные каталоги и пакетные менеджеры позволяют любому опубликовать сервер с названием, похожим на официальный. Злоумышленник может скопировать код настоящего проекта и добавить незаметную закладку. Пользователи ищут сервер по названию и устанавливают первый найденный. По данным OX Security, в эксперименте удалось разместить тестовые записи в большинстве проверенных каталогов MCP.
Для бизнеса: Систематическая скрытая утечка данных из бизнес-процессов, которая может длиться неделями до обнаружения.
Публичные случаи: postmark-mcp (Koi Security; The Hacker News, The Register, BleepingComputer, сентябрь 2025 года): первый публично подтверждённый вредоносный MCP-сервер, около 1500 загрузок в неделю
- Установка только из внутреннего зеркала и реестра одобренных серверов
- Проверка издателя: официальный репозиторий вендора, подпись, история публикаций
- Анализ кода и зависимостей при каждом обновлении
- Мониторинг исходящих соединений и адресатов у процессов MCP-серверов
Утечка данных между серверами и клиентами
В одной сессии агента данные, полученные от одного сервера, становятся доступны модели и могут быть переданы другому серверу как параметр вызова. Если один из серверов недоверенный, он получает чужие данные без какой-либо уязвимости в коде. Отдельный вариант — ошибки изоляции клиентов в облачных MCP-серверах, когда пользователь одной организации видит данные другой. OWASP относит избыточное раскрытие контекста к категории MCP10.
Для бизнеса: Передача конфиденциальных данных третьим лицам и инциденты с уведомлением клиентов и регуляторов.
Публичные случаи: Asana, июнь 2025 года: ошибка в MCP-сервере могла открыть данные одной организации пользователям других; сервер был отключён с 5 по 17 июня, признаков эксплуатации не выявлено (The Register, UpGuard)
- Разделение серверов разного уровня доверия по отдельным сессиям и агентам
- Контроль параметров вызовов на шлюзе на наличие чувствительных данных
- Требования к изоляции клиентов и аудит вендоров облачных MCP-серверов
- Минимизация данных в ответах инструментов
DNS rebinding и незащищённые локальные HTTP-серверы
Локальный MCP-сервер или служебный прокси, работающий по HTTP без аутентификации, доступен не только клиенту, но и любой веб-странице в браузере пользователя через подмену DNS или особенности обработки адреса 0.0.0.0. Если такой сервер слушает все сетевые интерфейсы, он доступен и из локальной сети. Спецификация требует проверки Origin, рекомендует привязку к 127.0.0.1 и аутентификацию. Близкий риск — SSRF, когда вредоносный сервер подсовывает клиенту внутренние адреса при OAuth-обнаружении.
Для бизнеса: Исполнение команд на машине разработчика при простом посещении сайта и доступ к внутренним сервисам и метаданным облака.
Публичные случаи: Oligo Security, 27 июня 2025 года: CVE-2025-49596 в MCP Inspector, CVSS 9.4, отсутствие аутентификации локального прокси, атака из браузера; исправлено в 0.14.1 (также The Hacker News)
- Проверка заголовка Origin и ответ 403 на недопустимые значения
- Привязка только к 127.0.0.1 или использование STDIO и Unix-сокетов
- Обязательный токен аутентификации даже для локальных серверов
- Блокировка частных диапазонов IP и egress-прокси для OAuth-обнаружения
- Инвентаризация открытых портов MCP на рабочих станциях
Чек-лист безопасности MCP
До подключения сервера
- Сервер внесён в реестр с бизнес- и техническим владельцем
- Источник проверен: официальный издатель, репозиторий, подпись или хэш
- Прочитаны полные описания всех инструментов и параметров
- Инструменты классифицированы по риску: чтение, запись, внешняя отправка, исполнение кода
- Определено, какие недоверенные данные сервер может вернуть в контекст модели
- Для облачного сервера проведена оценка вендора, включая изоляцию клиентов
Права и авторизация
- Токены выпускаются только для конкретного MCP-сервера, адресат проверяется
- Token passthrough отсутствует; для нижележащих API — отдельные токены
- Минимальные области доступа и пошаговое повышение прав
- Короткоживущие токены, ротация refresh-токенов, секреты в менеджере секретов
- У прокси-серверов — согласие для каждого клиента, точные redirect URI, проверка state
- Учётные записи целевых систем ограничены по объекту (репозиторий, проект, схема)
Исполнение и изоляция
- Локальные серверы запускаются в контейнере или песочнице с ограниченной ФС и сетью
- Конфигурацию MCP не могут менять модель и пользователи веб-интерфейсов
- Список разрешённых команд запуска и версий
- HTTP-серверы проверяют Origin, слушают 127.0.0.1, требуют аутентификацию
- Серверы разного уровня доверия не смешиваются в одной сессии
- Действия записи и внешней отправки подтверждает человек
Мониторинг
- Все соединения идут через MCP-шлюз или контролируемый клиент
- Журналируются подключение, список инструментов с хэшем, каждый вызов с параметрами
- События передаются в SIEM, настроены правила на изменение описаний и цепочки чтение-отправка
- EDR контролирует дочерние процессы ассистентов и сетевые соединения MCP-серверов
- Регулярная инвентаризация конфигураций MCP на конечных точках
Поставщики и обновления
- Установка только из внутреннего зеркала пакетов
- Версии закреплены, автоматические обновления отключены
- Каждое обновление проходит анализ кода, зависимостей и описаний инструментов
- В договорах с вендорами — требования к журналированию, изоляции и уведомлению об инцидентах
- Отслеживаются бюллетени по уязвимостям MCP-клиентов, SDK и серверов
Реагирование
- Есть процедура централизованного отключения сервера во всех клиентах
- Подготовлен порядок отзыва всех токенов, связанных с сервером
- Определено, как восстановить, какие данные попали в контекст и куда ушли
- Проводятся учения по сценарию вредоносного обновления MCP-пакета
- Сценарии MCP включены в общий план реагирования и модель угроз
Вопросы руководителей
Можно ли просто запретить MCP?
Формальный запрет обычно приводит к теневому использованию: разработчики и аналитики подключают серверы самостоятельно, и компания теряет видимость. Практичнее разрешить MCP через реестр одобренных серверов и шлюз, одновременно технически блокируя неодобренные подключения к корпоративным данным. Для подразделений с особо чувствительными данными запрет может быть оправдан до появления контролируемой инфраструктуры.
Достаточно ли того, что сервер выпустил известный вендор?
Нет. Официальный сервер может быть честным, но возвращать модели текст от внешних лиц, как в случае с GitHub MCP, или содержать ошибки, как в случае с Asana. Кроме того, злоумышленники копируют названия официальных проектов. Проверка издателя необходима, но права, изоляция и мониторинг нужны в любом случае.
Решает ли проблему фильтр внедрения инструкций?
Частично. Классификаторы и разметка недоверенного содержимого снижают вероятность успешной атаки, но не гарантируют защиту: и OWASP, и совместное руководство CISA и партнёров называют внедрение инструкций трудноустранимым риском. Основная защита — архитектурная: минимальные права, разделение контекстов и подтверждение опасных действий человеком.
Что опаснее: локальные или удалённые MCP-серверы?
Риски разные. Локальный STDIO-сервер исполняет код с правами пользователя на рабочей станции и часто хранит долгоживущие ключи в файлах. Удалённый сервер зависит от защищённости вендора, его авторизации и изоляции клиентов, и может изменить поведение без вашего ведома. Для обоих нужны реестр и контроль, но локальным дополнительно нужна песочница, а удалённым — оценка поставщика и контроль токенов.
Кто в компании должен отвечать за MCP?
Политику и классы риска утверждает CISO, эталонную архитектуру и шлюз определяет ИТ-архитектура, а каждый сервер имеет бизнес- и технического владельца. Владельцы систем, к которым подключаются агенты, должны давать согласие на такой доступ. Учёт MCP целесообразно вести в общем реестре AI-систем.
С чего начать, если MCP уже используется?
С инвентаризации конфигураций на рабочих станциях и серверах и сверки с реестром. Затем отозвать широкие и долгоживущие токены, заменить их на ограниченные, отключить серверы из неизвестных источников и включить журналирование вызовов. После этого можно переходить к пилоту через шлюз.
Как MCP соотносится с требованиями российских регуляторов?
Для организаций, на которые распространяется приказ ФСТЭК России № 117, требования к защите при использовании технологий AI и к контролю взаимодействия пользователей с AI-сервисами применимы и к агентам с MCP. На практике это означает учёт таких интеграций, контроль передаваемых данных и использование только доверенных компонентов. Отдельных требований именно к MCP в открытых документах регулятора на момент публикации нет.