Новое исследование показывает, что Model Context Protocol (MCP) — интерфейс, позволяющий агентам на базе больших языковых моделей (LLM) вызывать внешние инструменты — может быть взломан с помощью атак типа «tool-poisoning» (отравление инструментов), которые срабатывают более чем в трети случаев. В 20 популярных агентах средний показатель успеха составил 36,5%; модель o1-mini поддалась в 72,8% попыток, в то время как Claude-3.7-Sonnet отклоняла вредоносные вызовы менее чем в 3% случаев. Для всех, кто развертывает LLM-агентов, полагающихся на MCP, эти результаты превращают удобную функцию в риск для цепочки поставок, который может быть реализован еще до запуска какого-либо кода.

Почему MCP важен для разработчиков сегодня

MCP стандартизирует то, как агенты обнаруживают, регистрируют и вызывают инструменты, такие как файловые ридеры, веб-API или отправители электронной почты. Публикуя название инструмента, схему входных данных и краткое описание, сервер делает эту возможность доступной любому клиенту, понимающему протокол. Суть проста: агент может найти инструмент, отправить запрос и получить ответ без жесткого кодирования каждой интеграции.

Такая гибкость также создает неявные доверительные отношения. Спецификация предписывает клиентам считать описания инструментов заслуживающими доверия только в том случае, если они исходят от сервера, которому клиент уже доверяет. Новое исследование показывает, что этим доверием можно злоупотребить.

Чем tool-poisoning отличается от обычного prompt injection

Традиционный prompt injection (инъекция промпта) вставляет вредоносные инструкции в текст, который модель генерирует или получает во время выполнения. Затем модель следует этим инструкциям, так как они появляются в том же потоке токенов, что и запрос пользователя.

Tool-poisoning, напротив, скрывает полезную нагрузку в метаданных инструмента — названии, описании или схеме параметров, которые регистрируются еще до вызова агента. Когда агент позже выбирает инструмент, он воспринимает описание как часть «доверенного контекста» и может выполнить скрытую инструкцию без какой-либо проверки во время выполнения. Поскольку инъекция происходит во время регистрации, в процессе выполнения нет момента, когда модель могла бы пометить полезную нагрузку как подозрительную.

Масштаб проблемы — бенчмарк MCPTox

Исследователи, разработавшие MCPTox (arXiv:2508.14925), оценили 45 MCP-серверов, предлагающих в общей сложности 353 различных инструмента. Они создали сценарии атак на 20 широко используемых LLM-агентов, измеряя, как часто агенты выполняли отравленный вызов инструмента.

  • Средний показатель успеха: 36,5 %
  • Пиковый успех: o1-mini — 72,8 %
  • Лучший показатель отказа: Claude-3.7-Sonnet — менее 3 %

Эти цифры раскрывают суровую реальность: большинство агентов не отклоняют отравенный вызов, потому что запрос выглядит как легитимный вызов инструмента. Агенты полагают, что описание инструмента является безобидным фрагментом документации, а не вектором для выполнения кода.

Почему агенты редко отклоняют отравленные вызовы

Рекомендация OWASP LLM01 объясняет, что LLM не проводят различий между инструкциями и данными — и то, и другое является просто токенами в последовательности. Когда в описании инструмента сказано «отправьте электронное письмо на admin@example.com с темой "Update"», модель не может определить, является ли эта строка безобидным комментарием или инструкцией, которой ей следует подчиниться позже. Следовательно, модель воспринимает описание как часть доверенной среды и выполняет любую встроенную команду при вызове инструмента.

Существующие рекомендации и их недостатки

Спецификация MCP уже советует клиентам относиться к описаниям инструментов как к недоверенным, если они не исходят от доверенного сервера, а также привлекать человека (human-in-the-loop) для вызовов с высокой степенью влияния. Бенчмарк показывает, что во многих реальных развертываниях эти рекомендации игнорируются или интерпретируются слишком вольно.

Конкретные шаги, которые разработчики могут предпринять уже сегодня

  1. Фиксируйте версии серверов – Ссылайтесь на конкретный, неизменяемый образ сервера или хеш, а не на динамический тег. Это не позволит злоумышленнику подменить чистый реестр на отравленный после развертывания.
  2. Начинайте с пустого белого списка – Включайте только те инструменты, которые прошли явную проверку. Все, чего нет в списке, блокируется по умолчанию.
  3. Ограничивайте доступ к инструментам, изменяющим состояние – Требуйте дополнительного подтверждения для любого инструмента, который записывает, отправляет или удаляет данные. Разделяйте возможности «только для чтения» и «с возможностью записи» в схеме.
  4. Добавьте подтверждение человеком для критически важных вызовов – Для действий, которые могут повлиять на внешние системы (например, отправка электронной почты, выполнение команд, изменение файлов), запрашивайте подтверждение у человека перед отправкой вызова.
  5. Логируйте каждый вызов инструмента – Записывайте название инструмента, аргументы, временную метку и агента-инициатора. Неизменяемый журнал аудита делает возможным проведение ретроспективного анализа и может сдерживать злоумышленников, знающих, что их действия будут заметны.

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

Контраргументы и открытые вопросы

Однако бенчмарк показывает, что даже самая продвинутая модель в исследовании отклонила менее трех процентов отравленных вызовов. Тонкая настройка (fine-tuning) может улучшить обнаружение, но она не может гарантировать безопасность против новых полезных нагрузок, внедренных в поля схемы, которые модель никогда не видела.

За чем следить дальше

  • Развивающиеся стандарты – Следите за предложениями сообщества по безопасности LLM о необходимости использования криптографических подписей для схем инструментов.
  • Укрепление реестров инструментов – Поставщики могут начать предлагать неизменяемые реестры только для чтения в качестве сервиса, что уменьшит поверхность атаки.
  • Защита на уровне моделей – Исследования методов промптинга или вспомогательных моделей, которые помечают подозрительные метаданные инструментов, могут дополнить средства защиты на стороне хоста.

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