Model Context Protocol дал разработчикам единый язык для подключения AI-агентов к внешним инструментам. Но вместе с удобством пришла системная дыра: каждый новый сервер - это новая точка входа для атаки, а языковая модель по-прежнему не умеет отличить команду от данных.
Откуда растёт угроза
Проблема не в самом протоколе. Промпт-инъекции существовали задолго до MCP. Но стандарт резко умножил число акторов, чей текст попадает в контекст модели. Открываешь страницу, читаешь файл, тянешь данные из базы - всё это агент воспринимает как доверенный ввод. Встроенного механизма, чтобы отличить легитимный ответ инструмента от инструкции, спрятанной внутри него, у LLM нет. Это не баг реализации. Это архитектурное ограничение.
Спецификация MCP сама это фиксирует: описания инструментов должны считаться недоверенными, если сервер не верифицирован. То есть подключение через протокол само по себе не даёт оснований доверять содержимому. Осознание проблемы есть. Решения - пока нет.
Пять способов сломать агента
За последний год вокруг MCP сложилось целое поле исследований безопасности. Сценарии атак разные, но механика одна - модель делает то, чего пользователь не просил.
- Tool Poisoning. В описание стороннего инструмента прячут скрытую инструкцию. Пользователь спрашивает погоду - агент заодно тихо вытягивает историю заказов.
- Confused Deputy. Агент передаёт чужой идентификатор серверу, который не проверяет, кто реально авторизован. Классическая подмена полномочий, только теперь через AI-посредника.
- Indirect Prompt Injection. Текст внутри документа - баг-репорта, таблицы, FAQ - воспринимается моделью не как данные для пересказа, а как инструкция к исполнению. Известен реальный случай: агент читал отчёт через внешний MCP-сервер и выполнил команду, замаскированную под техническое решение.
- Sampling Abuse. MCP позволяет серверу самому инициировать запрос к модели хоста. Это открывает возможность для скрытых инъекций, незаметного запуска инструментов и истощения AI-квоты.
- Rug Pull. Инструмент меняется после того, как пользователь его одобрил. Имя и сигнатура прежние - поведение другое. Повторного подтверждения клиент не запрашивает.
Как индустрия затыкает дыру
Фундаментальную проблему никто не решил. Зато выстроили защиту снаружи. Появился целый класс продуктов - MCP-гейтвеи. Трафик между агентом и сервером идёт через прокси, который проверяет права, ведёт аудит-лог и применяет политику до того, как запрос достигает внешней системы.
Параллельно ужесточилась авторизация: свежая версия спецификации требует OAuth 2.0 с федеративными identity-провайдерами как базовый стандарт для enterprise-окружений. Ранние версии оставляли авторизацию на усмотрение каждого сервера - разнобой был полный. Третий слой - изоляция: каждый MCP-сервер запускается в отдельном контейнере с урезанным доступом к файловой системе, образы подписываются криптографически.
Но единого верифицированного реестра серверов до сих пор нет. Экосистема раздроблена между десятками независимых площадок. Анализ почти 1900 открытых MCP-серверов показал: сканирование безопасности нужно встраивать прямо в процесс регистрации, а не оставлять каждому гейтвею разбираться самостоятельно. Пока это рекомендация. Не стандарт.
