Как MCP защищает AI‑агентов: практический гид по безопасности и ред‑тестированию

Что такое MCP и почему это важно

Model Context Protocol (MCP) — открытый стандарт на базе JSON-RPC, который делает интеграции моделей и инструментов явными и проверяемыми. MCP определяет три примитива — инструменты, ресурсы и подсказки — и транспортные слои (stdio для локальных, Streamable HTTP для удалённых). Благодаря этому протоколу соединители перестают быть неявными компонентами и становятся первоклассными, инспектируемыми сущностями. Для команд безопасности это означает ясные границы доверия, аудитируемую авторизацию и воспроизводимые сценарии для ред‑тестирования.

Что стандартизует MCP

MCP-серверы публикуют три поверхности:

• Инструменты: типизированные действия, которые модель может вызвать.
• Ресурсы: объекты данных, которые клиент может получить и вставить в контекст.
• Подсказки (prompts): параметризуемые шаблоны сообщений, обычно инициируемые пользователем.

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

Транспорты и жизненный цикл

Спецификация задаёт stdio и Streamable HTTP и допускает расширения. Локальный stdio снижает сетевой экспозиции; Streamable HTTP поддерживает несколько клиентов и возобновляемые стримы. MCP формализует обнаружение возможностей сервера, согласование сессий и обмен сообщениями, что позволяет стандартизировать логирование и проверки предусловий/постусловий.

Нормативные правила авторизации

Требования к авторизации в MCP более жёсткие, чем в большинства интеграций, и их нужно применять строго:

• Никакого passthrough токенов. Серверы не должны пересылать токен, полученный от клиента; они действуют как OAuth 2.1 resource servers и принимают audience-bound токены, выданные по RFC 8707.
• Проверка audience. Сервер обязан валидации, что audience токена соответствует самому серверу, прежде чем обслуживать запрос.

Эти меры предотвращают атаки confused-deputy, сохраняют контроль и аудит upstream-сервисов и делают серверы полноценными субъектами с собственными учётными данными и журналами.

Практические преимущества для защиты

• Явные границы доверия: клиент/серверная граница становится местом для UI согласия, детального разрешения прав и структурированного аудита.
• Ограничение привилегий: серверы могут выдавать краткоживущие креденшелы и предоставлять узкие возможности вместо глобальных токенов.
• Детерминированные поверхности атак для ред‑тестов: типизированные схемы и воспроизводимые транспорты позволяют строить фикстуры и проверять постусловия последовательно.

Кейс: первый вредоносный MCP‑сервер

В конце сентября 2025 г. исследователи обнаружили троянский postmark-mcp npm-пакет, имитирующий Postmark email MCP‑сервер. Начиная с v1.0.16 вредоносная версия тихо BCC‑эксфильтровала все отправляемые через неё письма на адресы злоумышленников. Пакет удалили, рекомендовали удалить затронутую версию и сменить креденшелы.

Инцидент показывает, что MCP‑серверы часто работают с повышенным доверием и должны проходить проверку, версионироваться и контролироваться как привилегированные коннекторы. Практические выводы: поддерживать allowlist одобренных серверов и пинить версии и хэши, требовать доказуемого происхождения кода (подписи релизов, SBOM), мониторить еgress-образцы и практиковать вращение ключей и сценарии массового отключения.

Использование MCP в ред‑командах

Практические шаги для ред‑тестов:

1. Инъекции подсказок и проверка безопасной обработки вывода на границе инструментов. Вводите в систему враждебный корпус через ресурсы и проверяйте, что клиент санитизирует вывод, а сервер соблюдает постусловия.

2. Пробы confused-deputy. Пытаетесь заставить сервер использовать токен, выданный клиенту, или обращаться к нежелательной аудитории. Корректный сервер должен отвергать чужие audience-токены — успешная эксплуатация должна рассматриваться как критическая.

3. Тесты стойкости сессий и стримов. Проверяйте переподключение, возобновление и конкурентный доступ, чтобы выявить риски фиксации или перехвата сессий.

4. Практики цепочки поставок. В лаборатории вводите троянский сервер и проверяйте, ловят ли его allowlist, проверки подписи и мониторинг egress — измеряйте время обнаружения и MTTR для вращения креденшелов.

5. Базовые тесты на доверенных публичных серверах. Используйте проверенные публичные MCP‑серверы как стабильную платформу для воспроизводимых тестов.

Контрольный список для защиты (реализация)

Клиент:

• Показывать точную команду/конфигурацию запуска локального сервера; требовать явного согласия пользователя и перечислять включаемые инструменты/ресурсы.
• Вести allowlist серверов с пиннингом версий и контрольными суммами; по умолчанию блокировать неизвестные.
• Логировать каждый вызов инструмента и получение ресурса с метаданными для последующего анализа.

Сервер:

• Реализовать поведение OAuth 2.1 resource-server: валидировать токены и audience; не пересылать клиентские токены вверх по цепочке.
• Минимизировать scopes; отдавать предпочтение краткоживущим креденшелам и возможностям, кодирующим политику.
• Для локальных развёртываний отдавать предпочтение stdio в контейнере/песочнице и ограничивать файловую/сетевую активность; для удалённых — Streamable HTTP с TLS, лимитами и структурированными логами.

Обнаружение и реагирование:

• Сигнализировать о необычном egress (неожиданные адресаты, шаблоны BCC для почты) и резких изменениях возможностей между версиями.
• Подготовить автоматизацию для отзыва одобрений и быстрого вращения секретов при срабатывании алерта.

Управление и внедрение

Разделение ролей в MCP (клиенты как оркестраторы, серверы как ограниченные субъекты) хорошо соотносится с рекомендациями NIST AI RMF и OWASP LLM. Используйте эти фреймворки для обоснования мер безопасности и критериев приёмки MCP‑интеграций.

Текущая доступность для тестирования

Ряд реализаций предоставляет практические поверхности для тестирования: экосистема Claude, Google Data Commons MCP как источник стабильных наборов данных и Delinea MCP как пример брокера секретов с принципами минимальных прав. Эти серверы подходят для построения детерминированных задач и проверки политик.

Главная мысль

MCP не заменит продукт безопасности, но даёт практические рычаги: audience-bound токены, явные границы клиент/сервер, типизированные схемы инструментов и транспорты, которые можно инструментировать. Относитесь к MCP‑серверам как к привилегированным коннекторам — проверяйте, пиньте и мониторьте их, и используйте MCP для наблюдаемости и воспроизводимости атакующих сценариев.