Атака с отложенным предательством: как взломанный MCP-сервер сначала завоёвывает доверие агента, а потом бьёт

ИИ-агенты всё активнее подключают к внешним инструментам через протокол MCP — а значит, поверхность атаки смещается туда, куда никто не смотрел: в сам инструмент. Новая работа группы исследователей во главе с Дэниелом Такаби описывает класс атак TrustShift, где скомпрометированный сервер сначала неделями работает безупречно, «приручая» агента, а потом переключается на вредоносные ответы. На фронтирных моделях атака срабатывает почти в семи случаях из десяти — и предложенная защита снижает эту долю лишь наполовину.

Когда инструмент становится врагом

Чтобы понять, почему TrustShift — это сдвиг в ландшафте угроз, нужно вспомнить, как сегодня устроена безопасность ИИ-агентов. В основном она сосредоточена на двух точках. Первая — промпт пользователя: отсюда идут прямые и косвенные инъекции, когда злоумышленник прячет вредоносную инструкцию в тексте, который агент прочитает. Вторая — транспорт: перехват и подмена данных на пути между агентом и сервером, классический «человек посередине». Под обе угрозы построены защиты: фильтры промптов, шифрование, подписи.

Но обе модели угроз исходят из того, что сам инструмент, к которому агент обращается, честен. Это допущение стало удобным ровно потому, что в ноябре 2024 года Anthropic представила Model Context Protocol — открытый стандарт подключения LLM-агентов к внешним сервисам, данным и инструментам. Меньше чем за два года MCP превратился в фактический стандарт индустрии: публичная экосистема выросла до тысяч серверов, а внутри крупных компаний появились корпоративные шлюзы, агрегирующие их сотнями. Смежная работа команды PayPal (препринт arXiv:2608.23992, система SCOUT) даёт масштаб: более 200 серверов и свыше 2000 инструментов за одним шлюзом. Каждый из этих инструментов — потенциальный источник ответов, которым агент доверяет по умолчанию.

TrustShift разворачивает эту архитектуру доверия против неё самой. Идея проста и потому неприятна: скомпрометированный сервер не атакует сразу. Он проходит фазу «кондиционирования» — отвечает корректно, быстро, предсказуемо. Агент начинает полагаться на него: выстраивает маршруты вызовов, включает его результаты в рассуждения, перестаёт перепроверять. У атаки есть измеримый параметр — «горизонт доверия», порог числа взаимодействий, после которого скепсис агента к данному источнику заметно снижается. Пересёк этот порог — и сервер переключается на вредоносный режим.

Спящий агент наоборот

В корпоративной безопасности есть давно известный тип угрозы — инсайдер, человек внутри периметра, который пользуется легитимным доступом во вред. Есть и разведывательная метафора «спящего агента», годами живущего легендой, прежде чем его активируют. TrustShift объединяет обе, только внутрь периметра пускают не человека, а программный эндпоинт, которому агент делегирует часть своих решений.

Ключевое свойство атаки — её обход защит носит временной, а не синтаксический характер. Традиционные фильтры ищут вредоносные паттерны в данных: подозрительные строки, инструкции, сигнатуры. Но у TrustShift на любой конкретный момент времени трафик может быть абсолютно чистым. Статический анализ перед деплоем видит только честную фазу — потому что честная фаза и есть всё, что сервер показывает. Аудит кода? Если переключение управляется внешним триггером или счётчиком вызовов, вредоносная ветка может быть замаскирована или вовсе подгружаться позже. Middleware-фильтр на границе шлюза? Он проверяет каждый ответ по отдельности, а атака живёт в последовательности: сто честных ответов, сто первый — с payload.

Авторы предлагают таксономию из девяти вариантов TrustShift — по трём механизмам исполнения и трём целям. Механизмы: структурное нарушение (сервер ломает формат ответа, сбивая пайплайн агента), семантическая коррупция (формат чист, но содержание отравлено — фальшивые факты, подменённые ссылки, искажённые рекомендации) и расширение области (сервер пытается выманить у агента действия за пределами его полномочий). Цели: срыв работы системы, эксфильтрация данных либо комбинация обеих. Для экспериментов построен языконезависимый движок атак, реализующий варианты в виде реальных скомпрометированных MCP-серверов в четырёх прикладных доменах.

Цифры, которые не радуют

Результаты измерений — самая цитируемая часть работы, и к ним стоит относиться с двойным вниманием. На фронтирных проприетарных и открытых моделях средняя доля успешных атак составила 69,5%. Это означает: примерно в семи случаях из десяти агент, пройдя фазу кондиционирования, проглатывает вредоносный payload, не заподозрив подмены. Для технологии, которой делегируют покупки, бронирования и работу с корпоративными данными, цифра выглядит тревожно.

