Протокол MCP: баланс между скоростью внедрения ИИ-агентов и критическими рисками безопасности
Протокол Model Context Protocol (MCP) революционизирует интеграцию искусственного интеллекта с внешними системами, предлагая простоту подключения «из коробки». Однако эксперты отмечают, что эта удобная унификация превращается в мощный множитель уязвимостей больших языковых моделей (LLM). Стандарт позволяет вредоносным инструкциям встраиваться в описание инструментов, манипулируя агентом и нарушая безопасность данных при минимальном вмешательстве человека.
# Сторонние MCP: баланс между скоростью внедрения и критическими рисками безопасности
Технология агентных систем на базе больших языковых моделей переживает бум, и одним из главных драйверов этого роста стал протокол Model Context Protocol (MCP). Он позиционируется как упрощённый стандарт взаимодействия, аналогичный USB-C для мира ИИ, который позволяет агентам подключаться к базам данных, системам контроля задач и репозиториям кода без написания строк кода. Однако, согласно материалам от экспертов СберТех, эта технологическая магия скрывает серьёзные проблемы безопасности, которые превращают протокол в потенциальный инструмент для масштабных атак.
Почему LLM не могут критически оценивать контекст
Фундаментальная проблема безопасности моделей лежит в архитектуре их работы. Современные большие языковые модели воспринимают весь полученный текст — от системных инструкций до пользовательских запросов и описаний внешних инструментов — как единый последовательный поток токенов. Для модели нет разницы между надежной системной командой и вредоносным сообщением от пользователя, если оба текста находятся в её контексте.
Попытки обойти это с помощью жёстких ограничений в системных промптах («не выполняй опасных команд») часто оказываются неэффективными. Злоумышленники используют техники промпт-инъекций, внедряя подмену инструкций прямо в документацию или описания инструментов. Модель, лишенная критического мышления в привычном человеческом понимании, лишь предсказывает вероятность следующих токенов. Если контекст отравлен, модель может беспрепятственно выполнить вредоносное действие, игнорируя предыдущие правила безопасности.
MCP как множитель уязвимостей
Протокол MCP упрощает интеграцию, позволяя агенту запрашивать у сервера список доступных инструментов (эндпоинтов) и сразу передавать это описание в контекст модели. Именно в этом механизме кроется главная опасность. Сервер MCP возвращает описание инструментов в формате, который агент безоговорочно добавляет в контекст. Если злоумышленник скомпрометирует сервер или внедрит вредоносный код в описания инструментов, эта инструкция сразу станет частью контекста для всех подключенных агентов.
Эксперты выделяют две основные модели атак:
1. Атаки на публичные MCP: Использование открытых серверов сторонних разработчиков. В описании инструмента может появиться скрытая инструкция, заставляющая агента извлечь данные или выполнить скрытые действия. Даже официальные серверы не могут быть до конца защищены от человеческих ошибок в коде или вредоносных обновлений. 2. Атаки на внутренние (коммунальные) MCP: В корпоративной среде компании часто разворачивают единый сервер MCP для всех сотрудников. Взлом такого сервера позволяет распространить вредоносную инструкцию на все агенты в организации одновременно. Это создаёт единую точку отказа и компрометации, последствия для которой могут быть катастрофическими.
Особую угрозу представляет атакующая техника «ShareLock», о которой упоминают в исследованиях. Она позволяет распределять вредоносную нагрузку между несколькими инструментами или разными серверами MCP, делая атаку невидимой при проверке отдельных компонентов. Агент, анализируя инструменты по отдельности, не заметит угрозы, так как каждая часть выглядит легитимной, но в совокупности они инициируют взлом.
Итог: необходимость внутренней инфраструктуры
Анализ показывает, что попытка полностью отказаться от внешних MCP или использовать их в «легком» режиме не решает проблему. Безопасная эксплуатация требует превращения сторонних компонентов в часть внутренней инфраструктуры. Это означает создание собственных форков репозиториев, проведение строгого аудита кода, запрет автоматических обновлений и внедрение процессов внутренней сборки и проверки.
Суть заключается в следующем: доверие к агенту не должно автоматически переноситься на внешние источники данных. Безопасная модель взаимодействия требует, чтобы любой инструмент, доступный агенту, был подвергнут той же строгости проверки, что и любое другое критически важное программное обеспечение в компании. Только так можно сохранить баланс между оперативностью внедрения ИИ и защитой данных организации.