В октябре 2026 года Ars Technica описала уязвимости в агентах Google и ещё четырёх организаций, которые эксплуатируют доверие внутри MCPModel Context Protocol — открытый стандарт, которым приложения и агенты ИИ обмениваются данными внутри внутренней сети. За пять месяцев уязвимости признали пять организаций, у которых мало общего, кроме использования AI-агентов.
Атака — особая форма prompt injectionвнедрение инструкций в данные, которые обрабатывает модель, чтобы она выполнила чужие указания: цель не LLMбольшая языковая модель, генерирующая текст по входному запросу, а конкретный агент — например, для перевода или анализа данных. Такой агент пересылает вредоносные инструкции дальше по цепочке, потому что следующий агент доверяет первому.
Что именно произошло
Независимый исследователь Syed Anas Mohiuddin тестировал агентов организаций, включая Google, JP Morgan Chase, Weviate, Rapid7, межминистерский цифровой директорат французского правительства и федеральное правительство США. Его proof-of-concept атаки используют разрывы доверия в MCP.
Уязвимость в сети Rapid7 — CVE-2026-97228 с рейтингом опасности 2.7 из 10 — Rapid7 исправила в прошлом месяце. Уязвимость Google оказалась серьёзнее, рейтинг 8: MCP toolbox для баз данных (googleapis/mcp-toolbox) инициализировал HTTP-клиент без политики CheckRedirect — набора настроек, управляющих обработкой ошибок и перенаправлений URL, — и не проверял целевые IP-адреса. Подделанный параметр пути мог заставить toolbox следовать редиректу на внутренний endpoint и отправлять запросы от имени атакующего.
Syed называет класс атак protocol pivotingмногошаговая атака, при которой злоумышленник получает начальный доступ через один протокол, эксплуатирует доверие между протоколами и повышает привилегии через другой. Повышение привилегий здесь возможно потому, что каждый протокол проверяет только свою «входную дверь», а доверие или авторизация теряются при передаче задачи между ними: приложение или сервер через MCP поручает задачу агенту, а тот пересылает вредоносные инструкции другому агенту уже другим способом связи. Markus Vervier из X41 D-Sec считает более точным термином indirect prompt injectionкосвенная инъекция промпта, при которой вредоносные инструкции приходят не напрямую от пользователя, а из внешнего контента или другого протокола и отмечает, что переход между протоколами не обязателен для работы атаки.
Как устроен MCP
MCP — открытый стандарт для подключения AI-приложений к внешним системам; создан David Soria Parra и Justin Spahr-Summers. Спецификация 2025-06-18 определяет его как открытый протокол для интеграции LLM-приложений с внешними источниками данных и инструментами, использующий JSON-RPC 2.0текстовый формат обмена сообщениями, где каждая сторона шлёт запросы с идентификатором и именем метода и получает ответы с тем же идентификатором для связи между хостами, клиентами и серверами. Именно на этом формате строятся все сообщения протокола, поэтому атака, внедряющая инструкции в одно из них, проходит по той же цепочке, что и обычные вызовы.
Сообщения определены типами: запрос, уведомление или ответ. Запрос несёт идентификатор и имя метода, уведомление — только имя метода без идентификатора, ответ — идентификатор и результат.
Протокол предоставляет примитивы:
- Resources — ресурсы, которые клиент перечисляет и читает по URI; сервер может уведомлять об изменении списка.
- Prompts — шаблоны подсказок: клиент запрашивает конкретную подсказку с аргументами и получает сообщения с ролями user/assistant.
- Tools — вызываемые инструменты: клиент перечисляет их и вызывает с именем и аргументами; результат содержит содержимое, опциональный structuredContent и флаг ошибки.
- Sampling — запрос от сервера к клиенту на генерацию сообщения моделью; клиент сам выбирает модель и должен информировать пользователя для проверки запроса и ответа. Сервер обращается к клиенту, потому что сам не имеет доступа к модели: генерацию выполняет клиентское приложение, которое и решает, какую модель использовать.
- Roots — запрос от сервера к клиенту за списком корневых URI, чтобы понять, с какими каталогами или файлами работать.
- Elicitation — запрос дополнительной информации у пользователя в двух режимах: форма с ограниченной схемой или переход по ссылке.
При инициализации соединения клиент отправляет запрос initialize с набором поддерживаемых возможностей, сервер отвечает своим набором. Оба набора описаны как открытые: любая сторона может объявить собственные дополнительные возможности. Помимо известных полей, в обоих интерфейсах есть поле experimental для произвольных нестандартных возможностей и поле extensions для опциональных расширений MCP, ключи которых должны следовать правилам именования с обязательным префиксом: experimental — это собственные возможности стороны, не описанные в спецификации, а extensions — расширения самого протокола. Известные возможности сервера включают logging, completions, prompts, resources и tools.
Уведомления — сообщения без ответа, которые сервер отправляет клиенту вне контекста конкретного запроса. Обновление прогресса длительного запроса идёт внеполосно. Уведомление об изменении ресурса отправляется только для тех ресурсов, на которые клиент подписался. Уведомление об изменении списка инструментов может быть отправлено без предварительной подписки. Подписка оформляется отдельным запросом, где каждый тип уведомлений включается отдельно, и сервер не должен слать типы, которые клиент не запросил.
Почему это структурная проблема
MCP называют «самым рискованным протоколом, о котором вы не слышали»: он новый и уже повсюду, но недостаточно протестирован и укреплён. Риск создают конкретные механизмы.
MCP-серверы хранят учётные данные для каждого агента, а агенты построены так, что доверяют любому другому внутреннему агенту. Поэтому эксплойт, который был бы отклонён LLM, проходит. Защитные ограничения внутри специализированных агентов, если они вообще есть, часто слабые и передают инструкции дальше по цепочке.
Douglas McKee из Rapid7 описывает цепочку так: текст внедряется в контент, агент читает его и передаёт другому агенту как обычную делегированную задачу, а второй выполняет её, потому что доверяет передавшему. Каждый протокол строился в предположении, что живёт сам по себе, поэтому каждый проверяет свою входную дверь, пока никто не смотрит за коридором между ними. Доверие или авторизация теряются при переходе между протоколами.
Сам протокол не может обеспечить эти принципы безопасности на уровне спецификации: реализаторы должны сами встраивать согласие и авторизацию. Аннотации инструментов — лишь подсказки и не гарантируют достоверного описания поведения, поэтому клиенты не должны принимать решения об использовании инструмента на их основе.
Что меняется на практике
Небезопасной становится архитектура, в которой агенты доверяют друг другу и передают задачи без проверки. Взамен предлагается вернуться к принципу нулевого доверия: узлы должны требовать авторизации перед чувствительными операциями с другими узлами. Всё, что передаётся от LLM к инструменту, следует рассматривать как ввод от постороннего из интернета.
Для защиты от SSRFserver-side request forgery — уязвимость, заставляющая сервер делать неавторизованные сетевые запросы предлагается применять allow-list диапазонов IP и block-списки. Исправление Google отклоняет небезопасный базовый URL при запуске, а не при первом запросе. По оценке исследователей, это больше работы, чем сделало большинство MCP-серверов.
Спецификация MCP указывает, что хосты должны получать явное согласие пользователя перед вызовом любого инструмента и перед раскрытием данных серверам. Инструменты представляют собой произвольное выполнение кода и должны рассматриваться с осторожностью.
Ограничения и открытые вопросы
Организации в спешке построения агентных архитектур отказались от принципа нулевого доверия. Каждый протокол проектировался в расчёте на изолированную работу, поэтому стыки между ними не контролируются, а при передаче между протоколами доверие или авторизация теряются.
Метод остаётся разновидностью косвенной инъекции промпта, которую, по словам Vervier, неожиданно и трудно предотвратить в общем случае. То, что вредоносный промпт может приходить из другого протокола (например, A2AПротокол Google Agent-to-Agent, используемый для делегирования задач между агентами.) и проявляться при использовании через другой, не строго обязательно для работы атаки.
В качестве альтернативы для делегирования задач между агентами упоминается Google Agent-to-Agent (A2A). Он упоминается как часть цепочки атаки «protocol pivoting».
Спецификация MCP не описывает процедур миграции для уже развёрнутых агентов и не содержит сведений о влиянии уязвимости на совместимость существующих реализаций.
