Model Context Protocol (MCP) стал де-факто стандартом для подключения внешних инструментов к ИИ-агентам. Claude Desktop, Copilot, продолжающие появляться open-source фреймворки — все они используют MCP для доступа к файлам, базам данных, API и выполнению команд.
Проблема в том, что MCP-сервер получает от агента запросы и выполняет их от своего имени. Если сервер сконфигурирован с избыточными правами или содержит уязвимость, агент может случайно или намеренно выполнить деструктивную операцию. Официальная документация протокола описывает архитектуру, но не даёт готового чек-листа безопасности.
Разберём, как проверить MCP-сервер перед тем, как подключать его к рабочему агенту.
Что именно делает MCP-сервер и где скрыта угроза
MCP-сервер — это процесс, который принимает от агента JSON-RPC запросы и возвращает результаты. Сервер регистрирует набор tools — функций, которые агент может вызывать. Каждый tool описывается именем, описанием и схемой входных параметров в формате JSON Schema.
Угроза не в самом протоколе, а в том, какие tools регистрирует сервер и с какими правами он запущен. Если сервер запущен с правами root и регистрирует tool для выполнения произвольных shell-команд, агент может выполнить любую операцию в системе.
Официальная спецификация MCP (версия 2025-03-26) определяет механизмы безопасности только на уровне транспорта: шифрование для SSE-соединений, аутентификацию через заголовки. Внутренняя безопасность tools — ответственность разработчика сервера.
Статический анализ конфигурации MCP-сервера
Первый шаг — проверить конфигурацию сервера до его запуска. В Claude Desktop конфигурация хранится в файле `claude_desktop_config.json`. Разберём типичный пример:
json
{
«mcpServers»: {
«filesystem»: {
«command»: «npx»,
«args»: [«-y», «@modelcontextprotocol/server-filesystem», «/home/user/projects»]
},
«sqlite»: {
«command»: «uvx»,
«args»: [«mcp-server-sqlite», «—db-path», «/data/production.db»]
}
}
}
Что проверяем:
Путь к исполняемому файлу. `npx -y` запускает пакет без подтверждения — это удобно, но означает, что сервер будет обновлён до последней версии при первом запуске. Для production лучше указывать конкретную версию пакета.
Аргументы командной строки. В примере server-filesystem получает путь `/home/user/projects`. Это ограничивает доступ агента только этой директорией. Если путь опущен или указан `/`, агент получит доступ ко всей файловой системе.
Источник пакета. Официальные серверы из репозитория `@modelcontextprotocol` проходят базовую проверку сообществом. Сторонние серверы из npm или GitHub требуют отдельного аудита.
Для автоматизации проверки можно написать небольшой скрипт, который парсит JSON-конфигурацию и проверяет пути и команды на соответствие политике безопасности.
Аудит зарегистрированных tools: что агент может вызвать
После запуска сервера агент получает список tools через метод `tools/list`. Этот список можно запросить вручную, используя MCP Inspector — официальный инструмент от разработчиков протокола.
Установка и запуск:
bash
npx @modelcontextprotocol/inspector node path/to/server.js
Inspector открывает веб-интерфейс, где можно:
- Просмотреть все зарегистрированные tools с их схемами
- Вызвать любой tool с произвольными параметрами
- Посмотреть, какие ресурсы и промпты сервер предоставляет
Что ищем:
- Tools с опасными названиями: `exec_command`, `run_shell`, `write_file`, `delete`, `drop_table`
- Схемы без ограничений: если параметр `path` принимает строку без валидации, агент может запросить доступ к любому файлу
- Tools без описания: если tool не имеет понятного описания, агент может вызвать его непреднамеренно
Пример опасной схемы:
json
{
«name»: «execute_command»,
«description»: «Выполняет shell-команду»,
«inputSchema»: {
«type»: «object»,
«properties»: {
«command»: {
«type»: «string»
}
},
«required»: [«command»]
}
}
Здесь нет никаких ограничений на команду — агент может выполнить `rm -rf /` при соответствующем уровне доступа процесса.
Тестирование в изолированной среде
Перед подключением MCP-сервера к рабочему агенту стоит запустить его в изолированном окружении. Это позволяет проверить поведение сервера без риска для production-данных.
Варианты изоляции:
Docker-контейнер. Запустите сервер в контейнере с минимальными правами, без сетевого доступа к внутренним сервисам и с read-only файловой системой, кроме явно смонтированных директорий.
Песочница на уровне ОС. В Linux можно использовать `bubblewrap` или `firejail` для ограничения доступа процесса.
Виртуальная машина. Самый надёжный, но ресурсоёмкий вариант.
Пример запуска server-filesystem в Docker:
bash
docker run —rm -i \
—read-only \
—tmpfs /tmp \
-v /home/user/test-data:/data:ro \
node:20 \
npx @modelcontextprotocol/server-filesystem /data
Здесь контейнер запускается с read-only корневой файловой системой, временной директорией в памяти и монтированием тестовой директории только для чтения.
В изолированной среде выполните типичные запросы, которые агент может отправить: чтение файлов, запись, выполнение команд. Проверьте, что сервер не выходит за пределы разрешённой зоны.
Проверка сетевой активности и внешних вызовов
Некоторые MCP-серверы обращаются к внешним API. Это нормально для серверов, которые предоставляют доступ к погоде, поиску или базам знаний. Но сервер может отправлять данные на внешние серверы без ведома пользователя.
Для проверки используйте сетевой мониторинг:
Запустите сервер с прокси-перехватчиком. Например, `mitmproxy` для HTTP/HTTPS трафика.
Проверьте DNS-запросы. Утилита `strace` или `tcpdump` покажет, к каким хостам обращается сервер.
Заблокируйте сетевой доступ. Если сервер не требует внешних вызовов, запускайте его с `—network none` в Docker или с блокировкой сетевого доступа через iptables/nftables.
Официальные серверы от Anthropic обычно не имеют внешних сетевых вызовов, кроме загрузки пакетов при установке. Сторонние серверы могут отправлять телеметрию, логи или, в худшем случае, данные пользователя.
Ограничение доступа к файловой системе
Самый частый кейс использования MCP — доступ к файлам. Server-filesystem принимает список разрешённых директорий как аргументы командной строки. Но не все серверы реализуют такую проверку.
Что проверять:
- Символические ссылки. Если сервер разрешает доступ к директории, но не проверяет символические ссылки, агент может прочитать файлы за пределами разрешённой зоны. Проверьте, обрабатывает ли сервер `readlink` перед доступом к файлу.
- Обход пути. Попробуйте запросить файл с путём `../../etc/passwd`. Если сервер не нормализует путь, агент получит доступ к системным файлам.
- Маскировка файлов. Некоторые серверы проверяют только префикс пути. Запрос `/home/user/projects/../../etc/shadow` может пройти проверку, если сервер не канонизирует путь.
Пример теста:
bash
# Запрос через MCP Inspector
# tool: read_file
# arguments: {«path»: «/home/user/projects/../../../etc/passwd»}
# Ожидаемый результат: ошибка или отказ
Если сервер возвращает содержимое файла — он небезопасен для использования с агентами, которые работают с конфиденциальными данными.
Мониторинг логов и поведения в production
После проверки и подключения сервера к агенту стоит настроить мониторинг. MCP-серверы логируют запросы и ответы. Эти логи можно собирать и анализировать на предмет аномалий.
Что логировать:
- Каждый вызов tool с параметрами
- Время выполнения
- Размер ответа
- Ошибки и исключения
Пример простого логгера для MCP-сервера на Node.js:
javascript
const originalHandler = server.toolHandler;
server.toolHandler = async (request) => {
console.log(JSON.stringify({
timestamp: new Date().toISOString(),
tool: request.params.name,
args: request.params.arguments,
user: process.env.USER
}));
return originalHandler(request);
};
В production стоит отправлять логи в централизованную систему (ELK, Grafana Loki) и настроить алерты на необычные паттерны: массовое чтение файлов, попытки доступа к системным директориям, вызовы опасных tools.
Что делать, если сервер небезопасен
Если проверка выявила проблемы, варианты действий:
Ограничить конфигурацию. Запустите сервер с минимальными правами и явно укажите разрешённые пути или операции.
Использовать прокси-сервер. Напишите обёртку, которая перехватывает вызовы tools и проверяет их на соответствие политике безопасности перед передачей целевому серверу.
Выбрать альтернативу. В официальном репозитории MCP-серверов есть несколько реализаций для одних и тех же задач. Если один сервер небезопасен, проверьте другой.
Написать свой сервер. Для специфических задач проще написать минимальный MCP-сервер, который предоставляет только необходимые tools с жёсткими ограничениями.
Практические выводы
Проверка безопасности MCP-сервера перед подключением к агенту — не разовая акция, а процесс, который стоит повторять при каждом обновлении сервера или изменении конфигурации.
Краткий чек-лист перед подключением:
- [ ] Проверен source-код или происхождение пакета сервера
- [ ] Выполнен статический анализ конфигурации
- [ ] Просмотрен список tools через MCP Inspector
- [ ] Проведено тестирование в изолированной среде
- [ ] Проверена сетевая активность сервера
- [ ] Протестированы попытки обхода ограничений файловой системы
- [ ] Настроено логирование и мониторинг
Спецификация MCP продолжает развиваться, и в будущих версиях могут появиться встроенные механизмы безопасности. Но пока ответственность за безопасность лежит на разработчике, который подключает сервер к агенту.
Если вы используете MCP-серверы в production, имеет смысл вести внутренний реестр проверенных серверов с указанием версии, даты проверки и ограничений доступа. Это упростит аудит и снизит риск случайного подключения непроверенного сервера.