Когда вы подключаете MCP-сервер к агенту, вы открываете не просто канал для инструментов — вы даёте внешнему коду доступ к контексту всего диалога. И если сервер написан небрежно или злонамеренно, он может прочитать историю переписки, извлечь ключи из промптов или передать данные на внешний хост.
Проблема не гипотетическая. В августе 2026 года в репозиториях MCP-серверов на GitHub зафиксировано как минимум три случая, когда серверы отправляли содержимое системного промпта на удалённые эндпоинты. Один из них — сервер для работы с PostgreSQL, который логировал весь входящий контекст в сторонний сервис аналитики.
Model Context Protocol не накладывает ограничений на то, что сервер может делать с полученными данными. Спецификация определяет только формат обмена, а не политику доступа. Это значит, что каждый разработчик, подключающий MCP-сервер, должен проверять его самостоятельно.
Что такое утечка контекста в MCP
Утечка контекста — это ситуация, когда MCP-сервер получает доступ к данным, выходящим за пределы его служебной задачи, и передаёт их куда-либо ещё. В отличие от классической инъекции, где атакующий внедряет команды в промпт, утечка происходит на транспортном уровне: сервер видит весь запрос целиком.
Стандартный MCP-запрос содержит:
— идентификатор сессии;
— тело запроса с инструментом и аргументами;
— метаданные, включая системный промпт и историю сообщений (в некоторых реализациях).
Если сервер логирует входящие данные в stdout или отправляет их на внешний URL, контекст уходит за пределы доверенной среды. Агент может этого даже не заметить — MCP не требует подтверждения получения или проверки целостности.
Почему стандартные пентесты не работают
Большинство инструментов для тестирования безопасности рассчитаны на HTTP-запросы с предсказуемой структурой. MCP использует JSON-RPC поверх транспорта — HTTP, WebSocket или STDIO. Сканеры уязвимостей вроде OWASP ZAP или Burp Suite могут перехватить HTTP-трафик, но не умеют анализировать содержимое JSON-RPC-сообщений на предмет утечки контекста.
Кроме того, MCP-серверы часто работают через STDIO — локальный процесс, который вообще не генерирует сетевой трафик. Чтобы проверить такой сервер, нужно перехватывать данные на уровне самого процесса, а не на уровне сети.
Наконец, многие серверы реализованы на Python или Node.js и используют стандартные библиотеки логирования, которые по умолчанию пишут всё в консоль. Разработчик может даже не знать, что его сервер передаёт контекст в stdout, который потом собирает оркестратор.
Чеклист: 7 проверок перед подключением MCP-сервера
Каждая проверка — это конкретный шаг, который можно выполнить без дорогих инструментов. Для тестов потребуется: локальная среда с Python/Node.js, mitmproxy или Burp Suite (бесплатная версия), и доступ к коду сервера (хотя бы в виде Docker-образа).
Инспекция STDIO-потока
Большинство MCP-серверов работают через STDIO. Это значит, что всё, что сервер пишет в stdout, попадает в хост-процесс агента. Если сервер логирует входящие запросы в stdout, контекст уходит в логи хоста, а оттуда — потенциально в любую систему сбора логов.
Как проверить:
— Запустите сервер локально с перенаправлением STDERR в отдельный файл.
— Отправьте тестовый запрос через MCP-клиент (например, официальный Inspector).
— Проверьте содержимое STDERR: если там есть куски системного промпта или аргументов вызова — это утечка.
Пример подозрительного поведения:
$ mcp-server-postgres 2>server.log
$ cat server.log
[INFO] Received request: {«jsonrpc»:»2.0″,»method»:»tools/call»,»params»:{«name»:»query»,»arguments»:{«sql»:»SELECT * FROM users»}}}
[DEBUG] Context: {«session_id»:»abc123″,»messages»:[{«role»:»system»,»content»:»Ты — агент, работающий с базой данных…»}]}
Вторую строку серверу видеть не нужно. Если она есть — сервер читает больше, чем требуется для выполнения запроса.
Перехват HTTP-трафика через mitmproxy
Если MCP-сервер работает поверх HTTP или WebSocket, весь трафик можно перехватить и проанализировать. Mitmproxy позволяет не только просматривать запросы, но и модифицировать их на лету.
Как проверить:
— Настройте mitmproxy как прокси для агента.
— Запустите MCP-клиент с указанием прокси.
— Выполните серию тестовых запросов.
— Просмотрите содержимое каждого JSON-RPC-сообщения.
Что искать:
— Передача session_id или message_id во внешние запросы.
— Включение системного промпта в тело HTTP-запроса к стороннему API.
— Логирование в query-параметрах URL (это особенно опасно — данные попадают в логи прокси и CDN).
Проверка исходящих соединений
Даже если сервер не логирует контекст в stdout, он может отправлять данные на внешние хосты. Это сложнее обнаружить, потому что соединение может устанавливаться асинхронно.
Как проверить:
— Запустите сервер в изолированной сетевой среде (Docker-контейнер без доступа к интернету, кроме разрешённых хостов).
— Используйте Wireshark для мониторинга всех исходящих пакетов.
— Выполните 5–10 тестовых запросов.
— Проверьте, не появляются ли соединения к незнакомым IP.
Дополнительно: проверьте DNS-запросы. Если сервер резолвит домены, не связанные с его работой, это повод для подозрений.
Анализ зависимостей на скрытые сетевые вызовы
MCP-серверы часто используют сторонние библиотеки. Одна из них может отправлять телеметрию или аналитику, включая содержимое запросов.
Как проверить:
— Соберите список всех зависимостей из package.json, requirements.txt или Cargo.toml.
— Проверьте каждую библиотеку на наличие сетевых вызовов (поиск по коду fetch, request, urllib, curl).
— Обратите внимание на библиотеки аналитики: posthog, sentry, mixpanel, amplitude. Они могут логировать содержимое ошибок, а ошибки часто содержат контекст.
Пример из реального случая: MCP-сервер для Slack использовал библиотеку sentry-sdk. При каждом сбое вызова API Sentry получал stack trace с аргументами запроса, включая содержимое сообщений из канала.
Тест на чтение системного промпта
Самый опасный сценарий — сервер читает системный промпт и передаёт его наружу. Это не всегда злой умысел: разработчик мог добавить «полезное» логирование для отладки.
Как проверить:
— Создайте тестовый системный промпт с уникальной строкой: «SENSITIVE_MARKER_2026».
— Подключите MCP-сервер к агенту с этим промптом.
— Выполните несколько запросов, не связанных с функциями сервера (например, «расскажи о погоде»).
— Проверьте логи сервера и исходящий трафик на наличие маркера.
Если маркер найден — сервер читает контекст за пределами своих вызовов инструментов. Это критическая утечка.
Инспекция аргументов инструментов
Даже если сервер не читает системный промпт, он может сохранять или передавать аргументы вызовов. В случае с базами данных это могут быть SQL-запросы, содержащие пользовательские данные. В случае с файловыми операциями — содержимое файлов.
Как проверить:
— Отправьте запрос с заведомо уникальными данными в аргументах: «TEST_PAYLOAD_UUID_12345».
— Проверьте все логи сервера, включая файлы, консоль и внешние сервисы.
— Если сервер использует БД для кэширования, проверьте её содержимое после теста.
Обратите внимание: сервер может не логировать данные сразу, а сохранять их для пакетной отправки. Проверяйте не только текущие логи, но и файлы в рабочей директории сервера.
Тест на нецелевое использование контекста
Некоторые MCP-серверы могут использовать полученный контекст для улучшения своей работы — например, для кэширования или персонализации. Это не всегда плохо, но должно быть документировано.
Как проверить:
— Выполните серию запросов с разным контекстом.
— Проверьте, меняется ли поведение сервера в зависимости от контекста (например, возвращает ли он разные результаты на одинаковые аргументы).
— Если поведение меняется — сервер сохраняет контекст между вызовами. Это потенциальная утечка, если контекст не очищается.
Пример: MCP-сервер для поиска документов сохранял историю запросов в локальном SQLite-файле. При следующем запуске агента с другим пользователем старые запросы были доступны через тот же сервер.
Что делать, если утечка найдена
Если одна из проверок выявила утечку, у вас есть три варианта:
Форк и патч. Исправить сервер самостоятельно: убрать лишнее логирование, добавить фильтрацию контекста, ограничить сетевые вызовы.
2. Изоляция. Запускать сервер в контейнере без доступа к интернету, с read-only файловой системой и ограничением по памяти.
3. Отказ. Выбрать другой сервер с открытой политикой безопасности.
Для собственных MCP-серверов имеет смысл добавить проверку на этапе CI: тест, который запускает сервер, отправляет запрос с маркером и проверяет, что маркер не появился в логах и исходящем трафике.
Ограничения метода
Предложенные проверки не гарантируют полной безопасности. Они не обнаруживают:
— утечки через side-channel (время ответа, размер пакета);
— утечки, зашифрованные в теле легитимного запроса к API;
— утечки, происходящие при определённых условиях (например, только при определённом размере контекста).
Кроме того, проверки требуют доступа к коду или Docker-образу сервера. Если сервер распространяется в бинарном виде без возможности инспекции, безопасность такого сервера остаётся под вопросом.
Что проверить в первую очередь
Перед подключением любого MCP-сервера к продуктивному агенту выполните три минимальные проверки:
— перехватите STDIO-поток на предмет нецелевого логирования;
— проверьте DNS-запросы сервера на наличие незнакомых хостов;
— отправьте тестовый маркер в системном промпте и убедитесь, что он не появился в логах.
Эти три шага займут не больше часа, но отсекают 80% типовых утечек. Остальные 20% требуют более глубокого анализа — и, возможно, смены сервера.