Предложенная авторами защита SHIELD — многоуровневый runtime-аудит на транспортной границе MCP. Идея в том, чтобы перестать искать «плохое» и начать отслеживать отклонения от «обычного»: в периоды заведомо чистой работы («окна доверия») система выучивает поведенческие базовые линии сервера — как выглядят его типичные ответы, их структура, распределения. После переключения поведение сервера меняется, и аудит должен заметить разрыв с базовой линией без какого-либо внешнего оракула истины.

SHIELD снижает долю успешных атак с 69,5% до 42,7%. Это существенное улучшение — и одновременно честное признание неполноты: более четырёх атак из десяти всё равно проходят. Защита, после которой противник сохраняет шансы выше сорока процентов, — не решение проблемы, а первый рубеж. К этому добавляются открытые вопросы, которых в работе не закрыть в принципе: насколько SHIELD устойчив к адаптивному противнику, который знает о механизме аудита и подстраивает payload под базовую линию; каковы накладные расходы в продакшене — латентность на каждом вызове и частота ложных срабатываний, которые в системе на 2000 инструментов быстро превращаются в шум для дежурной смены.

Почему это бьёт по деньгам

Картину усиливает третья работа из той же волны препринтов — систематический анализ безопасности протокола AP2 (arXiv:2608.23858), платёжного стандарта для ИИ-агентов, разработанного Google. В AP2 транзакции авторизуются криптографически подписанными мандатами: агент получает от пользователя подписанное разрешение на покупку с заданными параметрами. Казалось бы, вот она, формальная гарантия. Но анализ показывает: валидные подписи не защищают транзакцию, если скомпрометирован контекст, предшествующий авторизации, — включая вызовы MCP-инструментов.

Логика прозрачна. Подпись гарантирует, что мандат не подделан. Она не гарантирует, что агент решил подписать именно этот мандат на основе правдивой информации. Если отравленный инструмент подсунул агенту ложную цену, подменённого продавца или фальшивое описание товара, агент честно, с валидной подписью, санкционирует невыгодную или вредоносную сделку. Криптография защищает форму, TrustShift атакует содержание. Авторы построили тестбед из пяти архитектур агентных платежей и каталог из 48 угроз, восемь из которых оценены как высокие.

Вместе три работы складываются в цепочку: экосистема MCP выросла до продакшен-масштаба (SCOUT), серверы в этой экосистеме могут предательски переключаться (TrustShift), а протоколы, по которым агенты тратят деньги, не защищены от отравленного контекста даже при идеальных подписях (AP2). Это не три разрозненные находки — это контур одной проблемы: доверие в агентных системах пока выдаётся статически, при подключении, а потребляется динамически, при каждом вызове.

Что с этим делать уже сейчас

Для команд, которые уже развернули MCP-шлюзы, из этих работ следует несколько практических выводов — при том что готового «лекарства» пока нет.

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

Второй: деградация привилегий важнее периметра. Если сервер не нужен агенту для платёжных действий, эти действия не должны зависеть от его ответов. Критичные операции — деньги, доступ к данным, отправка сообщений — стоит требовать подтверждения из независимых источников или человеком, особенно в свете выводов по AP2: подпись мандата не спасает от отравленного контекста.

Третий: выучить уроки классической защиты от инсайдеров. Ограничение области видимости, ротация доверия, разделение полномочий между несколькими инструментами, чтобы ни один не был единственным источником правды, — всё это давно придумано для людей и теперь переносится на агентные инфраструктуры почти без изменений.

Четвёртый: закладывать стоимость аудита в архитектуру заранее. SHIELD-подобные системы — это латентность и ложные срабатывания; добавлять их в постфактум в шлюз на сотни серверов будет больно. Лучше проектировать шлюз с точками наблюдения изначально.

Важные оговорки

Все три работы — свежие препринты arXiv, датированные августом 2026 года. Они не прошли рецензирование, и их результаты следует проверять по открытым репозиториям авторов, когда те будут опубликованы (на момент подготовки статьи доступность кода TrustShiftProbe и SHIELD не подтверждена). В аннотациях не указано, на каких именно моделях измерены 69,5% и 42,7% — только «фронтирные проприетарные и открытые», что затрудняет сравнение с другими исследованиями. Реальных зафиксированных случаев TrustShift-подобных атак в дикой природе пока нет: это продемонстрированная в тестовой среде уязвимость, а не описание состоявшейся кампании. И наконец, устойчивость SHIELD к адаптивному противнику — открытый вопрос самой работы.

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