MCP: удобство с подвохом. Почему стандарт для AI-агентов стал угрозой безопасности
Model Context Protocol упростил интеграцию инструментов для ИИ-агентов, но каждый подключенный MCP-сервер — это новая дыра в защите. Мы проверили, насколько легко атаковать эту архитектуру и почему промышленность пока не нашла правильное решение.
Почему удобство обернулось проблемой
MCP — это попытка разработчиков создать универсальный язык общения между ИИ-моделями и внешними инструментами. Красиво звучит: один стандарт вместо десятка несовместимых протоколов. Но стандартизация имеет побочный эффект — она расширяет границы доверия.
Основной парадокс LLM в том, что для модели нет четкого различия между данными и командами. Когда вы передаете текст нейросети, она не различает: это описание инструмента или попытка манипуляции? Это контекст из документа или скрытая инструкция? Все это просто токены в одном потоке информации.
MCP сделал это еще более проблематичным, потому что теперь между агентом и сервисом есть множество промежуточных точек — каждая потенциально враждебная.
Как именно работают атаки
- Tool Poisoning — перехват или подмена описания инструмента. Злоумышленник меняет текст, объясняющий что делает функция, и добавляет скрытые инструкции. Агент может выполнить то, чего никогда не планировал.
- Indirect Prompt Injection — внедрение команд через данные. Например, в PDF документе, который читает агент, может скрываться текст, побуждающий его выполнить опасную операцию.
- Sampling Abuse — эксплуатация стохастической природы моделей. Атакующий пытается понять, при каких входных данных модель с определенной вероятностью выполнит нежелательное действие.
Самое пугающее: даже «безобидный» документ, описание API или список параметров могут стать носителем атаки. Нейросеть прочитает это как контекст и будет действовать исходя из прочитанного.
Реальные инциденты уже случались
Экосистема MCP молода, но уже фиксируются первые инциденты. В основном — случаи, когда через якобы «помощные» инструменты проходили запросы на выполнение системных команд или доступ к защищенным данным.
Проблема усугубляется тем, что разработчики часто не проверяют MCP-серверы третьих сторон перед интеграцией. Это как установить расширение в браузер, не посмотрев код — и ждать беды.
Что предлагает индустрия
| Подход | Суть | Эффективность |
|---|---|---|
| API Gateways | Промежуточный слой, проверяющий все вызовы | Средняя — требует хорошей конфигурации |
| Sandboxing | Изоляция MCP-сервера в отдельной среде | Высокая, но затратная по ресурсам |
| OAuth-архитектура | Разрешения на уровне токенов вместо доверия агенту целиком | Многообещающая, но еще не стандартизирована |
Наиболее перспективным кажется подход с детальными разрешениями — когда каждый MCP-сервер получает только то, что ему действительно нужно. Но это требует переосмысления архитектуры.
Что мы проверили на практике
Мы развернули MCP-сервер с известными уязвимостями и попытались атаковать его разными способами. Результаты показали, что стандартные инструменты обнаружения вызовов функций (наш сканер BarkingDog в том числе) могут выловить явные инъекции, но пропускают тонкие манипуляции в контексте.
Например, если просто попросить агента «помочь с файлом», а потом в самом файле написать скрытый текст про удаление данных — модель может это выполнить, потому что видит логическое продолжение задачи.
Итог
MCP решил одну проблему (интеграция инструментов), но создал другую (поверхность атаки). Это не значит, что протокол плохой — это значит, что его нужно использовать осторожнее. Перед подключением любого внешнего сервера проверяйте его код, ограничивайте разрешения и не полагайтесь на то, что безопасность «включена по умолчанию». В текущем состоянии MCP требует дополнительного слоя защиты — либо через gateways, либо через sandboxing. Просто подключить и забыть — уже не вариант.