Model Context Protocol (MCP) становится стандартом де-факто для подключения AI-агентов к внешним данным и инструментам. Но каждый подключённый MCP-сервер — это не просто новый навык агента, а прямой канал доступа к файловой системе, базе данных или внешнему API. Если сервер настроен с избыточными правами или содержит уязвимости, агент может случайно (или целенаправленно) выполнить действия, которые вы не планировали.
Разберём, какие проверки нужно выполнить до того, как подключать MCP-сервер к рабочему агенту.
Что проверять в конфигурации до первого запуска
MCP-сервер получает от клиента (хоста) два ключевых параметра: список разрешённых инструментов и контекст текущего диалога. Но сервер также может запрашивать собственные ресурсы — файлы, записи в базе, данные из API. Именно здесь начинаются риски.
Первый шаг — проверка самого файла конфигурации сервера. В стандартной реализации MCP сервер запускается через `uvx` или `npx`, и его аргументы часто передаются в параметрах `args`. Если сервер принимает аргументы, которые могут быть переопределены извне — например, путь к базе данных или токен доступа — это потенциальная точка входа для атаки.
Второй шаг — проверка того, какие ресурсы сервер объявляет в своей схеме. MCP-сервер обязан предоставить JSON-схему всех доступных инструментов и ресурсов через эндпоинт `listTools` и `listResources`. Если сервер объявляет доступ к файловой системе без ограничения по директориям — это красный флаг.
Тестирование утечки контекста: как проверить, что сервер не передаёт лишнее
Один из самых опасных сценариев — MCP-сервер, который не фильтрует контекст, отправляемый от клиента. В спецификации MCP нет требования проверять, какие именно данные из промпта попадают в запрос к серверу. Это значит, что агент может передать весь диалог, включая предыдущие инструкции, API-ключи или личные данные, в вызов инструмента.
Как это проверить:
Запустите MCP-сервер в тестовом окружении с доступом к файловой системе.
Отправьте запрос с инструментом `read_file`, передав в промпт тестовый секрет: «Мой API-ключ: sk-test-12345».
3. Проверьте, что сервер не выводит этот ключ в логах или в теле ответа, если это не предусмотрено функцией инструмента.
4. Если сервер логирует весь входящий контекст — считайте это уязвимостью.
Хорошая практика — передавать серверу только минимально необходимые данные. Если инструменту для работы нужен только путь к файлу, не передавайте весь текст диалога.
Проверка прав доступа: что сервер может делать с вашими данными
MCP-серверы, предоставляющие доступ к файловой системе, базам данных или API, должны работать с минимально возможными привилегиями. Но на практике многие серверы из репозиториев сообщества настроены на полный доступ.
Для файловых серверов:
- Проверьте, ограничен ли доступ конкретной директорией. В спецификации MCP есть параметр `rootUri`, который должен задавать корневую папку. Если сервер не проверяет этот параметр или игнорирует его — он может читать и записывать файлы за пределами разрешённой зоны.
- Запросите тестовое чтение файла за пределами `rootUri` — например, `/etc/passwd` на Linux. Если сервер возвращает содержимое — он небезопасен.
Для серверов баз данных:
- Убедитесь, что сервер использует отдельного пользователя БД с правами только на чтение (или только на конкретные таблицы). Если сервер подключается под административной учётной записью, один SQL-инъекционный запрос может уничтожить данные.
- Проверьте, экранирует ли сервер входные параметры перед передачей в SQL-запрос. Отправьте тестовый запрос с кавычками и точкой с запятой — если сервер выполняет несколько запросов, это уязвимость.
Инъекции в инструменты: как проверить, что сервер не выполняет команды оболочки
MCP-серверы часто используют вызовы shell-команд или системных утилит для выполнения задач. Если сервер не экранирует аргументы, злоумышленник может внедрить произвольную команду через поле, которое агент передаёт как параметр инструмента.
Пример уязвимого сценария: сервер принимает имя файла и передаёт его в `cat {filename}`. Если имя файла содержит `; rm -rf /`, команда выполнит удаление.
Как проверить:
Найдите инструмент сервера, который принимает строковый параметр (например, имя пользователя, путь, идентификатор).
2. Передайте в него строку с shell-метасимволами: `$(whoami)`, « `whoami` «, `; echo injected`.
3. Проверьте вывод сервера и логи. Если команда выполнилась — сервер уязвим к инъекции.
Безопасные серверы либо не используют shell-вызовы вообще, либо экранируют все аргументы через специализированные библиотеки (например, `shlex.quote` в Python или `execFile` в Node.js вместо `exec`).
Ограничение сетевого доступа: что делать, если сервер ходит в интернет
MCP-сервер может иметь доступ к внешним API — например, для поиска в интернете или вызова сторонних сервисов. Но если сервер не ограничивает сетевые запросы, он может отправлять данные на произвольные хосты.
Минимальные меры:
- Запускайте MCP-сервер в изолированной сетевой зоне (контейнер, виртуальная машина) без доступа к внутренним корпоративным ресурсам.
- Если сервер не требует внешнего доступа, блокируйте исходящие соединения через firewall или сетевые политики контейнера.
- Для серверов, которым нужен доступ к конкретному API, используйте прокси с белым списком доменов.
Проверка: запустите сервер, выполните его инструмент и проверьте, к каким хостам он обращается (через `tcpdump`, `Wireshark` или логи сетевого трафика). Если сервер делает запросы к неожиданным доменам — это повод для дополнительного анализа.
Чеклист перед подключением MCP-сервера в продакшен
Соберите эти проверки в регулярный процесс:
Проверка конфигурации: сервер не принимает внешние аргументы, которые могут переопределить настройки безопасности.
2. Ограничение ресурсов: сервер объявляет только необходимые инструменты, не открывает доступ к файловой системе без ограничения по `rootUri`.
3. Тест на утечку контекста: сервер не логирует и не передаёт лишние данные из промпта.
4. Проверка прав доступа: сервер использует минимальные привилегии для работы с файлами, БД или API.
5. Тест на инъекции: сервер экранирует shell-аргументы или не использует shell-вызовы.
6. Сетевая изоляция: сервер работает в изолированном окружении с контролем исходящих соединений.
7. Обновление зависимостей: сервер использует актуальные версии библиотек без известных уязвимостей.
Эти проверки не гарантируют абсолютную безопасность, но снижают вероятность того, что MCP-сервер станет вектором атаки на вашу инфраструктуру. Если вы используете сервер из публичного репозитория — проверяйте его код перед запуском. Если разрабатываете свой — закладывайте безопасность на этапе проектирования инструментов, а не после инцидента.
